EnumResourceTypes and 16-bit modules
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.
Re: none
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 which process is > using which files etc, which has to be synchronised inside the dll. You shouldn't need any inter-process locking at all now that we have separate address spaces. And if two processes write to the same file they need their own synchronisation mechanism, it's not something we should try to do inside crtdll. -- Alexandre Julliard [EMAIL PROTECTED]
Re: CRTDLL Qtns
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 to provide our own msvcrt.dll for apps that require it. -- Alexandre Julliard [EMAIL PROTECTED]
Re: CRTDLL Qtns
Alexandre Julliard wrote: > > "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 it MT safe. This would mean a large part of the > > code could be shared with msvcrt.dll (way in the future). Also, under unix I > > would expect more processes to be running so potentially it is more > > important to be safe. Does this make sense? > > I think there's no point in making functions thread-safe if they are > not thread-safe in Microsoft implementation. Any app that uses these > functions will have to provide its own locking anyway, so we'd only be > duplicating it and slowing things down. 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? -Gav -- Gavriel State CEO TransGaming Technologies Inc. [EMAIL PROTECTED]
IBM Home Page Builder patches
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, test against those apps I have, and submit them to the wine-patch list for inclusion. Alternatively I can post them here first if that would be preferable. If I find any that are obviously clashing with any work that seems to be in progress I will contact the authors of the work in progress directly. Regards David -- Forwarded by David Goodenough/DGA/GB on 13-09-2000 04:55 PM --- David Goodenough 01-09-2000 02:39 PM To: [EMAIL PROTECTED] cc: Subject: IBM Home Page Builder patches A while ago someone on this list noted that IBM had released a Linux version of Home Page Builder which was really the Windows version with a patched version of Wine. This was built against Wine 2423. The patches seem to fall into four main categories:- 1) Bits from Wine 2526 which should already be in the current builds, 2) Changes to make their Wine separate from any other on the machine and a few very HPB specific changes that would not really be desirable in the standard builds, 3) Changes to disable some functionality (presumably that they were having some trouble with), 4) New function and fixes to existing function. The first two obviously do not need any further attention. The third is perhaps a pointer to places were some further work is needed, but the fourth is really the one I am interested in here. Has anyone been in contact with the authors (somewhere in Japan by the look of it), or IBM, about merging these fixes into the current builds? If not, are there any objections to my doing so? A few of the fixes conflict with other work that has been done since 0526, but most is standalone as far as I can see. The conflicts will need to be resolved with those who have made the changes.
Re: CRTDLL Qtns
"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 it MT safe. This would mean a large part of the > code could be shared with msvcrt.dll (way in the future). Also, under unix I > would expect more processes to be running so potentially it is more > important to be safe. Does this make sense? I think there's no point in making functions thread-safe if they are not thread-safe in Microsoft implementation. Any app that uses these functions will have to provide its own locking anyway, so we'd only be duplicating it and slowing things down. -- Alexandre Julliard [EMAIL PROTECTED]
Re: make system brushes, pens non-deletable
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 packages want > >to use one libgdi32.so) > > How about using GetProcAddress ? Yes, of course you could do that. I'm not sure what to do. He wants to flip the flags in memory in USER. That's probably a better idea, even though it's a bit ugly (calculating memory offsets and such). But Windows isn't "clean" either... We pretty much have agreed on that. I'll send a patch later today. Andreas Mohr
Re: CRTDLL Qtns
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 directories and it differs from our process.h. So I propose to move our process.h to include/wine/process.h and create a windows compatible process.h in include. Bye Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: Treeview patch once again
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[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
