- wine-devel - winehq.org

IPersistFile::Load() broken ? + WineLib queries
by Subhobroto Sinha 22 Aug '03

22 Aug '03

Respected members of the forum, I have a few queries, which I have tabulated under: First: (1) With Windows apps doing smoothly on Wine, I had thought of creating a little program which would resolve Windows shortcut (.lnk) files. The program behaved perfectly with NO glitches whatsoever with the Wine package of <20030217-23> which came with my SuSE 8.2 as RPM. I had also downloaded the Wine20030408 tarball, which I duly patched upto v20030813 (the latest), removed the installed RPM package and wineinstalled the source for Wine20030813. (The improvements made was immediately apparent, and I could run Norton 2000 Update Agent as well as install my own .msi packages !) However, my program (which resolved shortcuts) failed to work anymore ! Previously, to compile the source using WineLib(from Wine<20030217-23>) I had to make the following changes in my source code: (1) Replace IShellLink with IShellLinkA (2) Include the header "shlguid.h" With the latest WineLib(from Wine20030813), I did NOT have to make ANY changes to the original source however, but though the source compiled without any issues, it failed at the IPersistFile::Load() call ! To make debugging easier for you folks, I have prepared a ZIP Package called "WineShellDriverPak.zip" which contains the following software: (1) The source code "WineShellDriver.cpp" . (This compiles on VC6 AND WineLib without ANY modification) (2) The VC6 compiled EXE file "WineShellDriver.EXE". To make this program work, just pass the .lnk filename as command line arg, and if successful, it will write out the resolved path in a text file called "WineWorksResolvedPath.dat" (This ALSO failed to work under Wine20030813) (3) The previous "working" (it does NOT work anymore..) WineLib form ("linkresolve.exe.so") of this code. This had been compiled using Wine<20030217-23> which came with SuSE 8.2. It used to work fine. (4) A shortcut (Notepad.lnk) file for testing. It should resolve to "C:\WINNT\notepad.exe" Is it due to a BUG in the latest release, or did I do something wrong ? Second: (2) How do I REDUCE the size of WineLib compiled apps ? Those source code which compile to ~35KB using VC6, compile to ~900KB using WineLib. Currently, I have to "strip" the WineLib compiled apps, but often, this breaks them ! Any suggestions ? (3) How do I log the output to a file say "Winelog.log" of a command like: "$ wine --debugmsg +all winelibapp.exe.so -- commandline args" Redirection (>>) or pipes (|less) only captues the output given by "winelibapp.exe.so" and NOT that given by Wine. (I currently run Wine from the commandline using XTerm) Thank you for your time. Please keep up the good work ! Cheers Subhobroto Sinha ---------------------------- Help us to free ourselves! __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

2 1

Re: [Foxgui-users]Re: Wine fixes (1)
by Dimitrie O. Paun 22 Aug '03

22 Aug '03

On August 21, 2003 12:07 am, jeroen wrote: > > Ha! Well, I can't say that I disagree with you; however, if you're > actually shipping applications for Windows, you'd better test on the > real thing..... One thing the emulation won't tell you is whether > any oddball device driver issues crop up. This particularly happens > with OpenGL. I have had to add special directives to avoid hardware > accelerated OpenGL on Windows so that broken drivers may be circumvented. > > Interactions with other applications also must be tested; for example, > clipboard support. You will discover the weirdest things... It's a nice compliment (thank you!) to assume that Wine is such a good implementation of the Win32 API that one would assume to do no testing on Windows :) Unfortunately, we haven't gone that far (yet ;) ). Wine is good enough at the moment to allow for some development, but you will definitely run into problems, and you _will_ need to test the result on Windows, as you say. But regardless of utility, I still maintain a Wine port would be cool :) -- Dimi.

1 0

Re: PATCH - winnt.h move non-standard language IDs to wine/port.h
by Jonathan Wilson 22 Aug '03

22 Aug '03

Looks good. This should enable apps like notepad to build out of the box on win32 with MingW or VC headers assuming port.h is copied over.

1 0

IPersistFile::Load() broken ? + WineLib queries
by Subhobroto Sinha 21 Aug '03

21 Aug '03

Respected members of the forum, I have a few queries, which I have tabulated under: First: (1) With Windows apps doing smoothly on Wine, I had thought of creating a little program which would resolve Windows shortcut (.lnk) files. The program behaved perfectly with NO glitches whatsoever with the Wine package of <20030217-23> which came with my SuSE 8.2 as RPM. I had also downloaded the Wine20030408 tarball, which I duly patched upto v20030813 (the latest), removed the installed RPM package and wineinstalled the source for Wine20030813. (The improvements made was immediately apparent, and I could run Norton 2000 Update Agent as well as install my own .msi packages !) However, my program (which resolved shortcuts) failed to work anymore ! Previously, to compile the source using WineLib(from Wine<20030217-23>) I had to make the following changes in my source code: (1) Replace IShellLink with IShellLinkA (2) Include the header "shlguid.h" With the latest WineLib(from Wine20030813), I did NOT have to make ANY changes to the original source however, but though the source compiled without any issues, it failed at the IPersistFile::Load() call ! To make debugging easier for you folks, I have prepared a ZIP Package called "WineShellDriverPak.zip" which contains the following software: (1) The source code "WineShellDriver.cpp" . (This compiles on VC6 AND WineLib without ANY modification) (2) The VC6 compiled EXE file "WineShellDriver.EXE". To make this program work, just pass the .lnk filename as command line arg, and if successful, it will write out the resolved path in a text file called "WineWorksResolvedPath.dat" (This ALSO failed to work under Wine20030813) (3) The previous "working" (it does NOT work anymore..) WineLib form ("linkresolve.exe.so") of this code. This had been compiled using Wine<20030217-23> which came with SuSE 8.2. It used to work fine. (4) A shortcut (Notepad.lnk) file for testing. It should resolve to "C:\WINNT\notepad.exe" Is it due to a BUG in the latest release, or did I do something wrong ? Second: (2) How do I REDUCE the size of WineLib compiled apps ? Those source code which compile to ~35KB using VC6, compile to ~900KB using WineLib. Currently, I have to "strip" the WineLib compiled apps, but often, this breaks them ! Any suggestions ? (3) How do I log the output to a file say "Winelog.log" of a command like: "$ wine --debugmsg +all winelibapp.exe.so -- commandline args" Redirection (>>) or pipes (|less) only captues the output given by "winelibapp.exe.so" and NOT that given by Wine. (I currently run Wine from the commandline using XTerm) Thank you for your time. Please keep up the good work ! Cheers Subhobroto Sinha ---------------------------- Help us to free ourselves! __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

1 0

Can someone take a look at msvcmaker for me?
by Steven Edwards 21 Aug '03

21 Aug '03

I have tried using MSYS perl and ActiveState perl and both give me the following error: isolation@PH33R /g/src/wine-dev/wine $ ./tools/winapi/msvcmaker Global symbol "$wine_dir" requires explicit package name at ./tools/winapi/msvcm aker line 52. Global symbol "$wine_dir" requires explicit package name at ./tools/winapi/msvcm aker line 116. Global symbol "$wine_dir" requires explicit package name at ./tools/winapi/msvcm aker line 440. Global symbol "$wine_dir" requires explicit package name at ./tools/winapi/msvcm aker line 1031. Global symbol "$wine_dir" requires explicit package name at ./tools/winapi/msvcm aker line 1091. Global symbol "$wine_dir" requires explicit package name at ./tools/winapi/msvcm aker line 1141. Global symbol "$wine_dir" requires explicit package name at ./tools/winapi/msvcm aker line 1180. Global symbol "$wine_dir" requires explicit package name at ./tools/winapi/msvcm aker line 1217. Global symbol "$wine_dir" requires explicit package name at ./tools/winapi/msvcm aker line 1234. Execution of ./tools/winapi/msvcmaker aborted due to compilation errors. isolation@PH33R /g/src/wine-dev/wine

1 0

Re: patch 6
by puoti＠inwind.it 21 Aug '03

21 Aug '03

My email will never change. My email provider is the biggest in Italy, and it's very improbable that it will ever close, and even if I don't use it as an ISP any more, I will never change my email until I can use my current one. Of course, if you don't want email addresses in the source, just ignore that part of the patch.

1 0

Re: Build broken due to -lpthread
by Gerald Pfeifer 21 Aug '03

21 Aug '03

On Thu, 21 Aug 2003, Ulrich Spoerlein wrote: >> So perhaps we ought to use -lc_r instead of -lc and omit -lpthread on >> FreeBSD (or use -pthread)? > The "best" solution IMHO would be to have configure look for -lpthread > and put the value into @PTHREAD_LIBS@. Then the Wine port can just > s/-lpthread/${PTHREAD_LIBS}/g configure in the post-patch-target Please keep in mind that Wine should build as is (in CVS) without any FreeBSD-specific changes. I have been investing a lot of time and effort to reach that state and would like to keep it that way (and Alexandre agrees with that, as far as I know). As far as I can see, the ideal approach might be: o Check whether -lphtread exits/works and use it only, if it does. o Check whether -lc_r exists/works, and if it does, use that instead of -lc. These two are independent, and should work in general, that is, portably. Gerald -- Gerald Pfeifer (Jerry) gerald(a)pfeifer.com http://www.pfeifer.com/gerald/

1 0

Re: patch 6
by Alexandre Julliard 21 Aug '03

21 Aug '03

"puoti\(a)inwind\.it" <puoti(a)inwind.it> writes: > Added my email next to my name in cmdlgtst /It.rc It's better to avoid putting email addresses in source files, they quickly become obsolete and nobody ever bothers to update them. Just put your name there, and people who want to mail you can look up your most recent address in the Changelog. -- Alexandre Julliard julliard(a)winehq.com

1 0

RFC: evolution of file management
by Eric Pouech 21 Aug '03

21 Aug '03

in the process of separating ntdll from kernel32, one of the next hurdle if the implementation of NtCreateFile. Since it's rather a core API, some thoughts are needed. Moreover, there are a few shortcomings in current file handling we might want to address. The goal of this small RFC is to: 1/ gather all known shortcomings of current file implementation 2/ propose some solutions and roadmaps for the implementation feel free to add your own remarks to these lists. 1/ shortcomings --------------- 1.1) no dynamicity in DOS drive management: user should be able, in his/her session(1), to either change the mapping of a DOS drive letter, or mount a SMB share somewhere...) 1.2) mounting should be done session wide and not process wide, and of course shared across processes 1.3) ntdll and kernel32 are not separated regarding file management 1.4) devices (vxd and DOS) management is still a hack 1.5) it may be necessary to introduce a notion of filesystem for some operations (open, read, write, seek, close, dir_enum, ioctl) in order to support several FS (unix, smb...) 1.6) poor management of ejectable devices 1.7) short/long file name conversion should be consistent (across several processes in the same session, across several sessions) Note: (1) a session is linked to a running instance of the wineserver 2/ proposal ----------- 2.1 "path gates" (target: 1.1, 1.2, 1.3/partly, 1.4/partly, 1.6/partly) all file names will be handled using the NT-style: + DOS paths (C:\foo\bar) into \??\C:\foo\bar + network paths (\\station\foo\bar) into \??\UNC\station\foo\bar + DOS device names (CON) into \??\CON + NT device names (\\.\PhysicalDrive0) into \??\PhysicalDrive0 + a VXD ?? (normally \\.\VFD) into \??\VFD the device concept will disappear and be replaced by a "path gate": in NT-Win32 name space, point where to convert from a NT-path to a Unix-path for example, assuming we have created a path-gate from \\??\c: to /mnt/windows, the NT-path \\??\c:\foo\bar will be transformed into the unix-path /mnt/windows/foo/bar the path-gate will hold the current options that the device currently does (case sensivity, fixed/removable...) path-gates will be stored in the server (they are session wide) management of VxD and devices could benefit from it: they could be path gates pointing to them selves (or nothing ?) 2.2 FS (target: 1.4/partly, 1.5/partly, 1.6/partly) I'm still wondering if we really need a FS (even a very simplistic one) in Wine 2.3 short/long file names (target 1.7) since current short file name management seems satisfactory, there's no need IMO to move short/long names conversion in the server -- Eric Pouech

5 8

GetLastError strangeness with FindClose
by Alex Pasadyn 21 Aug '03

21 Aug '03

Hi all, I observed a program that was bailing out with an absolutely baffling error message. I have traced it to its cause, but now I'm stuck. Basically, it was telling me that it had an error in FindNextFile of "success". I did a relay trace and found out that it was calling FindFirstFile, FindNextFile a bunch of times, FindClose, and then GetLastError. So, I put together a little test: #include <windows.h> #include <stdio.h> WIN32_FIND_DATA fd; HANDLE h; int main(int argc, char *argv[]) { h = FindFirstFile("*", &fd); if (h == INVALID_HANDLE_VALUE) { printf("Error finding first file: %d\n", GetLastError()); return 1; } printf("found file: %s\n", fd.cFileName); while (FindNextFile(h, &fd)) { printf("found file: %s\n", fd.cFileName); } FindClose(h); switch (GetLastError()) { case ERROR_NO_MORE_FILES: printf("all done!\n"); return 0; default: printf("Error finding next file: %d\n", GetLastError()); return 1; } return 1; } Now, on Windows, the output is: G:\testfnf>testfnf found file: . found file: .. found file: testfnf.cpp found file: testfnf.exe all done! And with Wine the output is: [ajp@toaster testfnf]$ ~/wine/wine testfnf.exe found file: . found file: .. found file: testfnf.cpp found file: testfnf.exe Error finding next file: 0 So, it looks like somewhere in FindClose Wine is resetting the last error. I started digging through there and the functions it calls but I was unable to find where it was getting reset. Can anyone shed some light on this? Is there any way to break on that value changing? Thanks, -ajp

6 10

Directx 8.1 sound bug
by puoti＠inwind.it 21 Aug '03

21 Aug '03

Anybody intrested may want to look at this http://bugs.winehq.com/show_bug.cgi?id=1670

1 0

Re: FAQ: When will Wine integrate an x86 CPU emulator?
by Mike Hearn 21 Aug '03

21 Aug '03

On Wed, 2003-08-20 at 21:42, Francois Gouget wrote: > + environment, Wine should only need minimal modifications. What > + performance you loose due to Wine running inside the emulator > + rather than natively, you gain in complexity inside of Wine. s/loose/lose/ - I'm not sure the second part of that sentance makes sense. What you lose in performance, you gain in complexity inside of wine? Shouldn't that be simplicity? Random tangent: at some point somebody needs to write an "msinterop" program that simply looks at the environment, the type of EXE file and then invokes: 1) Wine 2) Mono 3) Wine in QEMU 4) Wine and Mono in QEMU 5) Offers to download and install these programs if need be. Especially as we'll start seeing more and more programs that are partly unmanaged and partly managed (.net) code floating about, it's going to be harder to figure out what programs you need in order to make the exe run.

1 0

Re: stub for (undocumented) SHCreateLinks
by Dmitry Timoshkov 21 Aug '03

21 Aug '03

"Mike McCormack" <mike(a)codeweavers.com> wrote: > + 172 stdcall SHCreateLinks(long long long long long) > +HRESULT WINAPI SHCreateLinks( HWND hWnd, LPCSTR lpszDir, LPDATAOBJECT lpDataObject, > + UINT uFlags, LPITEMIDLIST *lppidlLinks) Then the spec entry should be 172 stdcall SHCreateLinks(long ptr ptr long ptr) -- Dmitry.

2 2

Re: patch 6
by Tom 21 Aug '03

21 Aug '03

puotiinwindit wrote: >this patch is licensed under the LGPL only (patch 5 is also LGPL only). >ChangeLog >Added Italian support to avifil32.dll >Fixed a typo in the english rc file in avifil32.dll > > > > > > Hi, umm.. the patches? :) Tom

1 0

Re: spec file syntax and automated generation
by Jon Griffiths 21 Aug '03

21 Aug '03

Hi Martin, > thanks for your info. I just wanted to forward my problem I posted on > wine-users - I do not know if wine-devel is the right place for this, so wine-devel is the place for any development issues, including problems with Winelib. Since someone may have the same problem(s) in the future, I'm also sending this to wine-devel (it serves as an issues archive for common problems). >I am currently having trouble building the DLLs of an application ported >from Win32 to Winelib - compiling, thanks to some hints from Dimi O. >Paun, now works fine, only(?) the final link __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

1 0

Re: PATCH - some build fixes for w32api headers
by Alexandre Julliard 21 Aug '03

21 Aug '03

Steven Edwards <steven_ed4153(a)yahoo.com> writes: > Changelog: Fixes for building with w32api headers on Mingw Why do you need to add stdarg.h everywhere? AFAICS it should be already included by the headers that require it. As a general note, it's a very good thing to test with other headers, but make sure that the problem is really on the Wine side before making changes. Being compatible with w32api is not a goal in itself for Wine, we have to be compatible with Microsoft; and if the Wine code works with the Microsoft headers but not with w32api then the bug is in w32api and should be fixed there. And in the case where the bug is really in Wine, this means there's an incompatibility in the Wine headers, since it builds fine with them and it shouldn't. So this means we have to fix the Wine headers too, not only the C files. -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: Small spanish keyboard fix
by Dmitry Timoshkov 21 Aug '03

21 Aug '03

"José Manuel Ferrer Ortiz" <jmfo1982(a)yahoo.es> wrote: > Hi again, attached you have a patch to the spanish > keyboard that adds support to write the Euro sign > using <Alt-GR> + <E>, as seen in newer spanish > keyboards. XFree86 4.3.0 has no this, which however should not prevent the Euro sign to work. Moreover, XFree86 project tends to leave only two characters per keysym for all keyboard layouts, not to add new ones. -- Dmitry.

1 0

uClibc and wine
by Felipe Wilhelms Damasio 20 Aug '03

20 Aug '03

Hi, I couldn't compile wine using the latest (0.9.20) version of uClibc. I installed the devel stuff and am using the /usr/i386-uClibc/gcc on my path, and then I get: gcc -c -I. -I. -I../include -I../include -g -O2 -Wall -mpreferred-stack-boundary=2 -gstabs+ -fPIC -D__WINESRC__ -DDLLDIR="\"/mnt/usr/lib/wine\"" -D_REENTRANT -o port.o port.c port.c:597: warning: type defaults to `int' in declaration of `wchar_t' port.c:597: syntax error before '*' token port.c: In function `wine_rewrite_s4tos2': port.c:601: `str4' undeclared (first use in this function) port.c:601: (Each undeclared identifier is reported only once port.c:601: for each function it appears in.) make[1]: *** [port.o] Error 1 make[1]: Leaving directory `/home/felipewd/elipse/cvs/wine-20030115/library' make: *** [library] Error 2 If I change my path to use the default gcc location, it compiles fine. Does anybody have any ideas? Thanks in advance, Felipe

2 1

Re: winegcc
by puoti＠inwind.it 20 Aug '03

20 Aug '03

I'm trying to compile the bidi test progam posted on this list by Shachar Shemesh, you can find his post and his program here: http://www.winehq.org/hypermail/wine-devel/2003/08/0175.html this mail also got to wine-users, sorry about that.

2 1

Re: FAQ: Will there be a Windows version of Wine?
by Steven Edwards 20 Aug '03

20 Aug '03

Thanks Francois, I have been meaning to update some of the docs to answer these questions for a while. You put it much better and more to the point then I would have =). Steven --- Francois Gouget <fgouget(a)free.fr> wrote: > > > Changelog: > > * documentation/faq.sgml > > Tweak 'Will there be a Windows version of Wine?': > - Add a pointer to the MinGW project > - Fix the ReactOS case > - Explain the rational behind these porting projects > > > Index: documentation/faq.sgml > =================================================================== > RCS file: /home/wine/wine/documentation/faq.sgml,v > retrieving revision 1.13 > diff -u -r1.13 faq.sgml > --- documentation/faq.sgml 28 Jul 2003 19:06:10 -0000 1.13 > +++ documentation/faq.sgml 20 Aug 2003 20:24:25 -0000 > @@ -485,19 +575,26 @@ > </question> > <answer> > <para> > - Some people are working on getting Wine code to compile on Windows. > + Some people are working on getting Wine code to compile on Windows > + using one of the following projects as a basis: > </para> > <itemizedlist spacing="compact"> > <listitem> > <para> > - Cygwin (<ulink url="http:/www.cygwin.com"> > - http://www.cygwin.com/</ulink>) > + Cygwin > + (<ulink url="http:/www.cygwin.com/">http://www.cygwin.com</>) > + </para> > + </listitem> > + <listitem> > + <para> > + MinGW > + (<ulink url="http:/www.mingw.org/">http://www.mingw.org</>) > </para> > </listitem> > <listitem> > <para> > - Reactos (<ulink url="http://www.reactos.com/"> > - http://www.reactos.com/</ulink>) > + ReactOS > + (<ulink url="http://www.reactos.com/">http://www.reactos.com</>) > </para> > </listitem> > </itemizedlist> > @@ -505,9 +602,21 @@ > There's some progress, so a Wine version that's usable on Windows > might be available at some time. > </para> > + <para> > + Part of the rational for these projects is to find out areas where > + Wine portability is lacking. This is especially true of the > + ReactOS project which is a reimplementation of the Windows kernel > + and should thus be able to reuse most of Wine dlls. > + </para> > + <para> > + Another reason for pursuing these projects is to be able to > + replace a single Windows dll with its Wine counterpart. Besides > + being a good test for the Wine dll, this lets us detect cases where > + we made incorrect assumptions about how the dlls interact. > + </para> > </answer> > </qandaentry> > - > + > </qandadiv> > <qandadiv id="What-do-I-need-in-order-to-use-Wine"> > <title>What do I need in order to use Wine?</title> > > > > -- > Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ > It really galls me that most of the computer power in the world > is wasted on screen savers. > Chris Caldwell from the GIMPS project > http://www.mersenne.org/prime.htm > > __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

1 0

PATCH try 2 - build libwine_unicode with w32api headers
by Steven Edwards 20 Aug '03

20 Aug '03

Ok now with clean w32api headers from CVS we can build unicode. This shouldnt break cross compiling or the *nix build but if it does please let me know. Also you can change WINVER >= 0x0500 to whatever as long as it is higher. Thanks Steven Changelog: Fix building libwine_unicode with w32api headers. Index: Makefile.in =================================================================== RCS file: /home/wine/wine/libs/unicode/Makefile.in,v retrieving revision 1.5 diff -u -r1.5 Makefile.in --- Makefile.in 27 Jun 2003 19:02:23 -0000 1.5 +++ Makefile.in 20 Aug 2003 06:13:25 -0000 @@ -4,7 +4,7 @@ VPATH = @srcdir@ LIBRARY = wine_unicode SOVERSION = 1 -EXTRADEFS = -D__WINESRC__ -DNO_LIBWINE_PORT +EXTRADEFS = -D__WINESRC__ -DNO_LIBWINE_PORT -DWINVER=0x0500 CODEPAGES = \ 037 \ Index: unicode.h =================================================================== RCS file: /home/wine/wine/include/wine/unicode.h,v retrieving revision 1.20 diff -u -r1.20 unicode.h --- unicode.h 27 Jun 2003 19:02:23 -0000 1.20 +++ unicode.h 20 Aug 2003 07:36:07 -0000 @@ -24,6 +24,7 @@ #include <stdarg.h> #include "windef.h" +#include "winbase.h" #include "winnls.h" /* code page info common to SBCS and DBCS */ __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

2 2

Re: spec file syntax and automated generation
by Jon Griffiths 20 Aug '03

20 Aug '03

Hi, <disclaimer> I havent read the wine-user posts.... >1. The winebuild manpage only mentions ptr, str, wstr, long and double >as valid Win32 function argument size information - is the amount and >kind of symbols really important, or is it just the amount of used stack >space? the type is used for dumping of parameters so its good to have it right. >I am not too familiar with assembler, but I would assume the first is >right, since two arguments are pushed on the stack, each using 32bit. Correct. Logical types are irrelevant, only the physical size matters. % __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

1 0

is anyone running windows 95, windows 98, windows ME or windows 2003?
by Jonathan Wilson 20 Aug '03

20 Aug '03

If so, I need you to run some kind of PE dumper that can dump exports (such as dumpbin from MS with the /exports switch on user32.dll and gdi32.dll from your version and send me the results, along with details of which version of windows you are running. I want this info because I am compiling a list of the different versions of windows and which functions are exported by user32.dll and gdi32.dll in each version.

4 3

Re: [Foxgui-users]Re: Wine fixes (1)
by Dimitrie O. Paun 20 Aug '03

20 Aug '03

On 20 Aug 2003, Doug Henry wrote: > > Added this one too. [As to why you'd want to run FOX under Wine while it > > runs natively under X11, I don't know....] > > > > If you cross-compile for windows under linux, it is useful to test under > wine. Its more convenient than rebooting or going to another machine > just for simple testing. Top 10 reasons you want Fox ported to Wine: 10. Windows sux 9. Microsoft is evil 8. Test windows features without rebooting (as Doug mentioned) 7. Keep development on Linux 6. Run valgrind on the Windows port 5. Make sure the Win32 part is portable to multiple implementations 4. Help find missing features/problems/etc. in Wine 3. Some people may prefer the Wine widgets to the GTK+ ones 2. wxWindows is already ported to Wine, Fox needs that too! ;) and the number one reason is: 1. It is just cool!!! (what geek can resist this sort of virtualization? :)) -- Dimi.

1 0

Re: winegcc
by puoti＠inwind.it 20 Aug '03

20 Aug '03

I've just updated via cvs, and I get this [ivan@my Wine]$ winegcc -mwindows 01-biditest.c /tmp/wappZjLo5B.spec.o(.text+0x1010a): In function `__wine_exe_main': : undefined reference to `WinMain' collect2: ld returned 1 exit status Error: gcc failed. Error: winewrap failed. [ivan@my Wine]$ winewrap returns a seg fault.

3 2

LPT1 support in DOSFS_OpenDevice
by E Lea 20 Aug '03

20 Aug '03

I'm trying to add LPT1 support to DOSFS_OpenDevice. The software that requires this functionality controls a parallel port plotter by sending LOGO-style ASCII commands. I have based my attempts heavily on the serial port support, although I don't think I really know what I'm doing. Can anyone explain to me what's required? I have tried to implement a server call to create a file descriptor to /dev/lp0 (read from ~/.wine/config) and return a handle to it, but after that (perhaps when wine starts using the handle) both the wine and wineserver processes die. I don't really understand handles and how they are used. Are more functions required other than a simple create_parallel()? How do handles work?

1 0

anyone here got the format of icons & cursors?
by Jonathan Wilson 20 Aug '03

20 Aug '03

I am asking this since WINE appears to support icons and cursors but I cant find the code or the info. What I am looking for is: 1.the format of *.cur files 2.the format of *.ico files 3.the format of RT_CURSOR resources 4.the format of RT_ICON resources 5.the format of RT_CURSOR_GROUP resources and 6.the format of RT_ICON_GROUP resources

1 0

Re: PATCH - build libwine_unicode with w32api headers
by Steven Edwards 20 Aug '03

20 Aug '03

Nevermind. Send this patch and email to /dev/null. My w32api headers were hosed. Sorry for the noise. Thanks Steven --- Steven Edwards <steven_ed4153(a)yahoo.com> wrote: > You can now rm -fr *.h in wine/include (exclude config.h) and then do > configure. This patch fixes unicode.dll. I didnt know if you had a problem with > defining the WINVER but a define the winnls.h is not included in mingw without this. Should > wines > winnls be changed also? here is what we get without the patch. I am not near a MS_VC install to > check how it is done with the headers there. > > gcc -c -I. -I. -I../../include -I../../include -D_REENTRANT -D__WINESRC__ -DNO_ > LIBWINE_PORT -Wall -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ - > Wpointer-arith -g -O2 -o wctomb.o wctomb.c > wctomb.c: In function `is_valid_sbcs_mapping': > wctomb.c:73: `WC_NO_BEST_FIT_CHARS' undeclared (first use in this function) > wctomb.c:73: (Each undeclared identifier is reported only once > wctomb.c:73: for each function it appears in.) > wctomb.c: In function `is_valid_dbcs_mapping': > wctomb.c:256: `WC_NO_BEST_FIT_CHARS' undeclared (first use in this function) > make: *** [wctomb.o] Error 1 > > Changelog: Fix building libwine_unicode with w32api headers. > > Index: Makefile.in > =================================================================== > RCS file: /home/wine/wine/libs/unicode/Makefile.in,v > retrieving revision 1.5 > diff -u -r1.5 Makefile.in > --- Makefile.in 27 Jun 2003 19:02:23 -0000 1.5 > +++ Makefile.in 20 Aug 2003 06:13:25 -0000 > @@ -4,7 +4,7 @@ > VPATH = @srcdir@ > LIBRARY = wine_unicode > SOVERSION = 1 > -EXTRADEFS = -D__WINESRC__ -DNO_LIBWINE_PORT > +EXTRADEFS = -D__WINESRC__ -DNO_LIBWINE_PORT -DWINVER=0x0500 > > CODEPAGES = \ > 037 \ > > > __________________________________ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site design software > http://sitebuilder.yahoo.com > __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

1 0

rpcrt4.dll from WINE in ReactOS
by Steven Edwards 20 Aug '03

20 Aug '03

Hello, Are we going to be able to make use of WINEs rpcrt4.dll on ReactOS? I can build 99% of the dll with Mingw but am having trouble because of WINEs exception handler and a few calls to gettimeofday. If we should be able to use it then I will work on porting it when I get back from vacation on the 8th. We need a semi functioning rpcrt4 to be able to port ole32 and shell32. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

2 2

winegcc
by puoti＠inwind.it 20 Aug '03

20 Aug '03

Hi list, I was compiling the bidi test to try the ICU libs, and got this error ivan@my Wine]$ winegcc 01-biditest.c wgcc.ygvnee.o(.text+0x91): In function `main': : undefined reference to `GetCharacterPlacementW' collect2: ld returned 1 exit status Error: gcc failed. Error: /usr/local/bin/winewrap failed. [ivan@my Wine]$ so I tried winewrap and got a segmentation fault I'm running wine cvs current, compiled on Mandrake 9.1 with gcc 3.2.2, and glibc 2.3, any help would be gratly appreciated, Ivan.

2 1

problem with apps in desktop mode
by Rok Mandeljc 19 Aug '03

19 Aug '03

When I try running InstallShield in windowed mode ("Desktop" = "640x480" as per default in config), window appears for a second and then dissapears printing this message: X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 12 (X_ConfigureWindow) Serial number of failed request: 93 Current serial number in output stream: 98 Did latest modifications of x11drv break anything? -- Rok Mandeljc <rok.mandeljc(a)gimb.org> "All that is gold does not glitter, Not all those who wander are lost; The old that is strong does not wither, Deep roots are not reached by the frost. From the ashes a fire shall be woken, A light from the shadows shall spring; Renewed shall be blade that was broken, The crownless again shall be king." -- J.R.R. Tolkien

4 3

Re: REGRESSION: environment variables no longer possible
by Alexandre Julliard 19 Aug '03

19 Aug '03

"Dmitry Timoshkov" <dmitry(a)baikal.ru> writes: > Actually it's just the format of the Wine config has changed. Now all > environment variables should be surrounded by the percent signes (%HOME%), > and are handled by the normal registry code. Alexandre has changed the sample > config as well. Actually the format of the config has not really changed, most entries have been behaving that way for a long time already. I just made the drives part of the config behave like all the other entries. > Attached patch is rather useless, but however it makes the old profile > code be consistent with the new behaviour. A better approach is to > completely remove environment handling from profile.c. Yes, I think environment handling should be left to the application. -- Alexandre Julliard julliard(a)winehq.com

4 5

Parse error when trying to build imagehlp with the w32api headers
by Steven Edwards 19 Aug '03

19 Aug '03

Does anyone have any idea as to what is going on here. I dont really see why mingw has a problem. access.c: In function `ImageUnload': access.c:204: parse error before "LOADED_IMAGE" access.c:210: parse error before "LOADED_IMAGE" make1: *** [access.o] Error 1 Thanks Steven __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

3 2

Re: Anyone having problems with Alsa ?
by Sylvain Petreolle 19 Aug '03

19 Aug '03

Yes, did it, thanks. And wine recompiling too (done daily with cvs update). Another user seems to have found a problem into dlls/winmm/winealsa/audio.c, related to the software silence duration setting. --- Jerry Jenkins <Jerry_J_Jenkins(a)hotmail.com> a écrit : > Did you restart service alsasound or your computer? Maybe recompiling > WINE > is also needed. ===== Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) ICQ #170597259 alias upsf='false ; while [ $? -ne 0 ] ; do cvs update -APd ; done 2>&1 |tee cvslog' "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Re: Fix treeview with checkboxes creation
by Dmitry Timoshkov 19 Aug '03

19 Aug '03

"Maxime Bellengé" <maxime.bellenge(a)laposte.net> wrote: > Changelog: > * Fix the creation of treeview with checkboxes. Now they display fine. The only real change in this patch is the following snippet. Could you retest and send only that chunk alone? @@ -4848,12 +4850,14 @@ DrawFrameControl(hdc, &rc, DFC_BUTTON, DFCS_BUTTONCHECK|DFCS_FLAT|DFCS_CHECKED); + SelectObject(hdc, hbmOld); nIndex = ImageList_AddMasked(infoPtr->himlState, hbm, GetSysColor(COLOR_WINDOW)); TRACE("chckbox index %d\n", nIndex); - SelectObject(hdc, hbmOld); -- Dmitry.

2 5

Re: [PATCH] Compiling GNU winboard completed
by Dimitrie O. Paun 19 Aug '03

19 Aug '03

On August 18, 2003 02:07 pm, erwin wolff wrote: > I have been busy with compiling GNU winboard (the win32 graphic > front-end for GNU chess). If these patches are applied, it compiles > without a single warning. Please note that the mmsystem.diff is intended > for wine/include/mmsystem.h. Here is a smaller patch against winboard which does the following: -- cygwin.mak: modify it to also support building under Wine. This way, we have only one makefile for cygwin/mingw/Wine, and therefore we run a much smaller risk of obsolesence. -- winboard.rc: make sure the case in filenames referenced from .rc file match the case of file on disk For the _popen problem, I have sent fixes for Wine. > I hope this doesn't break anything. The other two files are for the > winboard source tarball version 2.4.6. (ftp://ftp.gnu.org/gnu/winboard > ). Although it compiles and starts good, I cannot play against a > computer component (only against myself;() due the following fixme: Unfortunately, it doesn't even start in my case. Maybe the _popen stubs kill it, needs investigating. diff -u winboard/cygwin.mak winboard.dimi/cygwin.mak --- winboard/cygwin.mak 2001-12-03 02:09:44.000000000 -0500 +++ winboard.dimi/cygwin.mak 2003-08-19 08:23:08.000000000 -0400 @@ -17,17 +17,22 @@ gamelist.o pgntags.o wedittags.o wgamelist.o zippy.o \ wsockerr.o wbres.o wclipbrd.o woptions.o +ifndef WINE +CC = gcc +RC = windres +LDVARS = -Xlinker "-e" -Xlinker "_mainCRTStartup" +else +CC = winegcc +RC = wrc +endif # 2 Dec 2001 - the mingw libraries that I have right now # (not updated for a few months) have bugs in fileno and stat # that prevent WinBoard from working. -#cygwin= -mno-cygwin +cygwin= -mno-cygwin -CFLAGS= $(cdebug) -CVARS= -I. -mwindows $(cygwin) -CC = gcc $(CVARS) -WCC = $(CC) -mwindows -Xlinker "-e" -Xlinker "_mainCRTStartup" \ - $(linkdebug) $(cygwin) +CFLAGS= $(cdebug) -I. -mwindows $(cygwin) +WCC = $(CC) -mwindows $(LDVARS) $(linkdebug) $(cygwin) LD = ld all: $(proj).exe @@ -39,7 +44,7 @@ # Update the resource if necessary wbres.o: $(proj).rc $(proj).h resource.h - windres --use-temp-file $< -O coff -o $@ + $(RC) --use-temp-file $< -O coff -o $@ # Update the object files if necessary @@ -54,4 +59,4 @@ -o $(proj).exe clean: - rm *.o parser.c + rm -f *.o parser.c winboard diff -u winboard/winboard.rc winboard.dimi/winboard.rc --- winboard/winboard.rc 2002-02-02 02:09:33.000000000 -0500 +++ winboard.dimi/winboard.rc 2003-08-19 02:44:57.000000000 -0400 @@ -959,330 +959,330 @@ // Bitmap // -P21O BITMAP MOVEABLE PURE "bitmaps\\P21o.bmp" -N21O BITMAP MOVEABLE PURE "bitmaps\\N21o.bmp" -B21O BITMAP MOVEABLE PURE "bitmaps\\B21o.bmp" -R21O BITMAP MOVEABLE PURE "bitmaps\\R21o.bmp" -K21O BITMAP MOVEABLE PURE "bitmaps\\K21o.bmp" -Q21O BITMAP MOVEABLE PURE "bitmaps\\Q21o.bmp" -P21S BITMAP MOVEABLE PURE "bitmaps\\P21s.bmp" -N21S BITMAP MOVEABLE PURE "bitmaps\\N21s.bmp" -B21S BITMAP MOVEABLE PURE "bitmaps\\B21s.bmp" -R21S BITMAP MOVEABLE PURE "bitmaps\\R21s.bmp" -Q21S BITMAP MOVEABLE PURE "bitmaps\\Q21s.bmp" -K21S BITMAP MOVEABLE PURE "bitmaps\\K21s.bmp" -P21W BITMAP MOVEABLE PURE "bitmaps\\P21w.bmp" -N21W BITMAP MOVEABLE PURE "bitmaps\\N21w.bmp" -B21W BITMAP MOVEABLE PURE "bitmaps\\B21w.bmp" -R21W BITMAP MOVEABLE PURE "bitmaps\\R21w.bmp" -Q21W BITMAP MOVEABLE PURE "bitmaps\\Q21w.bmp" -K21W BITMAP MOVEABLE PURE "bitmaps\\K21w.bmp" -P25O BITMAP MOVEABLE PURE "bitmaps\\P25o.bmp" -N25O BITMAP MOVEABLE PURE "bitmaps\\N25o.bmp" -B25O BITMAP MOVEABLE PURE "bitmaps\\B25o.bmp" -R25O BITMAP MOVEABLE PURE "bitmaps\\R25o.bmp" -Q25O BITMAP MOVEABLE PURE "bitmaps\\Q25o.bmp" -K25O BITMAP MOVEABLE PURE "bitmaps\\K25o.bmp" -P25S BITMAP MOVEABLE PURE "bitmaps\\P25s.bmp" -N25S BITMAP MOVEABLE PURE "bitmaps\\N25s.bmp" -B25S BITMAP MOVEABLE PURE "bitmaps\\B25s.bmp" -R25S BITMAP MOVEABLE PURE "bitmaps\\R25s.bmp" -Q25S BITMAP MOVEABLE PURE "bitmaps\\Q25s.bmp" -K25S BITMAP MOVEABLE PURE "bitmaps\\K25s.bmp" -P25W BITMAP MOVEABLE PURE "bitmaps\\P25w.bmp" -N25W BITMAP MOVEABLE PURE "bitmaps\\N25w.bmp" -B25W BITMAP MOVEABLE PURE "bitmaps\\B25w.bmp" -R25W BITMAP MOVEABLE PURE "bitmaps\\R25w.bmp" -Q25W BITMAP MOVEABLE PURE "bitmaps\\Q25w.bmp" -K25W BITMAP MOVEABLE PURE "bitmaps\\K25w.bmp" -P29O BITMAP MOVEABLE PURE "bitmaps\\P29o.bmp" -N29O BITMAP MOVEABLE PURE "bitmaps\\N29o.bmp" -B29O BITMAP MOVEABLE PURE "bitmaps\\B29o.bmp" -R29O BITMAP MOVEABLE PURE "bitmaps\\R29o.bmp" -Q29O BITMAP MOVEABLE PURE "bitmaps\\Q29o.bmp" -K29O BITMAP MOVEABLE PURE "bitmaps\\K29o.bmp" -P29S BITMAP MOVEABLE PURE "bitmaps\\P29s.bmp" -N29S BITMAP MOVEABLE PURE "bitmaps\\N29s.bmp" -B29S BITMAP MOVEABLE PURE "bitmaps\\B29s.bmp" -R29S BITMAP MOVEABLE PURE "bitmaps\\R29s.bmp" -Q29S BITMAP MOVEABLE PURE "bitmaps\\Q29s.bmp" -K29S BITMAP MOVEABLE PURE "bitmaps\\K29s.bmp" -P29W BITMAP MOVEABLE PURE "bitmaps\\P29w.bmp" -N29W BITMAP MOVEABLE PURE "bitmaps\\N29w.bmp" -B29W BITMAP MOVEABLE PURE "bitmaps\\B29w.bmp" -R29W BITMAP MOVEABLE PURE "bitmaps\\R29w.bmp" -Q29W BITMAP MOVEABLE PURE "bitmaps\\Q29w.bmp" -K29W BITMAP MOVEABLE PURE "bitmaps\\K29w.bmp" -P33O BITMAP MOVEABLE PURE "bitmaps\\P33o.bmp" -N33O BITMAP MOVEABLE PURE "bitmaps\\N33o.bmp" -B33O BITMAP MOVEABLE PURE "bitmaps\\B33o.bmp" -R33O BITMAP MOVEABLE PURE "bitmaps\\R33o.bmp" -Q33O BITMAP MOVEABLE PURE "bitmaps\\Q33o.bmp" -K33O BITMAP MOVEABLE PURE "bitmaps\\K33o.bmp" -P33S BITMAP MOVEABLE PURE "bitmaps\\P33s.bmp" -N33S BITMAP MOVEABLE PURE "bitmaps\\N33s.bmp" -B33S BITMAP MOVEABLE PURE "bitmaps\\B33s.bmp" -R33S BITMAP MOVEABLE PURE "bitmaps\\R33s.bmp" -Q33S BITMAP MOVEABLE PURE "bitmaps\\Q33s.bmp" -K33S BITMAP MOVEABLE PURE "bitmaps\\K33s.bmp" -P33W BITMAP MOVEABLE PURE "bitmaps\\P33w.bmp" -N33W BITMAP MOVEABLE PURE "bitmaps\\N33w.bmp" -B33W BITMAP MOVEABLE PURE "bitmaps\\B33w.bmp" -R33W BITMAP MOVEABLE PURE "bitmaps\\R33w.bmp" -Q33W BITMAP MOVEABLE PURE "bitmaps\\Q33w.bmp" -K33W BITMAP MOVEABLE PURE "bitmaps\\K33w.bmp" -P37O BITMAP MOVEABLE PURE "bitmaps\\P37o.bmp" -N37O BITMAP MOVEABLE PURE "bitmaps\\N37o.bmp" -B37O BITMAP MOVEABLE PURE "bitmaps\\B37o.bmp" -R37O BITMAP MOVEABLE PURE "bitmaps\\R37o.bmp" -Q37O BITMAP MOVEABLE PURE "bitmaps\\Q37o.bmp" -K37O BITMAP MOVEABLE PURE "bitmaps\\K37o.bmp" -P37S BITMAP MOVEABLE PURE "bitmaps\\P37s.bmp" -N37S BITMAP MOVEABLE PURE "bitmaps\\N37s.bmp" -B37S BITMAP MOVEABLE PURE "bitmaps\\B37s.bmp" -R37S BITMAP MOVEABLE PURE "bitmaps\\R37s.bmp" -Q37S BITMAP MOVEABLE PURE "bitmaps\\Q37s.bmp" -K37S BITMAP MOVEABLE PURE "bitmaps\\K37s.bmp" -P37W BITMAP MOVEABLE PURE "bitmaps\\P37w.bmp" -N37W BITMAP MOVEABLE PURE "bitmaps\\N37w.bmp" -B37W BITMAP MOVEABLE PURE "bitmaps\\B37w.bmp" -R37W BITMAP MOVEABLE PURE "bitmaps\\R37w.bmp" -Q37W BITMAP MOVEABLE PURE "bitmaps\\Q37w.bmp" -K37W BITMAP MOVEABLE PURE "bitmaps\\K37w.bmp" -P40O BITMAP MOVEABLE PURE "bitmaps\\P40o.bmp" -N40O BITMAP MOVEABLE PURE "bitmaps\\N40o.bmp" -B40O BITMAP MOVEABLE PURE "bitmaps\\B40o.bmp" -R40O BITMAP MOVEABLE PURE "bitmaps\\R40o.bmp" -Q40O BITMAP MOVEABLE PURE "bitmaps\\Q40o.bmp" -K40O BITMAP MOVEABLE PURE "bitmaps\\K40o.bmp" -P40S BITMAP MOVEABLE PURE "bitmaps\\P40s.bmp" -N40S BITMAP MOVEABLE PURE "bitmaps\\N40s.bmp" -B40S BITMAP MOVEABLE PURE "bitmaps\\B40s.bmp" -R40S BITMAP MOVEABLE PURE "bitmaps\\R40s.bmp" -Q40S BITMAP MOVEABLE PURE "bitmaps\\Q40s.bmp" -K40S BITMAP MOVEABLE PURE "bitmaps\\K40s.bmp" -P40W BITMAP MOVEABLE PURE "bitmaps\\P40w.bmp" -N40W BITMAP MOVEABLE PURE "bitmaps\\N40w.bmp" -B40W BITMAP MOVEABLE PURE "bitmaps\\B40w.bmp" -R40W BITMAP MOVEABLE PURE "bitmaps\\R40w.bmp" -Q40W BITMAP MOVEABLE PURE "bitmaps\\Q40w.bmp" -K40W BITMAP MOVEABLE PURE "bitmaps\\K40w.bmp" -P45O BITMAP MOVEABLE PURE "bitmaps\\P45o.bmp" -N45O BITMAP MOVEABLE PURE "bitmaps\\N45o.bmp" -B45O BITMAP MOVEABLE PURE "bitmaps\\B45o.bmp" -R45O BITMAP MOVEABLE PURE "bitmaps\\R45o.bmp" -Q45O BITMAP MOVEABLE PURE "bitmaps\\Q45o.bmp" -K45O BITMAP MOVEABLE PURE "bitmaps\\K45o.bmp" -P45S BITMAP MOVEABLE PURE "bitmaps\\P45s.bmp" -N45S BITMAP MOVEABLE PURE "bitmaps\\N45s.bmp" -B45S BITMAP MOVEABLE PURE "bitmaps\\B45s.bmp" -R45S BITMAP MOVEABLE PURE "bitmaps\\R45s.bmp" -Q45S BITMAP MOVEABLE PURE "bitmaps\\Q45s.bmp" -K45S BITMAP MOVEABLE PURE "bitmaps\\K45s.bmp" -P45W BITMAP MOVEABLE PURE "bitmaps\\P45w.bmp" -N45W BITMAP MOVEABLE PURE "bitmaps\\N45w.bmp" -B45W BITMAP MOVEABLE PURE "bitmaps\\B45w.bmp" -R45W BITMAP MOVEABLE PURE "bitmaps\\R45w.bmp" -Q45W BITMAP MOVEABLE PURE "bitmaps\\Q45w.bmp" -K45W BITMAP MOVEABLE PURE "bitmaps\\K45w.bmp" -P49O BITMAP MOVEABLE PURE "bitmaps\\P49o.bmp" -N49O BITMAP MOVEABLE PURE "bitmaps\\N49o.bmp" -B49O BITMAP MOVEABLE PURE "bitmaps\\B49o.bmp" -R49O BITMAP MOVEABLE PURE "bitmaps\\R49o.bmp" -Q49O BITMAP MOVEABLE PURE "bitmaps\\Q49o.bmp" -K49O BITMAP MOVEABLE PURE "bitmaps\\K49o.bmp" -P49S BITMAP MOVEABLE PURE "bitmaps\\P49s.bmp" -N49S BITMAP MOVEABLE PURE "bitmaps\\N49s.bmp" -B49S BITMAP MOVEABLE PURE "bitmaps\\B49s.bmp" -R49S BITMAP MOVEABLE PURE "bitmaps\\R49s.bmp" -Q49S BITMAP MOVEABLE PURE "bitmaps\\Q49s.bmp" -K49S BITMAP MOVEABLE PURE "bitmaps\\K49s.bmp" -P49W BITMAP MOVEABLE PURE "bitmaps\\P49w.bmp" -N49W BITMAP MOVEABLE PURE "bitmaps\\N49w.bmp" -B49W BITMAP MOVEABLE PURE "bitmaps\\B49w.bmp" -R49W BITMAP MOVEABLE PURE "bitmaps\\R49w.bmp" -Q49W BITMAP MOVEABLE PURE "bitmaps\\Q49w.bmp" -K49W BITMAP MOVEABLE PURE "bitmaps\\K49w.bmp" -P54O BITMAP MOVEABLE PURE "bitmaps\\P54o.bmp" -N54O BITMAP MOVEABLE PURE "bitmaps\\N54o.bmp" -B54O BITMAP MOVEABLE PURE "bitmaps\\B54o.bmp" -R54O BITMAP MOVEABLE PURE "bitmaps\\R54o.bmp" -Q54O BITMAP MOVEABLE PURE "bitmaps\\Q54o.bmp" -K54O BITMAP MOVEABLE PURE "bitmaps\\K54o.bmp" -P54S BITMAP MOVEABLE PURE "bitmaps\\P54s.bmp" -N54S BITMAP MOVEABLE PURE "bitmaps\\N54s.bmp" -B54S BITMAP MOVEABLE PURE "bitmaps\\B54s.bmp" -R54S BITMAP MOVEABLE PURE "bitmaps\\R54s.bmp" -Q54S BITMAP MOVEABLE PURE "bitmaps\\Q54s.bmp" -K54S BITMAP MOVEABLE PURE "bitmaps\\K54s.bmp" -P54W BITMAP MOVEABLE PURE "bitmaps\\P54w.bmp" -N54W BITMAP MOVEABLE PURE "bitmaps\\N54w.bmp" -B54W BITMAP MOVEABLE PURE "bitmaps\\B54w.bmp" -R54W BITMAP MOVEABLE PURE "bitmaps\\R54w.bmp" -Q54W BITMAP MOVEABLE PURE "bitmaps\\Q54w.bmp" -K54W BITMAP MOVEABLE PURE "bitmaps\\K54w.bmp" -P58O BITMAP MOVEABLE PURE "bitmaps\\P58o.bmp" -N58O BITMAP MOVEABLE PURE "bitmaps\\N58o.bmp" -B58O BITMAP MOVEABLE PURE "bitmaps\\B58o.bmp" -R58O BITMAP MOVEABLE PURE "bitmaps\\R58o.bmp" -Q58O BITMAP MOVEABLE PURE "bitmaps\\Q58o.bmp" -K58O BITMAP MOVEABLE PURE "bitmaps\\K58o.bmp" -P58S BITMAP MOVEABLE PURE "bitmaps\\P58s.bmp" -N58S BITMAP MOVEABLE PURE "bitmaps\\N58s.bmp" -B58S BITMAP MOVEABLE PURE "bitmaps\\B58s.bmp" -R58S BITMAP MOVEABLE PURE "bitmaps\\R58s.bmp" -Q58S BITMAP MOVEABLE PURE "bitmaps\\Q58s.bmp" -K58S BITMAP MOVEABLE PURE "bitmaps\\K58s.bmp" -P58W BITMAP MOVEABLE PURE "bitmaps\\P58w.bmp" -N58W BITMAP MOVEABLE PURE "bitmaps\\N58w.bmp" -B58W BITMAP MOVEABLE PURE "bitmaps\\B58w.bmp" -R58W BITMAP MOVEABLE PURE "bitmaps\\R58w.bmp" -Q58W BITMAP MOVEABLE PURE "bitmaps\\Q58w.bmp" -K58W BITMAP MOVEABLE PURE "bitmaps\\K58w.bmp" -P64O BITMAP MOVEABLE PURE "bitmaps\\P64o.bmp" -N64O BITMAP MOVEABLE PURE "bitmaps\\N64o.bmp" -B64O BITMAP MOVEABLE PURE "bitmaps\\B64o.bmp" -R64O BITMAP MOVEABLE PURE "bitmaps\\R64o.bmp" -Q64O BITMAP MOVEABLE PURE "bitmaps\\Q64o.bmp" -K64O BITMAP MOVEABLE PURE "bitmaps\\K64o.bmp" -P64S BITMAP MOVEABLE PURE "bitmaps\\P64s.bmp" -N64S BITMAP MOVEABLE PURE "bitmaps\\N64s.bmp" -B64S BITMAP MOVEABLE PURE "bitmaps\\B64s.bmp" -R64S BITMAP MOVEABLE PURE "bitmaps\\R64s.bmp" -Q64S BITMAP MOVEABLE PURE "bitmaps\\Q64s.bmp" -K64S BITMAP MOVEABLE PURE "bitmaps\\K64s.bmp" -P64W BITMAP MOVEABLE PURE "bitmaps\\P64w.bmp" -N64W BITMAP MOVEABLE PURE "bitmaps\\N64w.bmp" -B64W BITMAP MOVEABLE PURE "bitmaps\\B64w.bmp" -R64W BITMAP MOVEABLE PURE "bitmaps\\R64w.bmp" -Q64W BITMAP MOVEABLE PURE "bitmaps\\Q64w.bmp" -K64W BITMAP MOVEABLE PURE "bitmaps\\K64w.bmp" -P72O BITMAP MOVEABLE PURE "bitmaps\\P72o.bmp" -N72O BITMAP MOVEABLE PURE "bitmaps\\N72o.bmp" -B72O BITMAP MOVEABLE PURE "bitmaps\\B72o.bmp" -R72O BITMAP MOVEABLE PURE "bitmaps\\R72o.bmp" -Q72O BITMAP MOVEABLE PURE "bitmaps\\Q72o.bmp" -K72O BITMAP MOVEABLE PURE "bitmaps\\K72o.bmp" -P72S BITMAP MOVEABLE PURE "bitmaps\\P72s.bmp" -N72S BITMAP MOVEABLE PURE "bitmaps\\N72s.bmp" -B72S BITMAP MOVEABLE PURE "bitmaps\\B72s.bmp" -R72S BITMAP MOVEABLE PURE "bitmaps\\R72s.bmp" -Q72S BITMAP MOVEABLE PURE "bitmaps\\Q72s.bmp" -K72S BITMAP MOVEABLE PURE "bitmaps\\K72s.bmp" -P72W BITMAP MOVEABLE PURE "bitmaps\\P72w.bmp" -N72W BITMAP MOVEABLE PURE "bitmaps\\N72w.bmp" -B72W BITMAP MOVEABLE PURE "bitmaps\\B72w.bmp" -R72W BITMAP MOVEABLE PURE "bitmaps\\R72w.bmp" -Q72W BITMAP MOVEABLE PURE "bitmaps\\Q72w.bmp" -K72W BITMAP MOVEABLE PURE "bitmaps\\K72w.bmp" -P80O BITMAP MOVEABLE PURE "bitmaps\\P80o.bmp" -N80O BITMAP MOVEABLE PURE "bitmaps\\N80o.bmp" -B80O BITMAP MOVEABLE PURE "bitmaps\\B80o.bmp" -R80O BITMAP MOVEABLE PURE "bitmaps\\R80o.bmp" -Q80O BITMAP MOVEABLE PURE "bitmaps\\Q80o.bmp" -K80O BITMAP MOVEABLE PURE "bitmaps\\K80o.bmp" -P80S BITMAP MOVEABLE PURE "bitmaps\\P80s.bmp" -N80S BITMAP MOVEABLE PURE "bitmaps\\N80s.bmp" -B80S BITMAP MOVEABLE PURE "bitmaps\\B80s.bmp" -R80S BITMAP MOVEABLE PURE "bitmaps\\R80s.bmp" -Q80S BITMAP MOVEABLE PURE "bitmaps\\Q80s.bmp" -K80S BITMAP MOVEABLE PURE "bitmaps\\K80s.bmp" -P80W BITMAP MOVEABLE PURE "bitmaps\\P80w.bmp" -N80W BITMAP MOVEABLE PURE "bitmaps\\N80w.bmp" -B80W BITMAP MOVEABLE PURE "bitmaps\\B80w.bmp" -R80W BITMAP MOVEABLE PURE "bitmaps\\R80w.bmp" -Q80W BITMAP MOVEABLE PURE "bitmaps\\Q80w.bmp" -K80W BITMAP MOVEABLE PURE "bitmaps\\K80w.bmp" -P87O BITMAP MOVEABLE PURE "bitmaps\\P87o.bmp" -N87O BITMAP MOVEABLE PURE "bitmaps\\N87o.bmp" -B87O BITMAP MOVEABLE PURE "bitmaps\\B87o.bmp" -R87O BITMAP MOVEABLE PURE "bitmaps\\R87o.bmp" -Q87O BITMAP MOVEABLE PURE "bitmaps\\Q87o.bmp" -K87O BITMAP MOVEABLE PURE "bitmaps\\K87o.bmp" -P87S BITMAP MOVEABLE PURE "bitmaps\\P87s.bmp" -N87S BITMAP MOVEABLE PURE "bitmaps\\N87s.bmp" -B87S BITMAP MOVEABLE PURE "bitmaps\\B87s.bmp" -R87S BITMAP MOVEABLE PURE "bitmaps\\R87s.bmp" -Q87S BITMAP MOVEABLE PURE "bitmaps\\Q87s.bmp" -K87S BITMAP MOVEABLE PURE "bitmaps\\K87s.bmp" -P87W BITMAP MOVEABLE PURE "bitmaps\\P87w.bmp" -N87W BITMAP MOVEABLE PURE "bitmaps\\N87w.bmp" -B87W BITMAP MOVEABLE PURE "bitmaps\\B87w.bmp" -R87W BITMAP MOVEABLE PURE "bitmaps\\R87w.bmp" -Q87W BITMAP MOVEABLE PURE "bitmaps\\Q87w.bmp" -K87W BITMAP MOVEABLE PURE "bitmaps\\K87w.bmp" -P95O BITMAP MOVEABLE PURE "bitmaps\\P95o.bmp" -N95O BITMAP MOVEABLE PURE "bitmaps\\N95o.bmp" -B95O BITMAP MOVEABLE PURE "bitmaps\\B95o.bmp" -R95O BITMAP MOVEABLE PURE "bitmaps\\R95o.bmp" -Q95O BITMAP MOVEABLE PURE "bitmaps\\Q95o.bmp" -K95O BITMAP MOVEABLE PURE "bitmaps\\K95o.bmp" -P95S BITMAP MOVEABLE PURE "bitmaps\\P95s.bmp" -N95S BITMAP MOVEABLE PURE "bitmaps\\N95s.bmp" -B95S BITMAP MOVEABLE PURE "bitmaps\\B95s.bmp" -R95S BITMAP MOVEABLE PURE "bitmaps\\R95s.bmp" -Q95S BITMAP MOVEABLE PURE "bitmaps\\Q95s.bmp" -K95S BITMAP MOVEABLE PURE "bitmaps\\K95s.bmp" -P95W BITMAP MOVEABLE PURE "bitmaps\\P95w.bmp" -N95W BITMAP MOVEABLE PURE "bitmaps\\N95w.bmp" -B95W BITMAP MOVEABLE PURE "bitmaps\\B95w.bmp" -R95W BITMAP MOVEABLE PURE "bitmaps\\R95w.bmp" -Q95W BITMAP MOVEABLE PURE "bitmaps\\Q95w.bmp" -K95W BITMAP MOVEABLE PURE "bitmaps\\K95w.bmp" -P108O BITMAP MOVEABLE PURE "bitmaps\\P108o.bmp" -N108O BITMAP MOVEABLE PURE "bitmaps\\N108o.bmp" -B108O BITMAP MOVEABLE PURE "bitmaps\\B108o.bmp" -R108O BITMAP MOVEABLE PURE "bitmaps\\R108o.bmp" -Q108O BITMAP MOVEABLE PURE "bitmaps\\Q108o.bmp" -K108O BITMAP MOVEABLE PURE "bitmaps\\K108o.bmp" -P108S BITMAP MOVEABLE PURE "bitmaps\\P108s.bmp" -N108S BITMAP MOVEABLE PURE "bitmaps\\N108s.bmp" -B108S BITMAP MOVEABLE PURE "bitmaps\\B108s.bmp" -R108S BITMAP MOVEABLE PURE "bitmaps\\R108s.bmp" -Q108S BITMAP MOVEABLE PURE "bitmaps\\Q108s.bmp" -K108S BITMAP MOVEABLE PURE "bitmaps\\K108s.bmp" -P108W BITMAP MOVEABLE PURE "bitmaps\\P108w.bmp" -N108W BITMAP MOVEABLE PURE "bitmaps\\N108w.bmp" -B108W BITMAP MOVEABLE PURE "bitmaps\\B108w.bmp" -R108W BITMAP MOVEABLE PURE "bitmaps\\R108w.bmp" -Q108W BITMAP MOVEABLE PURE "bitmaps\\Q108w.bmp" -K108W BITMAP MOVEABLE PURE "bitmaps\\K108w.bmp" -P116O BITMAP MOVEABLE PURE "bitmaps\\P116o.bmp" -N116O BITMAP MOVEABLE PURE "bitmaps\\N116o.bmp" -B116O BITMAP MOVEABLE PURE "bitmaps\\B116o.bmp" -R116O BITMAP MOVEABLE PURE "bitmaps\\R116o.bmp" -Q116O BITMAP MOVEABLE PURE "bitmaps\\Q116o.bmp" -K116O BITMAP MOVEABLE PURE "bitmaps\\K116o.bmp" -P116S BITMAP MOVEABLE PURE "bitmaps\\P116s.bmp" -N116S BITMAP MOVEABLE PURE "bitmaps\\N116s.bmp" -B116S BITMAP MOVEABLE PURE "bitmaps\\B116s.bmp" -R116S BITMAP MOVEABLE PURE "bitmaps\\R116s.bmp" -Q116S BITMAP MOVEABLE PURE "bitmaps\\Q116s.bmp" -K116S BITMAP MOVEABLE PURE "bitmaps\\K116s.bmp" -P116W BITMAP MOVEABLE PURE "bitmaps\\P116w.bmp" -N116W BITMAP MOVEABLE PURE "bitmaps\\N116w.bmp" -B116W BITMAP MOVEABLE PURE "bitmaps\\B116w.bmp" -R116W BITMAP MOVEABLE PURE "bitmaps\\R116w.bmp" -Q116W BITMAP MOVEABLE PURE "bitmaps\\Q116w.bmp" -K116W BITMAP MOVEABLE PURE "bitmaps\\K116w.bmp" -P129O BITMAP MOVEABLE PURE "bitmaps\\P129o.bmp" -N129O BITMAP MOVEABLE PURE "bitmaps\\N129o.bmp" -B129O BITMAP MOVEABLE PURE "bitmaps\\B129o.bmp" -R129O BITMAP MOVEABLE PURE "bitmaps\\R129o.bmp" -Q129O BITMAP MOVEABLE PURE "bitmaps\\Q129o.bmp" -K129O BITMAP MOVEABLE PURE "bitmaps\\K129o.bmp" -P129S BITMAP MOVEABLE PURE "bitmaps\\P129s.bmp" -N129S BITMAP MOVEABLE PURE "bitmaps\\N129s.bmp" -B129S BITMAP MOVEABLE PURE "bitmaps\\B129s.bmp" -R129S BITMAP MOVEABLE PURE "bitmaps\\R129s.bmp" -Q129S BITMAP MOVEABLE PURE "bitmaps\\Q129s.bmp" -K129S BITMAP MOVEABLE PURE "bitmaps\\K129s.bmp" -P129W BITMAP MOVEABLE PURE "bitmaps\\P129w.bmp" -N129W BITMAP MOVEABLE PURE "bitmaps\\N129w.bmp" -B129W BITMAP MOVEABLE PURE "bitmaps\\B129w.bmp" -R129W BITMAP MOVEABLE PURE "bitmaps\\R129w.bmp" -Q129W BITMAP MOVEABLE PURE "bitmaps\\Q129w.bmp" -K129W BITMAP MOVEABLE PURE "bitmaps\\K129w.bmp" +P21O BITMAP MOVEABLE PURE "bitmaps\\p21o.bmp" +N21O BITMAP MOVEABLE PURE "bitmaps\\n21o.bmp" +B21O BITMAP MOVEABLE PURE "bitmaps\\b21o.bmp" +R21O BITMAP MOVEABLE PURE "bitmaps\\r21o.bmp" +K21O BITMAP MOVEABLE PURE "bitmaps\\k21o.bmp" +Q21O BITMAP MOVEABLE PURE "bitmaps\\q21o.bmp" +P21S BITMAP MOVEABLE PURE "bitmaps\\p21s.bmp" +N21S BITMAP MOVEABLE PURE "bitmaps\\n21s.bmp" +B21S BITMAP MOVEABLE PURE "bitmaps\\b21s.bmp" +R21S BITMAP MOVEABLE PURE "bitmaps\\r21s.bmp" +Q21S BITMAP MOVEABLE PURE "bitmaps\\q21s.bmp" +K21S BITMAP MOVEABLE PURE "bitmaps\\k21s.bmp" +P21W BITMAP MOVEABLE PURE "bitmaps\\p21w.bmp" +N21W BITMAP MOVEABLE PURE "bitmaps\\n21w.bmp" +B21W BITMAP MOVEABLE PURE "bitmaps\\b21w.bmp" +R21W BITMAP MOVEABLE PURE "bitmaps\\r21w.bmp" +Q21W BITMAP MOVEABLE PURE "bitmaps\\q21w.bmp" +K21W BITMAP MOVEABLE PURE "bitmaps\\k21w.bmp" +P25O BITMAP MOVEABLE PURE "bitmaps\\p25o.bmp" +N25O BITMAP MOVEABLE PURE "bitmaps\\n25o.bmp" +B25O BITMAP MOVEABLE PURE "bitmaps\\b25o.bmp" +R25O BITMAP MOVEABLE PURE "bitmaps\\r25o.bmp" +Q25O BITMAP MOVEABLE PURE "bitmaps\\q25o.bmp" +K25O BITMAP MOVEABLE PURE "bitmaps\\k25o.bmp" +P25S BITMAP MOVEABLE PURE "bitmaps\\p25s.bmp" +N25S BITMAP MOVEABLE PURE "bitmaps\\n25s.bmp" +B25S BITMAP MOVEABLE PURE "bitmaps\\b25s.bmp" +R25S BITMAP MOVEABLE PURE "bitmaps\\r25s.bmp" +Q25S BITMAP MOVEABLE PURE "bitmaps\\q25s.bmp" +K25S BITMAP MOVEABLE PURE "bitmaps\\k25s.bmp" +P25W BITMAP MOVEABLE PURE "bitmaps\\p25w.bmp" +N25W BITMAP MOVEABLE PURE "bitmaps\\n25w.bmp" +B25W BITMAP MOVEABLE PURE "bitmaps\\b25w.bmp" +R25W BITMAP MOVEABLE PURE "bitmaps\\r25w.bmp" +Q25W BITMAP MOVEABLE PURE "bitmaps\\q25w.bmp" +K25W BITMAP MOVEABLE PURE "bitmaps\\k25w.bmp" +P29O BITMAP MOVEABLE PURE "bitmaps\\p29o.bmp" +N29O BITMAP MOVEABLE PURE "bitmaps\\n29o.bmp" +B29O BITMAP MOVEABLE PURE "bitmaps\\b29o.bmp" +R29O BITMAP MOVEABLE PURE "bitmaps\\r29o.bmp" +Q29O BITMAP MOVEABLE PURE "bitmaps\\q29o.bmp" +K29O BITMAP MOVEABLE PURE "bitmaps\\k29o.bmp" +P29S BITMAP MOVEABLE PURE "bitmaps\\p29s.bmp" +N29S BITMAP MOVEABLE PURE "bitmaps\\n29s.bmp" +B29S BITMAP MOVEABLE PURE "bitmaps\\b29s.bmp" +R29S BITMAP MOVEABLE PURE "bitmaps\\r29s.bmp" +Q29S BITMAP MOVEABLE PURE "bitmaps\\q29s.bmp" +K29S BITMAP MOVEABLE PURE "bitmaps\\k29s.bmp" +P29W BITMAP MOVEABLE PURE "bitmaps\\p29w.bmp" +N29W BITMAP MOVEABLE PURE "bitmaps\\n29w.bmp" +B29W BITMAP MOVEABLE PURE "bitmaps\\b29w.bmp" +R29W BITMAP MOVEABLE PURE "bitmaps\\r29w.bmp" +Q29W BITMAP MOVEABLE PURE "bitmaps\\q29w.bmp" +K29W BITMAP MOVEABLE PURE "bitmaps\\k29w.bmp" +P33O BITMAP MOVEABLE PURE "bitmaps\\p33o.bmp" +N33O BITMAP MOVEABLE PURE "bitmaps\\n33o.bmp" +B33O BITMAP MOVEABLE PURE "bitmaps\\b33o.bmp" +R33O BITMAP MOVEABLE PURE "bitmaps\\r33o.bmp" +Q33O BITMAP MOVEABLE PURE "bitmaps\\q33o.bmp" +K33O BITMAP MOVEABLE PURE "bitmaps\\k33o.bmp" +P33S BITMAP MOVEABLE PURE "bitmaps\\p33s.bmp" +N33S BITMAP MOVEABLE PURE "bitmaps\\n33s.bmp" +B33S BITMAP MOVEABLE PURE "bitmaps\\b33s.bmp" +R33S BITMAP MOVEABLE PURE "bitmaps\\r33s.bmp" +Q33S BITMAP MOVEABLE PURE "bitmaps\\q33s.bmp" +K33S BITMAP MOVEABLE PURE "bitmaps\\k33s.bmp" +P33W BITMAP MOVEABLE PURE "bitmaps\\p33w.bmp" +N33W BITMAP MOVEABLE PURE "bitmaps\\n33w.bmp" +B33W BITMAP MOVEABLE PURE "bitmaps\\b33w.bmp" +R33W BITMAP MOVEABLE PURE "bitmaps\\r33w.bmp" +Q33W BITMAP MOVEABLE PURE "bitmaps\\q33w.bmp" +K33W BITMAP MOVEABLE PURE "bitmaps\\k33w.bmp" +P37O BITMAP MOVEABLE PURE "bitmaps\\p37o.bmp" +N37O BITMAP MOVEABLE PURE "bitmaps\\n37o.bmp" +B37O BITMAP MOVEABLE PURE "bitmaps\\b37o.bmp" +R37O BITMAP MOVEABLE PURE "bitmaps\\r37o.bmp" +Q37O BITMAP MOVEABLE PURE "bitmaps\\q37o.bmp" +K37O BITMAP MOVEABLE PURE "bitmaps\\k37o.bmp" +P37S BITMAP MOVEABLE PURE "bitmaps\\p37s.bmp" +N37S BITMAP MOVEABLE PURE "bitmaps\\n37s.bmp" +B37S BITMAP MOVEABLE PURE "bitmaps\\b37s.bmp" +R37S BITMAP MOVEABLE PURE "bitmaps\\r37s.bmp" +Q37S BITMAP MOVEABLE PURE "bitmaps\\q37s.bmp" +K37S BITMAP MOVEABLE PURE "bitmaps\\k37s.bmp" +P37W BITMAP MOVEABLE PURE "bitmaps\\p37w.bmp" +N37W BITMAP MOVEABLE PURE "bitmaps\\n37w.bmp" +B37W BITMAP MOVEABLE PURE "bitmaps\\b37w.bmp" +R37W BITMAP MOVEABLE PURE "bitmaps\\r37w.bmp" +Q37W BITMAP MOVEABLE PURE "bitmaps\\q37w.bmp" +K37W BITMAP MOVEABLE PURE "bitmaps\\k37w.bmp" +P40O BITMAP MOVEABLE PURE "bitmaps\\p40o.bmp" +N40O BITMAP MOVEABLE PURE "bitmaps\\n40o.bmp" +B40O BITMAP MOVEABLE PURE "bitmaps\\b40o.bmp" +R40O BITMAP MOVEABLE PURE "bitmaps\\r40o.bmp" +Q40O BITMAP MOVEABLE PURE "bitmaps\\q40o.bmp" +K40O BITMAP MOVEABLE PURE "bitmaps\\k40o.bmp" +P40S BITMAP MOVEABLE PURE "bitmaps\\p40s.bmp" +N40S BITMAP MOVEABLE PURE "bitmaps\\n40s.bmp" +B40S BITMAP MOVEABLE PURE "bitmaps\\b40s.bmp" +R40S BITMAP MOVEABLE PURE "bitmaps\\r40s.bmp" +Q40S BITMAP MOVEABLE PURE "bitmaps\\q40s.bmp" +K40S BITMAP MOVEABLE PURE "bitmaps\\k40s.bmp" +P40W BITMAP MOVEABLE PURE "bitmaps\\p40w.bmp" +N40W BITMAP MOVEABLE PURE "bitmaps\\n40w.bmp" +B40W BITMAP MOVEABLE PURE "bitmaps\\b40w.bmp" +R40W BITMAP MOVEABLE PURE "bitmaps\\r40w.bmp" +Q40W BITMAP MOVEABLE PURE "bitmaps\\q40w.bmp" +K40W BITMAP MOVEABLE PURE "bitmaps\\k40w.bmp" +P45O BITMAP MOVEABLE PURE "bitmaps\\p45o.bmp" +N45O BITMAP MOVEABLE PURE "bitmaps\\n45o.bmp" +B45O BITMAP MOVEABLE PURE "bitmaps\\b45o.bmp" +R45O BITMAP MOVEABLE PURE "bitmaps\\r45o.bmp" +Q45O BITMAP MOVEABLE PURE "bitmaps\\q45o.bmp" +K45O BITMAP MOVEABLE PURE "bitmaps\\k45o.bmp" +P45S BITMAP MOVEABLE PURE "bitmaps\\p45s.bmp" +N45S BITMAP MOVEABLE PURE "bitmaps\\n45s.bmp" +B45S BITMAP MOVEABLE PURE "bitmaps\\b45s.bmp" +R45S BITMAP MOVEABLE PURE "bitmaps\\r45s.bmp" +Q45S BITMAP MOVEABLE PURE "bitmaps\\q45s.bmp" +K45S BITMAP MOVEABLE PURE "bitmaps\\k45s.bmp" +P45W BITMAP MOVEABLE PURE "bitmaps\\p45w.bmp" +N45W BITMAP MOVEABLE PURE "bitmaps\\n45w.bmp" +B45W BITMAP MOVEABLE PURE "bitmaps\\b45w.bmp" +R45W BITMAP MOVEABLE PURE "bitmaps\\r45w.bmp" +Q45W BITMAP MOVEABLE PURE "bitmaps\\q45w.bmp" +K45W BITMAP MOVEABLE PURE "bitmaps\\k45w.bmp" +P49O BITMAP MOVEABLE PURE "bitmaps\\p49o.bmp" +N49O BITMAP MOVEABLE PURE "bitmaps\\n49o.bmp" +B49O BITMAP MOVEABLE PURE "bitmaps\\b49o.bmp" +R49O BITMAP MOVEABLE PURE "bitmaps\\r49o.bmp" +Q49O BITMAP MOVEABLE PURE "bitmaps\\q49o.bmp" +K49O BITMAP MOVEABLE PURE "bitmaps\\k49o.bmp" +P49S BITMAP MOVEABLE PURE "bitmaps\\p49s.bmp" +N49S BITMAP MOVEABLE PURE "bitmaps\\n49s.bmp" +B49S BITMAP MOVEABLE PURE "bitmaps\\b49s.bmp" +R49S BITMAP MOVEABLE PURE "bitmaps\\r49s.bmp" +Q49S BITMAP MOVEABLE PURE "bitmaps\\q49s.bmp" +K49S BITMAP MOVEABLE PURE "bitmaps\\k49s.bmp" +P49W BITMAP MOVEABLE PURE "bitmaps\\p49w.bmp" +N49W BITMAP MOVEABLE PURE "bitmaps\\n49w.bmp" +B49W BITMAP MOVEABLE PURE "bitmaps\\b49w.bmp" +R49W BITMAP MOVEABLE PURE "bitmaps\\r49w.bmp" +Q49W BITMAP MOVEABLE PURE "bitmaps\\q49w.bmp" +K49W BITMAP MOVEABLE PURE "bitmaps\\k49w.bmp" +P54O BITMAP MOVEABLE PURE "bitmaps\\p54o.bmp" +N54O BITMAP MOVEABLE PURE "bitmaps\\n54o.bmp" +B54O BITMAP MOVEABLE PURE "bitmaps\\b54o.bmp" +R54O BITMAP MOVEABLE PURE "bitmaps\\r54o.bmp" +Q54O BITMAP MOVEABLE PURE "bitmaps\\q54o.bmp" +K54O BITMAP MOVEABLE PURE "bitmaps\\k54o.bmp" +P54S BITMAP MOVEABLE PURE "bitmaps\\p54s.bmp" +N54S BITMAP MOVEABLE PURE "bitmaps\\n54s.bmp" +B54S BITMAP MOVEABLE PURE "bitmaps\\b54s.bmp" +R54S BITMAP MOVEABLE PURE "bitmaps\\r54s.bmp" +Q54S BITMAP MOVEABLE PURE "bitmaps\\q54s.bmp" +K54S BITMAP MOVEABLE PURE "bitmaps\\k54s.bmp" +P54W BITMAP MOVEABLE PURE "bitmaps\\p54w.bmp" +N54W BITMAP MOVEABLE PURE "bitmaps\\n54w.bmp" +B54W BITMAP MOVEABLE PURE "bitmaps\\b54w.bmp" +R54W BITMAP MOVEABLE PURE "bitmaps\\r54w.bmp" +Q54W BITMAP MOVEABLE PURE "bitmaps\\q54w.bmp" +K54W BITMAP MOVEABLE PURE "bitmaps\\k54w.bmp" +P58O BITMAP MOVEABLE PURE "bitmaps\\p58o.bmp" +N58O BITMAP MOVEABLE PURE "bitmaps\\n58o.bmp" +B58O BITMAP MOVEABLE PURE "bitmaps\\b58o.bmp" +R58O BITMAP MOVEABLE PURE "bitmaps\\r58o.bmp" +Q58O BITMAP MOVEABLE PURE "bitmaps\\q58o.bmp" +K58O BITMAP MOVEABLE PURE "bitmaps\\k58o.bmp" +P58S BITMAP MOVEABLE PURE "bitmaps\\p58s.bmp" +N58S BITMAP MOVEABLE PURE "bitmaps\\n58s.bmp" +B58S BITMAP MOVEABLE PURE "bitmaps\\b58s.bmp" +R58S BITMAP MOVEABLE PURE "bitmaps\\r58s.bmp" +Q58S BITMAP MOVEABLE PURE "bitmaps\\q58s.bmp" +K58S BITMAP MOVEABLE PURE "bitmaps\\k58s.bmp" +P58W BITMAP MOVEABLE PURE "bitmaps\\p58w.bmp" +N58W BITMAP MOVEABLE PURE "bitmaps\\n58w.bmp" +B58W BITMAP MOVEABLE PURE "bitmaps\\b58w.bmp" +R58W BITMAP MOVEABLE PURE "bitmaps\\r58w.bmp" +Q58W BITMAP MOVEABLE PURE "bitmaps\\q58w.bmp" +K58W BITMAP MOVEABLE PURE "bitmaps\\k58w.bmp" +P64O BITMAP MOVEABLE PURE "bitmaps\\p64o.bmp" +N64O BITMAP MOVEABLE PURE "bitmaps\\n64o.bmp" +B64O BITMAP MOVEABLE PURE "bitmaps\\b64o.bmp" +R64O BITMAP MOVEABLE PURE "bitmaps\\r64o.bmp" +Q64O BITMAP MOVEABLE PURE "bitmaps\\q64o.bmp" +K64O BITMAP MOVEABLE PURE "bitmaps\\k64o.bmp" +P64S BITMAP MOVEABLE PURE "bitmaps\\p64s.bmp" +N64S BITMAP MOVEABLE PURE "bitmaps\\n64s.bmp" +B64S BITMAP MOVEABLE PURE "bitmaps\\b64s.bmp" +R64S BITMAP MOVEABLE PURE "bitmaps\\r64s.bmp" +Q64S BITMAP MOVEABLE PURE "bitmaps\\q64s.bmp" +K64S BITMAP MOVEABLE PURE "bitmaps\\k64s.bmp" +P64W BITMAP MOVEABLE PURE "bitmaps\\p64w.bmp" +N64W BITMAP MOVEABLE PURE "bitmaps\\n64w.bmp" +B64W BITMAP MOVEABLE PURE "bitmaps\\b64w.bmp" +R64W BITMAP MOVEABLE PURE "bitmaps\\r64w.bmp" +Q64W BITMAP MOVEABLE PURE "bitmaps\\q64w.bmp" +K64W BITMAP MOVEABLE PURE "bitmaps\\k64w.bmp" +P72O BITMAP MOVEABLE PURE "bitmaps\\p72o.bmp" +N72O BITMAP MOVEABLE PURE "bitmaps\\n72o.bmp" +B72O BITMAP MOVEABLE PURE "bitmaps\\b72o.bmp" +R72O BITMAP MOVEABLE PURE "bitmaps\\r72o.bmp" +Q72O BITMAP MOVEABLE PURE "bitmaps\\q72o.bmp" +K72O BITMAP MOVEABLE PURE "bitmaps\\k72o.bmp" +P72S BITMAP MOVEABLE PURE "bitmaps\\p72s.bmp" +N72S BITMAP MOVEABLE PURE "bitmaps\\n72s.bmp" +B72S BITMAP MOVEABLE PURE "bitmaps\\b72s.bmp" +R72S BITMAP MOVEABLE PURE "bitmaps\\r72s.bmp" +Q72S BITMAP MOVEABLE PURE "bitmaps\\q72s.bmp" +K72S BITMAP MOVEABLE PURE "bitmaps\\k72s.bmp" +P72W BITMAP MOVEABLE PURE "bitmaps\\p72w.bmp" +N72W BITMAP MOVEABLE PURE "bitmaps\\n72w.bmp" +B72W BITMAP MOVEABLE PURE "bitmaps\\b72w.bmp" +R72W BITMAP MOVEABLE PURE "bitmaps\\r72w.bmp" +Q72W BITMAP MOVEABLE PURE "bitmaps\\q72w.bmp" +K72W BITMAP MOVEABLE PURE "bitmaps\\k72w.bmp" +P80O BITMAP MOVEABLE PURE "bitmaps\\p80o.bmp" +N80O BITMAP MOVEABLE PURE "bitmaps\\n80o.bmp" +B80O BITMAP MOVEABLE PURE "bitmaps\\b80o.bmp" +R80O BITMAP MOVEABLE PURE "bitmaps\\r80o.bmp" +Q80O BITMAP MOVEABLE PURE "bitmaps\\q80o.bmp" +K80O BITMAP MOVEABLE PURE "bitmaps\\k80o.bmp" +P80S BITMAP MOVEABLE PURE "bitmaps\\p80s.bmp" +N80S BITMAP MOVEABLE PURE "bitmaps\\n80s.bmp" +B80S BITMAP MOVEABLE PURE "bitmaps\\b80s.bmp" +R80S BITMAP MOVEABLE PURE "bitmaps\\r80s.bmp" +Q80S BITMAP MOVEABLE PURE "bitmaps\\q80s.bmp" +K80S BITMAP MOVEABLE PURE "bitmaps\\k80s.bmp" +P80W BITMAP MOVEABLE PURE "bitmaps\\p80w.bmp" +N80W BITMAP MOVEABLE PURE "bitmaps\\n80w.bmp" +B80W BITMAP MOVEABLE PURE "bitmaps\\b80w.bmp" +R80W BITMAP MOVEABLE PURE "bitmaps\\r80w.bmp" +Q80W BITMAP MOVEABLE PURE "bitmaps\\q80w.bmp" +K80W BITMAP MOVEABLE PURE "bitmaps\\k80w.bmp" +P87O BITMAP MOVEABLE PURE "bitmaps\\p87o.bmp" +N87O BITMAP MOVEABLE PURE "bitmaps\\n87o.bmp" +B87O BITMAP MOVEABLE PURE "bitmaps\\b87o.bmp" +R87O BITMAP MOVEABLE PURE "bitmaps\\r87o.bmp" +Q87O BITMAP MOVEABLE PURE "bitmaps\\q87o.bmp" +K87O BITMAP MOVEABLE PURE "bitmaps\\k87o.bmp" +P87S BITMAP MOVEABLE PURE "bitmaps\\p87s.bmp" +N87S BITMAP MOVEABLE PURE "bitmaps\\n87s.bmp" +B87S BITMAP MOVEABLE PURE "bitmaps\\b87s.bmp" +R87S BITMAP MOVEABLE PURE "bitmaps\\r87s.bmp" +Q87S BITMAP MOVEABLE PURE "bitmaps\\q87s.bmp" +K87S BITMAP MOVEABLE PURE "bitmaps\\k87s.bmp" +P87W BITMAP MOVEABLE PURE "bitmaps\\p87w.bmp" +N87W BITMAP MOVEABLE PURE "bitmaps\\n87w.bmp" +B87W BITMAP MOVEABLE PURE "bitmaps\\b87w.bmp" +R87W BITMAP MOVEABLE PURE "bitmaps\\r87w.bmp" +Q87W BITMAP MOVEABLE PURE "bitmaps\\q87w.bmp" +K87W BITMAP MOVEABLE PURE "bitmaps\\k87w.bmp" +P95O BITMAP MOVEABLE PURE "bitmaps\\p95o.bmp" +N95O BITMAP MOVEABLE PURE "bitmaps\\n95o.bmp" +B95O BITMAP MOVEABLE PURE "bitmaps\\b95o.bmp" +R95O BITMAP MOVEABLE PURE "bitmaps\\r95o.bmp" +Q95O BITMAP MOVEABLE PURE "bitmaps\\q95o.bmp" +K95O BITMAP MOVEABLE PURE "bitmaps\\k95o.bmp" +P95S BITMAP MOVEABLE PURE "bitmaps\\p95s.bmp" +N95S BITMAP MOVEABLE PURE "bitmaps\\n95s.bmp" +B95S BITMAP MOVEABLE PURE "bitmaps\\b95s.bmp" +R95S BITMAP MOVEABLE PURE "bitmaps\\r95s.bmp" +Q95S BITMAP MOVEABLE PURE "bitmaps\\q95s.bmp" +K95S BITMAP MOVEABLE PURE "bitmaps\\k95s.bmp" +P95W BITMAP MOVEABLE PURE "bitmaps\\p95w.bmp" +N95W BITMAP MOVEABLE PURE "bitmaps\\n95w.bmp" +B95W BITMAP MOVEABLE PURE "bitmaps\\b95w.bmp" +R95W BITMAP MOVEABLE PURE "bitmaps\\r95w.bmp" +Q95W BITMAP MOVEABLE PURE "bitmaps\\q95w.bmp" +K95W BITMAP MOVEABLE PURE "bitmaps\\k95w.bmp" +P108O BITMAP MOVEABLE PURE "bitmaps\\p108o.bmp" +N108O BITMAP MOVEABLE PURE "bitmaps\\n108o.bmp" +B108O BITMAP MOVEABLE PURE "bitmaps\\b108o.bmp" +R108O BITMAP MOVEABLE PURE "bitmaps\\r108o.bmp" +Q108O BITMAP MOVEABLE PURE "bitmaps\\q108o.bmp" +K108O BITMAP MOVEABLE PURE "bitmaps\\k108o.bmp" +P108S BITMAP MOVEABLE PURE "bitmaps\\p108s.bmp" +N108S BITMAP MOVEABLE PURE "bitmaps\\n108s.bmp" +B108S BITMAP MOVEABLE PURE "bitmaps\\b108s.bmp" +R108S BITMAP MOVEABLE PURE "bitmaps\\r108s.bmp" +Q108S BITMAP MOVEABLE PURE "bitmaps\\q108s.bmp" +K108S BITMAP MOVEABLE PURE "bitmaps\\k108s.bmp" +P108W BITMAP MOVEABLE PURE "bitmaps\\p108w.bmp" +N108W BITMAP MOVEABLE PURE "bitmaps\\n108w.bmp" +B108W BITMAP MOVEABLE PURE "bitmaps\\b108w.bmp" +R108W BITMAP MOVEABLE PURE "bitmaps\\r108w.bmp" +Q108W BITMAP MOVEABLE PURE "bitmaps\\q108w.bmp" +K108W BITMAP MOVEABLE PURE "bitmaps\\k108w.bmp" +P116O BITMAP MOVEABLE PURE "bitmaps\\p116o.bmp" +N116O BITMAP MOVEABLE PURE "bitmaps\\n116o.bmp" +B116O BITMAP MOVEABLE PURE "bitmaps\\b116o.bmp" +R116O BITMAP MOVEABLE PURE "bitmaps\\r116o.bmp" +Q116O BITMAP MOVEABLE PURE "bitmaps\\q116o.bmp" +K116O BITMAP MOVEABLE PURE "bitmaps\\k116o.bmp" +P116S BITMAP MOVEABLE PURE "bitmaps\\p116s.bmp" +N116S BITMAP MOVEABLE PURE "bitmaps\\n116s.bmp" +B116S BITMAP MOVEABLE PURE "bitmaps\\b116s.bmp" +R116S BITMAP MOVEABLE PURE "bitmaps\\r116s.bmp" +Q116S BITMAP MOVEABLE PURE "bitmaps\\q116s.bmp" +K116S BITMAP MOVEABLE PURE "bitmaps\\k116s.bmp" +P116W BITMAP MOVEABLE PURE "bitmaps\\p116w.bmp" +N116W BITMAP MOVEABLE PURE "bitmaps\\n116w.bmp" +B116W BITMAP MOVEABLE PURE "bitmaps\\b116w.bmp" +R116W BITMAP MOVEABLE PURE "bitmaps\\r116w.bmp" +Q116W BITMAP MOVEABLE PURE "bitmaps\\q116w.bmp" +K116W BITMAP MOVEABLE PURE "bitmaps\\k116w.bmp" +P129O BITMAP MOVEABLE PURE "bitmaps\\p129o.bmp" +N129O BITMAP MOVEABLE PURE "bitmaps\\n129o.bmp" +B129O BITMAP MOVEABLE PURE "bitmaps\\b129o.bmp" +R129O BITMAP MOVEABLE PURE "bitmaps\\r129o.bmp" +Q129O BITMAP MOVEABLE PURE "bitmaps\\q129o.bmp" +K129O BITMAP MOVEABLE PURE "bitmaps\\k129o.bmp" +P129S BITMAP MOVEABLE PURE "bitmaps\\p129s.bmp" +N129S BITMAP MOVEABLE PURE "bitmaps\\n129s.bmp" +B129S BITMAP MOVEABLE PURE "bitmaps\\b129s.bmp" +R129S BITMAP MOVEABLE PURE "bitmaps\\r129s.bmp" +Q129S BITMAP MOVEABLE PURE "bitmaps\\q129s.bmp" +K129S BITMAP MOVEABLE PURE "bitmaps\\k129s.bmp" +P129W BITMAP MOVEABLE PURE "bitmaps\\p129w.bmp" +N129W BITMAP MOVEABLE PURE "bitmaps\\n129w.bmp" +B129W BITMAP MOVEABLE PURE "bitmaps\\b129w.bmp" +R129W BITMAP MOVEABLE PURE "bitmaps\\r129w.bmp" +Q129W BITMAP MOVEABLE PURE "bitmaps\\q129w.bmp" +K129W BITMAP MOVEABLE PURE "bitmaps\\k129w.bmp" GALACTIC BITMAP MOVEABLE PURE "bitmaps\\galactic.bmp" TIM BITMAP MOVEABLE PURE "bitmaps\\tim.bmp" -- Dimi.

1 0

spec file syntax and automated generation
by Martin Troester 19 Aug '03

19 Aug '03

Hi, apart from my desperate linking problems I mentioned in the wine-users list, I have some questions regarding the spec file for defining and wrapping exported symbols: 1. The winebuild manpage only mentions ptr, str, wstr, long and double as valid Win32 function argument size information - is the amount and kind of symbols really important, or is it just the amount of used stack space? 1a: Assuming a function taking two boolean parameters (or anything logically smaller than 32bit) like this: > void func(boolean a, boolean b) Do I specify it in the spec file as > @ stdcall func(long,long) or as > @ stdcall func(long) ? I am not too familiar with assembler, but I would assume the first is right, since two arguments are pushed on the stack, each using 32bit. 1b: What about structs? Do I have to give the size as multiples of 32bit? Assuming the following example: > typedef struct { > long var1; > double var2; > bool var3; >} test_struct; Assuming the function to be exported looks like > int test_func ( test_struct test ); Is the corresponding spec-file entry for 64bit stack space for function parameters > @ stdcall test_func(double,double) due to the fact that I just care about the absolute amount of stack-space used for the struct, or do I have to regard the size of each single member, thus pushing > @ stdcall test_func(long,double,long) on the stack? 1c: What about classes in C++-exported functions, as well as mangled names? I suppose I have to use the mangled name in the spec-file, but I am not sure about that. How do I calculate stack space for classes, or are they always put on the stack as references or pointers? If yes, I assume both take 32bit. 2. One question regarding the spec-file: The following questions arise since I wrote the .spec file myself. Is there any automation available in this field? Seems to be quite some work for several DLLs, and has a high potential to cause errors when done manually... What I did was extracting output from dumpbin for the original Win32 dll, replacing all decorated exported function names with stdcall, while using cdecl for the undecorated ones. Is this assumption right? Thanks in advance for your answers and help. Cheers, Martin--

1 0

REGRESSION: environment variables no longer possible
by Marcus Meissner 19 Aug '03

19 Aug '03

Hi, Apparently the changes from yesterday removed support of environment variables in registry keys (very useful for the "Path" keys in the "Drive" sections). Can it be readded? Or is there a rational behind it? Ciao, Marcus

1 0

Re: Spanish translation of winemine
by Marcelo Duarte 19 Aug '03

19 Aug '03

----- Original Message ----- From: "José Manuel Ferrer Ortiz" <jmfo1982(a)yahoo.es> > > > Do you plan to translate other programs and dlls > > that still they lack? > > Probably, if I have enough spare time (I'll have two > exams in September). I think about evaluating the use of all the necessary translations. When I will have this soon, I will inform you, so that you can collaborate more a little. ;) > > What is the best wine mailing list to request the > addition of the Spain's Spanish sublanguage? > wine-patches to send your patches and additions (If I understood your question).

1 0

Re: calls to int 3d corrupt the stack
by Jukka Heinonen 19 Aug '03

19 Aug '03

FPU handling got broken over half a year ago when I removed separate interrupt DLL and added support for DPMI32. Interrupt DLL made sure that builtin protected mode interrupt handlers saw regular IRET return record on stack. Current protected mode interrupt code does not provide an IRET record and real mode interrupt code never did provide it. I'm currently working on a two part fix for FPU code: 1. Make sure that DOSRELAY called via RELAY_BuildCallFrame sees original stack and code pointers and can modify them. 2. Make FPU emulation use CS/IP instead of IRET record. Both of these patches are about 10 lines of code so I guess I shall have it fixed within a week, assuming testing patches don't take up too much time. -- Jukka Heinonen <http://www.iki.fi/jhei/>

2 1

Fw: Fix treeview with checkboxes creation
by Marcelo Duarte 19 Aug '03

19 Aug '03

I think that a comment in the code would have been very good. ;) > ----- Original Message ----- > From: "Dmitry Timoshkov" <dmitry(a)baikal.ru> > To: "Maxime Bellengé" <maxime.bellenge(a)laposte.net> > Cc: <wine-devel(a)winehq.com> > Sent: Monday, August 18, 2003 11:42 PM > Subject: Re: Fix treeview with checkboxes creation > > > > "Maxime Bellengé" <maxime.bellenge(a)laposte.net> wrote: > > > > > - hdc = CreateCompatibleDC(0); > > > - hbm = CreateCompatibleBitmap(hdc, 48, 16); > > > > > > hbm is a 1 bit per pixel bitmap > > > > > > + hdcScreen = CreateDCA("DISPLAY", NULL, NULL, NULL); > > > + > > > + hdc = CreateCompatibleDC(hdcScreen); > > > + hbm = CreateCompatibleBitmap(hdcScreen, 48, 16); > > > > > > hbm has now a screen compliant depth > > > > You are right. Probably it's better to just replace > CreateCompatibleBitmap() > > by CreateBitmap() with the desired number of bits per pixel. In any case > > send what you see more appropriate. > > > > -- > > Dmitry. > > > > > > >

1 0

How Thread Local Storage works in WIN32 and in Visual C++
by Jonathan Wilson 19 Aug '03

19 Aug '03

This is information I have figured out and found out about how Thread Local Storage (that is, variables declared with __declspec(thread)) works in Win32 from the perspective of the exe file (as opposed to the perspective of the kernel). I am posting this to the ReactOS list since it needs support for this in its kernel code. I am posting this to the WINE list since it also should support this from a kernel point of view. Plus it should (ideally) support __declspec(thread) in WineGCC at some point if that is possible I am posting this to the MingW list since MingW needs __declspec(thread) support. First, TLS in visual C++ relies on: 1.the __declspec(thread) keyword & some special stuff the compiler does when accessing TLS variables 2.the .tls segment in the PE file 3.the IMAGE_TLS_DIRECTORY32 structure (pointed at by a field in the PE header and stored in the read only data segment) and the things it points at (specificly the TlsStart, TlsEnd and TlsIndex variables) TlsIndex is stored in the read/write data segment Tls 4.the tlssup.obj file (which is inside the Visual C++ runtime library .lib files like libc.lib and msvcrt.lib) and 5.a linker feature that will combine segments in a special way if they are named right (for example, .tls will be written first, then anything labeled .tls$ then .tls$zzz. All of them will be combined into one segment labeled .tls) Firstly, when you declare a variable as __declspec(thread), the compiler accesses it a special way. It takes the current value in the TlsIndex variable. Then it takes the value stored at offset 2C in the TEB (which contains the pointer to the TLS data area for that thread) it then does TlsPointer + TlsIndex * 4. This is what it uses when it reads and writes from Thread Local Storage variables. The first variable seems to be stored at (this address) + 4 then + 8 and so on. at (this address) is the _tls_start variable as explained below) Also, when you declare a __declspec(thread) variable, its put into the obj file inside the .tls$ segment. Most of the magic happens inside the linker. First, lets explain tlssup.obj This contains an item called __tls_used that resides in the read only data segment which then becomes the TLS directory pointed at by the PE header. This points at __tls_start which is in the .tls segment, __tls_end which is in the .tls$zzz segment and __tls_index which is in the read write data segment There is also ___xl_a and ___xl_z, ___xl_a is pointed to by the thread callbacks pointer. So, what we have in the resulting exe file is: the __tls_used variable in the read only data segment the __tls_index variable in the read write data segment and the .tls segment containing: __tls_start //all the user declared __declspec(thread) variables __tls_end And we also have ___xl_a followed by calls to the thread callback functions folowed by ___xl_z So, basicly, to implement TLS in compilers, we need to: 1.make __declspec(thread) point at the thread local storage and get the compiler to access these variables correctly. 2.make the variables all end up in the correct place in the exe file with the TLS directory pointing at the start and end of the list 3.write the needed support code for the RTL (as needed) 4.make the callbacks (if needed) get generated & output to the exe file properly and 5.make sure that the PE header points to the TLS directory. If anyone has anything to add or wants more details, do reply As for kernel-mode support in ReactOS or whatever, that seems easy enough to implement, anyone wanna have a go?

1 0

How Thread Local Storage works in WIN32 and in Visual C++
by Jonathan Wilson 19 Aug '03

19 Aug '03

This is information I have figured out and found out about how Thread Local Storage (that is, variables declared with __declspec(thread)) works in Win32 from the perspective of the exe file (as opposed to the perspective of the kernel). I am posting this to the ReactOS list since it needs support for this in its kernel code. I am posting this to the WINE list since it also should support this from a kernel point of view. Plus it should (ideally) support __declspec(thread) in WineGCC at some point if that is possible I am posting this to the MingW list since MingW needs __declspec(thread) support. First, TLS in visual C++ relies on: 1.the __declspec(thread) keyword & some special stuff the compiler does when accessing TLS variables 2.the .tls segment in the PE file 3.the IMAGE_TLS_DIRECTORY32 structure (pointed at by a field in the PE header and stored in the read only data segment) and the things it points at (specificly the TlsStart, TlsEnd and TlsIndex variables) TlsIndex is stored in the read/write data segment Tls 4.the tlssup.obj file (which is inside the Visual C++ runtime library .lib files like libc.lib and msvcrt.lib) and 5.a linker feature that will combine segments in a special way if they are named right (for example, .tls will be written first, then anything labeled .tls$ then .tls$zzz. All of them will be combined into one segment labeled .tls) Firstly, when you declare a variable as __declspec(thread), the compiler accesses it a special way. It takes the current value in the TlsIndex variable. Then it takes the value stored at offset 2C in the TEB (which contains the pointer to the TLS data area for that thread) it then does TlsPointer + TlsIndex * 4. This is what it uses when it reads and writes from Thread Local Storage variables. The first variable seems to be stored at (this address) + 4 then + 8 and so on. at (this address) is the _tls_start variable as explained below) Also, when you declare a __declspec(thread) variable, its put into the obj file inside the .tls$ segment. Most of the magic happens inside the linker. First, lets explain tlssup.obj This contains an item called __tls_used that resides in the read only data segment which then becomes the TLS directory pointed at by the PE header. This points at __tls_start which is in the .tls segment, __tls_end which is in the .tls$zzz segment and __tls_index which is in the read write data segment There is also ___xl_a and ___xl_z, ___xl_a is pointed to by the thread callbacks pointer. So, what we have in the resulting exe file is: the __tls_used variable in the read only data segment the __tls_index variable in the read write data segment and the .tls segment containing: __tls_start //all the user declared __declspec(thread) variables __tls_end And we also have ___xl_a followed by calls to the thread callback functions folowed by ___xl_z So, basicly, to implement TLS in compilers, we need to: 1.make __declspec(thread) point at the thread local storage and get the compiler to access these variables correctly. 2.make the variables all end up in the correct place in the exe file with the TLS directory pointing at the start and end of the list 3.write the needed support code for the RTL (as needed) 4.make the callbacks (if needed) get generated & output to the exe file properly and 5.make sure that the PE header points to the TLS directory. If anyone has anything to add or wants more details, do reply :) As for kernel-mode support in ReactOS or whatever, that seems easy enough to implement, anyone wanna have a go?

1 1

Anyone having problems with Alsa ?
by Sylvain Petreolle 19 Aug '03

19 Aug '03

After upgrading my alsa drivers from 0.9.4 to 0.9.6, the wine alsa driver isnt working anymore on my system. Sound is working when I use the OSS emulation with wineoss.drv. But if i use winealsa.drv, many winmm tests fail. (I attached the log) ===== Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) ICQ #170597259 alias upsf='false ; while [ $? -ne 0 ] ; do cvs update -APd ; done 2>&1 |tee cvslog' "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Re: Int21 : Dont reset systematically CFLAG
by Jukka Heinonen 19 Aug '03

19 Aug '03

Sylvain Petreolle wrote: > Dont reset systematically CFLAG when calling the int 21 handler. > Some functions dont change it. This patch must not be applied because it is highly likely that it will break almost all DOS programs. Fix itself is correct but before this patch can be applied it must be made sure that all functions that are supposed to reset CFLAG really reset it. -- Jukka Heinonen <http://www.iki.fi/jhei/>

2 1

Re: Implement registry key unloading
by Steven Edwards 18 Aug '03

18 Aug '03

> ChangeLog: > * Implement registry key unloading Speaking of the registry if you guys are interested in implementing a faster binary format for the registry take a look at what we have done in ReactOS. Eric Kohl has offered to license his work as LGPL if you guys want to try to move to the same format we use. It should be much faster then the existing system currently in WINE. Now that we have a GUI regedit for WINE and ReactOS once write support is implemented then it might be a good idea to implement this. Thanks Steven

1 0

Re: some questions (required for my dmusic work)
by John K. Hohm 18 Aug '03

18 Aug '03

> 2. I still can't figure how to implement interface that consist of two > interfaces (I have IDirectMusicLoaderStream which should consist of > IStream and IDirectMusicGetLoader). Can someone send me detailed > instructions how to do it? (I can't find any examples) I think what you want to do is implement two interfaces in one object, which is a bit different than putting two interfaces in one interface (every interface has IUnknown in it). For an example, see the implementation of the StdComponentCategoriesMgr in dlls/comcat, which might be slightly unusual because there is just one static instance rather than potentially many dynamically created instances. The implementation is broken down like this: comcat_private.h declaration of ComCatMgrImpl struct with three Vtbl pointers manager.c implementation of IUnknown, used by other interface impls too, and static ComCatMgrImpl instance, would normally be alloc'd and init'd information.c implementation of ICatInformation, partially forwards to IUnknown register.c implementation of ICatRegister, partially forwards to IUnknown There are probably other examples, but that is one I'm familiar with.

1 0

Re: Re: winevdm: can't exec
by Christian Costa 18 Aug '03

18 Aug '03

Hi, What about adding the comment in the code? :-) Bye, Christian Message du 18/08/03 12:05 De : Dmitry Timoshkov A : Dominik Strasser Copie à : wine-patches(a)winehq.com Objet : Re: winevdm: can't exec Hello, Changelog: Windows ignores values of e_cparhdr and e_crlc of the MZ header. --- cvs/hq/wine/loader/module.c Tue Jul 22 01:13:12 2003 +++ wine/loader/module.c Mon Aug 18 09:54:32 2003 @@ -200,10 +200,6 @@ * structure encompasses the "Offset to extended header" * field. */ - if ((header.mz.e_cparhdr << 4) < sizeof(IMAGE_DOS_HEADER)) - return BINARY_DOS; - if (header.mz.e_crlc && (header.mz.e_lfarlc < sizeof(IMAGE_DOS_HEADER))) - return BINARY_DOS; if (header.mz.e_lfanew < sizeof(IMAGE_DOS_HEADER)) return BINARY_DOS; if (SetFilePointer( hfile, header.mz.e_lfanew, NULL, SEEK_SET ) == -1)

1 0

exceptions
by flyker 18 Aug '03

18 Aug '03

I use __TRY __EXCEPT defined in <wine/exception.h> but i get error: undefined reference to `__wine_exception_handler(__EXCEPTION_RECORD*, __EXCEPTION_FRAME*, _CONTEXT86*, void*)' what library support this ?

2 1

Compiling winboard (GNU Chess)
by root 18 Aug '03

18 Aug '03

Hi everybody, I'm busy with compiling winboard (the win32 version of xboard -- ftp://ftp.gnu.org/pub/gnu/winboard-4_2_6-src.tar.gz ). I made this makefile based on cygwin.mak (included in the source tarball) and I ran into problem. (I changed none of the source files.) The problem is probably one of the wine header files because the compiler gives this output: winegcc -I. -mwindows -mno-cygwin -g -c -o winboard.o winboard.c In file included from /usr/local/include/wine/windows/windows.h:55, from winboard.c:54: /usr/local/include/wine/windows/mmsystem.h:69: parse-fout voor stringconstante Error: gcc failed. make: [winboard.o] Fout 2 (genegeerd) winegcc -I. -mwindows -mno-cygwin -g -c -o backend.o backend.c flex -L parser.l cp lex.yy.c parser.c winegcc -I. -mwindows -mno-cygwin -g -c -o parser.o parser.c winegcc -I. -mwindows -mno-cygwin -g -c -o moves.o moves.c winegcc -I. -mwindows -mno-cygwin -g -c -o lists.o lists.c winegcc -I. -mwindows -mno-cygwin -g -c -o gamelist.o gamelist.c winegcc -I. -mwindows -mno-cygwin -g -c -o pgntags.o pgntags.c winegcc -I. -mwindows -mno-cygwin -g -c -o wedittags.o wedittags.c In file included from /usr/local/include/wine/windows/windows.h:55, from wedittags.c:26: /usr/local/include/wine/windows/mmsystem.h:69: parse-fout voor stringconstante Error: gcc failed. make: [wedittags.o] Fout 2 (genegeerd) winegcc -I. -mwindows -mno-cygwin -g -c -o wgamelist.o wgamelist.c In file included from /usr/local/include/wine/windows/windows.h:55, from wgamelist.c:26: /usr/local/include/wine/windows/mmsystem.h:69: parse-fout voor stringconstante Error: gcc failed. make: [wgamelist.o] Fout 2 (genegeerd) winegcc -I. -mwindows -mno-cygwin -g -c -o zippy.o zippy.c winegcc -I. -mwindows -mno-cygwin -g -c -o wsockerr.o wsockerr.c res --use-temp-file winboard.rc -O coff -o wbres.o make: res: Commando niet gevonden make: [wbres.o] Fout 127 (genegeerd) winegcc -I. -mwindows -mno-cygwin -g -c -o wclipbrd.o wclipbrd.c In file included from /usr/local/include/wine/windows/windows.h:55, from wclipbrd.c:26: /usr/local/include/wine/windows/mmsystem.h:69: parse-fout voor stringconstante Error: gcc failed. make: [wclipbrd.o] Fout 2 (genegeerd) winegcc -I. -mwindows -mno-cygwin -g -c -o woptions.o woptions.c In file included from /usr/local/include/wine/windows/windows.h:55, from woptions.c:26: /usr/local/include/wine/windows/mmsystem.h:69: parse-fout voor stringconstante Error: gcc failed. make: [woptions.o] Fout 2 (genegeerd) winegcc -I. -mwindows -mno-cygwin -mwindows -Xlinker "-e" -Xlinker "_mainCRTStartup" -g -mno-cygwin winboard.o backend.o parser.o moves.o lists.o gamelist.o pgntags.o wedittags.o wgamelist.o zippy.o wsockerr.o wbres.o wclipbrd.o woptions.o \ -lwsock32 -lcomctl32 -lwinmm -lkernel32 \ -ladvapi32 -luser32 -lgdi32 -lcomdlg32 -lwinspool \ -o winboard.exe gcc: -e: linker input file unused because linking not done gcc: _mainCRTStartup: linker input file unused because linking not done Error: Can n��lllllll Error: /usr/local/bin/winewrap failed. make: [winboard.exe] Fout 2 (genegeerd) [root@erwin winboard]# ock32 -lcomctl32 -lwinmm -lkernel32 \ > -ladvapi32 -luser32 -lgdi32 -lcomdlg32 -lwinspool \ > -o winboard.exe bash: ock32: command not found [root@erwin winboard]# gcc: -e: linker input file unused because linking not done bash: gcc:: command not found [root@erwin winboard]# gcc: _mainCRTStartup: linker input file unused because linking not done bash: gcc:: command not found [root@erwin winboard]# Error: Can n��lllllll bash: Error:: command not found [root@erwin winboard]# Error: /usr/local/bin/winewrap failed. bash: Error:: command not found [root@erwin winboard]# make: [winboard.exe] Fout 2 (genegeerd) As you can clearly see, some of the files compile correctly but 5 files have a problem with a header file called mmsystem.h. If anyone can fix this we have another program for the Fun Projects page :). -- E.C.F. Wolff

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel