January 2003 - Wine-Devel - list.winehq.org

ddraw/ddraw/hal.c:152: initialization from incompatible pointer type

by Gerald Pfeifer

The following static DDHALDDRAWFNS hal_funcs = { sizeof(DDHALDDRAWFNS), ===>set_hal_info,<=== NULL, /* VidMemAlloc */ NULL /* VidMemFree */ }; in dlls/ddraw/ddraw/hal.c causes GCC 3.2 (on SuSE Linux 8.1) to warn: ddraw/hal.c:152: warning: initialization from incompatible pointer type Could someone please have a look? Thanks, Gerald -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.pfeifer.com/gerald/

Jan. 20, 2003

Re: 1995-era installshield woes - foreground window never appears

by Dan Kegel

Marcus Meissner wrote: > Catch them in a desktop window for now: > ... > --- documentation/samples/config 13 Dec 2002 02:26:18 -0000 1.37 > +++ documentation/samples/config 20 Jan 2003 06:37:18 -0000 > @@ -277,6 +277,20 @@ > ;"UseDnsComputerName" = "N" > > ;; sample AppDefaults entries > + > +; 3 InstallShield versions who like to put their full screen window in front, > +; without any chance to switch to another X11 application. > +; So just catch them in a desktop window. > + > +[AppDefaults\\_INS5576._MP\\x11drv] > +"Desktop" = "640x480" > ... Wow, that works wonderfully; applying that patch and doing a fresh tools/wineinstall yields a Wine that runs the installer properly. If the executables that we mishandle like this really do tend to have just those three filenames, this seems like a great workaround. Can you submit that to wine-patches? Thanks, Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Jan. 20, 2003

wrc arguements

by John Westerman

Hi, Can anyone actually compile the minesweeper example with the current winemaker. Mine keeps failing when trying to convert the rc file using wrc. Is it possible the arguements winemaker generates are no longer correct for wrc. Thanks,

Jan. 20, 2003

1995-era Microsoft MFCKIT installer fails to unpack one of its DLLs

by Dan Kegel

On to the next button on the MSVC4.0 installer: MFC. Clicking it runs d:\mfckit\disk1\setup.exe, which appears to be a win16 executable. It exits quickly under Wine, saying Could not load 'RBHEAP.DLL' required by 'WBRUN20', error= 2 Tsk. Running it under XP works, of course. Now, \mfckit\disk1 does contain the file rbheap.dl_, which presumably something is supposed to unpack on the fly. In hopes of seeing what's going on, I ran this installer under Debugging Tools for Windows' logger; the result is at http://www.kegel.com/linux/mfckit.txt Here are the lines from mfckit.txt that reference rbheap.dll or a file descriptor open to it or rbheap.dl_: Thrd4 0FFB56F5 GetPrivateProfileStringA( "Files" "rbheap.dl_" "" 0x00000080 "D:\MFCKIT\DISK1\SETUP.LST") -> 0x0000000A ( "rbheap.dll") Thrd4 0FFB503E CreateFileW( "D:\MFCKIT\DISK1\RBHEAP.DL_" GENERIC_READ FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE [0x00000000] NULL OPEN_EXISTING 0x00000000 NULL) -> INVALID_HANDLE_VALUE [FAIL] Thrd4 0FFB505D CreateFileW( "D:\MFCKIT\DISK1\RBHEAP.DL_" GENERIC_READ FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE [0x00000000] NULL OPEN_EXISTING 0x00000000 NULL) -> 0x000000C4 Thrd4 0FFB50A7 SetFilePointer( 0x000000C4 0 [0x00000000] NULL FILE_BEGIN) -> 0x00000000 Thrd4 0FFB48B9 GetFileAttributesW( "C:\ms-setup.t\rbheap.dll") -> FILE_ATTRIBUTE_READONLY | FILE_ATTRIBUTE_HIDDEN | FILE_ATTRIBUTE_SYSTEM | FILE_ATTRIBUTE_DIRECTORY | FILE_ATTRIBUTE_ARCHIVE | FILE_ATTRIBUTE_ENCRYPTED | FILE_ATTRIBUTE_NORMAL | FILE_ATTRIBUTE_TEMPORARY | FILE_ATTRIBUTE_SPARSE_FILE | FILE_ATTRIBUTE_REPARSE_POINT | FILE_ATTRIBUTE_COMPRESSED | FILE_ATTRIBUTE_OFFLINE | FILE_ATTRIBUTE_NOT_CONTENT_INDEXED Thrd4 0F007B35 GetFileAttributesW( "C:\MS-SETUP.T\RBHEAP.DLL") -> FILE_ATTRIBUTE_READONLY | FILE_ATTRIBUTE_HIDDEN | FILE_ATTRIBUTE_SYSTEM | FILE_ATTRIBUTE_DIRECTORY | FILE_ATTRIBUTE_ARCHIVE | FILE_ATTRIBUTE_ENCRYPTED | FILE_ATTRIBUTE_NORMAL | FILE_ATTRIBUTE_TEMPORARY | FILE_ATTRIBUTE_SPARSE_FILE | FILE_ATTRIBUTE_REPARSE_POINT | FILE_ATTRIBUTE_COMPRESSED | FILE_ATTRIBUTE_OFFLINE | FILE_ATTRIBUTE_NOT_CONTENT_INDEXED Thrd4 0FFB503E CreateFileW( "C:\MS-SETUP.T\RBHEAP.DLL" GENERIC_READ | GENERIC_WRITE FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE [0x00000000] NULL CREATE_ALWAYS FILE_ATTRIBUTE_NORMAL NULL) -> 0x00000124 Thrd4 0FFB4584 SetFilePointer( 0x000000C4 0 [0x032AFC48] -> 0 FILE_CURRENT) -> 0x00000000 Thrd4 0FFB4459 ReadFile( 0x000000C4 0x00000008 [0x032AFC2C] -> 0x00000008 0x00000000) -> TRUE ( 0x0003BB70) Thrd4 0FFB4584 SetFilePointer( 0x000000C4 0 [0x032AFC48] -> 0 FILE_BEGIN) -> 0x00000000 Thrd4 0FFB503E CreateFileW( "D:\MFCKIT\DISK1\RBHEAP.DL_" GENERIC_READ FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE [0x00000000] NULL OPEN_EXISTING 0x00000000 NULL) -> INVALID_HANDLE_VALUE [FAIL] Thrd4 0FFB505D CreateFileW( "D:\MFCKIT\DISK1\RBHEAP.DL_" GENERIC_READ FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE [0x00000000] NULL OPEN_EXISTING 0x00000000 NULL) -> 0x000000C4 Thrd4 0FFB50A7 SetFilePointer( 0x000000C4 0 [0x00000000] NULL FILE_BEGIN) -> 0x00000000 Thrd4 0FFB4584 SetFilePointer( 0x000000C4 0 [0x032AFC48] -> 0 FILE_END) -> 0x0000189C Thrd4 0FFB4584 SetFilePointer( 0x000000C4 0 [0x032AFC48] -> 0 FILE_BEGIN) -> 0x00000000 Thrd4 0FFB4459 ReadFile( 0x000000C4 0x0000000E [0x032AFC2C] -> 0x0000000E 0x00000000) -> TRUE ( 0x0003BB28) Thrd4 0FFB4584 SetFilePointer( 0x000000C4 0 [0x032AFC48] -> 0 FILE_END) -> 0x0000189C Thrd4 0FFB4584 SetFilePointer( 0x000000C4 0 [0x032AFC48] -> 0 FILE_BEGIN) -> 0x00000000 Thrd4 0FFB4459 ReadFile( 0x000000C4 0x0000000E [0x032AFC2C] -> 0x0000000E 0x00000000) -> TRUE ( 0x0003BB2C) Thrd4 0FFB4584 SetFilePointer( 0x000000C4 14 [0x032AFC48] -> 0 FILE_BEGIN) -> 0x0000000E Thrd4 0FFB4584 SetFilePointer( 0x00000124 0 [0x032AFC48] -> 0 FILE_BEGIN) -> 0x00000000 Thrd4 0FFB4459 ReadFile( 0x000000C4 0x00008000 [0x032AFC2C] -> 0x00008000 0x00000000) -> TRUE ( 0x0320FB41) Thrd4 0FFB4459 ReadFile( 0x000000C4 0x00008000 [0x032AFC2C] -> 0x00008000 0x00000000) -> TRUE ( 0x0320FB41) Thrd4 0FFC117C WriteFile( 0x00000124 0x03217B60 0x00002B30 [0x032AFC40] -> 0x0FFDDB70 0x00000000) -> TRUE Thrd4 0FFB48B9 GetFileAttributesW( "C:\ms-setup.t\rbheap.dll") -> FILE_ATTRIBUTE_ARCHIVE Thrd4 0FFBABDD SetFileAttributesW( "C:\ms-setup.t\rbheap.dll" FILE_ATTRIBUTE_READONLY | FILE_ATTRIBUTE_ARCHIVE) -> TRUE Thrd4 0FFB503E CreateFileW( "C:\MS-SETUP.T\RBHEAP.DLL" GENERIC_READ FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE [0x00000000] NULL OPEN_EXISTING 0x00000000 NULL) -> 0x000000DC Thrd4 0FFB54DC GetProfileIntA( "ModuleCompatibility" "RBHEAP" 0) -> 0 Thrd4 0FFB48B9 GetFileAttributesW( "C:\ms-setup.t\rbheap.dll") -> FILE_ATTRIBUTE_READONLY | FILE_ATTRIBUTE_ARCHIVE Thrd4 0FFBABDD SetFileAttributesW( "C:\ms-setup.t\rbheap.dll" FILE_ATTRIBUTE_ARCHIVE) -> TRUE Thrd4 0F007D27 CreateFileW( "C:\ms-setup.t\rbheap.dll" 0x00010000 0x00000000 [0x00000000] NULL OPEN_EXISTING FILE_ATTRIBUTE_NORMAL NULL) -> 0x0000012C Looks pretty clear that whatever we're tracing is indeed unpacking the file and writing it to c:\ms-setup.t\rbheap.dll. (I think we're tracking the wow module which is running the win16 program.) Likewise, I ran it under Wine with --debugmsg +win,+profile,+file,+dosfs,+relay; the resulting log is at http://www.kegel.com/linux/mfckit-wine.txt Here are the lines from mfckit-wine.txt that mention rbheap at all: trace:profile:PROFILE_Load New key: name='rbheap.dl_', value='rbheap.dll' trace:file:FILE_DoOpenFile RBHEAP.DLL OF_READ OF_SHARE_COMPAT trace:file:FILE_DoOpenFile RBHEAP.DLL 0000 trace:dosfs:DOSFS_DoGetFullPathName passed 'RBHEAP.DLL' trace:dosfs:DOSFS_DoGetFullPathName got C:\ms-setup.t\RBHEAP.DLL trace:dosfs:DOSFS_DoGetFullPathName returning 'C:\ms-setup.t\RBHEAP.DLL' trace:dosfs:DOSFS_GetFullName RBHEAP.DLL (last=1) trace:dosfs:DOSFS_FindUnixName /home/dank/c/ms-setup.t,RBHEAP.DLL warn:dosfs:DOSFS_FindUnixName 'RBHEAP.DLL' not found in '/home/dank/c/ms-setup.t' trace:dosfs:DOSFS_FindUnixName /home/dank/c/windows/system,RBHEAP.DLL warn:dosfs:DOSFS_FindUnixName 'RBHEAP.DLL' not found in '/home/dank/c/windows/system' trace:dosfs:DOSFS_FindUnixName /home/dank/c/windows,RBHEAP.DLL warn:dosfs:DOSFS_FindUnixName 'RBHEAP.DLL' not found in '/home/dank/c/windows' trace:dosfs:DOSFS_GetFullName C:\MS-SETUP.T\RBHEAP.DLL (last=1) trace:dosfs:DOSFS_FindUnixName /home/dank/c,MS-SETUP.T\RBHEAP.DLL trace:dosfs:DOSFS_FindUnixName (/home/dank/c,MS-SETUP.T\RBHEAP.DLL) -> ms-setup.t (MS-SETUP.T) trace:dosfs:DOSFS_FindUnixName /home/dank/c/ms-setup.t,RBHEAP.DLL warn:dosfs:DOSFS_FindUnixName 'RBHEAP.DLL' not found in '/home/dank/c/ms-setup.t' trace:dosfs:DOSFS_GetFullName c:\windows\RBHEAP.DLL (last=1) trace:dosfs:DOSFS_FindUnixName /home/dank/c,windows\RBHEAP.DLL trace:dosfs:DOSFS_FindUnixName (/home/dank/c,windows\RBHEAP.DLL) -> windows (WINDOWS) trace:dosfs:DOSFS_FindUnixName /home/dank/c/windows,RBHEAP.DLL warn:dosfs:DOSFS_FindUnixName 'RBHEAP.DLL' not found in '/home/dank/c/windows' trace:dosfs:DOSFS_GetFullName c:\windows\system\RBHEAP.DLL (last=1) trace:dosfs:DOSFS_FindUnixName /home/dank/c,windows\system\RBHEAP.DLL trace:dosfs:DOSFS_FindUnixName (/home/dank/c,windows\system\RBHEAP.DLL) -> windows (WINDOWS) trace:dosfs:DOSFS_FindUnixName /home/dank/c/windows,system\RBHEAP.DLL trace:dosfs:DOSFS_FindUnixName (/home/dank/c/windows,system\RBHEAP.DLL) -> system (SYSTEM) trace:dosfs:DOSFS_FindUnixName /home/dank/c/windows/system,RBHEAP.DLL warn:dosfs:DOSFS_FindUnixName 'RBHEAP.DLL' not found in '/home/dank/c/windows/system' trace:dosfs:DOSFS_GetFullName e:\\RBHEAP.DLL (last=1) trace:dosfs:DOSFS_FindUnixName /tmp,RBHEAP.DLL warn:dosfs:DOSFS_FindUnixName 'RBHEAP.DLL' not found in '/tmp' trace:dosfs:DOSFS_GetFullName e:\test\RBHEAP.DLL (last=1) trace:dosfs:DOSFS_FindUnixName /tmp,test\RBHEAP.DLL warn:dosfs:DOSFS_FindUnixName 'test\RBHEAP.DLL' not found in '/tmp' trace:dosfs:DOSFS_GetFullName f:\\RBHEAP.DLL (last=1) trace:dosfs:DOSFS_FindUnixName /home/dank,RBHEAP.DLL warn:dosfs:DOSFS_FindUnixName 'RBHEAP.DLL' not found in '/home/dank' warn:file:FILE_DoOpenFile 'RBHEAP.DLL' not found or sharing violation warn:file:FILE_DoOpenFile (RBHEAP.DLL): return = HFILE_ERROR error= 2 Could not load 'RBHEAP.DLL' required by 'WBRUN20', error=2 No such unpacking going on here. Under Wine, nothing ever references RBHEAP.DL_. Anyone see anything like this before, or have a suggestion on how to track this down further? -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Jan. 20, 2003

Re: 1995-era installshield woes - foreground window never appears

by Marcus Meissner

On Sun, Jan 19, 2003 at 06:02:31PM -0800, Dan Kegel wrote: > All the installshield stuff in the msvc4 installer > seems to work -- except the Data Access Objects > installer. When you run it, you get to the first > screen with a big blue background, but the foreground > window never shows up. It's probably there, but > invisible, or something. Alt-tab doesn't help, and > the blue background is full-screen, so you can't > try moving it out of the way. I have to alt-tab and ^C > (why that works, I dunno) to get out. > > Any suggestions? I'm having trouble figuring out how > to track this down; win32 gui problems aren't my forte. Catch them in a desktop window for now: Ciao, Marcus Index: documentation/samples/config =================================================================== RCS file: /home/wine/wine/documentation/samples/config,v retrieving revision 1.37 diff -u -u -r1.37 config --- documentation/samples/config 13 Dec 2002 02:26:18 -0000 1.37 +++ documentation/samples/config 20 Jan 2003 06:37:18 -0000 @@ -277,6 +277,20 @@ ;"UseDnsComputerName" = "N" ;; sample AppDefaults entries + +; 3 InstallShield versions who like to put their full screen window in front, +; without any chance to switch to another X11 application. +; So just catch them in a desktop window. + +[AppDefaults\\_INS5576._MP\\x11drv] +"Desktop" = "640x480" + +[AppDefaults\\_INS5176._MP\\x11drv] +"Desktop" = "640x480" + +[AppDefaults\\_INS0466._MP\\x11drv] +"Desktop" = "640x480" + ;[AppDefaults\\iexplore.exe\\DllOverrides] ;"shlwapi" = "native" ;"rpcrt4" = "native"

Jan. 20, 2003

Games Swat 3d

by Ronald James

I am wondering if Swat3d will be added to the list anytime soon for use with wine ??

Jan. 20, 2003

Re: 1995-era installshield woes - foreground window never appears

by Dan Kegel

Greg Turner wrote: > I'm not sure that doesn't qualify as a bug in my book... I think you > are right to point out that it may not be easy to fix properly. But > even if its a feature, it's a confusing one. Yep, IMHO it's a bug. I guess the Wine FAQ should have an entry Q. I'm trying to install something. The first thing that shows up is a dialog box saying "Setup is preparing the InstallShield wizard...", then I just get a big blue screen with the name of the product in the background, and it sits there forever. A. Try editing ~/.wine/config and change the line that says Managed = "Y" to Managed = "N" That works around a problem where Wine gets the Z-order of some windows wrong. This problem will eventually be fixed. > Presumably, your install is still failing, Dan? Now that you have the > blue screen usurper taken care of, does winedbg speak to you? Nah, the DAO install went fine after that. I guess I'll move on to the next issue, the MFC migration kit install, since fixing this bug appears to be beyond my skill level for the moment. Say, does anyone know what bug # this is in the bug database? I had trouble searching just now... - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Jan. 20, 2003

Re: 1995-era installshield woes - foreground window never appears

by Greg Turner

On Sunday 19 January 2003 09:39 pm, Francois Gouget wrote: > On Sun, 19 Jan 2003, Dan Kegel wrote: > > Aha! .wine/config had managed=Y. Switching it to managed=N > > made the dialog box show up properly! hmm, so I get the impression it still doesn't work for you? > > OK, this has to be a bug in wine, doesn't it? > > Not really. I believe this is a typical case of 'unmanaged windows go > on top'. Let me explain. > > That big blue window is most probably handled by Wine as an unmanaged > X window because it should not have the regular window decorations or > something like that. The problem is that some window managers (e.g. > the KDE WM) systematically put such windows on top of regular managed > windows. So when Wine then creates the installer dialog, a regular > managed X window, it is hidden by that big blue window. Furthermore > these window managers often make it hard to bring the managed windows > on top. > > So the 'fix' is to get Wine to treat all windows as managed > windows... and tell the window manager not to give them decorations. > This has been discussed before and I believe it is in Alexandre's > todo-list. But this stuff is pretty complex so it may take some > time... > > So in the meantime the solution is to either use Managed=N or > Desktop="800x600". Desktop="800x600" is pretty nice for installers, > especially if you put it in an executable-specific section, typically > one with the name of the installer. But desktop mode does not work > very well either (new processes get out of the desktop). Oh, well... I'm not sure that doesn't qualify as a bug in my book... I think you are right to point out that it may not be easy to fix properly. But even if its a feature, it's a confusing one. Presumably, your install is still failing, Dan? Now that you have the blue screen usurper taken care of, does winedbg speak to you? -- gmt "Everything that is really great and inspiring is created by the individual who can labor in freedom." --Albert Einstein

Jan. 20, 2003

Re: Problem compiling current CVS on Redhat 8

by Martin Cracauer

John K. Hohm wrote on Sun, Jan 19, 2003 at 10:00:25PM -0600: > > wine/dlls/comcat/: > > > > comcat_private.h:45: conflicting types for `ClassFactoryImpl' > > comcat.h:49: previous declaration of `ClassFactoryImpl' > > [more of same error for ther types] > > I'm quite confused by this; the current comcat.h only has 34 lines, > and doesn't define ClassFactoryImpl. Ups. Sorry, my screwup. I am using my own CVS tree for offline work, made out of imported checkouts. My script ended up not cvs-deleting the comcat.h in dlls/comcat, having both the old and new version and using the stale one, of course. It compiles fine right now. Sorry for the noise. Martin

Jan. 20, 2003

Re: Wine kernel acceleration module?

by Francois Gouget

On Sun, 19 Jan 2003, Shachar Shemesh wrote: > Francois Gouget wrote: > > >So you're better of with the kernel module if the bug is in the > >application, and you're better of with shm if the bug is in the server. > >Then it's a matter of which one is more likely. > > > I'm not in front of the sources at the moment. How big is the wineserver > at the moment? > > If it's rather big (and I rather suspect it is), then it seems obvious > which one is more likely. $ find server -name "*.[ch]" | xargs cat | wc -l 22452 $ find . -name "*.[ch]" | xargs cat | wc -l 1237362 $ find dlls files graphics if1632 library loader memory misc miscemu msdos objects ole relay32 scheduler win32 windows -name "*.[ch]" | xargs cat | wc -l 861271 So depending how you count the server represents between 1.8% and 2.6% of the Wine code. That's far from being a big portion of Wine. > The windows apps are released apps that were working on Windows NT. > The wineserver, on the other hand, is a piece of Alpha software that > has not seen too much pounding into. I think that a bug in the server > is MUCH MUCH MUCH more likely to happen. That's not supported by the above, and especially not by experience. How often have you seen applications crash in Wine? Me i see them crash every day (but of course being a Wine developper I am only interested by applications that crash). But most of the time it is the application that crashed, not the Wine server. In fact, I have not had a Wine server crash in at least a month. The thing is that yes, applications may be stable when they run on Windows NT, but they are running in Wine and make heavy use of the Wine libraries (~70% of the code). And in fact, I forgot the most important line in my table. Here it is duely corrected: | Current | Kernel | Shm ------------------+---------------+----------------+-------------------- Bug in a Wine | Process | Process | Wine library | | | ------------------+---------------+----------------+-------------------- Bug in a Windows | Process | Process | Wine application | | | ------------------+---------------+----------------+-------------------- Bug in the server | Wine | Machine | Wine > I think the best approach is a hybrid one. We have a kernel module that > does only the bare minimum required in the kernel. Everything else is > done using user-mode processes. There I completely agree with you. Only the speed-critical items should be handled by the kernel module. Ideally it would only provide a couple of concepts (e.g. HANDLE <-> fd mapping) that would allow us to have good performance while only doing a minimum in the kernel (e.g. not doing the Windows <-> Unix path conversions). But that's probably easier said than done and the above handle and file descriptor example should be taken more as an illustration than as a hard and fast recommendation on the way to do it :-) [...] > 4. Rebooting wine does not require rebooting the kernel (machine), or > even unloading and reloading the kernel module. Whatever the scenario I am not sure there is anything forcing us to restart the Wine server for 'rebooting' the Wine environment. The only thing requiring a Wine server restart would be upgrades. But even a with a kernel module, unloading and reloading the module should be enough. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Avoid the Gates of Hell - use Linux.

Jan. 20, 2003