similar to: flac, UTF-8 and Windows

Currently MSVS can build dynamic libraries (libFLAC_dynamic.dll, libFLAC++_dynamic.dll), static libraries (libFLAC_static.lib, libFLAC++_static.lib) and executables (flac.exe, metaflac.exe, etc). All executables are statically linked to libFLAC. It's possible to create a flac.exe that is linked to thr libFLAC DLL file, but it requires manual editing of various projects in the FLAC solution.

So far I can see three ideal solutions of this issue: 1) Make Unicode support a part of the libFLAC API. In this case there will be no need in separate -lFLAC -lwin_utf8_io options, just -lFLAC will be needed. 2) Remove the dependency between libFLAC and win_utf8_io. In this case win_utf8_io will be linked statically to 1st-party apps, like other libraries from src/share:

I have been doing some heavy testing with the new FLAC version, and I found that CreateFile function in grabbag had been left out of UTF-8 treatment at some point. This causes re-encoding an existing flac to the same name to break the file if it contains non-ascii characters. Attached patch fixes this. -------------- next part -------------- diff --git a/include/share/win_utf8_io.h

First, this dependency exists only on Windows. For obvious reasons such dependency cannot exist on Linux/FreeBSD/OSX/etc. Previous versions (up to 1.2.1) didn't support Unicode filenames on Windows. And then it was decided to add such support. Windows uses UTF-16, where characters have 16-bit wchar_t type. LibFLAC receives strings only via char*. So one way to add Unicode support is to add

If anybody wants to know: current flac.exe is not compatible with Windows 2000. The only reason for this is the following line from get_utf8_argv() function from src/share/win_utf8_io/win_utf8_io.c: if (wgetmainargs(&wargc, &wargv, &wenv, 1, &i) != 0) return 1; Windows 2000 has slightly older version of msvcrt.dll, and this check always fails. I found an explanation about it

lvqcl wrote: > When I compile flac project with MSYS/MinGW-w64, I can see two files: > libFLAC.a and libFLAC-static.a. The only difference between them > is that libFLAC.a contains functions from win_utf8_io. > But 'make install' adds libFLAC.a into /local/lib, not libFLAC-static.a. Thank you for checking this. I've always had trouble with Autotools on Windows, even when

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01.04.2013 16:26, LRN wrote: > On 01.04.2013 14:40, Erik de Castro Lopo wrote: >> Hi all, > >> The latest pre-release is here: > >> http://downloads.xiph.org/releases/flac/beta/flac-1.3.0pre3.tar.xz > >> > flac-1.3.0pre3/include/share/compat.h:146:31: fatal error: > share/win_utf8_io.h: No such file or

On Tue, Sep 20, 2011 at 11:52 AM, Nikola Smiljanic <popizdeh at gmail.com> wrote: > I spent some more time on this. My idea was to use functionality from > llvm::sys::fs like file_status instead of stat struct, but as it turns out > this is not really possible. file_status structure is not a replacement for > stat, nor are there functions inside llvm::sys::fs that can replace

Hi, I've started working on libogg2 support in liboggz and Tremor support in libfishsound. I'm running into some problems with namespace clashes. Specifically, each of libogg, libogg2 and libvorbisidec (Tremor) define conflicting ogg_* symbols and declare incompatible ogg_* types in their headers. While I understand that a dedicated Ogg Vorbis decoder would only need to use one of these

lvqcl wrote: > all I can suggest > is to apply this patch, then fix issues if they'll happen after > this. But seriously, as a matter of fact win_utf8_io is a part of libFLAC. Functions from libFLAC call functions from win_utf8_io... For example: FLAC__stream_decoder_init_file() calls init_file_internal_() that calls flac_fopen() that is defined as fopen_utf8(). Currently

lvqcl wrote: >>> Win_utf8 stuff should not be included in libflac since it's only to be >>> used by the flac.exe frontend. It is not needed by other programs nor >>> would they benefit from it without doing the extra work of converting >>> their ansi filenames and functions to utf-8. >>> >>>> Version 2 of my patch attached, which fixes

Hopefully the last patch from me to UTF-8 issues. Metaflac can now print all console supported characters from tags on the screen. It also fixes metaflac to be able to import its own exports back without non-ascii characters getting mutilated. And --no-utf8-convert now works properly with import and export commands. I updated my Windows binary archive with these changes for any interested

Hugo Beauzée-Luyssen <hugo at beauzee.fr> wrote: > --- > src/share/win_utf8_io/win_utf8_io.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/src/share/win_utf8_io/win_utf8_io.c > b/src/share/win_utf8_io/win_utf8_io.c > index c61d27f3..1437b41e 100644 > --- a/src/share/win_utf8_io/win_utf8_io.c > +++ b/src/share/win_utf8_io/win_utf8_io.c >

OK since this approach makes sense I'll shoot with my questions :) 1. Where should get_utf8_argv go and is the name of this function OK? Right now the function is inside llvm::sys::fs namespace because I need access to Windows.h, should I leave it there. 2. get_utf8_argv allocates new char** representing utf8 argv, should I deallocate this inside driver.cpp, use std::vector<std::string>

Hi all, I tried building the latest flac.git on Windows with MinGW just today, and got the following build error: (I had to copy-paste this 'by hand', so there might be a few small mistakes) > CCLD utf8/libutf8.la > CC win_utf8_io/win_utf8_io.lo > win_utf8__io/win_utf8_io.c:266:13: error: static declaration > of 'set_filename_utf8' follows

Currently it is required to include share/compat.h before inclusion of share/win_utf8_io.h. That's because of print_console() declaration: its 3rd argument have type 'uint32_t' which is defined in share/compat.h. So share/win_utf8_io.h depends on share/compat.h which in turn includes share/win_utf8_io.h. Not a problem but it's a bit ugly imho. Actually, the 3rd argument of

On Tue, Sep 20, 2011 at 4:15 PM, Nikola Smiljanic <popizdeh at gmail.com> wrote: > OK since this approach makes sense I'll shoot with my questions :) > 1. Where should get_utf8_argv go and is the name of this function OK? Right > now the function is inside llvm::sys::fs namespace because I need access to > Windows.h, should I leave it there. I don't think it belongs

get_utf8_argv() function calls LoadLibrary to load msvcrt.dll, but doesn't call FreeLibrary() if it returns an error. Currently both flac.exe and metaflac.exe exit immediately if get_utf8_argv() fails, so it's not a big problem. But IMHO it's better no to have leaked resources anyway. -------------- next part -------------- A non-text attachment was scrubbed... Name: win_utf_io.patch

Here's a new patch that fixes all the issues mentioned before. Note that this isn't final, I didn't want to replace all calls to ::stat so that it's easier to review. I have only one more questions: 1. _wopen accepts _stat64i32 instead of stat structure. These two are exactly the same, the only difference is that stat uses time_t and _stat64i32 uses __time64_t (time_t is a

Hi all, Since I didn''t get any takers on the win32-ole rewrite I thought I''d take a stab at starting it. Here''s what I''ve got so far (along with some extra constants in Windows::COM only in CVS), but the call to CoCreateInstance() isn''t working. I''m not sure if I''m dealing with the IDispatch interface properly: # win32/ole.rb require