November 2006 - Wine-Devel - list.winehq.org

Re: d3d [9]: Remove AddRef from IWineD3DResource_GetDevice.
by Markus Amsler Nov. 21, 2006

Nov. 21, 2006

Don't apply d3d[9] - d3d[14], they are not independent and I missed one GetDevice AddRef. But I strongly assume they were already dropped for other reasons. Anything wrong with them? Markus

1 0

re: OLE Automatization Linux's OpenOffice from wine app
by Dan Kegel Nov. 21, 2006

Nov. 21, 2006

Kochmin wrote: > I have windows application wich use OLE Automatization to fill-in > OpenOffice document It's create OleObject like > OpenOffice := CreateOleObject('com.sun.star.ServiceManager'); >.. > How can I rewrite it, or use any tools, to work when OpenOffice is > installed on Linux, and my application runs in wine? Try installing the Windows version of OpenOffice in Wine. - Dan

4 5

re: What operating systems will Winelib run on non-x86 systems?
by Dan Kegel Nov. 21, 2006

Nov. 21, 2006

Hi Wei Li, last year, you asked in http://www.winehq.org/hypermail/wine-users/2004/06/0086.html > I could not find the info regarding what operating systems > (such as AIX 5L v5.2, HP-UX 11i, Solaris Release Level > 9) will Winelib run on non-x86 machines. I'll really > appreciate it if someone can provide my related link or > info. I can only find the following link regarding the > supporting OS but it does not provide Winelib's supporting > OS info: > http://www.winehq.org/site/docs/wine-faq/index 3.1. > Under what hardware > platform(s) and operating system(s) will Wine(Lib) run? I'm sorry nobody got back to you -- the wine-devel mailing list might have been a better place to ask. I believe winelib runs on the following non-x86 operating systems: Linux, Solaris, Mac OS X, and FreeBSD. There's no reason in principle it couldn't run on AIX or HP/UX. Some work has been done on an HP/UX port, but some assembly would be required to complete it: http://www.winehq.com/site/?issue=241#HP-UX%20Port Cheers, Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

3 2

OpenAL and DirectSound
by Stefan Dösinger Nov. 21, 2006

Nov. 21, 2006

Hi, Just stumbled uppon some interesting thing about openal and DirectSound 3D on vista: http://www.openal.org/openal_vista.html It sounds like openal will be the old way to get hw accelerated 3d sound on vista, and creative is writing a dsound -> openal wrapper. Maybe it gets a proper license so we can include it in wine :-) Maybe we should write an openal thunk for wine? Many games use openal, and it seems that on wine openal uses directsound. That might work more better and faster if we had a openal.dll which directly called linux openal :-) Just dropping the suggestions :-) Stefan

3 3

Regression in wininet between 0.9.23 and 0.9.24
by Pavel Troller Nov. 21, 2006

Nov. 21, 2006

Hi! I would like to report a regression in wininet.dll, causing Dreamcom Kubik SMS to crash as follows: wine: Unhandled page fault on read access to 0x00000000 at address 0x7e687b86 (thread 0013), starting debugger... Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x7e687b86). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:7e687b86 ESP:7d936820 EBP:7d9368d8 EFLAGS:00010246( - 00 -RIZP1) EAX:00000016 EBX:7e6a6728 ECX:00000002 EDX:00000000 ESI:00000000 EDI:00000000 Stack dump: 0x7d936820: 7b9177e0 7d936834 00000000 7e6a2520 0x7d936830: 001f3538 7e6a6728 001f3538 20000013 0x7d936840: 7d936900 7e68763b 00000000 f7cc0a2e 0x7d936850: 00000013 00000000 01160230 00000000 0x7d936860: 00010000 7b87fac6 7d9368b8 7bc35945 0x7d936870: 00001257 00010000 0010bdd0 7e68e354 Backtrace: =>1 0x7e687b86 in wininet (+0x17b86) (0x7d9368d8) 2 0x7e687f6b HttpQueryInfoW+0x1cb in wininet (0x7d936918) 3 0x7e6884d0 HttpQueryInfoA+0xc0 in wininet (0x7d936968) 4 0x0057a62c in dreamcom (+0x17a62c) (0x7d9369c8) 5 0x00579fb0 in dreamcom (+0x179fb0) (0x7d9369f0) 6 0x00578d0b in dreamcom (+0x178d0b) (0x7d9369f8) 7 0x7b88b488 in kernel32 (+0x6b488) (0x7d936ac8) 8 0x7bc5b570 in ntdll (+0x4b570) (0x7d9373c8) fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for libpthread.so.0 9 0xf7dd5528 start_thread+0xb8 in libpthread.so.0 (0x7d9374b8) 10 0xf7d6021e __clone+0x5e in libc.so.6 (0x00000000) 0x7e687b86: cmpw $0,0x0(%edx) I was doing "cvs bisect" in dlls/wininet and found that the problem lies between .23 and .24 - from .24 on it crashes, .23 is still OK. So now I'm using HEAD wine with .23 wininet and the program is happy. With regards, Pavel Troller

2 1

Tests for the Win16-API
by Detlef Riekenberg Nov. 20, 2006

Nov. 20, 2006

Hi. During some bug-hunting, i found a Problem with the 16Bit version of GetSystemDirectory. (WinXP returned "%windir%\system", wine: "%windir%\system32") The bad thing is, that we have no tests for the 16Bit API at all. I already tried Open Watcom on linux a while ago, and with the attached Patch for "include/wine/test.h", i'm able to cross-compile a standalone 16Bit test with Open Watcom 1.6beta (See attached Example: "sysdir.c") The test still need the header from the compiler, as "windows.h" from wine is not Win16-aware. Including Win16-Tests in the wine testsuite is still not possible yet (stdio limitations in Win16), but this Patch is a first step. Comments are welcome. Thanks -- By by ... Detlef

1 0

Re: dlls/ws2_32: Note and patch about strange UDP packets
by Detlef Riekenberg Nov. 20, 2006

Nov. 20, 2006

On Mo, 2006-11-20 at 11:22 +0100, Florian Echtler wrote: Welcome to wine. > the software was sending UDP packets to IP _254_.255.255.255 > (note the first octet). After some experimentation, I noticed that while Windows just > sends this as a broadcast packet, Are you sure, that the Function on Windows also get this wrong IP? If that is the case, then a fix is needed for the customized tracking software. There are various API-Hook Tools on the Net. Wine is also a great Software to make Application-Bugs visible. Did you already create a simple test-App, that used the IP 254.* and verified, that Windows interpreted that as Broadcast? A test for the wine testsuite is always prefered to verify, what Windows does. > I therefore build a small patch which checks for these strange adresses > and replaces them by broadcast adresses. You modify the beavior for a complete "/4" - Subnet. Is this really the same thing, what Windows does? Reimplement a Windows-Bug will require more tests. It's also Possible, that a different Function in wine malformed the IP. You need some tests to verify this. > However, the question now is whether it makes sense to include > this patch into Wine? Even, when tests verified, that Windows is not RFC compliant for this case, the tracking software should be fixed. Your Patch need some polish: - SPACE/TAB mixing - No C++ comments allowed - fprintf is wrong here. We have macros for this: (include/wine/debug.h) - > as I have not subscribed to the list. Please subscribe, it's easier for you to follow the discussion. -- By by ... Detlef

1 0

Re: dlls/ws2_32: Note and patch about strange UDP packets
by Jesse Allen Nov. 20, 2006

Nov. 20, 2006

On 11/20/06, Florian Echtler <echtler(a)in.tum.de> wrote: > Hi everybody, > > we are using a customized tracking software. This is a windows software, > but we decided some time ago that it would be more flexible to be able > to use it under Linux, too, so I gave it a try with Wine. > > As this software communicates with customized (expensive) cameras via > UDP, I noted a strange bug in the Wine debug channel "winsock": the > software was sending UDP packets to IP _254_.255.255.255 (note the first > octet). After some experimentation, I noticed that while Windows just > sends this as a broadcast packet, Linux rejects this address, because > the corresponding RFC states that the network 240.0.0.0/4 is reserved > and should not be used. > > I therefore build a small patch which checks for these strange adresses > and replaces them by broadcast adresses. This enabled our software to > work. However, the question now is whether it makes sense to include > this patch into Wine? On the one hand, it increases the similarity > between Wine's behaviour and Windows's, OTOH it decreases Wine's RFC > compliance.. > > Comments? Please CC me as I have not subscribed to the list. > > Thanks, Yours, Florian > > You can use a iptables rule to do the same thing. Right? Jesse

2 1

oleaut32: preliminary support for VT_DISPATCH as parameters to VarAdd (and other 2-operand operations)
by Alex Villacís Lasso Nov. 20, 2006

Nov. 20, 2006

This is a preliminary patch to add support for VT_DISPATCH as parameters to VarAdd and other arithmetic operations with variants. The tests still "pass" in the sense that null VT_DISPATCH as issued by the tests are still rejected. I post this in the hope that it will be reviewed while I prepare a test case. Changelog: * Add support for receiving of VT_DISPATCH parameters in several operator functions by fetching the result value, then reissuing the same operation on result data. -- The following cryptic message was allegedly found in the inner edge of a Windows XP installation CD: 4F6E65204F5320746F2072756C65207468656D20616C6C2C204F6E65204F5320746F2066696E6420 7468656D2C0D0A4F6E65204F5320746F206272696E67207468656D20616C6C20616E6420696E2074 6865206461726B6E6573732062696E64207468656D2E0A It is rumored that only a true Unix Wizard can decypher this mysterious message, which supposedly encodes the true nature and purpose of the software.

1 0

Re: winequartz.drv: Second glance at Window support.
by Alexandre Julliard Nov. 20, 2006

Nov. 20, 2006

Pierre d'Herbemont <pdherbemont(a)free.fr> writes: > +static inline void * BindCarbonFunctions(void) > +{ > + void * HIToolBoxDLHandle = dlopen("/System/Library/Frameworks/Carbon.framework/Frameworks/HIToolbox.framework/HIToolbox", RTLD_LAZY | RTLD_LOCAL); > + > + if (!HIToolBoxDLHandle) { > + fprintf(stderr, "%s impossible d'ouvrir HIToolBoxDLHandle\n", __FUNCTION__); > + return nil; > + } > +#define LOAD_FUNCTION(f) \ > + if((carbonPtr_##f = dlsym(HIToolBoxDLHandle, #f)) == NULL) \ > + { \ > + fprintf(stderr, "%s Can't find symbol %s\n", __FUNCTION__, #f); \ > + return nil; \ > + } > + LOAD_FUNCTION(ShowWindow) > + LOAD_FUNCTION(HideWindow) > +#undef LOAD_FUNCTION > + return HIToolBoxDLHandle; > +} This stuff should go in a C file, not in a header. Also you should use ERR instead of fprintf, and error messages should be in English <g> > +struct quartzdrv_thread_data > +{ > + int process_event_count; /* recursion count for event processing */ > +}; > + > +extern struct quartzdrv_thread_data *quartzdrv_init_thread_data(void); > +extern DWORD thread_data_tls_index; > + > +inline static struct quartzdrv_thread_data *quartzdrv_thread_data(void) > +{ > + struct quartzdrv_thread_data *data = TlsGetValue( thread_data_tls_index ); > + if (!data) data = quartzdrv_init_thread_data(); > + return data; > +} This is not used, it would be better to wait until you actually need per-thread data to add it. > +/* --------------------------------------------------------------------- > + quartzdrv_main.c > +*/ > +extern void wine_quartzdrv_lock(void); > +extern void wine_quartzdrv_unlock(void); Do you really need locking around Carbon calls, or is this just imitating x11drv? (either way there's no reason to export those). > +/* --------------------------------------------------------------------- > + * get_quartzdrv_win_data_from_hwnd > + */ > +struct quartzdrv_win_data *get_quartzdrv_win_data_from_hwnd(HWND hwnd) > +{ > + return (struct quartzdrv_win_data *)GetPropA(hwnd, wine_quartzdrv_win_data); > +} GetProp is not the best choice for associating data to a window as it requires a server round trip. A process-local mechanism is preferable. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: msi: Split msi_set_sourcedir_props into a separate function.
by James Hawkins Nov. 20, 2006

Nov. 20, 2006

On 11/19/06, Mike McCormack <mike(a)codeweavers.com> wrote: > --- > dlls/msi/action.c | 37 +++++++++++++++++++++++-------------- > 1 files changed, 23 insertions(+), 14 deletions(-) > +UINT msi_set_sourcedir_props(MSIPACKAGE *package) +{ Shouldn't this be static? -- James Hawkins

2 1

ASN.1 parser
by Kai Blin Nov. 20, 2006

Nov. 20, 2006

Hi Juan, I'm just looking into implementing Kerberos and Negotiate for SSPI. It seems like I'll need an ASN.1 parser for both of those. I know you have a partial implementation of an ASN.1 DER parser in crypt32, but I think it would be kind of silly to keep two seperate copies. Think it would make sense to create our own asn dll? Or is there any method to find out what functions msasn1.dll provides? Cheers, Kai -- Kai Blin, <kai Dot blin At gmail Dot com> WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton.

4 4

Re: winhelp: wRefCount
by Kirill K. Smirnov Nov. 19, 2006

Nov. 19, 2006

В сообщении от 19 ноября 2006 19:23 вы написали: > actually we should decrement the count for: > - closing the window attached to a page > - upon exit, remove references in history (and attached refcounts) > that should help here (not sure I got them all though) To be honest, I do not understand "cleary and distinctly" what wRefCount represents. Now, I consider wRefCount as amount of history entries (referring to the file) in all histories. But what to do with popup windows? They are not in any history. Also, there are help files used ONLY in popup windows (e.g. wdtip8.hlp in MS Office 97). This is another problem to meditate upon. -- Kirill K. Smirnov

2 1

Wine 0.9.25 for SuSE 10.1 is Wine 0.9.24
by theUser BL Nov. 19, 2006

Nov. 19, 2006

Yesterday I have seen, that Wine 0.9.25 is already published and I have downloaded it. I gave downloaded the Sorces http://prdownloads.sourceforge.net/wine/wine-0.9.25.tar.bz2 And the rpm-files for SuSE 10.1. But after installing the SuSE-rpms, after the input of "wine --version" it says, that it is version 0.9.24. After an "winver" its says also 0.9.24. Then I have compiled the sources. The self-compiled Wine says 0.9.25. And in 0.9.25 are some bugs fixed, which in 0.9.24 still exists. And the Wine 0.9.25 for SuSE 10.1 have still the old 0.9.24 bugs. So the builds of SuSE 10.1 are not correct created. Greatings theuserbl _________________________________________________________________ Sie suchen E-Mails, Dokumente oder Fotos? Die neue MSN Suche Toolbar mit Windows-Desktopsuche liefert in sekundenschnelle Ergebnisse. Jetzt neu! http://desktop.msn.de/ Jetzt gratis downloaden!

3 4

Re: winecfg: [2/2] Add ability to change colors and non-client sizes.
by Stefan Dösinger Nov. 19, 2006

Nov. 19, 2006

Am Samstag 18 November 2006 18:58 schrieb Vitaliy Margolen: > Change Log: > winecfg: Add ability to change colors and non-client sizes. Beeing able to configure colors in winecfg is a good idea :-) . But would it be possible to read the values from the window manager? Afaik there are environment variables for configuring this since a long time which are written by kde and gome ("Apply colors to non-kde programs"). I don't think it should be autoloaded every wine launch, with some configurations this might have bad results, so beeing able to edit it should still be possible. But maybe for creating an initial color sheme from wineprefixcreate?

1 0

Re: winhelp: add preliminary *.cnt file support (parser)
by Kirill K. Smirnov Nov. 19, 2006

Nov. 19, 2006

В сообщении от 19 ноября 2006 10:37 вы написали: > 1/ you forgot to include the changes (at least) to hlpfile.h Thanks! I've messed a little. > 2/ internal function definitions > > > +static BOOL HLPFILE_ReadCntFile(HLPFILE*); > > +static void HLPFILE_FreeCnt(HLPFILE_CNT*); > > I think those two functions are not correctly designed... I'd more > likely see something like: > > +static HLPFILE_CNT* HLPFILE_ReadCntFile(const char*); > +static void HLPFILE_FreeCnt(HLPFILE_CNT*); > > this makes the two functions consistent in what they depend on (either > both of them are passed a HLPFILE* or none of them), and also allows to > return the newly created HLPFILE_CNT which you never store in HLPFILE I messed here too... Also, I stumbled upon the following problem: HLPFILE_FreeCnt is never called! There is something bad with hlpfile->wRefCount - it's 4 (!) instead of 1 after just opening and closing file. --Kirill K. Smirnov

2 1

Re: winhelp: add preliminary *.cnt file support (parser)
by Eric Pouech Nov. 19, 2006

Nov. 19, 2006

Kirill K. Smirnov a écrit : > ChangeLog: > Add preliminary *.cnt file support (parser) > Hi Kirill, good to see someone enhancing winhelp!! a few comments though about your patch 1/ you forgot to include the changes (at least) to hlpfile.h 2/ internal function definitions > +static BOOL HLPFILE_ReadCntFile(HLPFILE*); > +static void HLPFILE_FreeCnt(HLPFILE_CNT*); > I think those two functions are not correctly designed... I'd more likely see something like: +static HLPFILE_CNT* HLPFILE_ReadCntFile(const char*); +static void HLPFILE_FreeCnt(HLPFILE_CNT*); this makes the two functions consistent in what they depend on (either both of them are passed a HLPFILE* or none of them), and also allows to return the newly created HLPFILE_CNT which you never store in HLPFILE 3/ don't use C++ comments in C code > + if (cur->level == entry->level) // level exists > + { > + entry->parent = cur->parent; > + cur->next = entry; > + } > + else // entry on new level > A+

1 0

Re; Solidworks 2006
by Kartik Thakore Nov. 19, 2006

Nov. 19, 2006

I added the bug to winehq here is the link thank you for the help I made it a little better to run: http://bugs.winehq.org/show_bug.cgi?id=6723 -- -------- Kartik Thakore 250313003 kthakore(a)uwo.ca 1st year engineering

1 0

Re; Solidworks 2006
by Kartik Thakore Nov. 19, 2006

Nov. 19, 2006

I added the bug to winehq here is the link thank you for the help I made it a little better to run: http://bugs.winehq.org/show_bug.cgi?id=6723 -- -------- Kartik Thakore 250313003 kthakore(a)uwo.ca 1st year engineering

1 0

Wine Version String
by Robert Lunnon Nov. 18, 2006

Nov. 18, 2006

Somewhere between Version 0.9.23 and Version 0.9.25 the version string format changed from Wine X.X.X to wine-X.X.X Can we please decide on a version string format and stick to it so packaging can be reasonably automated. Bob

2 1

oleaut32 tests and VarAdd(VT_DISPATCH, ...)
by Dan Kegel Nov. 18, 2006

Nov. 18, 2006

Alex Villacís Lasso wrote: >BTW, I see many attempts of VarAdd(VT_DISPATCH, ...) tested. All of them >are expected to fail. However, the tax app does just that >(VarAdd(VT_DISPATCH, ...)) and fails to display a print preview because >of this. I think that native oleaut32 fails these tests, not because it >does not support VarAdd(VT_DISPATCH) at all, but because these >VT_DISPATCHs are incorrectly formed (as in, just zeroing the variant, >then assigning VT_DISPATCH as variant type). I need to confirm this with >a test program. Yes, if you can improve the variant tests for oleaut32, please do! - Dan

1 0

CD-ROM access via "\\\\.\\Cdrom0"
by Pavel Roskin Nov. 18, 2006

Nov. 18, 2006

Hello! I've tried to figure out why some programs working with CD and DVD drives work only if the emulated version is set to Windows NT 4, but not Windows 2000 or XP. I used DVDDecrypter 3.5.4.0 with the current Wine from git. DVDDecrypter is configured to use SPTI, which is the default. Fixing ASPI would be a separate topic. If NT4 is emulated, the program scans all drives by letters and then opens drive H: (which is the DVD drive on my system). Here's an excerpt from the log produced by WINEDEBUG=+file,+cdrom,+ntdll,+kernel,+aspi wine DVDDecrypter.exe trace:file:CreateFileW L"\\\\.\\H:" GENERIC_READ GENERIC_WRITE FILE_SHARE_READ FILE_SHARE_WRITE creation 3 attributes 0x0 trace:file:RtlDosPathNameToNtPathName_U (L"\\\\.\\H:",0x7d6b75b0,(nil),(nil)) trace:file:RtlGetFullPathName_U (L"\\\\.\\H:" 520 0x7d6b7314 (nil)) trace:ntdll:NtCreateFile handle=0x7d6b75b8 access=c0000000 name=L"\\??\\H:" objattr=00000040 roo t=(nil) sec=(nil) io=0x7d6b75a8 alloc_size=(nil) attr=00000000 sharing=00000003 disp=1 options=00000050 ea=(nil).0x00000000 trace:file:get_dos_device L"H:" -> "/dev/scd0" trace:file:CreateFileW returning 0x8c And that's what the same command would produce with win2k emulation: trace:file:CreateFileW L"\\\\.\\Cdrom0" GENERIC_READ GENERIC_WRITE FILE_SHARE_READ FILE_SHARE_WR ITE creation 3 attributes 0x0 trace:file:RtlDosPathNameToNtPathName_U (L"\\\\.\\Cdrom0",0x7d6b25b0,(nil),(nil)) trace:file:RtlGetFullPathName_U (L"\\\\.\\Cdrom0" 520 0x7d6b2314 (nil)) trace:ntdll:NtCreateFile handle=0x7d6b25b8 access=c0000000 name=L"\\??\\Cdrom0" objattr=00000040 root=(nil) sec=(nil) io=0x7d6b25a8 alloc_size=(nil) attr=00000000 sharing=00000003 disp=1 options=00000050 ea=(nil).0x00000000 warn:file:CreateFileW Unable to create file L"\\\\.\\Cdrom0" (status c0000034) trace:file:CreateFileW returning 0xffffffff trace:file:CreateFileW L"\\\\.\\Cdrom1" GENERIC_READ GENERIC_WRITE FILE_SHARE_READ FILE_SHARE_WR ITE creation 3 attributes 0x0 trace:file:RtlDosPathNameToNtPathName_U (L"\\\\.\\Cdrom1",0x7d6b25b0,(nil),(nil)) The program cycles like this to Cdrom63 and then gives up. I think it would be great if Wine adds supported for opening CD-ROMs by number. Better yet if it enumerated CD-ROMs an other drives automatically. I have make a proof-of-concept patch that allows DVDDecrypter to find the CD-ROM drive under win2k emulation. I had to create a link from .wine/dosdevices/cdrom0 to /dev/scd0 manually. This is not the right fix, but it shows that it can be done. diff --git a/dlls/ntdll/path.c b/dlls/ntdll/path.c index e4af89a..2ca5883 100644 --- a/dlls/ntdll/path.c +++ b/dlls/ntdll/path.c @@ -316,6 +316,7 @@ DOS_PATHNAME_TYPE WINAPI RtlDetermineDos ULONG WINAPI RtlIsDosDeviceName_U( PCWSTR dos_name ) { static const WCHAR consoleW[] = {'\\','\\','.','\\','C','O','N',0}; + static const WCHAR cdromW[] = {'\\','\\','.','\\','C','D','R','O','M',0}; static const WCHAR auxW[3] = {'A','U','X'}; static const WCHAR comW[3] = {'C','O','M'}; static const WCHAR conW[3] = {'C','O','N'}; @@ -372,6 +373,12 @@ ULONG WINAPI RtlIsDosDeviceName_U( PCWST if (strncmpiW( start, comW, 3 ) && strncmpiW( start, lptW, 3 )) break; if (*end <= '0' || *end > '9') break; return MAKELONG( 4 * sizeof(WCHAR), (start - dos_name) * sizeof(WCHAR) ); + case 11: + if (*(end - 1) <= '0' || *(end - 1) > '9') break; + case 10: + if (*end <= '0' || *end > '9') break; + if (strncmpiW( start, cdromW, 9 )) break; + return MAKELONG( (end - start + 1) * sizeof(WCHAR), (start - dos_name) * sizeof(WCHAR) ); default: /* can't match anything */ break; } -- Regards, Pavel Roskin

2 3

Re: [3/5] wined3d: Make the offscreen render mode a registry setting
by Ivan Gyurdiev Nov. 17, 2006

Nov. 17, 2006

This flag needs to be per adapter - should be added to device.c like the shader mode.

2 7

Bug in MapAndLoad function
by Adam Connell Nov. 17, 2006

Nov. 17, 2006

Greetings, While investigating why a game (Kasparov's Chessmate) didn't work, I think I found a bug in the implementation of imagehlp.dll in the the MapAndLoad function located in dlls/imagehlp/access.c lines 165-167. The function looks like it tries to open an uninitialized string szFileName instead of the passed file name "pszImageName". I think there has been a bug filed already (Bug 6099 Alien Shooter needs imagehlp.dll override) and I think this explains it. Wine version 0.9.25 /*********************************************************************** * MapAndLoad (IMAGEHLP.@) */ BOOL WINAPI MapAndLoad( LPSTR pszImageName, LPSTR pszDllPath, PLOADED_IMAGE pLoadedImage, BOOL bDotDll, BOOL bReadOnly) { CHAR szFileName[MAX_PATH]; HANDLE hFile = NULL; HANDLE hFileMapping = NULL; HMODULE hModule = NULL; PIMAGE_NT_HEADERS pNtHeader = NULL; TRACE("(%s, %s, %p, %d, %d)\n", pszImageName, pszDllPath, pLoadedImage, bDotDll, bReadOnly); /* PathCombine(&szFileName, pszDllPath, pszImageName); */ /* PathRenameExtension(&szFileName, bDotDll?:"dll":"exe"); */ /* FIXME: Check if the file already loaded (use IMAGEHLP_pFirstLoadedImage) */ if(!(hFile = CreateFileA( szFileName, GENERIC_READ, 1, /* FIXME: FILE_SHARE_READ not defined */ NULL, OPEN_EXISTING, 0, NULL))) { SetLastError(ERROR_FILE_NOT_FOUND); goto Error; } Cheers, Adam

4 4

Re: [2/5] wined3d: Fix depth buffer formats to use actual depth textures
by Ivan Gyurdiev Nov. 17, 2006

Nov. 17, 2006

That's still missing runtime check for GL_ARB_DEPTH_TEXTURE extension. I don't like "developers only" and "registry key" - feature should be complete or not in the tree. > The trouble with the current setup is that we can't use different formats based on what extensions are present. Then the setup should be fixed, rather than adding dependent code without extension checks. I might have mentioned before that statically initialized tables are evil.... ======== Btw, good job, I am glad you're working on this.... does it make Battlefield 2 work?

1 0