This is the 93rd release of the Wine's kernel cousin publication. It's main goal is to distribute widely what's going on around Wine (a port of the Windows API to Unix-based operating systems).
I'm currently having major ISP problems. If you've sent me an email in the last few weeks I haven't gotten it. As a result I've changed the address above to one that will work, however it's not a permanent solution for me.
Marcus Meissner was doing some debugging and ran across a problem
and asked for thoughts on how to fix it. Alexandre Julliard replied
with, We could probably get rid of the
check. Syslevel locking is reasonably stable now, and dll separation
will cause more and more false alarms here.
So soon in the CVS
changelog an entry came across that read:
Changelog:
Drop SYSLEVEL checks from relay debugging, since they break debugging builtin GDI dlls.
The effect of this is you get less information printed out when debugging. Andreas Mohr felt it was simply not appropriate to take this out and responded to the change with:
Hmm, do we really want to do this ?
(I know it's already been applied)Shouldn't we create a different SYSLEVEL_CheckNotLevel_unenforced() function instead which simply doesn't call DebugBreak() ?
That way we don't lose the important information about possible syslevel violations.
Syslevel violations are an *ongoing* problem. They are not simply "solved". OTOH I could take Alexandre's cvs commit as his firm promise to go through every future patch line by line to check for syslevel mishaps/omissions ;-)
Oh yeah, and in case you didn't notice: it's me again complaining about yet another silencing ;-)
This patch is not even "too early", it's simply "wrong" IMHO, as it is an ongoing problem (I did mention this before, didn't I ? :).
Sorry for me being of such an opposing nature ;-)
A few more messages went back and forth between Marcus and Andreas about other ways to get around dropping the check, but the change stayed in CVS.
Lawson Whitney was working on a mail application and suddenly had problems with its fault handling. He suspected it was because of something recently added to Wine and began reverting patches until it seemed to be narrowed down. Lawson wrote:
It _might_ be a local misconfiguration, so don't waste too much time on it, but if you spot something that could be a bit wrong in one of these patches, please let me know.
N 1 Apr 23 Alexandre Julliard (2,414) wine/dlls/msvcrt time.c
N 2 Apr 23 Alexandre Julliard (2,089) wine/include/msvcrt stddef.h
N 3 Apr 23 Alexandre Julliard (2,071) wine/debugger types.c
This report generated a fair number of emails that left a lot of people
scratching their heads. Francois Gouget first wondered, If you're using native msvcrt then the first two should have no
impact. If you meant that the crash only occurs when you try using the
builtin msvcrt then maybe it's the patch to time.c. But I would still don't
see why... quite the opposite.
Eric Pouech then questioned the debugger patch and asked, I don't see how a fix in the debugger could change the way an app
work when the debugger is not launched... did you try to run the app with
the debugger started before the crash to see where you get the first fault
?
Lawson began messing around and narrowed it down to what he thought was
the patch to the debugger. He took a break and when he came back to working
on it discovered the problem, If you get this,
it comes by wine with the debugger patch in. It seems I was getting HD errors
which were causing wine to hang and otherwise misbehave. Load a library, and
when you are done there is nothing there, so when the init code gets called,
it faults. reverting moved the files to sectors that happened to work.
I should have known when the same version of wine worked on one box and not
on the other for the same app (shared by nfs) but at the time it only made
my head hurt. e2fsck -c has fixed it for now, but sterner measures may
become necessary.
Looks like its time to start trying to find that warranty information..