September 2005 - Wine-devel

Re: fake directx 9c instead of 9b (needed for rFactor Config)
by Oliver Stieber 07 Sep '05

07 Sep '05

--- Christoph Frick <frick(a)sc-networks.de> wrote: > hi gents. > > The attached patch sets the version for directx to 9C (instead of 9B). > The rF\ Config.exe from the game rFactor (www.rfactor.net) needs this to > work. After that change i was able to successfully run the config and > configure the game (yet the game itself fails to execute by a > stack-overflow in the exception handling). > The only real difference between 9C and 9B is shaders, a lot of cards don't support 9C shaders under windows, even though the drivers are 9C so even on windows you could consider the version to be 'faked'. I'll take a look at getting rfactor working a bit better too, or at least identifying the problems. ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

2 1

Re: include/sqltypes.h: Added SQLWCHAR typedef
by Francois Gouget 07 Sep '05

07 Sep '05

On Tue, 6 Sep 2005, Phil Krylov wrote: > ChangeLog: > > Added typedef SQLWCHAR to include/sqltypes.h. Could you also add SQLTCHAR while you're at it? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Nouvelle version : les anciens bogues ont été remplacés par de nouveaux.

1 0

Re: wine/dlls/shell32 shresdef.h shres.rc shfldr_u ...
by Michael Jung 07 Sep '05

07 Sep '05

Hi Ge, On Wednesday 07 September 2005 01:05, you wrote: > I'm working on importing the changes between Wine-20050725 and > Wine-20050830 into ReactOS. This also includes your patch below. > I'm not sure if you realized it, but shell32 now wastes a lot of memory. > The problem is the initialization of the icon cache. Previously, icons with > indexes 1-39 would be loaded. Since IDI_SHELL_MY_DOCUMENTS has such a high > number, now icons with indexes 1-235 are loaded. Most of those ofcourse > don't exist and will be replaced with index 1, but they still take up a lot > of space in the ImageList bitmaps. I've found that, for ReactOS running on > a 32bpp display, memory usage of shell32 increased by 17Mb. This may in > part be a problem in ReactOS (it's much higher than I expected), but even > for Wine the increase in mem usage should be considerable. The ImageLists > get expanded to 494 entries, taking up 494 (entries) * 2 (color + mask) * > 32 (sizex) * 32 (sizey) * 4 (32bpp) = 4Mb per ImageList. We're keeping 2 > ImageLists, plus 2 16*16 ImageLists, all in all we're talking about 10Mb > minimum. And this for every process that loads shell32. I'm aware of this problem (though I didn't know about the exact numbers). There was a short discussion on wine-devel about it: http://www.winehq.org/pipermail/wine-devel/2005-August/039452.html The problem is, that we currently can't read icons via PrivateExtractIcons from wine's ELF dlls. I would guess that for ReactOS, you don't need the hack'ish icon cache pre-initialization at all, since you do have real PE dlls? > For the moment I'm limiting the ReactOS icon cache to the lower 39 entries, > but I think we need to figure out a way to include the My Documents icon > without wasting so much space. As was pointed out by Alexandre, the correct fix for wine would probably be to try to load the given dll via LoadModule, if all other methods fail in PrivateExtractIcon. Unfortunetaly, I don't have time to work on this at the moment, and probably won't have for the next months. Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

2 1

Re: urlmon resource
by Alexandre Julliard 07 Sep '05

07 Sep '05

Stefan Leichter <Stefan.Leichter(a)camLine.com> writes: > diff -urw ../wine/dlls/urlmon/Makefile.in dlls/urlmon/Makefile.in > --- ../wine/dlls/urlmon/Makefile.in 2005-09-06 19:18:47.000000000 +0200 > +++ dlls/urlmon/Makefile.in 2005-09-03 21:05:48.000000000 +0200 > @@ -16,7 +15,8 @@ > umstream.c \ > urlmon_main.c > > -RC_SRCS = rsrc.rc > +RC_SRCS = rsrc.rc \ > + version.rc You shouldn't add multiple resource files, mingw unfortunately doesn't support that. Simply #include version.rc from the main file. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: add proper support for native NT drivers and programs to the build system
by Alexandre Julliard 07 Sep '05

07 Sep '05

Ivan Leo Puoti <ivanleo(a)gmail.com> writes: > @@ -469,8 +469,10 @@ > /* get the default entry point for a given spec file */ > static const char *get_default_entry_point( const DLLSPEC *spec ) > { > + if (spec->subsystem == IMAGE_SUBSYSTEM_NATIVE && spec->characteristics & IMAGE_FILE_DLL) > + return "__wine_spec_drv_entry"; > + if (spec->subsystem == IMAGE_SUBSYSTEM_NATIVE) return "__wine_spec_exe_nentry"; Native drivers are not supposed to be dlls. > @@ -322,9 +322,15 @@ > ORDDEF *odp = &spec->entry_points[i]; > if (odp->type != TYPE_STUB) continue; > fprintf( outfile, "#ifdef __GNUC__\n" ); > - fprintf( outfile, "extern void __wine_spec_unimplemented_stub( const char *module, const char *func ) __attribute__((noreturn));\n" ); > + if(spec->subsystem == IMAGE_SUBSYSTEM_NATIVE) > + fprintf( outfile, "extern void __wine_spec_nunimplemented_stub( const char *module, const char *func ) __attribute__((noreturn));\n" ); > + else > + fprintf( outfile, "extern void __wine_spec_unimplemented_stub( const char *module, const char *func ) __attribute__((noreturn));\n" ); > fprintf( outfile, "#else\n" ); > - fprintf( outfile, "extern void __wine_spec_unimplemented_stub( const char *module, const char *func );\n" ); > + if(spec->subsystem == IMAGE_SUBSYSTEM_NATIVE) > + fprintf( outfile, "extern void __wine_spec_nunimplemented_stub( const char *module, const char *func ) __attribute__((noreturn));\n" ); > + else > + fprintf( outfile, "extern void __wine_spec_unimplemented_stub( const char *module, const char *func );\n" ); You should provide your own handling of stubs inside ntoskrnl, like ntdll does. -- Alexandre Julliard julliard(a)winehq.org

2 2

Object manager case sensitivity issue
by Vitaliy Margolen 07 Sep '05

07 Sep '05

I want to make sure that this problem is well understood. Also to make it clear that Wine differs from windows in this really important aspect. For more details, you can refer to the following thread: http://www.winehq.org/hypermail/wine-devel/2005/04/0426.html It needs to be fixed at least on the server level (I have sent a patch for one of the possible solutions). Then we can get ntdll to follow the suite. For a test see attached program. You should be able to run it on windows with administrative privileges. As you can see, this is something very dangerous yet perfectly legal, at least on win2k sp4. -- Best regards, Vitaliy

1 0

Strange problem with writing files from wine
by Pavel Troller 07 Sep '05

07 Sep '05

Hi! I have problems with writing files from wine (today's CVS). Typical example is word95, which always writes something like: Cannot access folder "F:\filename.doc ": unaccessible or protected by password (in my local language, so it may be inaccurate). There is a small problem with this strange indentation (that the second double quote is on a next line, but it is not fatal. More fatal is that this dialog even occurs and the file cannot be written. I've created a tracefile with +file and I think I've found the problem. At the moment of attempt to write (in this example, F:\brumbal.doc), there appears: trace:file:CreateFileW L"\\\\.\\F:" GENERIC_READ FILE_SHARE_READ FILE_SHARE_WRITE creation 3 attributes 0x0 trace:file:RtlDosPathNameToNtPathName_U (L"\\\\.\\F:",0x7fc8975c,(nil),(nil)) trace:file:RtlGetFullPathName_U (L"\\\\.\\F:" 520 0x7fc89508 (nil)) trace:file:get_dos_device L"F:" -> "/dev/hdb1" warn:file:CreateFileW Unable to create file L"\\\\.\\F:" (status c0000022) trace:file:CreateFileW returning 0xffffffff trace:file:RtlDosPathNameToNtPathName_U (L"F:\\",0x7fc89744,(nil),(nil)) trace:file:RtlGetFullPathName_U (L"F:\\" 520 0x7fc89508 (nil)) trace:file:wine_nt_to_unix_file_name L"\\??\\F:\\" -> "/home/patrol/.wine/dosdevices/f:/" trace:file:GetFileAttributesW L"F:\\brumbal.doc\r\n" trace:file:RtlDosPathNameToNtPathName_U (L"F:\\brumbal.doc\r\n",0x7fc8aae4,(nil),(nil)) trace:file:RtlGetFullPathName_U (L"F:\\brumbal.doc\r\n" 520 0x7fc8a8b0 (nil)) trace:file:CreateFileW L"\\\\.\\F:" GENERIC_READ FILE_SHARE_READ FILE_SHARE_WRITE creation 3 attributes 0x0 trace:file:RtlDosPathNameToNtPathName_U (L"\\\\.\\F:",0x7fc8975c,(nil),(nil)) trace:file:RtlGetFullPathName_U (L"\\\\.\\F:" 520 0x7fc89508 (nil)) trace:file:get_dos_device L"F:" -> "/dev/hdb1" warn:file:CreateFileW Unable to create file L"\\\\.\\F:" (status c0000022) trace:file:CreateFileW returning 0xffffffff trace:file:RtlDosPathNameToNtPathName_U (L"F:\\",0x7fc89744,(nil),(nil)) trace:file:RtlGetFullPathName_U (L"F:\\" 520 0x7fc89508 (nil)) trace:file:wine_nt_to_unix_file_name L"\\??\\F:\\" -> "/home/patrol/.wine/dosdevices/f:/" patrol(a)arcus:/opt/samba-dir/Program Files/Microsoft Office/Office$ Why the hell wine is trying to access /dev/hdb1 ? Yes, my home directory is on it, but I think that such a form of access is not good :-). In my .wine/dosdevices, there is clearly a line lrwxrwxrwx 1 patrol users 12 Sep 7 06:50 f: -> /home/patrol Or am I misinterpreting the log and the failure is caused by something else ? Otherwise wine is working near to perfect now. With regards, Pavel Troller

1 0

Path for Testfiles (MSI: Test creating a package)
by Detlef Riekenberg 07 Sep '05

07 Sep '05

Hi After reading reading this commit, .... > ChangeSet ID: 20009 > Added files: > dlls/msi/tests : package.c > Test creating a package. > Patch: http://cvs.winehq.org/patch.py?id=20009 ... i Suggest that: - all directories and files for tests should be created in "%TEMP%\winetest" - we modify "wine/tests.h" to get this path and check for path and name overflows (MAX_PATH and nesting level). "c:" could be readonly or absent/hidden Any comments please. -- By By ... ... Detlef

2 1

DirectX status update....
by Oliver Stieber 06 Sep '05

06 Sep '05

I though it was about time I gave a status update on DirectX9/wined3d, so here goes. Short of a couple of bug fixes (one to shaders, and another that causes some games to crash) and a couple of patches that need resending (support for non-power2 textures in warhammer 40k) wined3d and d3d9 is functionally as complete as the version on http://directxwine.sourceforge.net/, that means that as soon as pixel shaders are coppied across from d3d8 it's more or less the end of adding features to wined3d and the start of fixing the remaining bugs and getting the performance up to spec. Anyhow, as soon as I've sent in those patches I'll provide another status update with a bit more information about moving d3d8 over to wined3d and the improvements that have been made. Oliver. ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com

3 2

Re: URLMON: Added file protocol implementation
by Stefan Leichter 06 Sep '05

06 Sep '05

Am Samstag, 3. September 2005 21:22 schrieb Jacek Caban: > Changelog: > Added file protocol implementation Hello, this patch breaks the cross compiling of the tests with mingw. Which is the correct location of the class id? Bye Stefan make[3]: Entering directory `/usr/src/wine/wine-mingw/dlls/urlmon/tests' i386-mingw32-gcc generated.cross.o misc.cross.o protocol.cross.o url.cross.o testlist.cross.o -o urlmon_crosstest.exe -lurlmon -luser32 -lkernel32 -lole32 -luuid /usr/local/lib/gcc/i386-mingw32/3.4.2/../../../../i386-mingw32/lib/ libuuid.a(uuid.o):/usr/src/packages/BUILD/mingw-3.7/w32api-3.2/lib/uuid.c: (.rdata+0x1340): multiple definition of `_CLSID_FileProtocol' protocol.cross.o:/usr/src/wine/wine-mingw/dlls/urlmon/tests/../../../../wine/ dlls/urlmon/tests/protocol.c:63: first defined here collect2: ld returned 1 exit status make[3]: *** [urlmon_crosstest.exe] Fehler 1 make[3]: Leaving directory `/usr/src/wine/wine-mingw/dlls/urlmon/tests'

1 0