Re: Throwing in an idea (probably it was discussed before though)
This will just allow developers to hide bugs in wine and slow development even further, I thing it's a bad idea. Ahem. To say it politely - I didn't get an impression that WINE developers are desperately looking for unknown bugs to fix. Situation is pretty simple. We have an application, which works Ok under WINE, provided that Managed=N specified (with CrossOver it works Ok out-of-the-box). We won't change our code to go around WINE shortcomings (we checked relevant portions of our code though for potential bugs and found nothing), but we would add some kind of hint to make life of our customers a little bit easier. On the other hand, if WINE team doesn't care about current WINE end-users (and there are lots of them, despite the fact that WINE is still Alpha; they just download binary RPM provided and expect their favorite applications to work out-of-the-box) and thinks that they should wait until bug-free WINE released - we don't care much either. From: Ivan Leo Puoti [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: wine-devel@winehq.com Subject: Re: Throwing in an idea (probably it was discussed before though) Date: Mon, 22 Aug 2005 00:31:07 +0100 John Smith wrote: As a Win developer, I want to make a suggestion (sorry if it was already discussed - or if similar mechanism already exists): What if some simple way will be provided for Win developers to say which options they prefer for WINE to use for their application? While it may seem to somewhat contradict to the 'big bright future' of the WINE (with all the apps running flawlessly under WINE), it would hopefully allow for immediate increase of out-of-the-box supported applications. For example, it could be a resource string of special format (for example, __WINE_CONFIG_HINT: Managed = N), and multiple hints should be allowed. This hint should override system-wide settings but in turn should be overridden by per-app settings in wine config file/registry. This will just allow developers to hide bugs in wine and slow development even further, I thing it's a bad idea. Ivan. _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Re: MSXML: add some node tests
Mike McCormack [EMAIL PROTECTED] writes:
diff -u -p -r1.1 domdoc.c
--- dlls/msxml3/tests/domdoc.c12 Aug 2005 11:25:05 - 1.1
+++ dlls/msxml3/tests/domdoc.c20 Aug 2005 07:38:47 -
@@ -27,59 +27,65 @@
#include xmldom.h
#include stdio.h
+#ifndef STANDALONE
#include wine/test.h
+#else
+#define ok(cond,str) do{ if(!(cond)) fprintf(stderr,line %d:
%s,__LINE__,str); }while (0)
+#endif
Please don't add that sort of thing again, simply copy wine/test.h
over to Windows and build with -DSTANDALONE.
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: [winedbg] Don't ever pass a NONCONTINUABLE exception
Glenn Wurster [EMAIL PROTECTED] writes: Changelog: Don't pass on non-continuable exceptions. Why do you want to do that? -- Alexandre Julliard [EMAIL PROTECTED]
Re: Throwing in an idea (probably it was discussed before though)
John Smith wrote: Situation is pretty simple. We have an application, which works Ok under WINE, provided that Managed=N specified Then just tell your users to set that in winecfg, AFAIK winecfg allows app specific settings. I'm sure your great guys but any such mechanism could be easily abuse by lazy programmers, also once it wasn't needed some sort of backwards compatibility may even be needed, I don't think it's a great idea. One simple solution would be to provide default settings for apps that have known problems, Alexandre hasn't ruled that out if it helps some apps to work out of the box. Ivan.
Re: Throwing in an idea (probably it was discussed before though)
Ivan Leo Puoti wrote: John Smith wrote: Situation is pretty simple. We have an application, which works Ok under WINE, provided that Managed=N specified Then just tell your users to set that in winecfg, AFAIK winecfg allows app specific settings. You can also set it yourselves in in your app. As configuration is in registry, every app can modify it. Jacek
Re: Throwing in an idea (probably it was discussed before though)
Then just tell your users to set that in winecfg, AFAIK winecfg allows app specific settings. I'm sure your great guys but any such mechanism could be easily abuse by lazy programmers, also once it wasn't needed some sort of backwards compatibility may even be needed, I don't think it's a great idea. One simple solution would be to provide default settings for apps that have known problems, Alexandre hasn't ruled that out if it helps some apps to work out of the box. Isn't it possible that the App just writes some registry entries to HKCU/Software/Wine/AppDefaults/Filename.exe/ ??? Stefan
Re: Throwing in an idea (probably it was discussed before though)
Then just tell your users to set that in winecfg, AFAIK winecfg allows app specific settings. 1. It is still not 'out-of-the-box' - and from this point of view it doesn't matter much whether it is hacking config file or using GUI; 80% of end-users will try it and throw it away if it doesn't work without hacking settings; 20% of others will ask questions, and will hack config or run winecfg, but those 80% will be lost. 2. (not really relevant to this discussion, but relevant to the whole issue of supporting end-users): binary RPMs for RedHat/Fedora on winehq.org are still 20050524, and winecfg is pretty much useless there. If WINE team does care about end-users, it would be nice to have binary RPMs for the most popular distribution not that much out-of-date. I'm sure your great guys but any such mechanism could be easily abuse by lazy programmers, Don't see much ways to abuse in general - eventually WINE is supposed to run _any_ Win application, right? Also I've suggested that config/winecfg per-application settings should override those 'hints', so user is still in control of it. also once it wasn't needed some sort of backwards compatibility may even be needed, If all it is about is overriding currently existing settings, no backward compatibility is required. One simple solution would be to provide default settings for apps that have known problems, Alexandre hasn't ruled that out if it helps some apps to work out of the box. Ok, this probably is even better; what about integrating such a thing with AppDB and automatically include some special field from AppDB data into winehq distribuitions? _ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/
Re: Throwing in an idea (probably it was discussed before though)
John Smith wrote: This will just allow developers to hide bugs in wine and slow development even further, I thing it's a bad idea. Ahem. To say it politely - I didn't get an impression that WINE developers are desperately looking for unknown bugs to fix. Because it's a tedious and boring task to narrow down those unknown bugs in closed-source apps. And that's exactly why we ask you (since you got access to the sources) to tell us what the application is trying to do which doesn't work in Wine... Actually fixing bugs is usually easy, tracking them down OTOH... (we checked relevant portions of our code though for potential bugs and found nothing) Even if your application relies on undocumented behaviour (potential bugs heh) it should work - if it doesn't that's a bug in Wine which should be fixed. And by the way: Managed=N breaks focusing for everything on my box (bug #2149)... :-) Felix
(no subject)
You can also set it yourselves in in your app. As configuration is in registry, every app can modify it. I like this idea, thanks. There are still 2 issues with such a soultion: a) most likely, it won't work until 2nd start of the application (we will modify it on the first run, and it most likely won't be applied until the second run); b) current WINE guides are discouraging us from detecting WINE - and messing up with Windows Registry, especially HKEY_LOCAL_MACHINE, on all the millions of non-WINE machines is not a thing I would really like to do (the last thing we want is to be caught by some antivirus, which monitors activity it considers suspicious and changing HKEY_LOCAL_MACHINE can easily qualify). _ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/
Dragon ns8 problem
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: {0C4B-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,
--
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
Re: Throwing in an idea (probably it was discussed before though)
Because it's a tedious and boring task to narrow down those unknown bugs in closed-source apps. And that's exactly why we ask you (since you got access to the sources) to tell us what the application is trying to do which doesn't work in Wine... Ahem. And how long it usually takes to fix the bug for not-top-10 application? And please, don't suggest to fix it ourselves - it is not going to happen in corporate environment. As for 'tell us what the application is trying to do' - you've got all APIs in your hands, so what's the problem to track down system calls? The issue our app is experiencing is quite a subtle one - it works Ok with Managed=N or with Desktop=YYYxZZZ (or from CrossOver BTW), but with default WineHQ distribution when it tries to minimize one of it's top-level windows with an explicit call to ShowWindow, the window is not only minimized, but also reduced to 1x1 pixel; when restoring it, sometimes it is restored normally, sometimes not. This behaviour was reported for Gnome/KDE/Xfce and can be fixed with 'Managed' or 'Desktop' settings I've mentioned above. (we checked relevant portions of our code though for potential bugs and found nothing) Even if your application relies on undocumented behaviour (potential bugs heh) it should work - if it doesn't that's a bug in Wine which should be fixed. Well, in fact WINE compatibility wasn't our goal in such a check (WINE installation base is still negligible, and probably will remain negligible until some attention will be paid to out-of-the-box compatibility - at least like in CrossOver); it was just a good reason to check for potential incompatibilities under 'native' Win platforms. Also note that having WINE work perfectly is not our goal (personally I would like it, but the company coudln't care less). Managed=N breaks focusing for everything on my box (bug #2149)... As it would fix the problem for 99% of our users, and won't affect those who doesn't run our app, IMO it is still good enough. Also I remember you've just told that fixing bugs is easy - why does it still exist then? _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Re: X11: Problems with ConfigureNotify events that are received/processed too late
Hi all, Some other propositions on how to fix this: 1. Don't handle X events in MsgWaitForMultipleObjectsEx, just wait for them. 2. Don't cache the X11 window rectangle and always use XGetGeometry to get the current window rectangle. That will surely solve the problem, but also calls like GetClientRect would always need a call to the X server, making things less efficient. The first proposal should not be too hard to implement for anyone familiar with Xlib. I hope somebody can do it. Regards Michael Hi all, I'm trying to get the dialog boxes of Word 95 working. They often appear with the minimal window size (about 70x50 pixels), so they're unusable. With KDE's window manager (KWin) this happens very often. With Enlightenment and GNOME's window manager (Metacity), it only happens from time to time. I've looked for the reason, and I think it's very closely related to WINE bug 1265 which Duane Clark has tried to fix here: http://www.winehq.com/hypermail/wine-patches/2003/02/0095.html That's what's going on (CVS version of WINE, managed window mode): 1. Word creates a dialog with an initial position of (0,0) and size 0x0 (using CreateWindowEx) 2. Word calls SetWindowPos to set the correct dialog position and size 3. Word calls SetWindowPos to show the dialog (SWP_SHOWWINDOW) 4. The dialog gets the focus, the main window is being deactivated 5. In the WM_NCACTIVATE procedure of the main window, Word calls GetQueueStatus. WINE will process X events. 6. WINE receives a ConfigureEvent for the initial dialog position and size (0x0) and saves this to data-whole_rect in X11DRV_sync_window_position (7. If you're lucky, WINE also receives a ConfigureEvent for the correct dialog position) 8. Wine shows the dialog and maps it. It calls X11DRV_set_wm_hints, which calls set_size_hints. This procedure uses data-whole_rect as the dialog's rectangle. But this stored rectangle is completely wrong because WINE has not yet received all ConfigureEvents. 9. The window manager has to resize the dialog to the wrong size. The best solution would be to process all X events before setting the window position in SetWindowPos, but I don't know if that's possible. I've tried another approach: WINE should not set the window size hints when mapping a window (step 8.). I've attached a patch, but it's not 100% correct, because the style of a window (e.g. the WS_THICKFRAME style) may be changed by an application using SetWindowLong and SetWindowPos (with the SWP_FRAMECHANGED flag). WINE doesn't look for the SWP_FRAMECHANGED flag and updates the X11 window every time if it's visible or gets visible. So if an application calls SetWindowPos with the SWP_SHOWWINDOW flag, WINE needs to set the size hints because the window has been hidden and its style may have been changed. What would be the correct fix for this problem? Any ideas? Thanks, Michael
UpdateWindow doesn't call XFlush
Hi all, I've noticed that after an application calls UpdateWindow, the window contents doesn't get updated until the application requests the next event (GetMessage/PeekMessage). That's because UpdateWindow doesn't flush the X output queue (XFlush). I think the best approach would be that UpdateWindow calls GdiFlush, but this function is currently not implemented. The problem is that GdiFlush doesn't get a DC handle, it must figure out itself which DCs it has to flush. Can anyone implement GdiFlush or propose another mechanism on how to call XFlush in UpdateWindow? Regards Michael
Re: Throwing in an idea (probably it was discussed before though)
John Smith wrote: Ahem. And how long it usually takes to fix the bug for not-top-10 application? And please, don't suggest to fix it ourselves - it is not going to happen in corporate environment. Not that long if you provide a small testcase with source that triggers the bug As it would fix the problem for 99% of our users, and won't affect those who doesn't run our app, IMO it is still good enough. Then write the setting to the reg yourself, and hope the wine config key never moves. Ivan.
Re: Throwing in an idea (probably it was discussed before though)
John Smith wrote: 1. It is still not 'out-of-the-box' - and from this point of view it doesn't matter much whether it is hacking config file or using GUI; 80% of end-users will try it and throw it away if it doesn't work without hacking settings; 20% of others will ask questions, and will hack config or run winecfg, but those 80% will be lost. As some have suggested you can write the settings to the registry yourself Ivan.
Re: Throwing in an idea (probably it was discussed before though)
John Smith wrote: Because it's a tedious and boring task to narrow down those unknown bugs in closed-source apps. And that's exactly why we ask you (since you got access to the sources) to tell us what the application is trying to do which doesn't work in Wine... Ahem. And how long it usually takes to fix the bug for not-top-10 application? And please, don't suggest to fix it ourselves - it is not going to happen in corporate environment. If you give a scenario that is easilly reproduceable, it is rare that problems go more than a couple of days unfixed. Sometimes you hit something that requires a rewirte of half the relevant subsystem, but usually it's just a small ommision, and is easilly fixed. The thing that takes so much time is tracking the exact behavior that goes wrong. Also I remember you've just told that fixing bugs is easy - why does it still exist then? Fixing bugs is easy. Finding them is not. It's exactly the same with proprietary software too, btw. If a user reports this doesn't work, my experience is that you spend two weeks in QA trying to reproduce the problem, half a day fixing it, and a couple more weeks testing the solution. It's fairly rare that the relations are much different, but do let us in on your experience. All we are saying is pin-point the problem for us. Shachar
Re: [winedbg] Don't ever pass a NONCONTINUABLE exception
Changelog: Don't pass on non-continuable exceptions. Why do you want to do that? 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. 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. Glenn
Re: [winedbg] Don't ever pass a NONCONTINUABLE exception
Glenn Wurster [EMAIL PROTECTED] writes: 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. 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. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Dragon ns8 problem
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
[EMAIL PROTECTED] 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: {0C4B-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,
Re: [winedbg] Don't ever pass a NONCONTINUABLE exception
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
Re: [winedbg] Don't ever pass a NONCONTINUABLE exception
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.
#include stdio.h
#include windows.h
int _tmain(int argc, char * argv[]) {
int espreg;
int value;
int dummy;
int * dummyptr = dummy;
__asm {
mov (espreg), esp;
mov esp, 0x12345678;
mov ebx, 0xdeadbeef;
mov eax, (dummyptr);
mov [eax], ebx;
mov ebx, [eax];
mov (value), ebx;
mov esp, (espreg);
}
printf( The end result of ebx is: %08X\n, value );
return 0;
}
int main( int argc, char * argv[]) {
return _tmain(argc, argv );
}
Re: [winedbg] Don't ever pass a NONCONTINUABLE exception
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.
Re: [winedbg] Don't ever pass a NONCONTINUABLE exception
Glenn Wurster [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
Re: Dragon ns8 problem
Le 22 août à 19:49:56 [EMAIL PROTECTED] é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
Re: Dragon ns8 problem
On Mon, 22 Aug 2005 23:13:54 +0200, Jean Magnan de Bornier [EMAIL PROTECTED] 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!
Re: Safedisc1 CD checks work, it tries to start the game but fails to do so
On 8/22/05, Ivan Leo Puoti [EMAIL PROTECTED] 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
Re: Throwing in an idea (probably it was discussed before though)
On Mon, 22 Aug 2005 22:46, John Smith wrote: Ahem. And how long it usually takes to fix the bug for not-top-10 application? And please, don't suggest to fix it ourselves - it is not going to happen in corporate environment. Sure it is. There are several corporates around here where fixing bugs in Wine is corporate policy.
Re: Remove unnecessary #pragma code_page(xxxx) statements from winefile .rc files
This is because 'LANGUAGE LANG_' statements don't actually change code page specified by a previous '#pragma code_page()', therefore russian resources get translated to unicode using wrong code page. I don't know whether it's an rc bug or a feature. We either need to remove '#pragma code_page' statements altogether, or add them to all included .rc files. I took the 1st approach. Changelog: Dmitry Timoshkov [EMAIL PROTECTED] Remove unnecessary #pragma code_page() statements from winefile .rc files, they confuse the resource compiler. Please be carefull to remove the code page pragmas. IMHO this is not the correct way. When there is no other code page given, the resource compiler uses the current code page of the operating system. And I don't think, all of those language specific resource scripts will compile correct on all possible OS code pages. The reliable way would be to include the correct code page at the begin of all resource scripts. Please take in mind: Wine is compiled on many different environments: LANG_C, de_DE.ISO-8859-1, en_EN.UTF-8, swedish, or whatever... Removing the code page pragmas would require to test the correctness of the compilation results of all different languages on all possible platforms. Regards, Martin
Re: Safedisc1 CD checks work, it tries to start the game but fails to do so
Monday, August 22, 2005, 3:39:22 PM, Ivan Leo Puoti 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. BTW that nested exception is caused my wine's (Get|Set)ThreadContext not working properly on suspended thread. Unfortunately Mike's patch http://wiki.winehq.org/Make_SetThreadContext_work_properly does not work properly. I have tried to fix it for some time, but to no avail. The problem seems that it always returns the same address for eip. I think it is 0xe410. The best way to test that would be winedbg. It always goes back to that address even when doing stepi. Vitaliy
Re: Safedisc1 CD checks work, it tries to start the game but fails to do so
--- Jesse Allen [EMAIL PROTECTED] wrote: On 8/22/05, Ivan Leo Puoti [EMAIL PROTECTED] 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. There's a large list of copy protected games and the protection they use here http://www.gameburnworld.com/PCprotectedgames.htm, the site also has some details on other copy protection methods and tools to detect copy protection. Jesse ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
Re: Dragon ns8 problem
Le 22 août à 23:28:43 [EMAIL PROTECTED] écrit notamment: | On Mon, 22 Aug 2005 23:13:54 +0200, Jean Magnan de Bornier | [EMAIL PROTECTED] 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! Quite right! I'll ask them cheers, -- 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
Re: Remove unnecessary #pragma code_page(xxxx) statements from winefile .rc files
Martin Fuchs [EMAIL PROTECTED] wrote: Please be carefull to remove the code page pragmas. IMHO this is not the correct way. When there is no other code page given, the resource compiler uses the current code page of the operating system. And I don't think, all of those language specific resource scripts will compile correct on all possible OS code pages. This not a problem with Wine resource compiler. wrc correctly compiles russian resources in my linux system with en_US locale, so I presume that all other languages should be handled correctly as well. If that's not the case for microsoft's rc, I'd consider it a bug in their tool. -- Dmitry.
Re: Automatic ANSIUnicode message translation
Phil Krylov [EMAIL PROTECTED] wrote: Still it is not the best. Now, WM_CHARs posted by PostMessageA and dispatched using GetMessageA work well (are converted back and forth). But when the message loop uses GetMessageW, these WM_CHARs come to the window procedure as 4-byte garbage (WCHAR which is converted from CP_ACP to 2 WCHARs). In Windows, the window procedure receives unchanged code... I no more can test on a win2k, but under XP with russian locale MsgCheckProcA in your test app receives 0x0001 in wParam. In Wine it gets 0x00F30001. I'd not say that it's not acceptable, but it needs more testing in win2k and XP with CJK locales to see what is an expected behaviour in that case. Do you know a real world app does depend on that behaviour? -- Dmitry.
