wine-devel

wine-devel@winehq.org

3 participants
84472 discussions

RE: warcraft 3
by Hans Leidekker 05 Jul '02

05 Jul '02

> After buying Warcraft 3, and reading on the mailing list that the beta had > worked under wine, I decided to try the final version under wine. It installed > fine, but won't run. Or rather, when I try to run it, it prints this out, and > just sits there: > > fixme:cdrom:CDROM_GetIdeInterface CD-ROM device with major ID 11 not supported > fixme:cdrom:CDROM_GetIdeInterface CD-ROM device with major ID 11 not supported > fixme:midi:OSS_MidiInit Synthesizer support MIDI in. Not supported yet (please report) Let me guess: you have SCSI cdrom drive. I stumbled on this one as well some time ago. I learned that 11 is the SCSI major. It looks strange to me that the function CDROM_GetIdeInterface gets called while we have a SCSI cdrom drive? Anyways, as a workaround -- I don't think this is the right solution -- I added the following line to the switch statement in cdrom:CDROM_GetIdeInterface: case SCSI_CDROM_MAJOR: *iface = 0; break; This allowed my application to proceed (don't remember which application that was though). Regards, -Hans Leidekker

2 1

GRand Prix Legends network code
by Christoph Frick 05 Jul '02

05 Jul '02

Hi! I did some debugging, to find out why the game Grand Prix Legends did not work as network client/server. The problem: Its only possible to connect to servers/let clients connect from the local network. Solution: The game set (WS_)SO_DONTROUTE on the socket - and of course this works perfect under unix - but i never had problems while i played this game under windows so this is either not set, when the game runs under windows - or it has no effect within windows. Also the game like to bind the socket for the client connection a second time, when the first connection failed or was canceled. This does not work (addr. in use) - so a (WS_)SO_REUSEADDR would have been needed. Could please someone with a deeper insight in the world of windows direct me to some docu/specs or what ever to get informations about the winsock stuff? The link in the header of the dlls/winsock/socket.c is not valid. I even dont know what winsock version is the current one (1.1,2.0,???). Help is appreciated! Thanx alot! CU!

1 0

Re: dlls/advapi32/registry.c patch for RegEnumValuesA
by Massimo 05 Jul '02

05 Jul '02

Resubmitting as for Tony Lambregts request :) Well, finally found and corrected a bug that made AutoCAD R14 hang... I guess some other apps could have the same problem solved, but had no time to test more :) In RegEnumValueA, when the size for requested data buffer is too small, function should return an error (as it does), but also return correct buffer size (as it doesn't). Found in AutoCAD; it asked for a reistry key value, got error, and then looped forever trying to get val with wrong buffer size. I guess, but had no time yet to check, that this problem could happen somwhere else in Registry.c, I'll check it out next days. With this patch, finally AutoCAD R14 is perfectly usable in wine, even without a native windows installed ! Change log: Change In RegEnumValueA, when the size for requested data buffer is too small, function should return an error (as it did), and also return correct buffer size (now it does). Max max(a)com.veneto [reversed :) ] ----- --- dlls/advapi32/registry.c Sat Jul 6 01:29:08 2002 +++ /home/massimo/wine-patches/registry.c Sat Jul 6 01:35:32 2002 @@ -1157,6 +1157,9 @@ RtlUnicodeToMultiByteSize( &len, info->Name, info->NameLength ); if (len >= *val_count) { + /* MUST RETURN REQUESTED CORRECT BUFFER SIZE, NOT ONLY TELL IT'S WRONG */ + *val_count = len + 1 ; status = STATUS_BUFFER_OVERFLOW; goto done; } @@ -1174,6 +1177,9 @@ { if (len > *count) { + /* MUST RETURN REQUESTED CORRECT BUFFER SIZE, NOT ONLY TELL IT'S WRONG */ + *count = len+1 ; status = STATUS_BUFFER_OVERFLOW; goto done; }

2 1

Re: Added support for APPMODE=<type>[:<mainFunc>]
by Alexandre Julliard 05 Jul '02

05 Jul '02

Gregg Mattinson <gm138242(a)scot.canada.sun.com> writes: > - .spec files can't be compiled with -g when using Forte C. This causes static > variables to have a "random" prefix attached to their name, and prevents the > assembly code from linking to them correctly. > - Forte C has linker issues, so cui executables with main() conflicted with > main() in $WINELOADER. Renaming main() to main2() solved the issue, so I added > support to winebuild to allow the main function name to be optionally specified > in the makefile. I have applied the rest of the patch, but these are bugs that need to be fixed, not simply worked around. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: dlls/advapi32/registry.c patch for RegEnumValuesA
by Tony Lambregts 04 Jul '02

04 Jul '02

Max wrote: >Here a patch that corrects a nasty bug in dll/advapi32/registry.c, causing >AutoCAD R14 (and I guess other apps too...) to hang. > >Regards > >Max > > > >------------------------------------------------------------------------ > >--- dlls/advapi32/registry.c Sat Jul 6 01:29:08 2002 >+++ /home/massimo/wine-patches/registry.c Sat Jul 6 01:35:32 2002 >@@ -1157,6 +1157,9 @@ > RtlUnicodeToMultiByteSize( &len, info->Name, info->NameLength ); > if (len >= *val_count) > { >+ /* CHANGELOG : 04.07.2002 by Max >+ MUST RETURN REQUESTED CORRECT BUFFER SIZE, NOT ONLY TELL IT'S WRONG */ > The comment is OK I suppose, but it is part of the change log. Change log entries should not be part of the patch itself. >+ *val_count = len + 1 ; > status = STATUS_BUFFER_OVERFLOW; > goto done; > } >@@ -1174,6 +1177,9 @@ > { > if (len > *count) > { >+ /* CHANGELOG : 04.07.2002 by Max >+ MUST RETURN REQUESTED CORRECT BUFFER SIZE, NOT ONLY TELL IT'S WRONG */ > Same here. >+ *count = len+1 ; > status = STATUS_BUFFER_OVERFLOW; > goto done; > } > > Sorry to nitpick could you resubmit something like this ---- This is the first part. This is where you can say what you did, and say what you wanted to say, in as long and as rambling way as you want. It is for expaining whatever you wanted to expain, why you wanted to do it the way you wanted to do it section. next comes the change log . after that your name and contact. Change log: Change In RegEnumValueA, when the size for requested data buffer is too small, function should return an error (as it did), and also return correct buffer size (now it does). Max max(a)veneto.co ----- attched patch

1 0

Running half-life turns X display into garbage
by Joshua Thielen 04 Jul '02

04 Jul '02

Hello, When I run half-life, the X display gets totally corrupted and the only way to restore is to restart the X server. I'm using an NVidia G-force 3 video card running at 1024x768 with 16-bit color. I have already run a few traces, but since I have no idea at what point the display gets corrupted, it's kind of hard to debug. Has anyone encountered this problem yet? Are there any specific functions or channels I should be looking at in the trace? Thanks, Josh Thielen __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com

4 4

2 quick things on the Cygwin/Mingw port
by Steven Edwards 03 Jul '02

03 Jul '02

Hola 1. This is simple but as you guys know I have this lysdexic thing when it comes to configure. Libwine needs to import certain functions from the c library to compile, at present it is hard coded for -lmsvcrt. This needs to be changes to import -lcygwin if configure detects a cygwin host/target. I know its simple we just need to have the check in configure that sets CLIBRARY=(lmsvcrt or lcygwin) then Makefile.in in libwine needs to be changed like this: libwine.dll: $(OBJS) $(DLLWRAP) $(DLLWRAPFLAGS) --export-all --implib libwine.a -o libwine.dll $(OBJS) -lmsvcrt to libwine.dll: $(OBJS) $(DLLWRAP) $(DLLWRAPFLAGS) --export-all --implib libwine.a -o libwine.dll $(OBJS) $(CLIBRARY) 2. I was able to get Wineserver.exe to compile under cygwin when I stubbed getthreadcontext and setthreadcontext. Kernel32.dll implements these to functions so on the Mingw or Cygwin port can I import it for these needed functions? Thanks and have a good 4th Steven __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

1 0

Re: DOSFS_GetPathDrive patch
by Alexandre Julliard 03 Jul '02

03 Jul '02

Duane Clark <dclark(a)akamail.com> writes: > In particular, it calls GetFileAttributes with a path like: > \c\Xilinx\bin\lib\tcl8.3\init.tcl > which fails in DOSFS_GetPathDrive. > > Changelog: Check for absolute Unix path in DOSFS_GetPathDrive The problem I see with that is that the app can no longer access a directory that has the same name as a drive root (for instance if you have a /msdos drive then the app cannot use \msdos to mean c:\msdos). Where does the Xilinx path come from? That's not a valid Windows path anyway so that looks like a bug. -- Alexandre Julliard julliard(a)winehq.com

2 1

(no subject)
by Steven Edwards 03 Jul '02

03 Jul '02

Anyone planning on attending the Linux World Expo? I was going to be in the Bay area on the 12th anyway to tour Berkley so I think I'm going to extend my trip to make the show. Steven __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

1 0

Bug in RegEnumValueA ?
by Massimo 03 Jul '02

03 Jul '02

Again investigating AutoCAD r14 app under wine, I found a bug that make app hang when some registry values are present. At first I've made a script that cleans up registry before launching AutoCAD,but this was only a way-around to the problem. Looking at relay output, I found a loop in calling RegEnumValueA : // @@@@ START OF LOOP BLOCK HERE......... :Call advapi32.dll.RegEnumValueA (000000cc,00000001,40486844,404868ec,00000000,404868f4,41e62020, 404868fc) ret=008a3850 :Call ntdll.dll.NtEnumerateValueKey (000000cc,00000001,00000001,40486544,00000100,40486540) ret=406afb24 :Ret ntdll.dll.NtEnumerateValueKey() retval=00000000 ret=406afb24 :Call ntdll.dll.RtlUnicodeToMultiByteSize(4048653c,40486558 L"REGPATH\\\\HKEY_LOCAL_MACHINE\\Software\\Autodesk\\AutoCAD\\R1 4.0\\ACAD-2452448:80143967\\AutodeskApps\\LsObj",0000000e) ret=406afc03 :Ret ntdll.dll.RtlUnicodeToMultiByteSize() retval=00000000 ret=406afc03 :Call ntdll.dll.RtlUnicodeToMultiByteN (40486844,00000007,00000000,40486558,0000000e) ret=406afc24 :Ret ntdll.dll.RtlUnicodeToMultiByteN() retval=00000000 ret=406afc24 :Call ntdll.dll.RtlUnicodeToMultiByteSize(40486538,40486566 L"\\\\HKEY_LOCAL_MACHINE\\Software\\Autodesk\\AutoCAD\\R14.0\\AC AD-2452448:80143967\\AutodeskApps\\LsObj",000000bc) ret=406afc77 :Ret ntdll.dll.RtlUnicodeToMultiByteSize() retval=00000000 ret=406afc77 :Call ntdll.dll.RtlNtStatusToDosError(80000005) <--ERROR HERE ! ret=406afd5d :Ret ntdll.dll.RtlNtStatusToDosError() retval=000000ea ret=406afd5d :Ret advapi32.dll.RegEnumValueA() retval=000000ea ret=008a3850 <-- MORE DATA AVAILABLE RETURN (AUTOCAD KEEPS TRYING TO GET DATA) // @@@@ END OF LOOP BLOCK HERE Here RegEnumValueA returns an error of invalid buffer; Looking into code it seems to me that the NtEnumerateValueKey() used to find the largest name and value sizes of keys to be enumerated returns a wrong size; next use for reading the key gives an arror of buffer overflow, being it allocated with wrong (too small) size. AutoCAD keeps trying to get the keys/values, in and endless loop. Looking more with some debug print statements, it appears that Autocad allocates 4 bytes of buffer for the value, but RegEnumValueA needs much more, 94 in this case, giving an Out-Of-Buffer error back. It seems to me that the 94 bytes are for the name of the key, not for the value.... Regards Max

3 2

Jump to page:

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