August 2002 - Wine-Devel - list.winehq.org

removing mp3 code

by Marcus Meissner

Hi, Apparently distributing even mp3 decoders is not royaltee free anymore, according to the slashdot thread and the Thomson MultiMedia pages. So we probably should remove the msacm mp3 decoder we include. :( Ciao, Marcus

Aug. 29, 2002

Re: Need to know some macro values

by Dmitry Timoshkov

"Andriy Palamarchuk" <apa3a(a)yahoo.com> wrote: > one of the ERROR_ constant values you provided to me > looks suspicious: > > ERROR_AUDITING_DISABLED c0090001 > > All other error codes have much lesser values (the > biggest is 14011 - 0x36bb). The value for this error > code reminds me values for STATUS_ constants. > > Could you check if this is correct value? > Is it definend in header file with other ERROR_ > constants or with STATUS_ constants? The value above is the correct one. It's defined along with other ERROR_ constants in the WinXP DDK header file \WINDDK\inc\crt\winerror.h One more constant which has a 0xc00 prefix is #define ERROR_ALL_SIDS_FILTERED _HRESULT_TYPEDEF_(0xC0090002L) -- Dmitry.

Aug. 29, 2002

Keyboard Switching

by Supphachoke Suntiwichaya

Hi I made Thai keyboard layout and compiled but I can't switch to thai char.. I use th in X but it not support X thai key input.. Help me.. Serious..! MrChoke -- ========================================== Supphachoke Suntiwichaya WWW:http://jedi.links.nectec.or.th/~mrchoke UIN:10509387 TEL:+66-1-5408959 Love Me Love Linux.... ===========================================

Aug. 29, 2002

Press: A couple articles about Wine products

by Francois Gouget

I have added a couple entries to WineHQ's press references: http://www.winehq.com/about/index.php?press Let me know if you know of other Wine-related articles or announcements that you think would be worth mentioning there. * August 19, 2002 - TransGaming TransGaming and TimeGate Partner to Port KOHAN http://www.transgaming.com/news.php?newsid=43 * August 14, 2002 - CodeWeavers CodeWeavers CrossOver Office Wins 'Best Desktop Office Solution' At LinuxWorld 2002 http://www.codeweavers.com/about/press_releases/?id=20020814 * August 13, 2002 - CodeWeavers CodeWeavers Unveils CrossOver Office Server Edition for Solaris and Linux thin clients http://www.codeweavers.com/about/press_releases/?id=20020813 * August 6, 2002 - DesktopLinux CrossOver Office 1.2 review: Quicken and QuickBooks and Visio, oh my! (on Linux, that is) http://www.desktoplinux.com/articles/AT2282537026.html -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ f u kn rd ts, ur wy 2 gky 4 ur wn gd.

Aug. 29, 2002

Re: CVS wine/ dlls/gdi/win16drv/font.c dlls/gdi/win16d ...

by Duane Clark

Xilinx again:-) This patch http://cvs.winehq.com/patch.py?id=1030574123182059719300927 causes a bunch of error messages when scrolling the main window in fpga_editor. The scrolling however works fine. This is repeated for every "sliver" (or whatever that is called) as the window is scrolled. trace:nonclient:WIN_UpdateNCRgn hwnd 2005a [1e12] hrgn 0000, unc 0005, ncf 0 err:region:CombineRgn Invalid rgn=0000

Aug. 29, 2002

Re: WIN_Handle{16,32} questions

by Alexandre Julliard

Michael Stefaniuc <mstefani(a)redhat.de> writes: > Assuming that WIN_Handle{16,32} are not windows funtions (a search on > google has given only links to wine pages) i would do following: > - rename WIN_Handle{16,32} to HWND_{16,32} to make the naming consistent > to the othe handle conversions > - maybe remove the declaration of the two functions from include/win.h > (or at least don't include win.h where it isn't yet used) > - define HWND_16 as macro like the other HANDLE_16 macros and put it > directly in the files where it's needed The macros should stay in win.h, you must not define them in every single C file. For other dlls, you need to define them in some appropriate internal header of the dll. There shouldn't be more than one definition of the macros for each dll. > - HWND_32 has to do a little bit more work then the other HANDLE_32 > macros and i would keep it as function. This means it has to be > duplicated in every dll that needs it and one of the *16.c files in > the dll directory would be the place to put it in. Other dlls should probably do a simple 16->32 conversion like for other handles; you definitely don't want to duplicate WIN_Handle32 in the other dlls. -- Alexandre Julliard julliard(a)winehq.com

Aug. 29, 2002

Re: DOSFS_FindUnixName and "unix" filesystem (was: Re: (HELP) ...)

by Alexandre Julliard

Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> writes: > Now in /home/martin/Software, I have subdirectories "Wine" and "wine". > DOSFS_FindUnixName() uses "wine" because > a) DOSFS_ReadDir returns it first, > b) The DOS short names match (the Unix names obviously don't). > > Since "wine" is the wrong path, the search fails shortly after. > This happens even if I set the Filesystem type of drive Y: to "unix". I'd say that DOSFS_ToDosFCBFormat should fail when the file contains upper-case chars on a case-sensitive file system. This will probably make it impossible to access some files in certain cases though. I'm afraid it's not possible to support case-sensitive file systems 100% right given that Windows apps don't preserve case correctly. -- Alexandre Julliard julliard(a)winehq.com

Aug. 29, 2002

Re: Wine Ma os X port

by Francois Gouget

On Wed, 28 Aug 2002, Lionel Ulmer wrote: [...] > Anyway, if you do that, you would need to simulate also a full Linux kernel > on this emulator (as otherwise, on what system would emulated Wine run). Not necessarily. What you propose to do for Wine can be done for the C and X11 libraries. Then you get an emulator that lets you run x86 Linux applications on a PPC machine... including Wine. It is similar, though more complex, to FreeBSD's Linux emulation mode. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ $live{free} || die "";

Aug. 28, 2002

WIN_Handle{16,32} questions

by Michael Stefaniuc

Hello, while converting HWND to a void* i've seen that the WIN_Handle{16,32} functions were used (but not everywhere) to do the conversion HWND16 <--> HWND. WIN_Handle16 is declared and implemented in include/win.h and WIN_Handle32 is also declared in include/win.h but implemented in windows/win.c . I have used both functions with success in dlls/user/, windows/, controls/ but i would have to link to windows/win.c to make that work for other dlls too. Assuming that WIN_Handle{16,32} are not windows funtions (a search on google has given only links to wine pages) i would do following: - rename WIN_Handle{16,32} to HWND_{16,32} to make the naming consistent to the othe handle conversions - maybe remove the declaration of the two functions from include/win.h (or at least don't include win.h where it isn't yet used) - define HWND_16 as macro like the other HANDLE_16 macros and put it directly in the files where it's needed - HWND_32 has to do a little bit more work then the other HANDLE_32 macros and i would keep it as function. This means it has to be duplicated in every dll that needs it and one of the *16.c files in the dll directory would be the place to put it in. Comments? bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

Aug. 28, 2002

Re: DOSFS_FindUnixName and "unix" filesystem (was: Re: (HELP) ...)

by Andreas Mohr

On Wed, Aug 28, 2002 at 06:35:08PM +0200, Martin Wilck wrote: > I wrote on 2002-06-27: > > > > $ make test > > > /home/martin/Software/Wine/TMP/wine/miscemu/wine: cannot find 'tests/kernel32_test.exe.so' > > > make: *** [tests/alloc.ok] Fehler 1 > > > > Am I the only one with this problem? Or is it so trivial that I should > > have figured it out? > > I have finally figured this out. It has to do with some (intentional?) > DOSFS_FindUnixName() weirdness. > > My wine sources are in a directory /home/martin/Software/Wine/CVS/wine. > /home/martin is my Windows drive Y: > > Now in /home/martin/Software, I have subdirectories "Wine" and "wine". > DOSFS_FindUnixName() uses "wine" because > a) DOSFS_ReadDir returns it first, > b) The DOS short names match (the Unix names obviously don't). > > Since "wine" is the wrong path, the search fails shortly after. > This happens even if I set the Filesystem type of drive Y: to "unix". > > I guess this is the right thing to do on Windows-style file systems, > but should it be this way on a "unix" file system, too? > > The patch below does what I'd consider "sane" behaviour on Unix. > Alternatively, on a "unix" filesystem, one could search the whole > directory for exact matches, and try short names only if that fails. Well, if your patch makes sure that on a "unix" mapping (as opposed to "win95" !) we only lookup the *exact* case sensitive name instead of iterating through all sorts of case cases (heh ! :), then I guess your patch is right. I guess nobody really cared about having correct behaviour of the "unix" mapping mode. (since everybody should use "win95" for normal use anyway) -- The Declaration of Software Freedom: http://freedevelopers.net/freedomdec/index.php

Aug. 28, 2002