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

Re: dos4gw stub exec failed

by Jukka Heinonen

Enrico Horn wrote: > I have some dos games that want to exec dos4gw.exe when starting. > but this seems to fail. > I hope i read the debug messages correctly and the comment from > file:Win32HandleToDosFileHandle is still valid. > what happens is dos:int21 wants to open file with the dos handle and > then read from it. > reading the file calls the function file:ReadFile with the > converted win32 file handle which is invalid if the above mentioned > comment is correct. > > Any ideas how to solve this or am I completely off-track here. Well, I don't actually know what is wrong with dos4gw. It is probably something subtle with int21 functions. However, why it hangs is something I haven't checked out. You could try running those programs using DOS32A (DOS/32 Advanced) extender. It seems to work quite well. I just posted a patch that is required to get its installer working, though, so you might have some trouble unpacking it... If you get those games to work under dos32a you will probably find out that Wine SVGA support is lacking. That is something I have considered to fix if I can find the time to do it. -- Jukka Heinonen <http://www.iki.fi/jhei/>

Jan. 22, 2003

Fwd: Displaying the LGPL license : avoid code duplication ?

by Sylvain Petreolle

___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Jan. 22, 2003

Re: PATCH: Adds my name to the AUTHORS list

by Vincent Béron

Le mer 22/01/2003 à 02:44, Shachar Shemesh a écrit : > Waldeck Schutzer wrote: > > > Now that my patches were incorporated to the tree, it would make me > > feel happier if my name was listed too :-) > > > > Best, > > Waldeck > > I think it's time Alexander regenerates the entire Authors list. People > want the credit, Alexander. > > There is a script in "tools" that does something, but I think it only > alphabetizes the list, it does not actually add names. > > Shachar > Looking at the revision history for AUTHORS, the file is updated from the Changelog once in a while by Alexandre. The last time was for release 20020904. I'd say let him continue to do it a couple times per year, rather than right away. You won't be forgotten :) Vincent

Jan. 22, 2003

GetCurrentObject(hdc,OBJ_BITMAP) should not return zero.

by Rein Klazes

Hi, ( cc'd to the developer list. There might well be some better way to solve the problem.) Eurdora 4.x and 5.x crash when handling a WM_PAINT message. The program gets a hdc from BeginPaint() and does a GetCurrentObject(hdc,OBJ_BITMAP) on that device context. In wine zero is returned and the program crashes as a result of that (step tracing it shows some math on it and then uses the result as a pointer). The same problem was reported on the developer list in: http://www.winehq.com/hypermail/wine-devel/2002/11/0599.htm Since the program does not do anything suspicious between aquiring the dc handle and the GetCurrentObject, Checking under Windows (Win2000). I found that GetCurrentObject(,OBJ_BITMAP) on the the dc returned both by BeginPaint() and CreateDC(), retrieves a non-zero handle. The handle looks genuine, but the bitmap does not appear to be valid (funny dimensions and so). My proposed solution is to do what CreatCompatibleDC already does: load a default bitmap in CreateDC(). This has worked here for a long time without any aparent problems. Changelog: objects: dc.c Load default stock bitmap in CreateDC() Rein. -- Rein Klazes rklazes(a)xs4all.nl

Jan. 22, 2003

Install MS Train Simulator using wine (version 20030115) [Virus checked]

by thomas.mertes＠t-mobile.at

When I try to Install the Microsoft Train Simulator using wine (version 20030115), I get the following messages: tm(a)penguin:~/c/msts > wine /cdrom/setupFor language 'german' several language ids were found:de_DE - 0407; de_CH - 0807; de_AT - 0C07; de_LU - 1007; de_LI - 1407;Instead of using first in the list, suggest to defineyour LANG environment variable like this: LANG=de_DEfixme:int21:INT_Int21Handler Unimplemented FAT32 int32 function 7303fixme:process:CreateProcessA (E:\EBU6412.exe,...): CREATE_NEW_PROCESS_GROUP ignoredfixme:process:CreateProcessA (E: \EBU6412.exe,...): CREATE_DEFAULT_ERROR_MODE ignoredFor language 'german' several language ids were found:de_DE - 0407; de_CH - 0807; de_AT - 0C07; de_LU - 1007; de_LI - 1407;Instead of using first in the list, suggest to defineyour LANG environment variable like this: LANG=de_DEfixme:console:SetConsoleCtrlHandler ((nil),1) - no error checking or testing yettm(a)penguin:~/c/msts > fixme:int21:INT_Int21Handler Unimplemented FAT32 int32 function 7303wine: Unhandled exception, starting debugger... Then a window with the following text is displayed: Unhandled page fault on read access to 0x00000064 at address 0x00442250 Do you wish to debug Pressing Yes gives: Couldn't start process '134830176 0x78' Couldn't start process '134830176 0x78' The wine processes are still running but nothing happens. As winversion I used win2k (other versions did not help) For the DLL config (builtin/native) I used the default. Using just builtin Dlls gives the trace above. Using native DLLs from WinNt 4.0 did not help. For the Int21 function 7303 (=Get Extended free space) I made a fix according to Info from Ralph Browns interrupt list. I will send a patch for this later. Testing of the Int 21 function 7303 was not possible, because logging information does not change, when the function reports plenty, few or zero disk space. Hopefully somebody can test the Int 21 function 7303 when I send the patch. For the other fixme's: fixme:process:CreateProcessA (E:\EBU6412.exe,...): CREATE_NEW_PROCESS_GROUP ignored fixme:process:CreateProcessA (E:\EBU6412.exe,...): CREATE_DEFAULT_ERROR_MODE ignored fixme:console:SetConsoleCtrlHandler ((nil),1) - no error checking or testing yet I need help. And also: Why does the debugger not start? PS.: Please CC me on discussions, since I am not subscribed at the mailing lists. Greetings Thomas Mertes

Jan. 22, 2003

Re: PATCH: Adds my name to the AUTHORS list

by Mike Hearn

I think the script in tools takes the AUTHORS file and then generates the code to embed it into the about box? I can't see any automated method for extracting authors entries, I suppose Alexandre must add them manually. On Wed, 2003-01-22 at 12:20, Sylvain Petreolle wrote: > Whats the difference with AUTHORS ? > --- Shachar Shemesh <wine-devel(a)sun.consumer.org.il> a écrit : > > Waldeck Schutzer wrote: > > > > > Now that my patches were incorporated to the tree, it would make me > > > > > feel happier if my name was listed too :-) > > > > > > Best, > > > Waldeck > > > > I think it's time Alexander regenerates the entire Authors list. > > People > > want the credit, Alexander. > > > > There is a script in "tools" that does something, but I think it only > > > > alphabetizes the list, it does not actually add names. > > > > Shachar > > > > > > > > ===== > Sylvain Petreolle > spetreolle(a)users.sourceforge.net > Fight against Spam ! http://www.euro.cauce.org/en/index.html > ICQ #170597259 > > "Don't think you are. Know you are." Morpheus, in "Matrix". > > ___________________________________________________________ > Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! > Yahoo! Mail : http://fr.mail.yahoo.com -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

Jan. 22, 2003

Re: PATCH: Adds my name to the AUTHORS list

by Sylvain Petreolle

Whats the difference with AUTHORS ? --- Shachar Shemesh <wine-devel(a)sun.consumer.org.il> a écrit : > Waldeck Schutzer wrote: > > > Now that my patches were incorporated to the tree, it would make me > > > feel happier if my name was listed too :-) > > > > Best, > > Waldeck > > I think it's time Alexander regenerates the entire Authors list. > People > want the credit, Alexander. > > There is a script in "tools" that does something, but I think it only > > alphabetizes the list, it does not actually add names. > > Shachar > > > ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus, in "Matrix". ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Jan. 22, 2003

Re: Installshield 6 crash: ole trouble

by Ove Kaaven

On 22 Jan 2003, Mike Hearn wrote: > Why not just use threads? Is there a particular advantage to using IPC > in this instance? I'd guess that ikernel.exe is the program that does > the installing, and the program you launch does the front end code? It does use threads, and a lot of other things. But I think the idea of using advanced COM stuff makes sense from the InstallShield point of view - all that COM/DCOM/RPC stuff is already on every Windows installation, so the installer executable does become smaller by using it instead of writing their own mechanisms to achieve the same thing. The program you launch simply does the "Preparing InstallShield Wizard" thing, this is where interprocess COM call takes place. Once you get past that and start the actual installer, the main engine (ikernel) only uses threads (though unfortunately, interthread COM calls aren't quite implemented yet, so repainting suffers). However, that engine does export OLE Automation-compatible COM interfaces, probably so that app-specific installation routines can be written in any language, including Visual Basic, Java, C++, etc (not just iscript), and still be able to easily call the ikernel API. This sometimes calls for IPC, but again, this is all handled by the stuff that's already there in every Windows installation, so there's no reason for InstallShield to bloat itself with its own reimplementation of these mechanisms - other than "it causes headaches for those Wine guys", but that probably wouldn't be their primary concern...

Jan. 22, 2003

Re: Installshield 6 crash: ole trouble

by Mike Hearn

Ah, I meant from the perspective of the InstallShield developers rather than how to hack around it in Wine. Well, they must have had their reasons.... On Wed, 2003-01-22 at 10:34, Greg Turner wrote: > On Wednesday 22 January 2003 03:53 am, Mike Hearn wrote: > > Why not just use threads? Is there a particular advantage to using > > IPC in this instance? I'd guess that ikernel.exe is the program that > > does the installing, and the program you launch does the front end > > code? > > I don't know the full story with IS6: I haven't experimented with that > particular bug. But, generally speaking, you can't just fudge threads > for processes; if a.exe runs b.exe, and exepects to speak to it via > RPC, there's basically no hope of getting around the cross-process > nature of the problem. -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

Jan. 22, 2003

Re: Installshield 6 crash: ole trouble

by Greg Turner

On Wednesday 22 January 2003 03:53 am, Mike Hearn wrote: > Why not just use threads? Is there a particular advantage to using > IPC in this instance? I'd guess that ikernel.exe is the program that > does the installing, and the program you launch does the front end > code? I don't know the full story with IS6: I haven't experimented with that particular bug. But, generally speaking, you can't just fudge threads for processes; if a.exe runs b.exe, and exepects to speak to it via RPC, there's basically no hope of getting around the cross-process nature of the problem. -- gmt

Jan. 22, 2003