March 2001 - Wine-Devel - list.winehq.org

Re: Handling overlapping buffers in wcstombs_sbcs

by Alexandre Julliard

Fran=E7ois Gouget <fgouget(a)codeweavers.com> writes: > Actually the documentation specifies that WideCharToMultiByte (cal= led > by ConvertVersionInfo32To16) fails if the source and destination > pointers are the same. But it does not specify what happens if the > buffers merelyt overlap. And of course in the ConvertVersionInfo32To16 > case there's a 2 byte difference between them! Then ConvertVersionInfo32To16 is broken; WideCharToMultiByte does not support overlapping buffers. > I'm not really convinced by the loop unrolling but I tried to keep= it > anyway. I just modified it a bit. If someone's interested in doing > actual performance tests, wants to look at the assembly or knows how > manual loop unrolling must be done, go ahead. You know, I did exactly that (looking at the assembly and running performance tests) when implementing it; it may be possible to improve it more by optimizing CPU pipelines usage, which is something I don't know too much about. But I strongly doubt you can improve it by only looking at the C source... --=20 Alexandre Julliard julliard(a)winehq.com

March 23, 2001

Re: [PATCH] Add Callback for wavemapper -> widOpen

by James Hatheway

> But these other functions are not using the WINE_MLD internal winmm > structure, so why do you need it in widOpen()? Couldn't you instead do > exactly what wodOpen() does? Hi Alexandre, Ok, I see what you are saying now. Sorry about that. Humm.. I guess the short answer is because it doesn't work if I do it the same way wodOpen does. :-) I'll look into this and send another patch when I have a bit of time (maybe today or on Monday), it appears that it is breaking in MMDRV_WaveIn_Callback, but I'm not 100% sure yet... -James -- James Hatheway Software Designer - Macadamian Technologies, Inc. james(a)macadamian.com ~ http://www.macadamian.com "Man könnte froh sein, wenn die Luft so rein wäre wie das Bier" "One could be happy if the air were as pure as the beer"

March 23, 2001

Re: [PATCH] Add Callback for wavemapper -> widOpen

by Alexandre Julliard

"James Hatheway" <james(a)macadamian.com> writes: > I implemented the callback in a very similar way as the Wave out callback > is implemented. You can see this in the functions wodOpen(), wodOpenHelper(), > and WAVEMAP_DstCallback() , look at the data passed in the wom structure > (in dlls/winmm/wavemap/wavemap.c). I don't see any other way that I will > be able to callback into the app when the WineOSS layer notifies the wavemap > layer. The way it is now (wineoss directly calling the app) > causes my app to crash, and doesn't work that way on waveout. But these other functions are not using the WINE_MLD internal winmm structure, so why do you need it in widOpen()? Couldn't you instead do exactly what wodOpen() does? -- Alexandre Julliard julliard(a)winehq.com

March 22, 2001

Re: [PATCH] Add Callback for wavemapper -> widOpen

by James Hatheway

> It doesn't seem right to use winmm internal structures here. Are you > sure this is the right way to do it? Hi Alexandre, I implemented the callback in a very similar way as the Wave out callback is implemented. You can see this in the functions wodOpen(), wodOpenHelper(), and WAVEMAP_DstCallback() , look at the data passed in the wom structure (in dlls/winmm/wavemap/wavemap.c). I don't see any other way that I will be able to callback into the app when the WineOSS layer notifies the wavemap layer. The way it is now (wineoss directly calling the app) causes my app to crash, and doesn't work that way on waveout. -James -- James Hatheway Software Designer - Macadamian Technologies, Inc. james(a)macadamian.com ~ http://www.macadamian.com "Man könnte froh sein, wenn die Luft so rein wäre wie das Bier" "One could be happy if the air were as pure as the beer"

March 22, 2001

Re: Nasty Wine/kernel bug, anyone?

by Alexandre Julliard

lawson_whitney(a)juno.com writes: > Or is this a different glibc bug? Yes, it's apparently a bug in reference counting when freeing libraries; since we never free our libraries at the moment, we haven't run into this one yet. -- Alexandre Julliard julliard(a)winehq.com

March 22, 2001

Re: [PATCH] Add Callback for wavemapper -> widOpen

by Alexandre Julliard

"James Hatheway" <james(a)macadamian.com> writes: > Changelog: > James Hatheway - james(a)macadamian.com > widOpen in the wavemapper should use a callback. It doesn't seem right to use winmm internal structures here. Are you sure this is the right way to do it? -- Alexandre Julliard julliard(a)winehq.com

March 22, 2001

Re: problems compiling mfc with winelib

by Francois Gouget

On 21 Mar 2001, Doug Alcorn wrote: [...] > So, my > assumption based on reading winehq.com is that I need to compile the > mfc using winelib. Correct. > I got all the code over to my linux box and converted all the > files/directories to lowercase only. winemaker can do that for you. [...] > I had to define both CFLAGS and CPPFLAGS "-D_WIN32 -DWIN32 -D_WINDOWS > -D_MBSC" in the environment. Here's my configure line: > > $ ./configure --with-win=/path/to/wine/sources > --with-atl-includes=/path/to/atl/includes > --with-mfc-includes=/path/to/parent/of/mfc/includes '--with-atl-includes' and '--with-mfc-includes' are only necessary when compiling an MFC application, not the MFC themselves. They are used to specify where to find the MFC includes. But since you're compiling the MFC you already know where they are: it's coded into your Makefile.in. > It goes allong pretty well until it checks for afx.h. That's when it > bombs majorly. Yes. I guess you let winemaker do its stuff and it guessed that the MFC sources are MFC-based because of the stdafx.h file. But they are obviously not :-)! I suggest you rerun winemaker in interactive mode 'winemaker --interactive .' and specify --nomfc in the mfc/src directory (and the atl/src directory if you're going to really use it which you may very well not). This will also give you a chance to specify the exact include path for each directory. > I get pages and pages of compile time errors in the > config.log. Lots of parse errors, syntax errors, scoping errors, > redifinitions... lots of stuff. Once you get past the configure step above, which should be simple once you've done the above, you'll be able to take care of these. It will take some time, see my recent post in the newsgroup (titled 'Re: winelib + MFC'). > Am I right that I have to compile mfc? Yes, you have to. There's at least two good reasons for this: - winebuild cannot yet import dlls directly, but even if it could, it would not work with C++ dlls because VC++ and g++ use different binary layouts for classes, virtual tables, name mangling, etc. - the headers don't compile as is. So you'll have to modify them before you can use them anyway. > Is this something that most > developers using winelib to compile windows programs do? I don't really know. I guess if you have a large application it would be much more work to get rid of the MFC than to compile the MFC with Winelib. You may also end up having to support two versions unless you go for a cross-platform toolkit. > Are there instructions for doing so? Not much. See my post to the newsgroup. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ In a world without fences who needs Gates?

March 22, 2001

Re: Nasty Wine/kernel bug, anyone?

by lawson_whitney＠juno.com

On Thu, 22 Mar 2001, gerard patel wrote: > Btw, since Borland released Kylix they talk of a glibc bug in dlopen : > > http://community.borland.com/article/0,1410,26998,00.html > > do you know if it's a concern for Wine too ? > Didn't we code around one of those not too long ago? One in glibc-2.1, and a different one in glibc-2.2 that was provoked by our solution to the first? > Gerard Or is this a different glibc bug? Lawson ---cut here ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

March 22, 2001

Re: Port to OS/390 mainframe USS?

by James Hatheway

> > > Is there someone at Ulrich that I should be talking to? > > > > Ulrich is a person: Ulrich Weigand. He subscribes to the mailing list > > so I am sure he saw your message. You can get his email address from the > > mail list archives. > > ROTFL ! > > This really fits nicely into the old suspicion that he's not simply one > person, but in fact a myriad of people happily hacking away :) > (due to the amount of patches he used to submit) Hmm, I didn't see that angle. That is quite funny. I can picture a team of developers getting up on stage at a trade show and saying "We Are Ulrich!!" ^_^ -James -- James Hatheway Software Designer - Macadamian Technologies, Inc. james(a)macadamian.com ~ http://www.macadamian.com "Man könnte froh sein, wenn die Luft so rein wäre wie das Bier" "One could be happy if the air were as pure as the beer"

March 22, 2001

Re: Nasty Wine/kernel bug, anyone?

by gerard patel

At 12:14 PM 20/03/2001 -0600, you wrote: <snip> >I saw at least other user report on this (Steve Fox reported this >with Lotus Notes). > >My best guess is that this is a bug in the vfat driver, >but that's just a hunch. Where did this Notes bug turn up ? I never saw it on the news group, and it's not in your bug database. I'm curious because I would like to know how to reproduce it (I don't want not install Win98 and Outlook to test this :-/) Btw, since Borland released Kylix they talk of a glibc bug in dlopen : http://community.borland.com/article/0,1410,26998,00.html do you know if it's a concern for Wine too ? Gerard

March 22, 2001

Re: Port to OS/390 mainframe USS?

by Andreas Mohr

On Wed, Mar 21, 2001 at 02:27:08PM -0500, James Hatheway wrote: > > Is there someone at Ulrich that I should be talking to? > > Ulrich is a person: Ulrich Weigand. He subscribes to the mailing list > so I am sure he saw your message. You can get his email address from the > mail list archives. ROTFL ! This really fits nicely into the old suspicion that he's not simply one person, but in fact a myriad of people happily hacking away :) (due to the amount of patches he used to submit) -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.germany.net/100-30936/

March 22, 2001

problems compiling mfc with winelib

by Doug Alcorn

I have a small apps with only about half a dozen dialogs. It was originally developed in MS-DevStudio. Our desire is to use the same code between MS-Windows and Linux/Unix using the winelib. This app is derived from CWinApp and uses mfc for all the widgets. I'm told it would take too much effort to redo the app without mfc (I'm not a windows programmer, and don't know much about all that). So, my assumption based on reading winehq.com is that I need to compile the mfc using winelib. I got all the code over to my linux box and converted all the files/directories to lowercase only. I got the mfc, atl, and some other include directory that was under "Program Files/Visual Studio/VC98" (or something similar). I ran winemaker on the mfc directory and successfully got the configure script built. The problem is getting the make files built. I had to define both CFLAGS and CPPFLAGS "-D_WIN32 -DWIN32 -D_WINDOWS -D_MBSC" in the environment. Here's my configure line: $ ./configure --with-win=/path/to/wine/sources --with-atl-includes=/path/to/atl/includes --with-mfc-includes=/path/to/parent/of/mfc/includes It goes allong pretty well until it checks for afx.h. That's when it bombs majorly. I get pages and pages of compile time errors in the config.log. Lots of parse errors, syntax errors, scoping errors, redifinitions... lots of stuff. Am I right that I have to compile mfc? Is this something that most developers using winelib to compile windows programs do? Are there instructions for doing so? At this point I'm totally stumped. I'm not about to start debugging mfc. I'll re-write the app before I do that. What is the suggested course of action? -- (__) Doug Alcorn <doug(a)lathi.net> http://www.lathi.net oo / PGP 02B3 1E26 BCF2 9AAF 93F1 61D7 450C B264 3E63 D543 |_/ If you're a capitalist and you have the best goods and they're free, you don't have to proselytize, you just have to wait.

March 22, 2001

Re: Nasty Wine/kernel bug, anyone?

by Steve Fox

> Could you check in which kernel routine the process is blocked? > (e.g. using ps -Ao pid,wchan) Running 'ps -Ao pid,wchan' shows that all the processes in uninterruptible sleep are in the do_exit routine. >> Because the process is already gone, I can't strace or gdb it. > > What do you mean 'the process is already gone'? Could it be that > ptrace doesn't work because the Wine server has already attached > to that client process? I am unable to attach to it with gdb either. I get the error: Attaching to program: /opt/notes5/wine/bin/wine, Pid 22018 ptrace: Operation not permitted. > Steve, is VFAT also involved in your case? Only ext2 here. Steve Fox IBM Linux Technology Center http://oss.software.ibm.com/developerworks/opensource/linux http://stevefx.rchland.ibm.com (IBM Intranet)

March 21, 2001

Re: Port to Sparc64

by Ulrich Weigand

Hi Jutta, > What about the suggested port to Sparc? > Did anybody work on that again? I did send my fixes to Alexandre; I think the current release should build on Sparc (unless it has been broken again in the meantime -- I haven't tried for some time). In any case, that is a port to Sparc32; Sparc64 is another issue completely (and probably much more difficult) ... Bye, Ulrich -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

March 21, 2001

Re: Nasty Wine/kernel bug, anyone?

by Ulrich Weigand

Hi Jeremy, > That is, if I use a pretty stock Wine config, and launch > msimn.exe, we get the splash screen, and then a process > stuck in 'D' (uninterruptible sleep). At this point, > AFAIK, the only solution is to wait for the IO to timeout > (I haven't been patient enough to see if it does), or > to reboot. Could you check in which kernel routine the process is blocked? (e.g. using ps -Ao pid,wchan) > Because the process is already gone, I can't strace or gdb it. What do you mean 'the process is already gone'? Could it be that ptrace doesn't work because the Wine server has already attached to that client process? > Anyone > a) Want to take this on? > b) Have advice on how I can generate enough debug info > that we can feed it to the Kernel guys to get it fixed? > > And yes, this happens both on a 2.2 system and a 2.4 system. Hmm. Could you try getting a Wine trace (especially the server/ client interaction)? > I saw at least other user report on this (Steve Fox reported this > with Lotus Notes). > > My best guess is that this is a bug in the vfat driver, > but that's just a hunch. Steve, is VFAT also involved in your case? Bye, Ulrich -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

March 21, 2001

Re: Port to OS/390 mainframe USS?

by Ulrich Weigand

James, > Will there be a port of WINE to OS/390 mainframe USS? > LINUX runs fine under USS, so it would seem that WINE should run there as > well. > Has anyone done this yet? To clear up a possible misunderstanding first: Linux for S/390 does *not* run under USS or under OS/390. OS/390 is (one of) the standard operating system(s) used on S/390 mainframes. One component of OS/390, the Unix System Services (USS), provides an environment that allows to run certain Unix applications. However, USS is not itself an operating system, just an ABI layer on top of OS/390 (somewhat similar to the POSIX subsystem of Windows NT). Linux for S/390, on the other hand, is a true port of the Linux operating system to the S/390 hardware. It runs directly on the S/390 platform, *instead* of OS/390 or any other mainframe operating system. This has the effect that while USS is much more integrated into the OS/390 environment, Linux on S/390 is much more similar to 'real' Unix platforms. Porting Unix or Linux applications to USS is often non-trivial (e.g. gcc does not run on USS at all), while porting to Linux on S/390 is most of the time just a recompile. What I want to say by that is that a port of Wine to *USS* seems rather unlikely, given the difficulties I mentioned. However, a port to *Linux* on S/390 should really be possible, and some time ago I already did a proof-of-concept implementation. Of course, a port of Wine to any non-Intel hardware means just a port of the Wine *library* at the moment, as Wine does not contain a Intel processor emulator and cannot run Windows/Intel binaries on non-Intel hardware. James (Hatheway) has already explained this ... Bye, Ulrich -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

March 21, 2001

Re: Port to OS/390 mainframe USS?

by James Hatheway

Hello James, > I am not real clear about the difference between the PE loader and the > WINELIB, but then, I am also unclear as to why my user would want to run a > Windows app on the mainframe in the first place. Sorry, I should have been a bit more descriptive with my answer. The PE loader is used to run executable files that were compiled to be executed in Windows/intel environment (standard windows apps). It handles the 'magic' of loading a windows executable including the necessary dependecy checking, dynamic link library loading, etc. Once the executable is loaded and all dependecies to DLLs resolved and loaded the program is started and runs with the same intel code that would have executed in windows. Whenever the app makes a call to a Windows API function, the code actually is handled by WINE code (or the native windows DLLs if that is the user's configuration) That is why WINE is not an 'emulator' rather a reimplementation of the Windows API. That is also why it is tied to the intel platform, since it is still directly executing intel code. Since WINE is comprised mainly of a reimplementation of the Windows API, it can also be used as a porting library for application developers. WineLib allows a developer to recompile his Windows source so that it will run on other unix platforms (including other CPU architectures than intel). The problem is that not as much work goes into the WineLib side of WINE than does go into the mainstream WINE side of things. My understanding is that WineLib has been built on Solaris/Sparc, powerpc, and s390 with varying degrees of success. Also I don't know if the patches that got these platforms to build are actually in the main CVS tree. Searches through past WineHQ discussions can bring up the names of those who worked on this stuff. So, unless your user has access to the source code to his app, he can't use WINE to run his app on the S390. I'm not sure if WineLib has advanced enough to support his app on the S390, and in fact Wine itself might not support his app on intel either, that is a case by case thing. (although WINE works quite well for a lot of apps) Finally I have no idea why a user would want to run a windows app on a s390. ^_^ > Is there someone at Ulrich that I should be talking to? Ulrich is a person: Ulrich Weigand. He subscribes to the mailing list so I am sure he saw your message. You can get his email address from the mail list archives. -James -- James Hatheway Software Designer - Macadamian Technologies, Inc. james(a)macadamian.com ~ http://www.macadamian.com "Man könnte froh sein, wenn die Luft so rein wäre wie das Bier" "One could be happy if the air were as pure as the beer"

March 21, 2001

Re: Port to OS/390 mainframe USS?

by James Hatheway

> Will there be a port of WINE to OS/390 mainframe USS? > LINUX runs fine under USS, so it would seem that WINE should run there as > well. > Has anyone done this yet? Hi James, If you are talking about WINE the Windows binary PE loader (directly supporting and loading windows .exe files) this will probably never happen, unless somebody wants to add intel emulation code into WINE. (at a significant speed penalty, of course) If you are talking about WineLib, I believe that Ulrich made a post earlier this year mentioning getting at least a partial port of a WineLib app running on an S390. (I believe he mentioned getting Winemine to compile) >From the sounds of it there is still some work needed before WineLib will build and run out of the box on that platform. -James -- James Hatheway Software Designer - Macadamian Technologies, Inc. james(a)macadamian.com ~ http://www.macadamian.com "Man könnte froh sein, wenn die Luft so rein wäre wie das Bier" "One could be happy if the air were as pure as the beer"

March 21, 2001

Port to OS/390 mainframe USS?

by James.Robinson＠crowley.com

Will there be a port of WINE to OS/390 mainframe USS? LINUX runs fine under USS, so it would seem that WINE should run there as well. Has anyone done this yet? Thanks James Robinson james.robinson(a)crowley.com

March 21, 2001

any questions?

by Natanael Copa

Hi! David A. Solomon, the author of "Inside MS Windows 2000", is comming for a seminar 2-3 April here in Oslo. He is a friend of one of mine friends so I got a free ride. I am not envolved in the wine development (I would love to if I had the time) and I don't have any experience with the win32 API or any windows programming. But when I got this invitation my first thought was you guys, who develop wine. So if anyone want me to ask him about anyhing about windows and the win32 API, I would love to so. David is an expert when it comes to win32 API and he has the source codes for windows. http://solsem.com Best Regards, Natanael Copa

March 21, 2001

Re: Port to OS/390 mainframe USS?

by Ian Pilcher

James.Robinson(a)crowley.com wrote: > > Will there be a port of WINE to OS/390 mainframe USS? > LINUX runs fine under USS, so it would seem that WINE should run there as > well. > Has anyone done this yet? > Linux does not run under USS. USS (Unix System Services) is an implementation of the Unix 95 (Unix 98?) API set on top of MVS (where it is known as Open Edition), OS/390, and now z/OS. USS is a prerequisite for the OS/390 Java Virtual Machine, WebSphere Application Server, and Lotus Domino among others. In theory, USS also allows Unix applications to be easily recompiled for OS/390. The reality is that most applications of interest use non- standard APIs (be they Solaris, AIX, HP-UX, etc.); the ASCII to EBCDIC conversion also causes a lot of problems. "Linux/390", on the other hand, is just the Linux kernel source compiled for the S/390 architecture--the same way it might be compiled for Alpha, UltraSPARC, PowerPC, MIPS, IA64, etc. (You do of course need a compiler that supports the S/390 instruction set; gcc does now.) "Linux/390" can be installed by itself on a S/390, in a LPAR, or as a VM guest. It uses the ASCII character set, although it does do ASCII to EBCDIC conversion for the hardware console. Wine provides a PE (Portable Executable--the Windows executable format) program loader and a set of libraries that implement some of the Win32 API. This allows some Windows binaries to run unmodified on x86 *ix operating systems. (I suppose it might be theoretically possible to run an NT/Alpha executable on Linux/Alpha, but I don't know if anyone's ever tried.) Since Wine doesn't emulate the Intel processor, you can't use it to run Intel binaries on a S/390. (You might be able to use Bochs, however.) Wine does have another personality, known as Winelib, that allows the source code for Windows applications to be recompiled as "pseudo-native" *ix applications. Instead of a Windows PE executable linked to Windows DLLs, you end up with an ELF executable linked to the Wine shared libraries. This can be used to port Windows programs to non-Intel architectures, although byte order and word size can be issues. So if you have the source code to your Windows application, you may be able to get it running on "Linux/390"--41,000 times under VM! -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

March 21, 2001

any questions?

by Natanael Copa

Hi! David A. Solomon, the author of "Inside MS Windows 2000", is comming for a seminar 2-3 April here in Oslo. He is a friend of one of mine friends so I got a free ride. I am not envolved in the wine development (I would love to if I had the time) and I don't have any experience with the win32 API or any windows programming. But when I got this invitation my first thought was you guys, who develop wine. So if anyone want me to ask him about anyhing about windows and the win32 API, I would love to so. David is an expert when it comes to win32 API and he has the source codes for windows. http://solsem.com Best Regards, Natanael Copa

March 21, 2001

Re: Allow loading of built-in dlls with LOAD_LIBRARY_AS_DATAFILE flag set

by Alexandre Julliard

"Dmitry Timoshkov" <dmitry(a)sloboda.ru> writes: > Does the attached patch look as applicable? Yep, looks good. -- Alexandre Julliard julliard(a)winehq.com

March 20, 2001

Re: x11drv patch

by lawson_whitney＠juno.com

On Tue, 20 Mar 2001, Ove Kaaven wrote: > Yes, Alexandre complained too, so I had to mail him the missing pieces... > the added file looks like this: > Good-oh. Thanks! Lawson ---cut here ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

March 20, 2001

Re: wine: debugtools.c:210: wine_dbg_vprintf: Assertion failed

by Rein Klazes

On Wed, 21 Mar 2001 00:07:16 +0800, you wrote: > Hello all. > > I have this very strange situation: > Debugging with +relay,+win,+region,+message has revealed: > ... > Call user32.18: CallNextHookEx(4b483218,00000000,00000001,405a3f40) ret=3d1010fe fs=008f > Ret user32.18: CallNextHookEx() retval=00000000 ret=3d1010fe fs=008f > trace:message:SPY_EnterMessage (0000565c) {Static} message [0087] > WM_GETDLGCODE sent from self wp=00000000 lp=00000000 > trace:relay:WINPROC_CallWndProc > (wndproc=0x40619540,hwnd=0000565c,msg=WM_GETDLGCODE,wp=00000000,lp=00000000) > trace:relay:WINPROC_CallWndProc > (wndproc=0x40619540,hwnd=0000565c,msg=WM_GETDLGCODE,wp=00000000,lp=00000000) retval=00000100 > trace:message:SPY_ExitMessage (0000565c) {Static} message [0087] > WM_GETDLGCODE returned 00000100 > wine: debugtools.c:210: wine_dbg_vprintf: Assertion `ret < sizeof(info->output) - (info->out_pos - > info->output)' failed. > err:ntdll:RtlpWaitForCriticalSection Critical section 0x40685190 wait timed out, retrying (60 sec) > fs=0287 > > It seemed to be as libc bug and I have upgraded my stock rh 6.2 from > ftp://updates.redhat.com/6.2 to the latest available glibc-2.1.3-22.i386.rpm > and glibc-devel-2.1.3-22.i386.rpm. But nothing has changed. > Yes, when I saw this, I just increased the string sizes of the debug_info structure in the top of debugtools.c. Those sizes seem to be quite calculated, but I haven't realy looked yet how this calculation is done and why it is wrong. Rein. -- Rein Klazes rklazes(a)casema.net

March 20, 2001

Nasty Wine/kernel bug, anyone?

by Jeremy White

I'm able to consistently reproduce a kernel bug whilst running Wine (both 0305 and todays CVS) and the version of Outlook Express that comes with Win98. That is, if I use a pretty stock Wine config, and launch msimn.exe, we get the splash screen, and then a process stuck in 'D' (uninterruptible sleep). At this point, AFAIK, the only solution is to wait for the IO to timeout (I haven't been patient enough to see if it does), or to reboot. Because the process is already gone, I can't strace or gdb it. Anyone a) Want to take this on? b) Have advice on how I can generate enough debug info that we can feed it to the Kernel guys to get it fixed? And yes, this happens both on a 2.2 system and a 2.4 system. I saw at least other user report on this (Steve Fox reported this with Lotus Notes). My best guess is that this is a bug in the vfat driver, but that's just a hunch. Jer

March 20, 2001

wine: debugtools.c:210: wine_dbg_vprintf: Assertion failed

by Dmitry Timoshkov

Hello all. I have this very strange situation: Debugging with +relay,+win,+region,+message has revealed: ... Call user32.18: CallNextHookEx(4b483218,00000000,00000001,405a3f40) ret=3d1010fe fs=008f Ret user32.18: CallNextHookEx() retval=00000000 ret=3d1010fe fs=008f trace:message:SPY_EnterMessage (0000565c) {Static} message [0087] WM_GETDLGCODE sent from self wp=00000000 lp=00000000 trace:relay:WINPROC_CallWndProc (wndproc=0x40619540,hwnd=0000565c,msg=WM_GETDLGCODE,wp=00000000,lp=00000000) trace:relay:WINPROC_CallWndProc (wndproc=0x40619540,hwnd=0000565c,msg=WM_GETDLGCODE,wp=00000000,lp=00000000) retval=00000100 trace:message:SPY_ExitMessage (0000565c) {Static} message [0087] WM_GETDLGCODE returned 00000100 wine: debugtools.c:210: wine_dbg_vprintf: Assertion `ret < sizeof(info->output) - (info->out_pos - info->output)' failed. err:ntdll:RtlpWaitForCriticalSection Critical section 0x40685190 wait timed out, retrying (60 sec) fs=0287 It seemed to be as libc bug and I have upgraded my stock rh 6.2 from ftp://updates.redhat.com/6.2 to the latest available glibc-2.1.3-22.i386.rpm and glibc-devel-2.1.3-22.i386.rpm. But nothing has changed. Any suggestions?

March 20, 2001

Re: Allow loading of built-in dlls with LOAD_LIBRARY_AS_DATAFILE flag set

by Dmitry Timoshkov

"Alexandre Julliard" <julliard(a)winehq.com> wrote: > I think it would be better to keep the existing support for native > dlls, and simply fall back to loading the builtin library if > SearchPath fails. Does the attached patch look as applicable?

March 20, 2001

Re: x11drv patch

by Ove Kaaven

On Mon, 19 Mar 2001 lawson_whitney(a)juno.com wrote: > Good day! > > I think this misses x11ddraw.h. Yes, Alexandre complained too, so I had to mail him the missing pieces... the added file looks like this: /* * DirectDraw HAL base interface * * Copyright 2001 TransGaming Technologies, Inc. */ #ifndef __WINE_X11DDRAW_H #define __WINE_X11DDRAW_H #include "config.h" #include "ddrawi.h" extern LPDDRAWI_DDRAWSURFACE_LCL X11DRV_DD_Primary; extern LPDDRAWI_DDRAWSURFACE_GBL X11DRV_DD_PrimaryGbl; extern HBITMAP X11DRV_DD_PrimaryDIB; extern BOOL X11DRV_DD_IsDirect; void X11DRV_DDHAL_SwitchMode(DWORD dwModeIndex, LPVOID fb_addr); void X11DRV_DDHAL_SetPalEntries(Colormap pal, DWORD dwBase, DWORD dwNumEntries, LPPALETTEENTRY lpEntries); #endif /* __WINE_X11DDRAW_H */

March 20, 2001

Re: x11drv patch

by lawson_whitney＠juno.com

On Mon, 19 Mar 2001, Ove Kaaven wrote: > Here's some more x11drv code... in addition to the HAL bits, it adds some > gamma control stuff, so we can implement Get/SetDeviceGammaRamp (in GDI). > > Log: > Ove Kaaven <ovek(a)transgaming.com> > Added gamma ramp code to the XVidMode interface. Good day! I think this misses x11ddraw.h. At least, I don't have it. xvidmode.c:16: x11ddraw.h: No such file or directory I will find it though. Lawson ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

March 20, 2001

Re: Allow loading of built-in dlls with LOAD_LIBRARY_AS_DATAFILE flag set

by Alexandre Julliard

"Dmitry Timoshkov" <dmitry(a)sloboda.ru> writes: > Perhaps version.dll code should use DONT_RESOLVE_DLL_REFERENCES instead of > undesirable LOAD_LIBRARY_AS_DATAFILE? Not necessarily, it may be considered a feature to load version info from the native dll, even though the actual code will run from the builtin. This may help programs believe they got the exact version they wanted (since presumably the app installed the dll in the first place). > Will DONT_RESOLVE_DLL_REFERENCES work with built-in dlls somewhere in the future? Unlikely; the problem is that we cannot prevent constructors from running, and we need to resolve imports before running constructors. -- Alexandre Julliard julliard(a)winehq.com

March 20, 2001

Re: Allow loading of built-in dlls with LOAD_LIBRARY_AS_DATAFILE flag set

by Dmitry Timoshkov

"Alexandre Julliard" <julliard(a)winehq.com> wrote: > I think it's reasonable to give the native dll priority when doing > LOAD_LIBRARY_AS_DATAFILE. An app using this wants to poke inside the > dll binary file and we are much better off giving it the 'real' thing > in this case IMO. Perhaps version.dll code should use DONT_RESOLVE_DLL_REFERENCES instead of undesirable LOAD_LIBRARY_AS_DATAFILE? Will DONT_RESOLVE_DLL_REFERENCES work with built-in dlls somewhere in the future?

March 20, 2001

Re: Allow loading of built-in dlls with LOAD_LIBRARY_AS_DATAFILE flag set

by Alexandre Julliard

"Dmitry Timoshkov" <dmitry(a)sloboda.ru> writes: > But here is a problem. This doesn't honor a load order. If load order > of a requested dll explicitly specified as 'builin' but 'native' library > there is somewhere in the path, then we will get unexpected result. > How to cope with it? I think it's reasonable to give the native dll priority when doing LOAD_LIBRARY_AS_DATAFILE. An app using this wants to poke inside the dll binary file and we are much better off giving it the 'real' thing in this case IMO. -- Alexandre Julliard julliard(a)winehq.com

March 20, 2001

Re: Allow loading of built-in dlls with LOAD_LIBRARY_AS_DATAFILE flag set

by Dmitry Timoshkov

"Alexandre Julliard" <julliard(a)winehq.com> wrote: > I think it would be better to keep the existing support for native > dlls, and simply fall back to loading the builtin library if > SearchPath fails. It's unlikely we are ever going to support proper > LOAD_LIBRARY_AS_DATAFILE for builtin dlls anyway. But here is a problem. This doesn't honor a load order. If load order of a requested dll explicitly specified as 'builin' but 'native' library there is somewhere in the path, then we will get unexpected result. How to cope with it? At least DONT_RESOLVE_DLL_REFERENCES should be doable.

March 20, 2001

Re: Allow loading of built-in dlls with LOAD_LIBRARY_AS_DATAFILE flag set

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)sloboda.ru> writes: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Allow loading of built-in dlls with LOAD_LIBRARY_AS_DATAFILE flag set. I think it would be better to keep the existing support for native dlls, and simply fall back to loading the builtin library if SearchPath fails. It's unlikely we are ever going to support proper LOAD_LIBRARY_AS_DATAFILE for builtin dlls anyway. -- Alexandre Julliard julliard(a)winehq.com

March 19, 2001

fixme:win32:DeviceIoControl Unimplemented control 104 for VxD device SECPROV

by Achilleas Mantzios

Does anyone have a clue??? P.S. You have done serious job :) i wanna say. -- Á÷éëëÝáò ÌÜíôæéïò Application Developer Eurisko A.E. ÐéíäÜñïõ 9 106 71 ÁèÞíá Ôçë: +301 3633362 Öáî: +301 3633074 e-mail: achilleas.mantzios(a)eurisko.gr

March 19, 2001

Re: RFC: client side implementation of async I/O

by Mike McCormack

Hi All, WWW reported that my client side async patch relies on the service thread... sorry for not clearly explaining, but it doesn't. It works by multiplexing the server's wait reponse fd with pending i/o operation fds using poll. When i have time, i'll try to clean it up a bit. Currently i'm working on a kernel patch to help implement other WaitCommEvent flags. i hope Alexandre considers applying the client side async patch in some form. Mike ------------------------------------------ mailto:Mike_McCormack(a)looksmart.com.au ph +82 16 430 0425 __________________________________________________________________ Get your own free web email at http://www.looksmart.com.au LookSmart Australia

March 19, 2001

Re: Menu crash - was : Re: [PATCH] Version info for comctl32.dll

by lawson_whitney＠juno.com

On Sun, 18 Mar 2001, gerard patel wrote: > At 11:44 PM 17/03/2001 -0500, you wrote: > > >Strange but true. I reverted the patch, and alt-b beeps but does not > >cause a crash. With the patch in, wine crashes without a beep. > > > >Now I guess I'll put it back in. It doesn't cripple me if wine crashes > >when I fat-finger the GUI. I guess wine-devel doesn't want to see a > >trace, and maybe you don't either, but if you do it will save time to > >send it. > > I had left out some cases in my first try :/, but maybe it's better to understand > firsst what the app is doing. > > Could you send me a complete (from start) +relay,+menu trace of your app crashing > with current Wine (no copy to wine-devel is best in this case) > > If you can apply the following patch to enhance trace first : Okay. This troubles me. AFAIK I should be current with wine-cvs. I even took out Dmitry's loader patch (for builtin version loading) though that can't be anything to do with an offset in menu.c. [whit(a)giftie controls]$ patch -p0 -l </gp/p04/trace patching file menu.c Hunk #3 succeeded at 4607 (offset 4 lines). [whit(a)giftie controls]$ exit With full +relay,+menu, wine crashes, then winedbg does, and the trace is 181m. It is taking a while to bzip2. sure You wouldn't rather have a +menu,-relay=rtlentercriticalsection:RTLleavecriticalsection:rtldeletecriticalsection:initializecriticalsection:interlockedincrement:interlockeddecrement ? Lawson ---cut here ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

March 18, 2001

Re: Menu crash - was : Re: [PATCH] Version info for comctl32.dll

by gerard patel

At 11:44 PM 17/03/2001 -0500, you wrote: >Strange but true. I reverted the patch, and alt-b beeps but does not >cause a crash. With the patch in, wine crashes without a beep. > >Now I guess I'll put it back in. It doesn't cripple me if wine crashes >when I fat-finger the GUI. I guess wine-devel doesn't want to see a >trace, and maybe you don't either, but if you do it will save time to >send it. I had left out some cases in my first try :/, but maybe it's better to understand firsst what the app is doing. Could you send me a complete (from start) +relay,+menu trace of your app crashing with current Wine (no copy to wine-devel is best in this case) If you can apply the following patch to enhance trace first : --- menu.c.orig Sun Mar 18 10:18:31 2001 +++ menu.c Sun Mar 18 11:28:29 2001 @@ -1852,6 +1852,7 @@ LPWSTR prevText = IS_STRING_ITEM(item->fType) ? item->text : NULL; debug_print_menuitem("MENU_SetItemData from: ", item, ""); + TRACE("flags=%x str=%p\n", flags, str); if (IS_STRING_ITEM(flags)) { @@ -4511,6 +4512,9 @@ { if (!menu) return FALSE; + debug_print_menuitem("MENU_SetItemInfo_common from: ", menu, ""); + TRACE("mask=%x type=%x text=%p\n", lpmii->fMask, lpmii->fType, lpmii->dwTypeData); + if (lpmii->fMask & MIIM_TYPE ) { /* Get rid of old string. */ if ( IS_STRING_ITEM(menu->fType) && menu->text) { @@ -4589,7 +4603,7 @@ if (lpmii->fMask & MIIM_DATA) menu->dwItemData = lpmii->dwItemData; - debug_print_menuitem("SetMenuItemInfo_common: ", menu, ""); + debug_print_menuitem("SetMenuItemInfo_common to : ", menu, ""); return TRUE; } Thanks. Gerard

March 18, 2001

Re: Menu crash - was : Re: [PATCH] Version info for comctl32.dll

by lawson_whitney＠juno.com

On Sat, 17 Mar 2001, gerard patel wrote: > case. What is strange is this problem appears only with my patch. Maybe Strange but true. I reverted the patch, and alt-b beeps but does not cause a crash. With the patch in, wine crashes without a beep. Now I guess I'll put it back in. It doesn't cripple me if wine crashes when I fat-finger the GUI. I guess wine-devel doesn't want to see a trace, and maybe you don't either, but if you do it will save time to send it. Lawson ---cut here ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

March 18, 2001

Re: [PATCH] Version info for comctl32.dll

by lawson_whitney＠juno.com

On Sat, 17 Mar 2001 lawson_whitney(a)juno.com wrote: > > > With wine_common_ver.rc changed as attached, and > dlls/oleaut32/version.rc > > #define WINE_FILEVERSION 10,0,0,0 > #define WINE_FILEVERSION_STR "10.0" > #define WINE_PRODUCTVERSION 10,1,0,0 Oops, where did that ____________^ come from? > #define WINE_PRODUCTVERSION_STR "10.0" It also still works with this as version.rc: #define WINE_FILEVERSION 10,0,0,0 #define WINE_FILEVERSION_STR "10.0" #define WINE_PRODUCTVERSION 10,0,0,0 #define WINE_PRODUCTVERSION_STR "10.0" #define WINE_FILEDESCRIPTION_STR "Wine OLE dll" #define WINE_FILENAME_STR "oleaut32.dll" #include "wine/wine_common_ver.rc" Lawson ---cut here ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

March 18, 2001

Re: Menu crash - was : Re: [PATCH] Version info for comctl32.dll

by lawson_whitney＠juno.com

On Sat, 17 Mar 2001, gerard patel wrote: > > First thanks for the bug report. > > The trace is not difficult to read, the menu item is a text item and > the text pointer is NULL. MENU_CalcItemSize is not handling this > case. What is strange is this problem appears only with my patch. Maybe Now hang on! I didn't say that. I said I had first provoked it after applying your patch. :-). I guess I should have reverted the patch so I would know for sure before I said anything, but I figured you had just worked in that area and might have a better idea about fixing it than I just jumping in and putting a test for null or a __try around it. I don't use GUI very much, and that crash could have been waiting for years to be provoked. I will revert presently and repeat the test in case that might help. > your app is really initializing the menu when receiving the WM_INITMENU > message, but *only* when there is need to display the menu. I can't see > how it could find out about it, though. > > Anyway, could you try the following patch ? It tries to remove the main > case I saw where the app can set a menu item to text type with a null text > pointer. It is a legitimate patch by itself, even if it does not fix your problem. > Maybe it could have nasty side effects. If it avoids the systematic crash, > try to find if the other is really gone for good too. Still crashes. The patch is in the source, the object file and libuser32.so are newer than menu.c, so I _think_ there must be another way to get a null text pointer with a text type. This time I spelled "info local" right. tee is a wonderful little program. > > I have found a strangeness in the HEAP_strdup macros - WARNING - > this is of interest to anyone dabbling with Wine code. > While HEAP_strdupW and HEAP_strdupAtoW appear very similar, the specs > are not the same; one returns a null pointer when called with a > null pointer, the other allocates 2 bytes of memory and returns a pointer > to it. Nice trap :-) > > Gerard Lawson

March 18, 2001

Re: [PATCH] Version info for comctl32.dll

by lawson_whitney＠juno.com

On Sat, 17 Mar 2001, Dmitry Timoshkov wrote: > > I'm sorry, I didn't focus you on the subject that FILEVERSION and PRODUCTVERSION > are distinctly different things? How about to experiment with different WINE_FILEVERSION > and PRODUCTVERSION (WINE_FILEVERSION_STR and WINE_PRODUCRVERSION_STR) numbers? > > Sorry, if it is not the same as you expected from me... > With wine_common_ver.rc changed as attached, and dlls/oleaut32/version.rc #define WINE_FILEVERSION 10,0,0,0 #define WINE_FILEVERSION_STR "10.0" #define WINE_PRODUCTVERSION 10,1,0,0 #define WINE_PRODUCTVERSION_STR "10.0" #define WINE_FILEDESCRIPTION_STR "Wine OLE dll" #define WINE_FILENAME_STR "oleaut32.dll" #include "wine/wine_common_ver.rc" Tha app still works, and I can't see that it matters to About.exe either. Is that what you meant? Regards, Lawson ---cut here

March 17, 2001

Re: [PATCH] Version info for comctl32.dll

by lawson_whitney＠juno.com

On Sat, 17 Mar 2001, Dmitry Timoshkov wrote: > > Great! > > > #define WINE_FILEVERSION 10,0,0,0 > > #define WINE_FILEVERSION_STR "10.0" > > #define WINE_FILEDESCRIPTION_STR "Wine OLE dll" > > #define WINE_FILENAME_STR "oleaut32.dll" > > > > #include "wine/wine_common_ver.rc" > > > > If you get this letter, it works. > > I'm sorry, I didn't focus you on the subject that FILEVERSION and PRODUCTVERSION > are distinctly different things? How about to experiment with different WINE_FILEVERSION > and PRODUCTVERSION (WINE_FILEVERSION_STR and WINE_PRODUCRVERSION_STR) numbers? > > Sorry, if it is not the same as you expected from me... > I am sorry, I am not understanding some thing[s]. I changed only WINE_FILEVERSION and WINE_FILEVERSION_STRING. All else is as it was set in include/wine/wine_common_ver.rc. I can't see that this includes any provision to make PRUDUCTVERSION variable. Shoukd I make one, in the manner of FILEVERSION? I don't think the app cares about it, at least it is content with 1,0,0,0 and "1.0", if I am reading this right. I will experiment with it anyway, in case it might help, and also test Gerard's patch shortly. Lawson ---cut here ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

March 17, 2001

Menu crash - was : Re: [PATCH] Version info for comctl32.dll

by gerard patel

At 10:26 PM 16/03/2001 -0500, you wrote: > >On a related note, I provoked that crash in menu.c again, this time by >hitting an accelerator key (?) for a button that was not enabled at the >time. First thanks for the bug report. The trace is not difficult to read, the menu item is a text item and the text pointer is NULL. MENU_CalcItemSize is not handling this case. What is strange is this problem appears only with my patch. Maybe your app is really initializing the menu when receiving the WM_INITMENU message, but *only* when there is need to display the menu. I can't see how it could find out about it, though. Anyway, could you try the following patch ? It tries to remove the main case I saw where the app can set a menu item to text type with a null text pointer. It is a legitimate patch by itself, even if it does not fix your problem. Maybe it could have nasty side effects. If it avoids the systematic crash, try to find if the other is really gone for good too. I have found a strangeness in the HEAP_strdup macros - WARNING - this is of interest to anyone dabbling with Wine code. While HEAP_strdupW and HEAP_strdupAtoW appear very similar, the specs are not the same; one returns a null pointer when called with a null pointer, the other allocates 2 bytes of memory and returns a pointer to it. Nice trap :-) Gerard --- menu.c.orig Wed Mar 14 20:19:46 2001 +++ menu.c Sat Mar 17 14:47:30 2001 @@ -4524,11 +4524,15 @@ menu->text = lpmii->dwTypeData; - if (IS_STRING_ITEM(menu->fType) && menu->text) { - if (unicode) - menu->text = HEAP_strdupW(GetProcessHeap(), 0, lpmii->dwTypeData); - else - menu->text = HEAP_strdupAtoW(GetProcessHeap(), 0, (LPSTR)lpmii->dwTypeData); + if (IS_STRING_ITEM(menu->fType)) { + if (menu->text) { + if (unicode) + menu->text = HEAP_strdupW(GetProcessHeap(), 0, lpmii->dwTypeData); + else + menu->text = HEAP_strdupAtoW(GetProcessHeap(), 0, (LPSTR)lpmii->dwTypeData); + } + else + menu->fType |= MF_SEPARATOR; } }

March 17, 2001

Re: [PATCH] Version info for comctl32.dll

by Dmitry Timoshkov

<lawson_whitney(a)juno.com> wrote: > > I just don't like an idea to hunt down all that cases when some application will want > > that strange version numbers. Will 10.0 work for you? > > > Yes. I can't promise it will work for other apps, and maybe in time we > will have to go to "255.0" or something, but for now, 10.0 works for me. Great! > #define WINE_FILEVERSION 10,0,0,0 > #define WINE_FILEVERSION_STR "10.0" > #define WINE_FILEDESCRIPTION_STR "Wine OLE dll" > #define WINE_FILENAME_STR "oleaut32.dll" > > #include "wine/wine_common_ver.rc" > > If you get this letter, it works. I'm sorry, I didn't focus you on the subject that FILEVERSION and PRODUCTVERSION are distinctly different things? How about to experiment with different WINE_FILEVERSION and PRODUCTVERSION (WINE_FILEVERSION_STR and WINE_PRODUCRVERSION_STR) numbers? Sorry, if it is not the same as you expected from me...

March 17, 2001

Re: [PATCH] Version info for comctl32.dll

by lawson_whitney＠juno.com

On Sat, 17 Mar 2001, Dmitry Timoshkov wrote: > I just don't like an idea to hunt down all that cases when some application will want > that strange version numbers. Will 10.0 work for you? > Yes. I can't promise it will work for other apps, and maybe in time we will have to go to "255.0" or something, but for now, 10.0 works for me. #define WINE_FILEVERSION 10,0,0,0 #define WINE_FILEVERSION_STR "10.0" #define WINE_FILEDESCRIPTION_STR "Wine OLE dll" #define WINE_FILENAME_STR "oleaut32.dll" #include "wine/wine_common_ver.rc" If you get this letter, it works. Lawson ---cut here ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

March 17, 2001

Re: [PATCH] Version info for comctl32.dll

by Dmitry Timoshkov

<lawson_whitney(a)juno.com> wrote: > > Could you please experiment some more and try to replace 2,20,4054,1 and > > "2.20.4054" to the something more simple: 2,0,0,0 and "2.0". If with that > > numbers juno will not work 2,1,0,0 and "2.1", then 2,2,0,0 and "2.2" and > > so forth? > > Okay. 2.20.4054 is the minimum, it seems, but I'll try 2.21 and so on > shortly. Perhaps we should use some bogus version value (say 10.0) for all wine built-in dlls? I just don't like an idea to hunt down all that cases when some application will want that strange version numbers. Will 10.0 work for you?

March 17, 2001

Re: [PATCH] Version info for comctl32.dll

by Dmitry Timoshkov

<lawson_whitney(a)juno.com> wrote: > > Could you please experiment some more and try to replace 2,20,4054,1 and > > "2.20.4054" to the something more simple: 2,0,0,0 and "2.0". If with that > > numbers juno will not work 2,1,0,0 and "2.1", then 2,2,0,0 and "2.2" and > > so forth? > > Okay. 2.20.4054 is the minimum, it seems, but I'll try 2.21 and so on > shortly. Perhaps we should use some bogus version value (say 10.0) for all wine built-in dlls? I just don't like an idea to hunt down all that cases when some application will want that strange version numbers. Will 10.0 work for you?

March 17, 2001

Re: [PATCH] Version info for comctl32.dll

by Dmitry Timoshkov

<lawson_whitney(a)juno.com> wrote: > > Could you please experiment some more and try to replace 2,20,4054,1 and > > "2.20.4054" to the something more simple: 2,0,0,0 and "2.0". If with that > > numbers juno will not work 2,1,0,0 and "2.1", then 2,2,0,0 and "2.2" and > > so forth? > > Okay. 2.20.4054 is the minimum, it seems, but I'll try 2.21 and so on > shortly. Perhaps we should use some bogus version value (say 10.0) for all wine built-in dlls? I just don't like an idea to hunt down all that cases when some application will want that strange version numbers. Will 10.0 work for you?

March 17, 2001