- wine-devel - winehq.org

Help with dlopen and friends
by Shachar Shemesh 23 May '03

23 May '03

Hi all, I am trying to add ICU as a soft dependancy of Wine, so I can use it's BiDi functions. Unfortunetly, it seems to be using miracolous name mangling. ubidi.h has: U_CAPI UBiDi * U_EXPORT2 ubidi_open(void); however, 'nm -D libicuuc.so.21.0' gives: 00046784 T ubidi_open_2_1 The problem is not just theoretical. When I try to add to configure.ac: AC_CHECK_LIB(icuuc,ubidi_open,icu_lib=yes) the resulting program does not compile. It only compiles properly if the original header is used (I presume because that's how it knows about the name mangling). My dillema - even if I sort the configure mess out, for example by telling it to compile my own program, that uses the proper include, I am still not going to be successful in importing the symbol. As it appears that the mangling is a simple append of the library version, I can do this manually, but then future version stand no chance of working. Even if a simple recompile would solve it, the version will need to be updated at the import code. Possible solutions: 1. Use a different library - can be done, but messy. This is the most apropriate tool for the job. FriBiDi doesn't have shaping support, so Arabic will not work properly. 2. Inline the entire library - huge, and a maintanace headache. 3. Reimplement everything - possible, but seems like a total waste just because of a stupid name mangling. 4. Create a hard dependancy - not really an option. 5. Static link the library - now that will actually work. It is equivalent to 2 without the maintanance headache. Opinions and thoughts, please. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/

7 13

load_dll problem
by Dimitrie O. Paun 23 May '03

23 May '03

Folks, I am trying to run some Winelib apps built with winegcc, and they don't work. winegcc/winewrap do the wrapper idea to avoid initialization problems: basically the main app is built as a .dll which is loaded with LoadLibrary by a small loader. Well, this DLL is not found, and the app doesn't load. I think the problem is in load_dll(), in dlls/ntdll/loader.c line 887: if (!libdir || allocated_libdir) found = SearchPathA(NULL, libname, ".dll", MAX_PATH, filename, NULL); else found = DIR_SearchAlternatePath(libdir, libname, ".dll", MAX_PATH, filename, NULL); As SearchPathA doesn't seem to know that it also needs to look for the .so version of the DLL. Here is what happens: 1. Directory contents (simplified) [dimi@dimi dialogs]$ ls CVS dialogs.def dialogs.h dialogs.pro descrip.mms dialogs.dll.so dialogs.ico dialogs.rc dialogs dialogs.dsp dialogsM5.xml dialogs.rcO dialogs.cpp dialogs.exe.so dialogs.o dialogs_resources.o 'dialogs' is a small bash script which loads 'dialogs.exe.so' which does a simple LoadLibrary('dialogs.dll') to load 'dialogs.dll.so' which is the actual application. 2. Here is the relevant part of: ./dialogs --debugmsg +dosfs,+file,+module,+loaddll with a 'grep -v trace:dosfs:DOSFS_ReadDir' for brevity. trace:module:LdrGetDllHandle 0 0 L"user32.dll" -> 0x40980000 trace:module:LdrGetDllHandle 0 0 L"user32.dll" -> 0x40980000 trace:module:LdrGetDllHandle 0 0 L"user32.dll" -> 0x40980000 trace:module:LdrGetDllHandle 0 0 L"user32.dll" -> 0x40980000 trace:module:GetModuleFileNameW L"F:\\dev\\wine\\wxWindows\\samples\\dialogs\\dialogs.exe" trace:dosfs:DOSFS_GetFullName L"F:\\dev\\wine\\wxWindows\\samples\\dialogs\\dialogs.dll" (last=1) trace:dosfs:DOSFS_FindUnixName /home/dimi,L"dev\\wine\\wxWindows\\samples\\dialogs\\dialogs.dll" trace:dosfs:DOSFS_ToDosFCBFormat (L"dev\\wine\\wxWindows\\samples\\dialogs\\dialogs.dll", 0x408a1af0) trace:dosfs:DOSFS_OpenDir "/home/dimi" trace:dosfs:DOSFS_FindUnixName (/home/dimi,L"dev\\wine\\wxWindows\\samples\\dialogs\\dialogs.dll") -> L"dev" (L"DEV") trace:dosfs:DOSFS_FindUnixName /home/dimi/dev,L"wine\\wxWindows\\samples\\dialogs\\dialogs.dll" trace:dosfs:DOSFS_ToDosFCBFormat (L"wine\\wxWindows\\samples\\dialogs\\dialogs.dll", 0x408a1af0) trace:dosfs:DOSFS_OpenDir "/home/dimi/dev" trace:dosfs:DOSFS_FindUnixName (/home/dimi/dev,L"wine\\wxWindows\\samples\\dialogs\\dialogs.dll") -> L"wine" (L"WINE") trace:dosfs:DOSFS_FindUnixName /home/dimi/dev/wine,L"wxWindows\\samples\\dialogs\\dialogs.dll" trace:dosfs:DOSFS_ToDosFCBFormat (L"wxWindows\\samples\\dialogs\\dialogs.dll", 0x408a1af0) trace:dosfs:DOSFS_OpenDir "/home/dimi/dev/wine" trace:dosfs:DOSFS_FindUnixName (/home/dimi/dev/wine,L"wxWindows\\samples\\dialogs\\dialogs.dll") -> L"wxWindows" (L"WXWI~MP0") trace:dosfs:DOSFS_FindUnixName /home/dimi/dev/wine/wxWindows,L"samples\\dialogs\\dialogs.dll" trace:dosfs:DOSFS_ToDosFCBFormat (L"samples\\dialogs\\dialogs.dll", 0x408a1af0) trace:dosfs:DOSFS_OpenDir "/home/dimi/dev/wine/wxWindows" trace:dosfs:DOSFS_FindUnixName (/home/dimi/dev/wine/wxWindows,L"samples\\dialogs\\dialogs.dll") -> L"samples" (L"SAMPLES") trace:dosfs:DOSFS_FindUnixName /home/dimi/dev/wine/wxWindows/samples,L"dialogs\\dialogs.dll" trace:dosfs:DOSFS_ToDosFCBFormat (L"dialogs\\dialogs.dll", 0x408a1af0) trace:dosfs:DOSFS_OpenDir "/home/dimi/dev/wine/wxWindows/samples" trace:dosfs:DOSFS_FindUnixName (/home/dimi/dev/wine/wxWindows/samples,L"dialogs\\dialogs.dll") -> L"dialogs" (L"DIALOGS") trace:dosfs:DOSFS_FindUnixName /home/dimi/dev/wine/wxWindows/samples/dialogs,L"dialogs.dll" trace:dosfs:DOSFS_ToDosFCBFormat (L"dialogs.dll", 0x408a1af0) trace:dosfs:DOSFS_OpenDir "/home/dimi/dev/wine/wxWindows/samples/dialogs" warn:dosfs:DOSFS_FindUnixName L"dialogs.dll" not found in '/home/dimi/dev/wine/wxWindows/samples/dialogs' trace:dosfs:DOSFS_GetFullName L"dialogs.dll" (last=1) trace:dosfs:DOSFS_FindUnixName /home/dimi/dev/wine/wxWindows/samples/dialogs,L"dialogs.dll" trace:dosfs:DOSFS_ToDosFCBFormat (L"dialogs.dll", 0x408a1da8) trace:dosfs:DOSFS_OpenDir "/home/dimi/dev/wine/wxWindows/samples/dialogs" warn:dosfs:DOSFS_FindUnixName L"dialogs.dll" not found in '/home/dimi/dev/wine/wxWindows/samples/dialogs' trace:dosfs:DOSFS_FindUnixName /home/dimi/cxoffice/support/dotwine/fake_windows/Windows/System,L"dialogs.dll" trace:dosfs:DOSFS_ToDosFCBFormat (L"dialogs.dll", 0x408a1dd0) trace:dosfs:DOSFS_OpenDir "/home/dimi/cxoffice/support/dotwine/fake_windows/Windows/System" warn:dosfs:DOSFS_FindUnixName L"dialogs.dll" not found in '/home/dimi/cxoffice/support/dotwine/fake_windows/Windows/System' trace:dosfs:DOSFS_FindUnixName /home/dimi/cxoffice/support/dotwine/fake_windows/Windows,L"dialogs.dll" trace:dosfs:DOSFS_ToDosFCBFormat (L"dialogs.dll", 0x408a1dd0) trace:dosfs:DOSFS_OpenDir "/home/dimi/cxoffice/support/dotwine/fake_windows/Windows" warn:dosfs:DOSFS_FindUnixName L"dialogs.dll" not found in '/home/dimi/cxoffice/support/dotwine/fake_windows/Windows' trace:module:GetModuleFileNameW L"F:\\dev\\wine\\wxWindows\\samples\\dialogs\\dialogs.exe" trace:dosfs:DOSFS_GetFullName L"c:\\windows\\dialogs.dll" (last=1) trace:dosfs:DOSFS_FindUnixName /home/dimi/cxoffice/support/dotwine/fake_windows,L"windows\\dialogs.dll" trace:dosfs:DOSFS_ToDosFCBFormat (L"windows\\dialogs.dll", 0x408a1d44) trace:dosfs:DOSFS_OpenDir "/home/dimi/cxoffice/support/dotwine/fake_windows" trace:dosfs:DOSFS_FindUnixName (/home/dimi/cxoffice/support/dotwine/fake_windows,L"windows\\dialogs.dll") -> L"Windows" (L"WINDOWS") trace:dosfs:DOSFS_FindUnixName /home/dimi/cxoffice/support/dotwine/fake_windows/Windows,L"dialogs.dll" trace:dosfs:DOSFS_ToDosFCBFormat (L"dialogs.dll", 0x408a1d44) trace:dosfs:DOSFS_OpenDir "/home/dimi/cxoffice/support/dotwine/fake_windows/Windows" warn:dosfs:DOSFS_FindUnixName L"dialogs.dll" not found in '/home/dimi/cxoffice/support/dotwine/fake_windows/Windows' trace:dosfs:DOSFS_GetFullName L"c:\\windows\\system\\dialogs.dll" (last=1) trace:dosfs:DOSFS_FindUnixName /home/dimi/cxoffice/support/dotwine/fake_windows,L"windows\\system\\dialogs.dll" trace:dosfs:DOSFS_ToDosFCBFormat (L"windows\\system\\dialogs.dll", 0x408a1d44) trace:dosfs:DOSFS_OpenDir "/home/dimi/cxoffice/support/dotwine/fake_windows" trace:dosfs:DOSFS_FindUnixName (/home/dimi/cxoffice/support/dotwine/fake_windows,L"windows\\system\\dialogs.dll") -> L"Windows" (L"WINDOWS") trace:dosfs:DOSFS_FindUnixName /home/dimi/cxoffice/support/dotwine/fake_windows/Windows,L"system\\dialogs.dll" trace:dosfs:DOSFS_ToDosFCBFormat (L"system\\dialogs.dll", 0x408a1d44) trace:dosfs:DOSFS_OpenDir "/home/dimi/cxoffice/support/dotwine/fake_windows/Windows" trace:dosfs:DOSFS_FindUnixName (/home/dimi/cxoffice/support/dotwine/fake_windows/Windows,L"system\\dialogs.dll") -> L"System" (L"SYSTEM") trace:dosfs:DOSFS_FindUnixName /home/dimi/cxoffice/support/dotwine/fake_windows/Windows/System,L"dialogs.dll" trace:dosfs:DOSFS_ToDosFCBFormat (L"dialogs.dll", 0x408a1d44) trace:dosfs:DOSFS_OpenDir "/home/dimi/cxoffice/support/dotwine/fake_windows/Windows/System" warn:dosfs:DOSFS_FindUnixName L"dialogs.dll" not found in '/home/dimi/cxoffice/support/dotwine/fake_windows/Windows/System' trace:dosfs:DOSFS_GetFullName L"e:\\\\dialogs.dll" (last=1) trace:dosfs:DOSFS_FindUnixName /tmp,L"dialogs.dll" trace:dosfs:DOSFS_ToDosFCBFormat (L"dialogs.dll", 0x408a1d44) trace:dosfs:DOSFS_OpenDir "/tmp" warn:dosfs:DOSFS_FindUnixName L"dialogs.dll" not found in '/tmp' trace:dosfs:DOSFS_GetFullName L"e:\\test\\dialogs.dll" (last=1) trace:dosfs:DOSFS_FindUnixName /tmp,L"test\\dialogs.dll" trace:dosfs:DOSFS_ToDosFCBFormat (L"test\\dialogs.dll", 0x408a1d44) trace:dosfs:DOSFS_OpenDir "/tmp" warn:dosfs:DOSFS_FindUnixName L"test\\dialogs.dll" not found in '/tmp' trace:dosfs:DOSFS_GetFullName L"f:\\\\dialogs.dll" (last=1) trace:dosfs:DOSFS_FindUnixName /home/dimi,L"dialogs.dll" trace:dosfs:DOSFS_ToDosFCBFormat (L"dialogs.dll", 0x408a1d44) trace:dosfs:DOSFS_OpenDir "/home/dimi" trace:dosfs:DOSFS_OpenDir "/home/dimi" warn:dosfs:DOSFS_FindUnixName L"dialogs.dll" not found in '/home/dimi' trace:module:MODULE_GetLoadOrder looking for C:\WINDOWS\SYSTEM\dialogs.dll trace:module:GetModuleFileNameW L"F:\\dev\\wine\\wxWindows\\samples\\dialogs\\dialogs.exe" trace:module:open_app_key searching 'dialogs' in AppDefaults\dialogs.exe\DllOverrides trace:module:MODULE_GetLoadOrder got standard wildcard "b,n" for "dialogs.dll" trace:module:load_dll Trying built-in 'C:\WINDOWS\SYSTEM\dialogs.dll' warn:module:BUILTIN32_dlopen cannot open .so lib for builtin dialogs.dll: /usr/local/lib/wine/dialogs.dll.so: cannot open shared object file: No such file or directory trace:module:load_dll Trying native dll 'C:\WINDOWS\SYSTEM\dialogs.dll' trace:file:CreateFileW L"C:\\WINDOWS\\SYSTEM\\dialogs.dll" GENERIC_READ FILE_SHARE_READ OPEN_EXISTING attributes 0x0 trace:dosfs:DOSFS_GetFullName L"C:\\WINDOWS\\SYSTEM\\dialogs.dll" (last=1) trace:dosfs:DOSFS_FindUnixName /home/dimi/cxoffice/support/dotwine/fake_windows,L"WINDOWS\\SYSTEM\\dialogs.dll" trace:dosfs:DOSFS_ToDosFCBFormat (L"WINDOWS\\SYSTEM\\dialogs.dll", 0x408a1fe0) trace:dosfs:DOSFS_OpenDir "/home/dimi/cxoffice/support/dotwine/fake_windows" trace:dosfs:DOSFS_FindUnixName (/home/dimi/cxoffice/support/dotwine/fake_windows,L"WINDOWS\\SYSTEM\\dialogs.dll") -> L"Windows" (L"WINDOWS") trace:dosfs:DOSFS_FindUnixName /home/dimi/cxoffice/support/dotwine/fake_windows/Windows,L"SYSTEM\\dialogs.dll" trace:dosfs:DOSFS_ToDosFCBFormat (L"SYSTEM\\dialogs.dll", 0x408a1fe0) trace:dosfs:DOSFS_OpenDir "/home/dimi/cxoffice/support/dotwine/fake_windows/Windows" trace:dosfs:DOSFS_FindUnixName (/home/dimi/cxoffice/support/dotwine/fake_windows/Windows,L"SYSTEM\\dialogs.dll") -> L"System" (L"SYSTEM") trace:dosfs:DOSFS_FindUnixName /home/dimi/cxoffice/support/dotwine/fake_windows/Windows/System,L"dialogs.dll" trace:dosfs:DOSFS_ToDosFCBFormat (L"dialogs.dll", 0x408a1fe0) trace:dosfs:DOSFS_OpenDir "/home/dimi/cxoffice/support/dotwine/fake_windows/Windows/System" warn:dosfs:DOSFS_FindUnixName L"dialogs.dll" not found in '/home/dimi/cxoffice/support/dotwine/fake_windows/Windows/System' warn:file:CreateFileW Unable to get full filename from L"C:\\WINDOWS\\SYSTEM\\dialogs.dll" (GLE 2) warn:module:load_dll Failed to load module 'C:\WINDOWS\SYSTEM\dialogs.dll'; status=-1073741809 trace:module:LdrGetDllHandle 0 0 L"user32.dll" -> 0x40980000 -- Dimi.

6 21

Overlapped I/O + hEvent == NULL reopened + other questions
by Thomas Charbonnel 23 May '03

23 May '03

Hi, I'm trying to migrate a proprietary TCP/IP client/server db application from Windows NT to Linux using Wine, and am encountering some difficulties. * First of all the application uses overlapped I/O in an unconventionnal way. The application scenario is as follows : Setup server socket Call WSAAsyncSelect On accept, create a new window associated with the new socket Call WSAAsyncSelect for this new socket/window. On network event on the new socket, if the FD_READ event is passed to the WindowProc, call ReadFile with an overlapped struct, but hEvent == NULL On IO_PENDING_READ_ERROR, call GetOverlappedResult with bWait set to TRUE There was a thread about this on this list on November 2002 ("Overlapped I/O without an hEvent"). At that time Martin Wilck submited a patch that did not get commited to CVS. I got things working by slightly modifying his patch. The idea was floating around in the November thread : in the GetOverlappedResult function, if the bWait flag is set, then wait calling WaitForSingleObjectEx with the socket handle passed in instead of the overlapped structure handle. I suspect this method is unclean, but works for me as the server app I'm trying to run instantiates a window (thus a WindowProc) per client. I'm waiting for your comments and suggestions on how to properly handle this. * Next I have a problem with high network loads (maybe related to the previous issue). When I run the sever app in Wine and access it with a remote client, operations generating a high network load tend to be unstable. Most of the time the client application hangs at some point, and sometimes the server hangs too. This does not happen if I run the client with Wine on the same machine as the server. Are they known issues with the winsock implementation ? * Wine used to crash because the server app called WritePrivateProfileString with a NULL lpFileName. I fixed this by returning FALSE if lpFileName == NULL, but I don't know how windows handles this. The app calls WritePrivateProfileString with a proper file name a couple of times before setting it to NULL, so I suspect windows is caching the file name. * The client comes with a printing helper app. They communicate through dde. I get the 'fixme:class:get_class_ptr reading from class of other process window' message. How is this supposed to be handled ? * Minor remaining problems : - the end of tooltip texts is garbled - help doesn't work (it seems the help file name is not passed as a parameter) Thanks for your attention, Thomas

3 2

A under-educated question
by Steven Edwards 23 May '03

23 May '03

Hello, I am going to attempt to split commdlg and comdlg32 in to win16/32 parts and am having trouble with all of the internal functions. How can I export a function from one object to another? I have tried declairing the internal functions in a header and its still not working. Forgive me I am still new to this. Here is a mini-example of what I am talking about. fubar32.c /********fu internal function*********/ void fu() { do stuff } /*******Bar[A/W] Win32 function*******/ STDCALL BarW() { fu("importing fu in to barW\n"); } Next I have a Win16 function that needs to import fu. How can I export it? fubar16.c and then in the win16 file we import the fu function/ /************Bar16***********/ PASCAL bar16() { fu("importing fu for Win16 function"); } Thanks Steven

2 1

Fw: Re: [latest cvs] Yet more GTA3 errors.
by erwin wolff 22 May '03

22 May '03

Hi, Thanks for the device.c. GTA3 still crashes in a fatal exception when starting a level ;(. But this time it produces an other error than before :) : fixme:d3d:IDirect3D8Impl_CheckDeviceFormat (0x402a5380)->(Adptr:0, DevType:(1,D3DDEVTYPE_HAL), AdptFmt:(23,D3DFMT_R5G6B5), Use:(0,none), ResTyp:(3,D3DRTYPE_TEXTURE), CheckFmt:(41,D3DFMT_P8)) fixme:d3d:IDirect3DDevice8Impl_SetPaletteEntries (0x402e5e70) : setting p[41] <= RGBA(00,00,00,ff) fixme:dialog:MSGBOX_OnInit task modal msgbox ! Not modal yet. wine: Unhandled exception, starting debugger... At the ingame menu it produces this fixme: fixme:d3d:IDirect3DDevice8Impl_SetCurrentTexturePalette >>>>>>>>>>>>>>>>> 500 from glColorTableEXT @ device.c / 4437 fixme:d3d:IDirect3DDevice8Impl_SetCurrentTexturePalette (0x402e5e60) : Setting to (48) fixme:d3d:IDirect3DDevice8Impl_SetCurrentTexturePalette >>>>>>>>>>>>>>>>> 500 from glColorTableEXT @ device.c / 4437 The menu textures still don't look nice but it is much better than before :). If you want a screenshot, just ask. --------------------------------------------- erwin wolff erwinwolffnl(a)microformatica.com

2 1

-fexceptions? -fasync-unwind-tables?
by Gregory M. Turner 22 May '03

22 May '03

OK, as you may have guessed, I'm still driving myself insane trying to fix __try and friends. I have some other less promising ideas on the backburner; this one seemed to have sufficient potential that I thought I would ask the group to let me know what they think. In short: gcc accepts the above options. The first, is considered to be a C++ compatibility mode in C. That is to say, it provides the right glue such that exceptions can unwind through calls to C libraries. If /any/ library in the call-chain leaves this option out, I'm afraid it breaks down. The second, -fasync-unwind-tables, provides "dwarf2 unwind tables". I've looked through the dwarf2 spec and some other sources, but I have yet to find solid documentation for this... perhaps it's a "use the source, Luke" situation. But this second option promises "instruction-granularity" unwind tables of some kind. IOW, presumably, this would be enough to implement __try and friends without looking beyond the stack pointer. As for the idea of stealing the return pointer on the stack. I like it even less now. It appears that signal handlers are allowed to clobber the stack above the SP on some architectures, which means we're pretty much up a creek. There still might be some ultra-clever work-around involving copying the current stack frame, but I think we would at least have to create our own trampolines in asm, which, I fear, might break in subsequent gcc releases... So... anybody know where these options are actually documented? I mean, I see the blurb in the info pages, which is enticing, but surely there is some API or datastructure to look at somewhere.... -- "Security is mostly superstition. It does not exist in nature, nor do the children of men as a whole experience it. Avoiding danger is no safer in the long run than outright exposure. Life is either a daring adventure, or nothing. To keep our faces toward change and behave like free spirits in the presence of fate is strength undefeatable." --Helen Keller gmt

4 7

TAB doesn't work for controls anymore
by Gerhard W. Gruber 22 May '03

22 May '03

Since a few days I noticed that you can't use TAB anymore to cycle through controls. I noticed that when using Forte Agent, because I can't use the keyboard to switch from To: to Subject and so on. Any ideas what has been changed? -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken)

8 18

Re : Fix sound3d compile problem
by Sylvain Petreolle 22 May '03

22 May '03

I dont understand why this patch fixes anything, this is a noop ? - TRACE("(%p)\n",ds3db); /* volume, at which the sound will be played after all calcs. */ D3DVALUE lVolume = 0; @@ -205,6 +204,7 @@ D3DVALUE flFreq, flBufferVel, flListenerVel; #endif + TRACE("(%p)\n",ds3db); ===== Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259 No more War ! "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". For the Law of Oil and Fire, Im an European that lives in France. For all my Brothers and friends, Im a human living on Earth. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

3 2

Speaking about the Putty Regression
by Carlos Lozano 22 May '03

22 May '03

Hello, The line what is produccing the regression is: void X11DRV_SetWindowStyle( HWND hwnd, LONG oldStyle ) { Display *display = thread_display(); WND *wndPtr; LONG changed; if (hwnd == GetDesktopWindow()) return; if (!(wndPtr = WIN_GetPtr( hwnd ))) return; if (wndPtr == WND_OTHER_PROCESS) return; changed = wndPtr->dwStyle ^ oldStyle; if (changed & WS_VISIBLE) { if (!IsRectEmpty( &wndPtr->rectWindow ) && !is_window_top_level(wndPtr)) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Before of the regression it was: if (!IsRectEmpty( &wndPtr->rectWindow )) Regards, Carlos. -- ___ _ \ | / Consulting | . |._ _ _| | ___ ___ ___ http://www.andago.com | || ' |/ . |<_> |/ . |/ . \__ GNU/Linux |_|_||_|_|\___|<___|\_. |\___/ _ \ __|\ \ / Carlos A. Lozano <___'/ | \ -_) __/\__ \ > < -_) [ carlos.lozano(a)andago.com ]\___|_| ____/ _/\_\___| [ calb(a)epsxe.com ] http://www.ePSXe.com

1 0

Re: int21 testing
by Jukka Heinonen 22 May '03

22 May '03

Ferenc Wagner wrote: > is there a way to incorporate DOS interrupt testing in the > conformance testing framework? I recall that I saw some > comments that Win32 applications should not be able to call > DOS interrupts. But it should be testable at least... Now > I have separate DOS16 programs for that. Win32 application cannot call interrupts directly. You could use VWIN32 VxD to call some interrupts (int21 for example) and this should even work under Win95/Win98/WinMe. It could even be possible that this works under WinXP, if it has emulation code for supporting old applications, but I doubt it. -- Jukka Heinonen <http://www.iki.fi/jhei/>

2 3

Today's meeting
by Dimitrie O. Paun 21 May '03

21 May '03

Hi guys, To clarify: -- channel is #winemeet on freenode.net (I use the asimov.freenode.net server) -- time is 3 EDT (1900 UTC) -- a few of us should log the session (BTW, how do you log a session?) I am there now, but I will not have too much time to chat until the regular meeting starts. -- Dimi.

4 5

Re: [D3D] Some execute buffers rewrites + misc fixes
by Lionel Ulmer 21 May '03

21 May '03

Well, I have a comment... But it's in a part of the code that will be so rarely used that it could be completely thrown away anyway :-) Basically, you are doing the full projection (without doing the clipping though) in software... And this does not go well at all with lighting. This is why I choose in the previous code to only do the world transformation to NOT impact at all lighting (and it worked for Twist AFAIK). So I am wondering why you choose to go all the way and did not do exactly as I did (basically, only do the WORLD transform and set only the PROJ / VIEW one using the D3D7 API and set the WORLD to Identity as we already did the transform). Even better would have been to have reused fully our VertexBuffer code and our (hacky :-) ) TransformVertices code. Lionel -- Lionel Ulmer - http://www.bbrox.org/

1 0

Re: dlls/ntdll/cdrom.c CDROM_ScsiPassThrough on NetBSD
by yorickhardy 21 May '03

21 May '03

Alexandre, My sincerest apologies, I see it is in fact there. I think I missed something when I looked through wine-cvs and the web cvs (I looked at source.winehq.org instead of cvs.winehq.com). Thanks, Yorick. ----- Original Message ----- Date: Wed May 21, 2003 09:22 AM From: Alexandre Julliard <julliard(a)winehq.com> To: yh(a)metroweb.co.za cc: wine-devel(a)winehq.com Subject: Re: dlls/ntdll/cdrom.c CDROM_ScsiPassThrough on NetBSD yh(a)metroweb.co.za writes: > I see this patch was included > http://www.winehq.org/hypermail/wine-patches/2003/05/0258.html > http://www.winehq.org/hypermail/wine-cvs/2003/05/0312.html > > I apologise if it was not clear but the patch > http://www.winehq.org/hypermail/wine-patches/2003/05/0241.html > should be applied first, which includes the neccessary header files. I thought I applied it, what did I do wrong? -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: dlls/ntdll/cdrom.c CDROM_ScsiPassThrough on NetBSD
by yh＠metroweb.co.za 21 May '03

21 May '03

I see this patch was included http://www.winehq.org/hypermail/wine-patches/2003/05/0258.html http://www.winehq.org/hypermail/wine-cvs/2003/05/0312.html I apologise if it was not clear but the patch http://www.winehq.org/hypermail/wine-patches/2003/05/0241.html should be applied first, which includes the neccessary header files. Regards, Yorick Hardy. ------------------------------------------------------- This message was sent using MetroWEB's WebMail service. http://www.metroweb.co.za/ - full access for only R59

2 1

Re: Fix ListView Bugs
by Dimitrie O. Paun 21 May '03

21 May '03

On May 17, 2003 06:37 am, Robert Shearman wrote: > It is the second one. The 0th subitem always seems to stay in the 0th > column and the other subitems are shifted. (Note that the column headings > are shifted normally, ie. column 0 has a new column heading). Interesting. This seems to mean that we can remove a lot of fancy code from there :) What about this patch: Index: dlls/comctl32/listview.c =================================================================== RCS file: /var/cvs/wine/dlls/comctl32/listview.c,v retrieving revision 1.351 diff -u -r1.351 listview.c --- dlls/comctl32/listview.c 13 May 2003 00:30:10 -0000 1.351 +++ dlls/comctl32/listview.c 19 May 2003 07:28:54 -0000 @@ -6242,25 +6242,10 @@ /* now we have to actually adjust the data */ if (!(infoPtr->dwStyle & LVS_OWNERDATA) && infoPtr->nItemCount > 0) { - SUBITEM_INFO *lpSubItem, *lpMainItem, **lpNewItems = 0; + SUBITEM_INFO *lpSubItem; HDPA hdpaSubItems; INT nItem, i; - /* preallocate memory, so we can fail gracefully */ - if (nNewColumn == 0) - { - lpNewItems = COMCTL32_Alloc(sizeof(SUBITEM_INFO *) * infoPtr->nItemCount); - if (!lpNewItems) goto fail; - for (i = 0; i < infoPtr->nItemCount; i++) - if (!(lpNewItems[i] = COMCTL32_Alloc(sizeof(SUBITEM_INFO)))) break; - if (i != infoPtr->nItemCount) - { - for(; i >=0; i--) COMCTL32_Free(lpNewItems[i]); - COMCTL32_Free(lpNewItems); - goto fail; - } - } - for (nItem = 0; nItem < infoPtr->nItemCount; nItem++) { hdpaSubItems = (HDPA)DPA_GetPtr(infoPtr->hdpaItems, nItem); @@ -6270,21 +6255,7 @@ if (lpSubItem->iSubItem >= nNewColumn) lpSubItem->iSubItem++; } - - /* for inserting column 0, we have to special-case the main item */ - if (nNewColumn == 0) - { - lpMainItem = (SUBITEM_INFO *)DPA_GetPtr(hdpaSubItems, 0); - lpSubItem = lpNewItems[nItem]; - lpSubItem->hdr = lpMainItem->hdr; - lpSubItem->iSubItem = 1; - ZeroMemory(&lpMainItem->hdr, sizeof(lpMainItem->hdr)); - lpMainItem->iSubItem = 0; - DPA_InsertPtr(hdpaSubItems, 1, lpSubItem); - } } - - COMCTL32_Free(lpNewItems); } /* make space for the new column */ -- Dimi.

2 1

Re: ddraw: load OpenGL at runtime
by Lionel Ulmer 20 May '03

20 May '03

Alexandre, please do NOT commit this... The separation of GL calls from DDraw will be part of the D3D core work and not via the usage of funtion pointers. Basically, we will have a d3dcore library linked to OpenGL and if DDraw fails to load it (for example if GL is not present on the system), DDraw will not support D3D. Mike, next time ask on IRC before doing a big patch like this on DDraw / D3D (or ask on the wine-d3d mailing list, it will add to its activity :-) ). Lionel -- Lionel Ulmer - http://www.bbrox.org/

11 30

[FYI] SourceForge stats
by Dimitrie O. Paun 20 May '03

20 May '03

Folks, For the first time we are in the first 30 downloads (position 29 :)) on SourceForge: http://sourceforge.net/top/toplist.php?type=downloads_week We need to make it to the fist 10, so we are always featured on the front page :) But we need to more than quadruple our downloads to achieve that. Alexandre, I think you need to release more often ;) -- Dimi.

4 11

Re: ntdll/kernel32: #25
by Alexandre Julliard 20 May '03

20 May '03

Eric Pouech <pouech-eric(a)wanadoo.fr> writes: > - access to PROCESS_PARAMETERS from kernel32: currently this is done > by exporting a function pointer from ntdll, but this is not a good > solution IMO. Should we better: 1/ create a real PEB and store it at > its real offset. 2/ store the pointer to PROCESS_PARAMETER in the PDB > (even if it doesn't exist in PDB but in PEB) at an unused offset (I > don't think it's really doable to merge PDB and PEB, or we'll have to > trash PDB.exit_code) PDB and PEB are really the same thing, so they definitely have to be merged. -- Alexandre Julliard julliard(a)winehq.com

2 2

DSound bug in 'DuplicateSoundBuffer'
by Lionel Ulmer 20 May '03

20 May '03

Hi all, One of my test application (which now starts to run with my latest D3D work) fails now due to a bug in DSound. Basically, I have this : trace:dsound:IDirectSoundImpl_DuplicateSoundBuffer (0x4040aa80,0x4861fad0,0x4199cf58) fixme:dsound:IDirectSoundImpl_DuplicateSoundBuffer need to duplicate 3D buffer trace:dsound:IDirectSoundBufferImpl_AddRef (0x4861fad0) ref was 2, thread is 0009 trace:dsound:IDirectSoundImpl_DuplicateSoundBuffer buffer count is now 4 trace:dsound:IDirectSoundBufferImpl_SetVolume (0x40463080,0) And, of course, it crashes as the 'DuplicateSoundBuffer' code sets this : (*ippdsb)->ds3db = NULL; /* FIXME? */ Now I could try to fix this, but well, DSound is not really the same than the last time I looked at it, so I will surely do this the wrong way. Otherwise, I may give it a shot, but do not complain later that it's not the way it should have been done :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

2 2

Re: [D3D] Some execute buffers rewrites + misc fixes
by Lionel Ulmer 20 May '03

20 May '03

Some comments on 'small' parts... I will have to commit the patch on my tree to try to understand the resulting code to understand it better :-) > + if ( IsEqualGUID( &IID_IDirectDrawSurface, riid ) || > + IsEqualGUID( &IID_IDirectDrawSurface2, riid ) || > + IsEqualGUID( &IID_IDirectDrawSurface3, riid ) ) { > + IDirectDrawSurface7_AddRef(ICOM_INTERFACE(This->surface, IDirectDrawSurface7)); > + *obp = ICOM_INTERFACE(This->surface, IDirectDrawSurface3); > + TRACE(" Return IDirectDrawSurface3 interface %p\n", *obp); > + return S_OK; > + } > + if ( IsEqualGUID( &IID_IDirectDrawSurface3, riid ) || > + IsEqualGUID( &IID_IDirectDrawSurface7, riid ) ) { > + IDirectDrawSurface7_AddRef(ICOM_INTERFACE(This->surface, IDirectDrawSurface7)); > + *obp = ICOM_INTERFACE(This->surface, IDirectDrawSurface7); > + TRACE(" Return IDirectDrawSurface7 interface %p\n", *obp); > + return S_OK; > + } Well, it's a bit strange to have 'IID_IDirectDrawSurface3' twice, no :-) ? > /* We only support the BLT with DEPTH_FILL for now */ > - if (This->ddraw_owner->d3d != NULL) { > + if ((dwFlags & DDBLT_DEPTHFILL) && This->ddraw_owner->d3d != NULL) { > if (This->ddraw_owner->d3d->current_device != NULL) { > This->ddraw_owner->d3d->current_device->clear(This->ddraw_owner->d3d->current_device, > 0, NULL, /* Clear the whole screen */ Did you add this check here because some game were actually doing a 'normal' blit on the ZBuffer ? What happens in this case ? Moreover, you could also add here (which I forgot to do in my patch), support for the 'dst locking rectangle' in case an application tries to clear only part of the buffer (see example in the Blt overide function in d3ddevice/mesa.c for the 'Colorfill' case). Lionel -- Lionel Ulmer - http://www.bbrox.org/

1 0

Linking errors when crosscompiling tests
by Hans Leidekker 20 May '03

20 May '03

Hi, When I run a 'make crosstest' using MingW I get errors like these: /usr/local/src/wine-cvs/wine/dlls/oleaut32/tests/safearray.c:289: undefined reference to `IID_IUnknown' safearray.cross.o(.text+0x1814):/usr/local/src/wine-cvs/wine/dlls/oleaut32/tests/safearray.c:290: undefined reference to `IID_IUnknown' What's happening is that this test references symbols that reside in wine_uuid, which is added to the library search path for the regular Wine build, but left out in the crosscompile build. For good reasons, because wine_uuid is built as a Unix archive, not as an import library, which is what MingW needs. So I created an import library from the Unix archive: nm libwine_uuid.a | egrep -v "^$" | egrep -v "^*.o:$" | cut -d" " -f 3 \ >> wine_uuid.def i386-mingw32-dlltool -l wine_uuid.lib -d ./wine_uuid.def And I had a working executable. But this obviously is not the way Wine does it. Wine generates .def files from .spec files. To use Wine's build system I had to create a new dll -- uuid -- and copy the sources over from libs/uuid. This gave me a Wine generated import library. Next I added uuid as an import library to the Makefile for the oleaut32 test and removed wine_uuid from EXTRALIBS. Did this solve my problem? No it didn't. Because, as it turns out, winebuild does not support importing non-function entry points, such as IID_IUnknown. After googling around a bit I have to conclude that this is quite a fundamental problem. If I understand it correctly, it's because in this case PE style linking can not be emulated using the ELF linker. Then I decided to bypass linking and go with LoadLibraryA and GetProcAddress, which are already used in the tests to find the functions to be tested. This finally gave me a uniform build system for regular and crosscompiled tests. My question is, is this acceptable for integration into Wine? The consequence would be that, to be consistent, all parts of Wine that are now linked with wine_uuid would need to be converted. Or is such consistency maybe considered less important than getting crosscompiled tests going? -Hans

3 4

wine and VC++ MFC classes
by Thomas Erdmann 20 May '03

20 May '03

Hello list, i use a new wine from may 2003 on SuSE8.0 and want to run a self written Visual C++ Program with MFC. There is a "CMonthCalCtrl" used, which displayes a calendar und allowes to choose a day. This Control doesn't work, the Selection by Mouse is not possible. As i started it by "wine prog" in a shell, i can see the wine output, but there isn't any warning or error. What can i do to fix the Problem ? THX Thomas

2 1

Re: Agent/Wine/Mandrake 9.1 problem
by Rein Klazes 20 May '03

20 May '03

Gentlemen, I am trying to help Alex Heney who reported problems in agent newsgroup running Agent on his Manrdake 9.1 system. Wine is compiled with the --with-nptl configuration switch enabled, but we still get what looks like thread lock-ups. Both with wine-20030408 and 20030508 Agent frequently freezes when doing online tasks. Here is an example: | 0012:Call kernel32.CreateThread(00000000,00002000,00573144,421db238,00000000,407120c0) ret=005731f3 | 0014:Starting thread (entryproc=0x573144) thread with id 14 is started. It performs a few simple tasks: | 0014:Call kernel32.SetFilePointer(000000bc,00000020,42a4271c,00000000) ret=0043eb2f | 0014:Ret kernel32.SetFilePointer() retval=00000020 ret=0043eb2f | 0014:Call kernel32.SetLastError(00000000) ret=0043ed82 | 0014:Ret kernel32.SetLastError() retval=00000000 ret=0043ed82 | 0014:Call kernel32.ReadFile(000000bc,421d7af8,00000020,42a42718,00000000) ret=0043ed97 | 0014:Ret kernel32.ReadFile() retval=00000001 ret=0043ed97 does something on inherited file handles. | 0014:Call kernel32.GetPrivateProfileIntA(005d5b53 "Purging",005d5b5b "PurgeOnNewHeaders",00000001,41a60d48 "C:\\Program Files\\agent\\DATA\\AGENT.INI") ret=00577677 | 0014:Ret kernel32.GetPrivateProfileIntA() retval=00000001 ret=00577677 reads a flag from its ini file. | 0014:Call kernel32.VirtualQuery(427e0000,42a426d0,0000001c) ret=00588d5e | 0014:Ret kernel32.VirtualQuery() retval=0000001c ret=00588d5e | 0014:Call kernel32.VirtualQuery(427e0000,42a426c8,0000001c) ret=00588d5e | 0014:Ret kernel32.VirtualQuery() retval=0000001c ret=00588d5e | 0014:Call kernel32.VirtualFree(427e0000,00010000,00004000) ret=00588bd7 | 0014:Ret kernel32.VirtualFree() retval=00000001 ret=00588bd7 | 0014:Call kernel32.VirtualFree(427e0000,00000000,00008000) ret=00588be8 | 0014:Ret kernel32.VirtualFree() retval=00000001 ret=00588be8 does some virtual queries. | 0014:Call user32.PostMessageA(00040023,00000411,421d1000,00000000) ret=0046c56d | 0014:Call kernel32.GetTickCount() ret=408865f9 | 0014:Ret kernel32.GetTickCount() retval=004f7151 ret=408865f9 | 0014:Ret user32.PostMessageA() retval=00000001 ret=0046c56d post a message to the main window. | 0014:Call kernel32.ExitThread(00000000) ret=0057326c And it is done, after some unloading call from this thread the log stops and no other threads resume. On my (non nptl) system I do see a "Ret CreateThread" from the calling thread long before the subthread exits. For completeness: Alex reported this to happen only when he connects to his local newsserver on "localhost", not when using that of his ISP. I cannot find anything suspicious about this in the relaylog, so it is probably a timing issue. Any suggestions how to debug this? Full +relay,+winsock log on http://www.xs4all.nl/~rklazes/temp/agent.log.bz2 Rein. -- Rein Klazes rklazes(a)xs4all.nl

2 2

Re: Bugzilla Upgraded
by Dan Kegel 20 May '03

20 May '03

Sylvain Petreolle wrote: > - Login is mandatory otherwise you cant read bugs. > Its too bad, you cant see if a bug already exists before openeing an > account nor follow a link to a bug. I think it's ok to require login to read bugs. This is the only effective defence against rampaging robots. I recently created a web page about how to triage OpenOffice.org bugs (http://www.kegel.com/openoffice/), and even though I stuck <meta name="robots" content="nofollow"> in the head, I think spambots are hammering the openoffice issuezilla server and make the current slowdowns worse. Plus there's the matter of all those email addresses. Requiring login helps shield the email addresses in bugzilla from spambots. So hip hip hooray for the upgrade from this developer, restrictive access and all. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

9 23

Building wine as shared objects for mono
by Mike Hearn 20 May '03

20 May '03

Hi, OpenLink Software just announced their patches to Wine to allow mono to Wine directly, rather than by building a winelib wrapper. You can find some info and the patch here: http://www.openlinksw.com/mono/ Warning - the patch is large (~75k) and has lots of #ifdef MONOs and such, but interesting nonetheless, regardless of how big a hack it is. It'd be interesting for Alexandre to review this sometime and evaluate how much would be required to make this mergable (assuming it is). This goes back to our discussion earlier about what would be required for Wine to be dlopen()able for other projects to use it. thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

1 0

OGL: cubemaps
by Robert Lunnon 20 May '03

20 May '03

Compiling the latest CVS wine gives the following compile time error due to use of cubemapping under Solaris. I suggest perhaps a configure test for the OGL version prior to enabling this code since this obviously Isn't supported for Mesa 3.2 and utah glx. (No Can't use DRI, not (yet) supported under Solaris) cubetexture.c:125: `GL_TEXTURE_CUBE_MAP_POSITIVE_X_ARB' undeclared here (not in a function) cubetexture.c:125: initializer element is not constant cubetexture.c:125: (near initialization for `cube_targets[0]') cubetexture.c:126: `GL_TEXTURE_CUBE_MAP_NEGATIVE_X_ARB' undeclared here (not in a function) cubetexture.c:126: initializer element is not constant cubetexture.c:126: (near initialization for `cube_targets[1]') cubetexture.c:127: `GL_TEXTURE_CUBE_MAP_POSITIVE_Y_ARB' undeclared here (not in a function) cubetexture.c:127: initializer element is not constant cubetexture.c:127: (near initialization for `cube_targets[2]') cubetexture.c:128: `GL_TEXTURE_CUBE_MAP_NEGATIVE_Y_ARB' undeclared here (not in a function) cubetexture.c:128: initializer element is not constant cubetexture.c:128: (near initialization for `cube_targets[3]') cubetexture.c:129: `GL_TEXTURE_CUBE_MAP_POSITIVE_Z_ARB' undeclared here (not in a function) cubetexture.c:129: initializer element is not constant cubetexture.c:129: (near initialization for `cube_targets[4]') cubetexture.c:132: `GL_TEXTURE_CUBE_MAP_NEGATIVE_Z_ARB' undeclared here (not in a function) cubetexture.c:132: initializer element is not constant cubetexture.c:132: (near initialization for `cube_targets[5]') cubetexture.c: In function `IDirect3DCubeTexture8Impl_PreLoad': cubetexture.c:144: `GL_TEXTURE_CUBE_MAP_ARB' undeclared (first use in this function)

1 0

Re: Fixes some debug messages
by Dimitrie O. Paun 20 May '03

20 May '03

On May 19, 2003 06:06 pm, Lozano, Carlos A. wrote: > * Avoid print a no init buffer. What about this instead: Index: dlls/x11drv/xvidmode.c =================================================================== RCS file: /var/cvs/wine/dlls/x11drv/xvidmode.c,v retrieving revision 1.18 diff -u -r1.18 xvidmode.c --- dlls/x11drv/xvidmode.c 22 Apr 2003 00:15:48 -0000 1.18 +++ dlls/x11drv/xvidmode.c 20 May 2003 12:21:47 -0000 @@ -461,7 +461,7 @@ static const char * _CDS_flags(DWORD fields) { BOOL first = TRUE; - char buf[128]; + char buf[128] = ""; char *p = buf; _X_FIELD(CDS,UPDATEREGISTRY);_X_FIELD(CDS,TEST);_X_FIELD(CDS,FULLSCREEN); _X_FIELD(CDS,GLOBAL);_X_FIELD(CDS,SET_PRIMARY);_X_FIELD(CDS,RESET); @@ -471,7 +471,7 @@ static const char * _DM_fields(DWORD fields) { BOOL first = TRUE; - char buf[128]; + char buf[128] = ""; char *p = buf; _X_FIELD(DM,BITSPERPEL);_X_FIELD(DM,PELSWIDTH);_X_FIELD(DM,PELSHEIGHT); _X_FIELD(DM,DISPLAYFLAGS);_X_FIELD(DM,DISPLAYFREQUENCY);_X_FIELD(DM,POSITION); -- Dimi.

1 0

CVS bombs
by Andreas Mohr 20 May '03

20 May '03

Hi all, main.c:34: warning: implicit declaration of function `exit' gcc -o wine -Wl,--section-start,.interp=0x3c000100 main.o -L../dlls -lntdll.dll -L../libs/wine -lwine -L../libs/unicode -lwine_unicode -L../libs/port -lwine_port ../dlls/libntdll.dll.so: undefined reference to `SetWaitableTimer' ../dlls/libntdll.dll.so: undefined reference to `CancelWaitableTimer' ../dlls/libntdll.dll.so: undefined reference to `CreateWaitableTimerA' collect2: ld returned 1 exit status make[1]: *** [wine] Error 1 make[1]: Leaving directory `/usr/local/src/wine/miscemu' make: *** [miscemu] Error 2 Not sure whether that's a general problem of the timer transitions or just a quirkiness in my local modified tree, but... -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://mohr.de.tt

3 3

CX merge
by Steven Edwards 19 May '03

19 May '03

How close are we to being done with the CrossOver merge? I have more ole32 to submit and want to merge the ReactOS stuff. Thanks Steven __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com

2 1

seh_try_macros2-00
by Gregory M. Turner 19 May '03

19 May '03

This should not go in, it's WIP, just trolling for comments... License: Bugroff Changelog: - include/wine/excpetion.h - memory/global.c Implement gcc-specific "__TYPED_TRY" macro supposedly capable of intercepting return and running the finally clause. If it compiles, it should work on x86... If it fails to compile, it needs you to specify the return type as in __TYPED_TRY(float) { } __FINALLY(func) { } __ENDTRY . Other arches may have much less success ;) of course, almost any problem of this kind should be fixed by turning __TRY into the appropriate __TYPED_TRY. __TRY generates warnings, some may be fixable. Untested, and probably broken... but this should give you an idea of where I'm headed. From here, I can probably implement __try and friends much as before, with the twist that __try is just __typed_try(int ****) or what-have-you. -gmt -- diff -ur --minimal --exclude-from=/home/greg/bin/winetreediff_excl ../wine.vanilla/include/wine/exception.h ./include/wine/exception.h --- ../wine.vanilla/include/wine/exception.h 2003-01-29 21:50:14.000000000 -0600 +++ ./include/wine/exception.h 2003-05-14 21:37:51.000000000 -0500 @@ -74,6 +74,94 @@ #else /* USE_COMPILER_EXCEPTIONS */ +#if defined(__GNUC__) + +#define __TYPED_TRY(return_type) \ + if ( ({ \ + __label__ __typed_try_block_setup, __typed_try_block_entry, \ + __typed_try_block_exit_no_return, __typed_try_block_exit_return0, \ + __typed_try_block_exit_return1, __typed_try_block_exit_full; \ + __WINE_FRAME __wf; \ + typeof(return_type) __scope_return_val; \ + auto typeof(return_type) __scope_tryblock_fn(); \ + goto __typed_try_block_setup; \ + \ + __typed_try_block_entry: \ + __scope_return_val = __scope_tryblock_fn(); \ + __wine_pop_frame( &__wf.frame ); \ + goto __typed_try_block_exit_return0; \ + \ + __typed_try_block_exit_return1: \ + return __scope_return_val; \ + \ + typeof(return_type) __scope_tryblock_fn() \ + { \ + { + +#define __TRY __TYPED_TRY(unsigned int ****) + +#define __FINALLY(func) \ + } \ + /* this unwinds the __scope_tryblock_fn call */ \ + goto __typed_try_block_exit_no_return; \ + } \ + \ + __typed_try_block_setup: \ + __wf.frame.Handler = (PEXCEPTION_HANDLER)__wine_finally_handler; \ + __wf.u.finally_func = (func); \ + __wine_push_frame( &__wf.frame ); \ + goto __typed_try_block_entry; \ + \ + __typed_try_block_exit_return0: \ + (func)(1); \ + goto __typed_try_block_exit_return1; \ + \ + __typed_try_block_exit_no_return: \ + __wine_pop_frame( &__wf.frame ); \ + (func)(1); \ + { \ + { + +#define __EXCEPT(func) \ + } \ + /* this unwinds the __scope_tryblock_fn call */ \ + goto __typed_try_block_exit_no_return; \ + } \ + \ + __typed_try_block_exit_return0: \ + goto __typed_try_block_exit_return1; \ + \ + __typed_try_block_exit_no_return: \ + __wine_pop_frame( &__wf.frame ); \ + goto __typed_try_block_exit_full; \ + \ + __typed_try_block_setup: \ + __wf.frame.Handler = (PEXCEPTION_HANDLER)__wine_exception_handler; \ + __wf.u.filter = (func); \ + __wine_push_frame( &__wf.frame ); \ + if (!(setjmp( __wf.jmp ))) { \ + goto __typed_try_block_entry; \ + } else { \ + const __WINE_FRAME * const __eptr WINE_UNUSED = &__wf; \ + { + +#define __ENDTRY \ + } \ + } \ + __typed_try_block_exit_full: 0; \ + }) ) { } else { } + +#define __BREAK goto __typed_try_block_exit_no_return + +#else /* __GNUC__ */ + +/* these are the old wine __TRY macros. They are not + * capable of intercepting returns, which means the + * return-from-tryblock feature of the above macros + * shouldn't be used in parts of wine which will be used + * with non-gcc compilers. + */ + #define __TRY \ do { __WINE_FRAME __f; \ int __first = 1; \ @@ -81,6 +169,8 @@ { \ do { +#define __TYPED_TRY(x) __TRY + #define __EXCEPT(func) \ } while(0); \ __wine_pop_frame( &__f.frame ); \ @@ -114,6 +204,9 @@ } \ } while (0); +#define __BREAK break + +#endif /* __GNUC__*/ typedef DWORD (CALLBACK *__WINE_FILTER)(PEXCEPTION_POINTERS); typedef void (CALLBACK *__WINE_FINALLY)(BOOL); diff -ur --minimal --exclude-from=/home/greg/bin/winetreediff_excl ../wine.vanilla/memory/global.c ./memory/global.c --- ../wine.vanilla/memory/global.c 2003-05-14 15:06:26.000000000 -0500 +++ ./memory/global.c 2003-05-14 21:38:13.000000000 -0500 @@ -1251,7 +1251,7 @@ if (ISPOINTER(pmem)) { if (HeapValidate( GetProcessHeap(), 0, pmem )) { handle = (HGLOBAL)pmem; /* valid fixed block */ - break; + __BREAK; } handle = POINTER_TO_HANDLE(pmem); } else @@ -1263,7 +1263,7 @@ test = maybe_intern->Pointer; if (HeapValidate( GetProcessHeap(), 0, (char *)test - HGLOBAL_STORAGE ) && /* obj(-handle) valid arena? */ HeapValidate( GetProcessHeap(), 0, maybe_intern )) /* intern valid arena? */ - break; /* valid moveable block */ + __BREAK; /* valid moveable block */ } handle = 0; SetLastError( ERROR_INVALID_HANDLE ); -- "There is no dignity quite so impressive, and no independence quite so important, as living within your means." --Calvin Coolidge gmt

6 18

Function forwarding in DLL
by Gerhard W. Gruber 19 May '03

19 May '03

I noticed that some functions from w95inf32 are similarily named and already implemented in setupx.dll. For some functions even the arguments are the same. So I wanted to try if this works when I simply forward the function to setupx. I looked into other spec files on how this is done but when I try to compile it then I get a compile error: make[2]: Entering directory `/mnt/data2/home/gerhard/src/wine/dlls/w95inf32' make[2]: *** No rule to make target `../../dlls/libsetupx.def', needed by `w95inf32.spec.c'. Stop. make[2]: Leaving directory `/mnt/data2/home/gerhard/src/wine/dlls/w95inf32' make[1]: *** [w95inf32] Error 2 make[1]: Leaving directory `/mnt/data2/home/gerhard/src/wine/dlls' -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken)

3 4

How symbols are resolved?
by Pierre d'Herbemont 19 May '03

19 May '03

Hi, I would like to have some precision on how symbols are resolved, because I am having troubles like : 000b:trace:module:find_ordinal_export ordinal 24410 out of range(10/1049)! err:module:import_dll No implementation for kernel32.dll.24420 imported from C:\windows\system\notepad.exe, setting to 0xdeadbeef My specific is how does the link is done from a symbol to the ordinal? Is it handled by winebuild? Thanks, Pierre

2 1

Re: wine/dlls/shell32 shlexec.c
by Eric Pouech 19 May '03

19 May '03

Alexandre Julliard wrote: > Log message: > Aric Stewart <aric(a)codeweavers.com> > Added support for the %L escape. from the docs I have found, %L is meant to be the long name followed by the 8+3 short name (last time I tried with wmp just the long name part it didn't work, maybe it's better with latest wmp version) A+ -- Eric Pouech

1 0

US international keyboard layout
by Gerhard W. Gruber 19 May '03

19 May '03

I'm using Suse 8.0 Prof and I configured a US international keyboard. I have a US keyboard but I need to have german umlauts as well. When I run wine then I get the errormessage that my keyboard can't be recognized and I should include it in x11drv/keyboard .c . Now I checked this file and I was surprised to find this layout already there. Apparently wine can't detect my layout for some reason but I don't know how to fix this. Any suggestions how I should proceed? The funny thing is that the keyboard layout works properly in wine, so I get all the Umlauts. Seems that the error message is wrong. -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken)

4 6

glXGetProcAddressARB causing dozens of warnings
by Gerald Pfeifer 19 May '03

19 May '03

I'm afraid the following patch date: 2003/05/07 03:18:51; author: julliard; state: Exp; lines: +1 -0 Michael Schlüter <michael(a)johalla.de> Added wglGetExtensionsStringARB. to dlls/opengl32/opengl32.spec, dlls/opengl32/wgl.c and dlls/opengl32/wgl.h is responsible for the following warnings (seen on FreeBSD 4.8/i386 with XFree86-4.3.0 and Mesa-3.4.2). Would you mind fixing these? stateblock.c:203: warning: implicit declaration of function `glActiveTextureARB' wgl.c:325: warning: implicit declaration of function `glXGetProcAddressARB' wgl.c:325: warning: comparison between pointer and integer wgl.c:334: warning: assignment makes pointer from integer without a cast opengl_norm.c:28: warning: implicit declaration of function `glActiveTextureARB' opengl_norm.c:210: warning: implicit declaration of function `glClientActiveTextureARB' opengl_norm.c:2152: warning: implicit declaration of function `glMultiTexCoord1dARB' opengl_norm.c:2162: warning: implicit declaration of function `glMultiTexCoord1dvARB' opengl_norm.c:2172: warning: implicit declaration of function `glMultiTexCoord1fARB' opengl_norm.c:2182: warning: implicit declaration of function `glMultiTexCoord1fvARB' opengl_norm.c:2192: warning: implicit declaration of function `glMultiTexCoord1iARB' opengl_norm.c:2202: warning: implicit declaration of function `glMultiTexCoord1ivARB' opengl_norm.c:2212: warning: implicit declaration of function `glMultiTexCoord1sARB' opengl_norm.c:2222: warning: implicit declaration of function `glMultiTexCoord1svARB' opengl_norm.c:2232: warning: implicit declaration of function `glMultiTexCoord2dARB' opengl_norm.c:2242: warning: implicit declaration of function `glMultiTexCoord2dvARB' opengl_norm.c:2252: warning: implicit declaration of function `glMultiTexCoord2fARB' opengl_norm.c:2262: warning: implicit declaration of function `glMultiTexCoord2fvARB' opengl_norm.c:2272: warning: implicit declaration of function `glMultiTexCoord2iARB' opengl_norm.c:2282: warning: implicit declaration of function `glMultiTexCoord2ivARB' opengl_norm.c:2292: warning: implicit declaration of function `glMultiTexCoord2sARB' opengl_norm.c:2302: warning: implicit declaration of function `glMultiTexCoord2svARB' opengl_norm.c:2312: warning: implicit declaration of function `glMultiTexCoord3dARB' opengl_norm.c:2322: warning: implicit declaration of function `glMultiTexCoord3dvARB' opengl_norm.c:2332: warning: implicit declaration of function `glMultiTexCoord3fARB' opengl_norm.c:2342: warning: implicit declaration of function `glMultiTexCoord3fvARB' opengl_norm.c:2352: warning: implicit declaration of function `glMultiTexCoord3iARB' opengl_norm.c:2362: warning: implicit declaration of function `glMultiTexCoord3ivARB' opengl_norm.c:2372: warning: implicit declaration of function `glMultiTexCoord3sARB' opengl_norm.c:2382: warning: implicit declaration of function `glMultiTexCoord3svARB' opengl_norm.c:2392: warning: implicit declaration of function `glMultiTexCoord4dARB' opengl_norm.c:2402: warning: implicit declaration of function `glMultiTexCoord4dvARB' opengl_norm.c:2412: warning: implicit declaration of function `glMultiTexCoord4fARB' opengl_norm.c:2422: warning: implicit declaration of function `glMultiTexCoord4fvARB' opengl_norm.c:2432: warning: implicit declaration of function `glMultiTexCoord4iARB' opengl_norm.c:2442: warning: implicit declaration of function `glMultiTexCoord4ivARB' opengl_norm.c:2452: warning: implicit declaration of function `glMultiTexCoord4sARB' opengl_norm.c:2462: warning: implicit declaration of function `glMultiTexCoord4svARB' Thanks, Gerald -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.pfeifer.com/gerald/

4 6

Valgrind for WINE tarball now available
by Adam Gundy 19 May '03

19 May '03

For all you developers out there who haven't tried valgrinding WINE yet (it's fun - honest!) there is now a pre-patched tarball of the latest valgrind 1.9.6 for WINE available from the valgrind website: http://developer.kde.org/~sewardj/ no patching needed to WINE or valgrind. Just get the latest snapshot of WINE (or a CVS checkout), build for debugging, get the pre-patched valgrind and use it! there are still plenty of bugs in WINE which need fixing - most are simple 1 line edits.. Seeya, Adam -- Real Programmers don't comment their code. If it was hard to write, it should be hard to read, and even harder to modify. These are all my own opinions.

3 5

Another keyboard problem
by Gerhard W. Gruber 18 May '03

18 May '03

I'm using a US keyboard with US international driver. When using this driver under Windows you can press ALT and then an ASCII code on the NUM block. This works since back to the days when DOS was still in use and you could use this to enter characters that may not be supported by the keyboard driver. This doesn't work in Wine. -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken)

2 2

Re: Always print version on startup
by Marcus Meissner 18 May '03

18 May '03

On Sat, May 17, 2003 at 01:42:03PM +0200, Uwe Bonnes wrote: > Changelog: > misc/options.c: OPTIONS_ParseOptions > Always print out version > > The recent posting about the Altere quartus installer not working seems to > be caused by an old version used. The poster shows the startup and > messages. If the version was printed by default, it could help debugging This will break apps checking on stdout output. It is also not very helpful, since for larger apps it will be printed dozens of times. Ciao, Marcus

3 2

How long for a patch?
by Gerhard W. Gruber 18 May '03

18 May '03

I submitted a patch about a week (maybe more) ago to include a new DLL w95inf32 into wine. The patch has not been included and there was also no feedback as to why it is not included. How long does it usually take until a patch will be taken in? Or is there some other reason why this is not done? -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken)

5 6

Perl on Redhat 9 switches to character semantics
by Hans Leidekker 18 May '03

18 May '03

Hi, On Redhat 9 I get errors like this one when doing a 'make htmlpages': Malformed UTF-8 character (unexpected non-continuation byte 0x6e, immediately after start byte 0xfc) in substitution (s///) at ../../tools/c2man.pl line 313, <SOURCE_FILE> line 2. This is because I have LANG="en_US.UTF-8" as part of my environment, and perl will now switch to character semantics (as opposed to byte semantics) when it detects a Unicode character set. Wine source files contain characters with ordinals > 127 (it looks like the Wine sources are ISO_8859-1) and of course, these usually don't also form valid UTF-8 sequences. Off hand I see three solutions (in order of increasing acceptability): 1. Convert Wine source files to ASCII-7 or UTF-8 2. Set character set to "C" or "ISO8859-1" prior to running perl on the sources 3. Force perl back into using byte semantics 1. Most non-ASCII-7 characters are in C comments (in the names of authors, e.g. Ove Kåven). But there are files like dlls/x11drv/keyboard.c that contain them as part of a C string. Going this way would mean these characters would have to be escaped. Of course this is a step backwards. It would degrade readability of the sources and probably offend some awkwardly named authors ;^) It would also require a change of pratice, which is hard to accomplish. Converting to UTF-8 seems more promising. C strings still need to be escaped but then our Hungarian, authors can finally have their names spelled properly in the sources! Still, there are more programs that have to interpret C source files and I estimate that most of them do not yet handle UTF-8 properly (though vi and emacs are amongst the capable). 2. Changing the character set beforehand will get rid of the errors and is much less controversial than the above solution ;) But it's still cumbersome to have to do so. 3. This will work regardless of the character set specified in the user's environment. The attached patch does this for c2man.pl Bye, -Hans Changelog: Force perl to use byte semantics

2 3

Re: wine/ dlls/winedos/Makefile.in dlls/winedos/.c ...
by hatky 18 May '03

18 May '03

> Log message: > Moved vxd support to winedos. > > Patch: > http://cvs.winehq.com/patch.py?root=/home/winehq/opt/cvs-commit&id=8230 I did not know wine has vxd suppot I remeber trying kali and as it trys to load a vxd that does ipx->tcp/ip I was getting fixme's and the vxd was not loaded.... And to the topic why sould it be in dos when win95 and win98 support it I know winnt/winxp do not, I am not sure about the rest but this is not dos.... Hatky. __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com

5 7

Re: [Bug 1448] Getting Unreal Turnement 2003 (game) working - video detection probelm - registry accsess
by Sylvain Petreolle 18 May '03

18 May '03

Whats the problem with the new bugzilla, some bugs are empty now (no description at all) look at this one, the only comments are the last which were posted. http://bugs.winehq.com/show_bug.cgi?id=1448 ===== Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259 No more War ! "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". For the Law of Oil and Fire, Im an European that lives in France. For all my Brothers and friends, Im a human living on Earth. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

3 2

Re: Getting DXBall to run
by Hans Leidekker 18 May '03

18 May '03

On Fri, 16 May 2003, Lionel Ulmer wrote: > The real problem is that the application is setting the PITCH flag and gives > us a Pitch set to '0'... Which is *not* a good thing :-) > > I tested the attached patch and it seems to work too (and I feel that it's a > bit better :-) ). I agree. Thanks very much, I've tested it and it works for me too! -Hans

1 0

Re: [dx8-34 bis] too many things for a subject ;)
by Alexandre Julliard 18 May '03

18 May '03

Raphaël Junqueira <fenix(a)club-internet.fr> writes: > Index: d3d8_private.h > =================================================================== > RCS file: /home/wine/wine/dlls/d3d8/d3d8_private.h,v > retrieving revision 1.26 > diff -u -r1.26 d3d8_private.h > --- d3d8_private.h 14 May 2003 19:33:35 -0000 1.26 > +++ d3d8_private.h 17 May 2003 15:32:24 -0000 > @@ -55,10 +55,11 @@ > #include "d3d8.h" > > /* Device caps */ > +#define MAX_PALETTES 256 > #define MAX_STREAMS 16 > #define MAX_ACTIVE_LIGHTS 8 > #define MAX_CLIPPLANES D3DMAXUSERCLIPPLANES > -#define MAX_LEVELS 256 > +#define MAX_LEVELS 256 > > /* Other useful values */ > #define HIGHEST_RENDER_STATE 174 > @@ -272,13 +273,16 @@ > float lightPosn[MAX_ACTIVE_LIGHTS][4]; > float lightDirn[MAX_ACTIVE_LIGHTS][4]; > > + /* palettes texture management */ > + PALETTEENTRY palettes[MAX_PALETTES][256]; > + UINT currentPalette; I applied the patch, but you will really need to allocate that thing dynamically. Reserving 256Kb for palette data is a bit too much (not to mention that MAX_PALETTES should be 65536 if I read the doc correctly). -- Alexandre Julliard julliard(a)winehq.com

2 1

PuTTY breakage uncovered
by Dimitrie O. Paun 17 May '03

17 May '03

Alexandre, It seems that this patch: http://www.winehq.org/hypermail/wine-cvs/2002/08/0158.html broke PuTTY. Before the patch, the dialog would come up, after the patch, it doesn't. You can get putty.exe from this link: http://the.earth.li/~sgtatham/putty/latest/x86/putty.exe it requires no installation, just do $ wine putty.exe to run it. -- Dimi.

1 0

Re: New _lcreat tests
by Mike Hearn 17 May '03

17 May '03

it seems you forget the attachment? On Sat, 2003-05-17 at 17:26, Ferenc Wagner wrote: > These are to reveal the difference to the DOS interface > (int 21 sevice 3c). > > Changelog: > New _lcreat test for filename ending in a slash. > New _lcreat test for volume label attribute. >

1 0

Re: winelpk.dll
by Dimitrie O. Paun 17 May '03

17 May '03

On Thu, 15 May 2003, Shachar Shemesh wrote: > The attached patch is adding a new DLL, called "winelpk". This DLL is > meant to replace a Windows undocumented DLL called "LPK.DLL", or > Language Pack. LPK.DLL implemented the BiDi for GetCharacterPlacement, > DrawText, EditControl and so on and so forth. As the interfaces there > are undocumented, however, I changed the name of the Wine DLL, to avoid > confusion and attempts to replace one with the other. This doesn't make sense. If we're not compatible with LPK, why add a DLL in the first place, and not implement those functions in their respective DLLs? -- Dimi.

4 3

Re: NPTL auto detection
by Dag Wieers 17 May '03

17 May '03

Hi, I'm not subscribed to this list but noticed the NPTL discussion on Wine Traffic #170. I saw a lot of people mentioning to make it a compile-time option, but no one with a definitive runtime check. Valgrind went through the same problem and I proposed a solution on their list. AFAIK they're not using it, they still have a run-time parameter instead of auto-detecting it on loadtime. The discussion is here: http://sourceforge.net/mailarchive/forum.php?thread_id=2027895&forum_id=320… http://sourceforge.net/mailarchive/forum.php?thread_id=2052985&forum_id=320… And a couple of lines to check what threading library is used: //#define _XOPEN_SOURCE #define _POSIX_C_SOURCE 2 #include <unistd.h> #include <stdio.h> int main(void) { char *buf; size_t n; n=confstr(_CS_GNU_LIBPTHREAD_VERSION, NULL, (size_t) 0); if ((buf = (char *) malloc(n)) == NULL) abort(); confstr(_CS_GNU_LIBPTHREAD_VERSION, buf, n); fprintf(stdout, "%s\n", buf); exit(0); } Which is basicly the same as: getconf GNU_LIBPTHREAD_VERSION I'm not sure if this is new information, but I didn't see it mentioned anywhere. Kind regards, -- dag wieers, dag(a)wieers.com, http://dag.wieers.com/ -- �Any errors in spelling, tact or fact are transmission errors�

2 1

System Shock 2 Working (Almost)
by OverrideX 17 May '03

17 May '03

Hey guys, I don't know if anyone else has but I've been trying to get system shock 2 working with wine for quite some time. It segfaults with the latest versions of winex, but with a cvs of wine from 20030115 it works! Menus, sound and 3D all seem to be working fine, except for some slight texture corruption on things like door handles. The problem is the 2D overlay stuff - the HUD, inventory, etc. are all missing which makes it unplayable. I saw on some other forum that it had been added to either wine or winex... anyone have any ideas? Another problem is that ss2 no longer seems to work with the newer wine builds (20030327 at least) it just displays a message that says video card not supported. So, I'd just like to know if the 2D stuff may work in the latest wines or not, and if so how to fix the video card not supported message - thanks for any info :) -Dan -- OverrideX <overridex(a)punkass.com> GPG Key Fingerprint = 4AD5 CE9C D7C8 0069 BDD3 7F72 3AB2 642A 5A5D EB89 Woody: What's going on, Mr. Peterson? Norm: A flashing sign in my gut that says, ``Insert beer here.'' -- Cheers, Call Me, Irresponsible

2 3

[latest cvs] Yet more GTA3 errors.
by erwin wolff 17 May '03

17 May '03

Hi, Here are some more GTA 3 error witch prevents GTA3 from running smoothly: This is what I get when loading the in-game intro: fixme:d3d:IDirect3D8Impl_CheckDeviceFormat (0x402b56a0)->(Adptr:0, DevType: 1, AdptFmt: 23, Use: 0, ResTyp: 3, CheckFmt: 23) fixme:d3d:IDirect3DDevice8Impl_SetCurrentTexturePalette (0x402b6460) : stub PreparePathData Single car node: 311.002502 -938.778015 22.178200 (1817) GraphType:0. FloodFill groups:4 GraphType:1. FloodFill groups:87 Done with PreparePathData fixme:d3d:IDirect3D8Impl_CheckDeviceFormat (0x402b56a0)->(Adptr:0, DevType: 1, AdptFmt: 23, Use: 0, ResTyp: 3, CheckFmt: 23) fixme:d3d:IDirect3DDevice8Impl_SetCurrentTexturePalette (0x402b6460) : stub Done Initing waterlevels fixme:d3d:IDirect3DDevice8Impl_SetCurrentTexturePalette (0x402b6460) : stub fixme:d3d:IDirect3D8Impl_CheckDeviceFormat (0x402b56a0)->(Adptr:0, DevType: 1, AdptFmt: 23, Use: 0, ResTyp: 3, CheckFmt: 21) fixme:d3d:IDirect3D8Impl_CheckDeviceFormat (0x402b56a0)->(Adptr:0, DevType: 1, AdptFmt: 23, Use: 0, ResTyp: 3, CheckFmt: 22) fixme:d3d:IDirect3D8Impl_CheckDeviceFormat (0x402b56a0)->(Adptr:0, DevType: 1, AdptFmt: 23, Use: 0, ResTyp: 3, CheckFmt: 41) These fixme's are repeated over and over in the in-game intro of the game: fixme:d3d:IDirect3DTexture8Impl_PreLoad >>>>>>>>>>>>>>>>> 500 from glTexImage2D @ texture.c / 151 fixme:d3d:IDirect3DDevice8Impl_SetCurrentTexturePalette (0x402e5e50) : stub fixme:d3d:fmt2glType Unhandled fmt(41,D3DFMT_P8) fixme:d3d:fmt2glFmt Unhandled fmt(41,D3DFMT_P8) fixme:d3d:fmt2glintFmt Unhandled fmt(41,D3DFMT_P8) When eventually playing the game I get this: fixme:d3d:IDirect3DDevice8Impl_SetCurrentTexturePalette (0x402e5e50) : stub fixme:d3d:IDirect3DDevice8Impl_SetPixelShaderConstant (0x402e5e50) : stub fixme:d3d:IDirect3DDevice8Impl_SetPixelShader (0x402e5e50) : stub -268435453 fixme:d3d:IDirect3DDevice8Impl_SetTextureStageState Unhandled D3DTSS_TEXCOORDINDEX 10000 fixme:d3d:IDirect3DDevice8Impl_SetTextureStageState Unhandled D3DTSS_TEXCOORDINDEX 10000 This is pretty much all the errors that I get. Happy fixing :)

2 1

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