Re: Throwing in an idea (probably it was discussed before though)

2005-08-22 Thread John Smith
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

2005-08-22 Thread Alexandre Julliard
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

2005-08-22 Thread Alexandre Julliard
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)

2005-08-22 Thread Ivan Leo Puoti

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)

2005-08-22 Thread Jacek Caban

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)

2005-08-22 Thread Stefan Dösinger
 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)

2005-08-22 Thread John Smith
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?


_
Don’t 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)

2005-08-22 Thread Felix Nawothnig

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)

2005-08-22 Thread John Smith

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).


_
Don’t just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/





Dragon ns8 problem

2005-08-22 Thread Jean Magnan de Bornier
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)

2005-08-22 Thread John Smith
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

2005-08-22 Thread Michael Kaufmann

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

2005-08-22 Thread Michael Kaufmann

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)

2005-08-22 Thread Ivan Leo Puoti

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)

2005-08-22 Thread Ivan Leo Puoti

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)

2005-08-22 Thread Shachar Shemesh
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

2005-08-22 Thread Glenn Wurster
  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

2005-08-22 Thread Alexandre Julliard
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

2005-08-22 Thread wino
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

2005-08-22 Thread 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




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

2005-08-22 Thread 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.
#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

2005-08-22 Thread 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.



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

2005-08-22 Thread Alexandre Julliard
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

2005-08-22 Thread Jean Magnan de Bornier
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

2005-08-22 Thread wino
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

2005-08-22 Thread Jesse Allen
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)

2005-08-22 Thread Troy Rollo
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

2005-08-22 Thread Martin Fuchs
 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

2005-08-22 Thread Vitaliy Margolen
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

2005-08-22 Thread Oliver Stieber

--- 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

2005-08-22 Thread Jean Magnan de Bornier
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

2005-08-22 Thread Dmitry Timoshkov
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

2005-08-22 Thread Dmitry Timoshkov
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.