I'm still trying to fix aol so it can communicate with the web proxy, and I think I've narrowed down the problem to user32.dll, kernel32.dll, and ws2_32.dll.
Is it possible to use the native user32.dll? I know kernel and ws3_32 don't work native.
I found this:
http://wine.codeweavers.com/docs/wine-user/dll-overrides.shtml
"user, user32 Window management and standard controls. It was possible to use Win95's native versions at some point (if all other DLLs that depend on it, such as comctl32 and comdlg32, were also run native). However, this is no longer possible after the Address Space Separation, so leave at builtin."
and I was wondering if it's still true.
thanks michael
and I was wondering if it's still true.
yes, and it will likely remain so native user32 requires lots of bits from native kernel (which are no longer available because of adress space separation)
A+
and I was wondering if it's still true.
yes, and it will likely remain so native user32 requires lots of bits from native kernel (which are no longer available because of adress space separation)
From what I recall, the core problem was that shared DLL
segments no longer worked after address space separation, and user heavily relies on those to implement its cross- process activities (like messages etc.).
32-bit PE shared section were fixed in the meantime and should work again, I gather, but 16-bit NE shared segments still do not work. Unfortunately, all the real work is done in the 16-bit user (32-bit user32 is just a wrapper layer), so this is probably a show-stopper.
(Maybe it would be possible to run only a single task with native user. But I haven't tried in a long time, and it's probably broken for some reason or other ...)
Bye, Ulrich
Why would address space separation break the native user dll? Shouldn't wine's address space handling be the same as windows? Maybe there's something I'm not understanding...
On Sat, May 04, 2002 at 11:48:12PM +0200, Ulrich Weigand wrote:
and I was wondering if it's still true.
yes, and it will likely remain so native user32 requires lots of bits from native kernel (which are no longer available because of adress space separation)
From what I recall, the core problem was that shared DLL segments no longer worked after address space separation, and user heavily relies on those to implement its cross- process activities (like messages etc.).
32-bit PE shared section were fixed in the meantime and should work again, I gather, but 16-bit NE shared segments still do not work. Unfortunately, all the real work is done in the 16-bit user (32-bit user32 is just a wrapper layer), so this is probably a show-stopper.
(Maybe it would be possible to run only a single task with native user. But I haven't tried in a long time, and it's probably broken for some reason or other ...)
Bye, Ulrich
-- Dr. Ulrich Weigand weigand@informatik.uni-erlangen.de
"Michael" == Michael Cardenas michael.cardenas@lindows.com writes:
Michael> Why would address space separation break the native user dll? Michael> Shouldn't wine's address space handling be the same as windows? Michael> Maybe there's something I'm not understanding...
Well, there's a memory model for win32 and some hacks MS uses for Win9X...
Michael> On Sat, May 04, 2002 at 11:48:12PM +0200, Ulrich Weigand wrote: >> > > and I was wondering if it's still true. > yes, and it will >> likely remain so > native user32 requires lots of bits from native > >> kernel (which are no longer available because of > adress space ...
Trying to run with native User32, the first obstacle I meet is K208. After the call to K208, DS==0 and things obvious crash. Making K208 a void function returning 0 continues until the function GETFASTQUEUE, which anounces itself "expect failure!" as the thread-local queue seems not initialized at that moment...
Bye
Uwe Bonnes wrote:
Trying to run with native User32, the first obstacle I meet is K208. After the call to K208, DS==0 and things obvious crash. Making K208 a void function returning 0 continues until the function GETFASTQUEUE, which anounces itself "expect failure!" as the thread-local queue seems not initialized at that moment...
Are you sure you have only one task? For 16-bit tasks, I think we still have that hidden 'initial task' -- this alone would break things.
The K208 problems look like segments / LDT not being shared.
GetFastQueue was recently broken for native user when Alexandre removed the Callout to user there ...
Bye, Ulrich
"Ulrich" == Ulrich Weigand weigand@immd1.informatik.uni-erlangen.de writes:
Ulrich> Uwe Bonnes wrote: >> Trying to run with native User32, the first obstacle I meet is >> K208. After the call to K208, DS==0 and things obvious crash. Making >> K208 a void function returning 0 continues until the function >> GETFASTQUEUE, which anounces itself "expect failure!" as the >> thread-local queue seems not initialized at that moment...
Ulrich> Are you sure you have only one task? For 16-bit tasks, I think Ulrich> we still have that hidden 'initial task' -- this alone would Ulrich> break things.
I tried to run calc.exe.
From the log I have, it looks like this was the only task.
Ulrich> The K208 problems look like segments / LDT not being shared.
Ulrich> GetFastQueue was recently broken for native user when Alexandre Ulrich> removed the Callout to user there ...
Having native user running would be a big thing for debugging e.g. message problems. E.g. I have an application that at some point started to deny the WM_NCCREATE call in CreateWindows, and I guess that some missing message leaves some memory uninitialized.
Bye
On Mon, May 06, 2002 at 10:43:36PM +0200, Uwe Bonnes wrote:
Ulrich> The K208 problems look like segments / LDT not being shared. Ulrich> GetFastQueue was recently broken for native user when Alexandre Ulrich> removed the Callout to user there ...Having native user running would be a big thing for debugging e.g. message problems. E.g. I have an application that at some point started to deny the WM_NCCREATE call in CreateWindows, and I guess that some missing message leaves some memory uninitialized.
...
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
I agree. I've pretty much given up on trying to fix the embedded internet explorer in aol7 because I'm fairly sure it relies on window messaging.
Maybe we could fix it just for winver==win95 ? There's no reason that the address space for NT should be used when the user explicitly requests 95.
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de writes:
Having native user running would be a big thing for debugging e.g. message problems. E.g. I have an application that at some point started to deny the WM_NCCREATE call in CreateWindows, and I guess that some missing message leaves some memory uninitialized.
I agree it would help for finding bugs. Unfortunately the Win95 architecture is completely brain-damaged, and trying to support it would introduce so many new bugs and instabilities than the end result would be much worse than what we have today. So no, native user is not going to happen.
Michael Cardenas wrote:
Why would address space separation break the native user dll? Shouldn't wine's address space handling be the same as windows? Maybe there's something I'm not understanding...
Well, there's Windows and then there's Windows ;-)
In Win9x, address spaces are handled in a peculiar way: the lower 2 GB of the address space are changed on context switch, while the upper 2 GB remain the same across all processes.
In particular, all 16-bit segments and certain 32-bit DLLs are de facto mapped shared across all 32-bit processes. The user.exe implementation relies on this fact, as I mentioned previously.
Before address space separation, we were handling things somewhat like Win 3.1 (with win32s), in that everything shared one space. After address space separation, we are handling things more like Win NT, in that nothing is shared between processes by default, except for explicit shared mappings (and shared PE sections).
In particular, 16-bit segments are not shared between processes (like they aren't in Win NT), which means that user.exe won't work.
Implementing the weird Win9x address space handling exactly under Linux would be difficult, and in any case we *want* to be more like Win NT for stability reasons ...
Bye, Ulrich
On Mon, May 06, 2002 at 09:49:22PM +0200, Ulrich Weigand wrote:
...
In particular, 16-bit segments are not shared between processes (like they aren't in Win NT), which means that user.exe won't work.
Implementing the weird Win9x address space handling exactly under Linux would be difficult, and in any case we *want* to be more like Win NT for stability reasons ...
Ulrich, thanks for that detailed response!
Don't we want to be more like win9x for the moment since most of the NT dlls are unimplemented right now?
For example, aol7 with winver=win95 runs very well, except that the web proxy communciation doesn't work, but with winver=win2000 it won't even launch because it uses some registy handling functions that are unimplemented stubs. Even with those functions stubbed out, it still doesn't launch.
Michael Cardenas wrote:
Don't we want to be more like win9x for the moment since most of the NT dlls are unimplemented right now?
That's Alexandre's decision. But in any case I agree with Alexandre in this instance; in making a fundamental design decision like this goals like stability should count more than minor issues like whether native user.exe runs (which might or might not run due to a whole bunch of other issues, and is not representative of *any* other workload ...).
Bye, Ulrich
-
Alexandre Julliard -
Eric Pouech -
Michael Cardenas -
Ulrich Weigand -
Uwe Bonnes