At 06:46 PM 9/12/00 -0500, you wrote:
Hmm, we had some more discussion about that system object deletion,
and Alexandre told me that we can't accept extra DLL exports
(we have to remain compatible in case different software packages want
to use one libgdi32.so)
How about using GetProcAddress ?
Chris Morgan writes:
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Hallo Chris,
no need to send the message to both lists.
Either send to wine-devel, if you want to discuss the patch or to
wine-patches if you _think_ the patch is correct and want it included.
Bye
Uwe Bonnes
Griffiths, Jonathon writes:
...
-Wines "process.h" will conflict with the crt "process.h". Is it desirable
to have crt headers in the wine include dir, or should they be in
include/crt? (note I wont be writing headers for some time).
There is a "process.h" in most windows include
On Wed, Sep 13, 2000 at 01:36:06AM -0500, gerard patel wrote:
At 06:46 PM 9/12/00 -0500, you wrote:
Hmm, we had some more discussion about that system object deletion,
and Alexandre told me that we can't accept extra DLL exports
(we have to remain compatible in case different software
"Griffiths, Jonathon" [EMAIL PROTECTED] writes:
-MS docs state that crtdll is not very threadsafe, however I cant see any
reason why wines shouldnt be. I don't think any apps depend on non
threadsafe behaviour since by definition it is unpredictable. So I think it
may be worthwhile to make
Well I took the silence that this note triggered as a "no-one else has done
this, go ahead". So I went ahead and IBM Japan are quite happy for their
patches to be incorporated. I will therefore extract the type 4 fixes (see
list below), test each against the current build, adjust as necessary,
Gavriel State [EMAIL PROTECTED] writes:
Again, what about WineLib apps? Remember, that these apps on Windows would have
been linked to thread safe functions in msvcrt, but under WineLib will be linked
to libcrt.dll. Or are we going to have a seperate libmsvcrt.dll?
Yes, obviously we need
Jon Griffiths [EMAIL PROTECTED] writes:
There are two issues here: Locking and thread safety. Locking is
needed if multiple processes (not threads) are to do things like have
their own files open, and not be able to write to each others files,
etc. This is because we'll need to keep track of
Hello all.
The question is short: is EnumResourceTypes supposed to work with
16-bit modules?
I ask because I don't know what to do: simply avoid crashing by
checking HIWORD(hModule), or implement a full working solution.
Dmitry.
