August 2005 - Wine-Devel - list.winehq.org

Re: Safedisc1 CD checks work, it tries to start the game but fails to do so

by Jesse Allen

On 8/22/05, Ivan Leo Puoti <ivanleo(a)gmail.com> wrote: > Hello list, here's a little update > Safedisc1 now successfully passes all anti debugger check, and recognises the CD correctly. > It then attempts to start the game, but this doesn't work yet because of the nested exception on > signal stack bug. Hopefully we aren't too far from getting it to run. > > Ivan. > > > Let me know when you have a patch ready, and I can test with some of my games. Maybe some games are working now. Jesse

Aug. 22, 2005

Safedisc1 CD checks work, it tries to start the game but fails to do so

by Ivan Leo Puoti

Hello list, here's a little update Safedisc1 now successfully passes all anti debugger check, and recognises the CD correctly. It then attempts to start the game, but this doesn't work yet because of the nested exception on signal stack bug. Hopefully we aren't too far from getting it to run. Ivan.

Aug. 22, 2005

Crash on glBegin() (Was: Help with debugging needed)

by Stefan Dösinger

Hi, I've continued my work on Empire Earth my Solution(or is it a hack that works by pure chance?) seems to work quite well, and the string operation was also easy to solve, I just may not delete the intro movie. Now I've run into the next problem: Any call to glBegin(GL_Something) crashes in the libs of my OpenGL driver(ATI fglrx) due to some NULL pointer access[1]. If I disable Hardware Acceleration, the crash doesn't occur and Empire Earth starts up to the Main Menu more or less successfully: It only shows a black screen, but it reacts to keypresses(Sounds are playing, I can take screenshots with the in-game Screen Shot Funktionality[2]. A +ddraw log can be found at http://www.doesi.gmxhome.de/ee.out.bz2 I suspect the crash and the black screen problem to have more or less the same cause somewhere in the OpenGL initialization. I will test with some other OpenGL implementations(The X.Org one and if possible the one from the nvidia driver). Does anyone have any experiance with this? Some Pointers? A few words to the Screen Shot: Appearently the screen shot is not totally black, it shows the correct mouse Pointer and the Texts are correct. It should draw a background image. The background seems not to be redrawn, so the old mouse pointer remains visible. The vertical mirroring appears only sometimes, it's perhaps also redraw related. Thanks again for your help, Stefan Dösinger PS: are there any freely downloadable Direct3D 7 games available wich are working with Wine? I'd like to test these with the somewhat strange fglrx driver. [1] Crash dump: First chance exception: page fault on read access to 0x000000d4 in 32-bit code (0x7e8b2280). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:7e8b2280 ESP:5b8df1c8 EBP:5b8df1e0 EFLAGS:00210212( - 00 - RIA1) EAX:00000000 EBX:00000000 ECX:7c2926c8 EDX:0000011c ESI:00000004 EDI:7fe47b00 Stack dump: 0x5b8df1c8: 00000003 7e24dfc0 7e23945c 7c20c7c0 0x5b8df1d8: 7c20c7c0 00000004 5b8df200 7e8b1e02 0x5b8df1e8: 00000004 7e24dfc0 7e23945c 7e2394a8 0x5b8df1f8: 7e24d1d4 00000000 5b8df2cc 7e203e9c 0x5b8df208: 00000004 00000000 00000000 7e2395d3 0x5b8df218: 5b8dfed3 5b8dfb0b 5b8dfed3 00000000 Backtrace: =>1 0x7e8b2280 in atiogl_a_dri.so (+0x3a3280) (0x5b8df1e0) 2 0x7e8b1e02 in atiogl_a_dri.so (+0x3a2e02) (0x5b8df200) 3 0x7e203e9c draw_primitive_strided(This=0x7fe16ab0, d3dptPrimitiveType=0x4, d3dvtVertexType=0x152, lpD3DDrawPrimStrideData=0x5b8df308, dwVertexCount=0x4, dwIndices=0x5b8df3a8, dwIndexCount=0x6, dwFlags=0x0) [/media/usbdisk/develop/wine/dlls/ddraw/device_opengl.c:1444] in ddraw (0x5b8df2cc) 4 0x7e205304 GL_IDirect3DDeviceImpl_7_3T_DrawIndexedPrimitiveVB(iface=0x7fe16ab0, d3dptPrimitiveType=0x4, lpD3DVertexBuf=0x7fe47b00, dwStartVertex=0x0, dwNumVertices=0x4, lpwIndices=0x5b8df3a8, dwIndexCount=0x6, dwFlags=0x0) [/media/usbdisk/develop/wine/dlls/ddraw/device_opengl.c:1782] in ddraw (0x5b8df374) 5 0x7db42f41 ??0DX7Movie@@QAE(a)ABV0@@Z in dx7hrdisplay (0x5b8df3e4) 6 0x7fa60b92 ??0UIBFull@@QAE(a)KABVUString@@ABUGETextureDescription@@ABVGERectangle@@ABVUILayoutUtility@@PAVUIForm@@KKK_N(a)Z in low-level engine (0x5b8df4a8) 7 0x7fa6ca69 ?DrawBackground(a)UIForm@@MAEJABVGERectangle@@@Z in low-level engine (0x5b8df504) 8 0x7fa743dd ?AddDirtyRectangle(a)UIManager@@QAEXABVGERectangle@@PAVUIForm@@@Z in low-level engine (0x5b8df520) 9 0x005058c0 in empire earth.exe.norepe (+0x1058c0) (0x5b8df55c) 10 0x00507573 in empire earth.exe.norepe (+0x107573) (0x5b8df590) 11 0x00507104 in empire earth.exe.norepe (+0x107104) (0x00000000) 0x7e8b2280: movl 0xd4(%eax),%eax [2] Example Screenshot: www.doesi.gmxhome.de/EE000.jpg [3] www.doesi.gmxhome.de/ee.out.bz2

Aug. 22, 2005

Re: Dragon ns8 problem

by wino＠piments.com

On Mon, 22 Aug 2005 23:13:54 +0200, Jean Magnan de Bornier <jean(a)bornier.net> wrote: > Well I don't have v7 and I don't think I could install it from the > package they sent me... so I will soon be quite frustrated with that > unless there is a miracle! > Thanks anyway, maybe someone has some other idea? Well if you have paid them for the v8 product why not ask them to support it or give you a free down-grade! I've read that they have tested NS on Linux (some redhat version if I recall) so they are not blind to the potencial market Linux presents and that there is no credible equivalent on Linux. Dont know until you ask!

Aug. 22, 2005

Re: Dragon ns8 problem

by Jean Magnan de Bornier

Le 22 août à 19:49:56 wino(a)piments.com écrit notamment: | This goes back a few months but I recall helping a guy who was trying to | get ns8 german working (multilang in fact so it may be the same you have). > | I advised him to he would likely get further with v7 , initially he | persisted with his efforts on ns8 (and he seemed pretty capable) then came | round to my way of thinking and got v7 sorted fairly quickly. > | That's all I can tell you about v8. > | If you want to try v7 I think I put some more info (wine version etc) in | the wine app DB, plus you already have my posts here it seems. > | Sorry I cant be more help , but I am pretty sure the rec. engine is just | the same and you probably would not get any than some interprocess tweeks | that wont be of any use on Wine , and maybe some install/security | headaches. Well I don't have v7 and I don't think I could install it from the package they sent me... so I will soon be quite frustrated with that :-( unless there is a miracle! Thanks anyway, maybe someone has some other idea? -- Jean Magnan de Bornier | Cours Victor Hugo e-mots: jean at bornier.net | 13980 Alleins France T 08 70 39 34 03 | P 06 09 17 35 87

Aug. 22, 2005

Re: [winedbg] Don't ever pass a NONCONTINUABLE exception

by Alexandre Julliard

Glenn Wurster <gwurster(a)scs.carleton.ca> writes: > Moving the calling of the debugger into the signal handler takes away > the dependance on a correct signal stack. It lets us: > > 1) Debug a program without having to modify it's memory to call the > debugger. > > 2) Set breakpoints and single step through areas where the stack > pointer is incorrect. > > 3) Use the debugger even when the application is at it's upper stack > limit (so we can see where the stack overflow exists). > > 4) Examine exceptions and application state when an exception is > generated while stack pointer is bad. > > All these can be done on Windows, and therefore sending events to the > Windows debugger must be done without relying on the program stack. > It would make sense for the wine debugger to be equally capable. Sure, that would be nice, just be aware that it's not acceptable to break anything in the normal exception handling semantics, since that has to always take priority over the debugger support. Also note that we used to handle exceptions on the signal stack, and it was causing lots of problems, which is why I'm a bit skeptical. Now, doing only the first chance bit on the signal stack would probably be easier, but it's still far from trivial... -- Alexandre Julliard julliard(a)winehq.org

Aug. 22, 2005

Re: [winedbg] Don't ever pass a NONCONTINUABLE exception

by Glenn Wurster

> >Not really, if the app handles the exception there's no reason it > >would fail. > > And that's just what safedisc does so please don't change it because it > appears to work and enough things it needs are broken already. I'm not looking to change exception handling at the application level, just trying to make the debugger work better. Again, EXCEPTION_NONCONTINUABLE was the wrong flag to check, EH_STACK_INVALID is what the revised patch checks, because exceptions with this flag will never make it to the application at all anyway. Glenn.

Aug. 22, 2005

Re: [winedbg] Don't ever pass a NONCONTINUABLE exception

by Glenn Wurster

> > In short, because we're never going to be able to continue, so there's > > no point on trying to pass because that's going to fail. > > Not really, if the app handles the exception there's no reason it > would fail. Not passing the exception will break things like > IsBadReadPtr. Ok. My understanding of the non-continuable flag was not correct. A fixed patch follows in a seporate e-mail to wine-patches. > > In long, because I've got another patch in the pipeline (it needs some > > tweaking) that moves the calling of the debugger into the signal > > handler. It allows the debugger to catch exceptions that would > > previously have resulted in a total crash (non-continuable > > exceptions), and it more accurately reflects how the Windows debugger > > is called. Using a debugger will also no longer modify program memory > > as it does currently. In all, it should allow the debugger to work in > > more circumstances than it currently does. > > Well, I'll wait to see the patch, but I doubt we want to do that. The > current way is pretty much identical to what Windows does, and it > sounds like your way isn't. Doing SEH via the application stack is correct in the current code. Passing exceptions to the debugger via the application stack is not correct. I've attached a small C file which will demonstrate the problem. On windows, you can single step through the assembly code correctly, on Wine, you can not. The one conclusion that we can draw is that the method for calling the debugger on Windows must not use the application stack at all. Furthermore, if an exception does occur while the stack pointer is bad in windows, the debugger will trap it and let you examine the situation. Wine right now crashes. Moving the calling of the debugger into the signal handler takes away the dependance on a correct signal stack. It lets us: 1) Debug a program without having to modify it's memory to call the debugger. 2) Set breakpoints and single step through areas where the stack pointer is incorrect. 3) Use the debugger even when the application is at it's upper stack limit (so we can see where the stack overflow exists). 4) Examine exceptions and application state when an exception is generated while stack pointer is bad. All these can be done on Windows, and therefore sending events to the Windows debugger must be done without relying on the program stack. It would make sense for the wine debugger to be equally capable. Now, if calling the debugger shifts positions to the signal stack, it is possible to detect whether we can deliver a corresponding SE to the applications SEH. If we can detect when the exception can not actually be delivered, then we can force the debugger to stop, even if this is the first notification of a excpetion to the debugger. The point behind the non-continuable change was to tell the debugger this. That patch was wrong. I should have used EH_STACK_INVALID (it would be impossible to even pass this flag to the debugger if the debugger relied on the application stack). Glenn.

Aug. 22, 2005

Re: [winedbg] Don't ever pass a NONCONTINUABLE exception

by Ivan Leo Puoti

Alexandre Julliard wrote: > Not really, if the app handles the exception there's no reason it > would fail. And that's just what safedisc does so please don't change it because it appears to work and enough things it needs are broken already. Ivan

Aug. 22, 2005

Re: Dragon ns8 problem

by wino＠piments.com

This goes back a few months but I recall helping a guy who was trying to get ns8 german working (multilang in fact so it may be the same you have). I advised him to he would likely get further with v7 , initially he persisted with his efforts on ns8 (and he seemed pretty capable) then came round to my way of thinking and got v7 sorted fairly quickly. That's all I can tell you about v8. If you want to try v7 I think I put some more info (wine version etc) in the wine app DB, plus you already have my posts here it seems. Sorry I cant be more help , but I am pretty sure the rec. engine is just the same and you probably would not get any than some interprocess tweeks that wont be of any use on Wine , and maybe some install/security headaches. HTH On Mon, 22 Aug 2005 14:43:49 +0200, Jean Magnan de Bornier <jean(a)bornier.net> wrote: > Hello all, > > My machine: Linux-gentoo, wine 20050725 > > I'm quite new to wine, just installed it in order to use dns8, of which I > have the french version. I looked at recent threads on this list and have > been more or less hopeful, but right now I have had no success; here is > the log of my last attempt with the command "wine setup.exe": > > === Début de l'écriture dans le journal : 22/08/2005 14:18:02 === > Début de l'action 14:18:02 : INSTALL. > Début de l'action 14:18:02 : ISMsiServerStartup. > Fin de l'action 14:18:03 : ISMsiServerStartup. Valeur renvoyée : 1. > 1: The InstallScript engine version currently installed on this machine > is adequate. > Début de l'action 14:18:03 : ISStartup. > 1: Event 'E183186' is created > 1: GetInstallDriver, Can not find InstallDriver in ROT table, Return > Code = 0x800401e3 > 1: {DDDD0C4B-57F7-4A85-ACF0-DB3FC8F1DBB4} > 1: ISMsiServerStartup Failure. Unknown Exception. > Fin de l'action 14:18:03 : ISMsiServerStartup. Valeur renvoyée : 1603. > 1: ISStartUp Failure. OpenEvent, Error = 0x2 > Fin de l'action 14:18:03 : ISStartup. Valeur renvoyée : 3. > Début de l'action 14:18:03 : SetupCompleteError. > Informations 2898. Tahoma8, Tahoma, 0 > Informations 2898. TahomaBold10, Tahoma, 0 > Début de l'action 14:18:06 : ISCleanUpFatalExit. > Fin de l'action 14:18:06 : ISCleanUpFatalExit. Valeur renvoyée : 3. > DEBUG: Error 2896: Executing action ISCleanUpFatalExit failed. > Erreur interne 2896. ISCleanUpFatalExit > Fin de l'action 14:18:06 : SetupCompleteError. Valeur renvoyée : 3. > Fin de l'action 14:18:06 : INSTALL. Valeur renvoyée : 3. > === Fin de l'écriture dans le journal : 22/08/2005 14:18:06 === > MSI (c) (0C:0E): Produit : Dragon NaturallySpeaking 8 -- L'installation > a échoué. > > The eighth line of this seems to be tne interesting one; what would this > InstallDriver and this ROT table be? Can I find them somewhere? Any hope > still? > TIA,

Aug. 22, 2005