Re: RtlpWaitForCriticalSection?
Christian Costa wrote: All the static CRITICAL_SECTIONs in Wine DLLs have names. The only unnamed ones are those that are initialized at runtime. It is what I said! No? :-) I guess I missed part of what you said, sorry. To give these a name, we'd either have to convert them to static initialization, or change InitializeCriticalSection to somehow generate a name from the caller's program counter. What about writing a new macro that initializes the name in the CRITICAL_SECTION struct. . InitializeCriticalSection(crit); SET_CRITICAL_SECTION_NAME(crit,name); Hmm. Seems to be the Wine DLL sources should try to avoid stuff that doesn't compile under Windows. That said, we could provide a header file that defined SET_CRITICAL_SECTION_NAME in Windows, and made it do nothing. Furthermore, we could be real sneaky, and make that header file turn InitializeCriticalSection into a macro that called the real InitializeCriticalSection, then called SET_CRITICAL_SECTION_NAME, so no source changes would be needed to get the name in there, maybe. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
Re: Wine kernel acceleration module?
Gavriel State wrote: Another key factor in favour of the ShmServer is that we've got a working prototype available right now that runs several real-world apps. 8-) May I ask for a list of Apps ? Tom Take care -Gav
Re: debugger detection in newbin.
On Thu, Jan 23, 2003 at 10:12:32AM +0100, Rein Klazes wrote: Hi, The latest version of newsbin 4.1B5 refuses to run, displaying debugger or monitoring tool detected. The detection code is very simple, immedeately at the program entry point 0x516000 it does (intel syntax): | Disassembly of 0x00516000 | 0x51600D: 64A02300 mov al,fs:[0x23] | 0x516013: EB03 jmp 0x516018 | ;*** | 0x516018: 84C0 test al,al | 0x51601A: EB03 jmp 0x51601f | ;*** | 0x51601F: 7567 jnz 0x516088 This jump is taken and leads immedeatly to the messagebox displaying the message above. Any idea's and/or explanation? Well, we store the thread pid there, see thread.h: DWORDpid;/* !2- 20 Process id (win95: debug context) */ Try to move the pid somewhere else and mark this field as unused. Ciao, Marcus
debugger detection in newbin.
Hi, The latest version of newsbin 4.1B5 refuses to run, displaying debugger or monitoring tool detected. The detection code is very simple, immedeately at the program entry point 0x516000 it does (intel syntax): | Disassembly of 0x00516000 | 0x51600D: 64A02300 mov al,fs:[0x23] | 0x516013: EB03 jmp 0x516018 | ;*** | 0x516018: 84C0 test al,al | 0x51601A: EB03 jmp 0x51601f | ;*** | 0x51601F: 7567 jnz 0x516088 This jump is taken and leads immedeatly to the messagebox displaying the message above. Any idea's and/or explanation? Rein. -- Rein Klazes [EMAIL PROTECTED]
Re: A strange problem with xmpeg
1. When the splash screen desapears, so does all of my desktop. I have to make a Refresh Desktop to get it back. Judging by the log below, I am suspecting of something in the DirectDraw functions. Upon request I will gladily send a (45Kb) screen shot of this. This problem also occurs with QuickTime when it's using DirectDraw. It was easier to switch it to GDI mode than debug though :) -- Mike Hearn [EMAIL PROTECTED] QinetiQ - Malvern Technology Center
Re: Spanish Documentation Project
Javier Canovas wrote: hi, this is my first message on this mailing list... HI! I am a spanish user of wine, and I am going to translate the english documentation of wine (I manage the project). I am creating the project (cvs, bugzilla...) in Lucas (es.tldp.org) but I cant do it alone. I am meeting people to work in this, somebody can help us? Thks I just want to say thanks for taking on part of the translation. I am aware that wine needs the README : http://cvs.winehq.com/cvsweb/wine/README?hideattic=0 translated to as many languages as possiable at this time. This would be a good place to start.. You might want to read over : http://cvs.winehq.com/cvsweb/~checkout~/wine/documentation/i18n.sgml?rev=1.3content-type=text/plainhideattic=0 as well . And im sure we could use many more volinteers in this department. Many thanks for your support !!! Tom
LockFile support
I have an old, nasty application that uses the Paradox database engine. This app attempts to lock the database files using LockFile. Now, it USED to work under Wine. It no longer does. The program coughs up an error No access to directory, and stderr shows a bunch of LockFile not supported in server errors. Did the behavior of LockFile change in the past couple of months? Are there plans to add LockFile support into Wine?
Re: LockFile support
Now, it USED to work under Wine. It no longer does. The program coughs up an error No access to directory, and stderr shows a bunch of LockFile not supported in server errors. LockFile didn't change AFAICT. What may have changed is: - timing of some operations may have changed (and if LockFile is really used several threads/processes are used, this changes the whole picture) - reading operations has been a bit improved (which comes back to bullet above) But, I don't think those would lead to the no access to directory error. I think it's more something in the file management code which can play in this area, not the file locking. Are there plans to add LockFile support into Wine? they've been some talks of implementing it lately, but not lots of very conclusive so far. A+
Re: A strange problem with xmpeg
On Thursday 23 January 2003 10:59, Mike Hearn wrote: 1. When the splash screen desapears, so does all of my desktop. I have to make a Refresh Desktop to get it back. Judging by the log below, I am suspecting of something in the DirectDraw functions. Upon request I will gladily send a (45Kb) screen shot of this. This problem also occurs with QuickTime when it's using DirectDraw. It was easier to switch it to GDI mode than debug though :) And how do you switch to GDI mode?
Re: A strange problem with xmpeg
It's in the preferences/settings dialog. You can get to it from the player I think. Then select Video mode, then Safe Mode (GDI Only) On Thu, 2003-01-23 at 15:42, Zsolt Rizsanyi wrote: On Thursday 23 January 2003 10:59, Mike Hearn wrote: 1. When the splash screen desapears, so does all of my desktop. I have to make a Refresh Desktop to get it back. Judging by the log below, I am suspecting of something in the DirectDraw functions. Upon request I will gladily send a (45Kb) screen shot of this. This problem also occurs with QuickTime when it's using DirectDraw. It was easier to switch it to GDI mode than debug though :) And how do you switch to GDI mode? -- Mike Hearn [EMAIL PROTECTED] QinetiQ - Malvern Technology Center
Re: debugger detection in newbin.
Marcus Meissner wrote: On Thu, Jan 23, 2003 at 10:12:32AM +0100, Rein Klazes wrote: Hi, The latest version of newsbin 4.1B5 refuses to run, displaying debugger or monitoring tool detected. Well, we store the thread pid there, see thread.h: DWORDpid;/* !2- 20 Process id (win95: debug context) */ Try to move the pid somewhere else and mark this field as unused. All, I saw this same problem with a different application, and it behaves the same way whether the Windows version is NT or 9x. After a bit of research, it appears that NT pids should be less than 65k, so I created a patch that makes all of Wine's Win32 PIDs less than 65k. It makes the application I was using work (for winver set to both NT and 9x), but I had not posted it to wine-patches because I was afraid it might break something else. I will go ahead and post it now, but it would appreciate comments from someone who knows more Regards, Alex Pasadyn
Doccumetation issue: The Service Thread Does it exist?
This concerns the documentation on thw www.winehq.com website, if it's out of date, then this post may be irrelevant. In the Wine Developer's Guide In Section 8.1.4, The Service thread Says there exists a service thread, that is implemented in: scheduler/services.c. It also says this thread is used to support the X11 driver's event loop. Firstly, I cannot find the scheduler/services.c file. Secondly from my reading of the x11drv code, the X11 event loop is serviced for every call of to X11DRV_MsgWaitForMultipleObjectsEx, which is inturn called by MsgWaitForMultipleObjectsEx, and GetMessage. Therefore, whichever thread is active will service the X11 event queue. It also appears, because each thread has it's own XDisplay object that messages created by a X11 window will only be picked up in the thread that created the window. Am I correct, or have I missed something fundamental? Bye -Rob.
Re: Whither fnt2bdf?
Dan Kegel [EMAIL PROTECTED] writes: What happened to fnt2bdf? It was removed as of http://cvs.winehq.com/cvsweb/wine/tools/Makefile.in.diff?r1=1.20r2=1.21 but the comment for 1.21 doesn't seem to mention this removal http://cvs.winehq.com/cvsweb/wine/tools/Makefile.in Might this be a mistake? It's still available, it's just no longer installed by default, as part of the effort to clean up the namespace of things we install in /usr/bin. Anyway these days you are much better off using client-side fonts than trying to manually convert Windows fonts to X format. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Doccumetation issue: The Service Thread Does it exist?
Robert North a écrit: This concerns the documentation on thw www.winehq.com website, if it's out of date, then this post may be irrelevant. In the Wine Developer's Guide In Section 8.1.4, The Service thread Says there exists a service thread, that is implemented in: scheduler/services.c. It also says this thread is used to support the X11 driver's event loop. Firstly, I cannot find the scheduler/services.c file. Secondly from my reading of the x11drv code, the X11 event loop is serviced for every call of to X11DRV_MsgWaitForMultipleObjectsEx, which is inturn called by MsgWaitForMultipleObjectsEx, and GetMessage. Therefore, whichever thread is active will service the X11 event queue. It also appears, because each thread has it's own XDisplay object that messages created by a X11 window will only be picked up in the thread that created the window. Am I correct, or have I missed something fundamental? Bye -Rob. From http://cvs.winehq.org/cvsweb/wine/scheduler/Attic/services.c: Revision 1.14 FILE REMOVED Removed service thread support. Guess it answer why you can't find scheduler/services.c. Somebody else than me can probably tell you why, or what replaced it. Vincent
Re: Wine kernel acceleration module?
Tom Wickline wrote: Gavriel State wrote: Another key factor in favour of the ShmServer is that we've got a working prototype available right now that runs several real-world apps. 8-) May I ask for a list of Apps ? Well the paper that we posted with the donation announcement (http://www.transgaming.com/papers/shmserver.html) provides a certain list. We were of course concerned with games that we knew had this problem (American McGee's Alice and Quake3). As for a complete list I don't think that we have one but it has been tried, without any observed issues, on several other games that reside in my blurry hazy memory. Guess that doesn't help much. The paper does also mention some of the toy applications in the program directory that were used. Perhaps people could post their success and failure stories? Ciao, Peter Tom Take care -Gav
Re: debugger detection in newbin.
On Thu, 23 Jan 2003 11:00:43 -0600, you wrote: Marcus Meissner wrote: On Thu, Jan 23, 2003 at 10:12:32AM +0100, Rein Klazes wrote: Hi, The latest version of newsbin 4.1B5 refuses to run, displaying debugger or monitoring tool detected. Well, we store the thread pid there, see thread.h: DWORDpid;/* !2- 20 Process id (win95: debug context) */ Try to move the pid somewhere else and mark this field as unused. All, I saw this same problem with a different application, and it behaves the same way whether the Windows version is NT or 9x. After a bit of research, it appears that NT pids should be less than 65k, so I created a patch that makes all of Wine's Win32 PIDs less than 65k. It makes the application I was using work (for winver set to both NT and 9x), but I had not posted it to wine-patches because I was afraid it might break something else. I will go ahead and post it now, but it would appreciate comments from someone who knows more That would be nice. Following Marcus' suggestion takes me past this obstacle, but at a later point in some piece of self-modified code an exception happens: | wine: Unhandled exception, starting debugger... | Couldn't start process '0 64 ' | Couldn't start process '0 64 ' | Couldn't start process '0 64 ' | Couldn't start process '0 64 ' Btw, the program also refuses to run in a Win2K guest under Vmware. It runs OK in pure Win2K. Rein. -- Rein Klazes [EMAIL PROTECTED]
Re: Doccumetation issue: The Service Thread Does it exist?
Vincent Béron vberon-at-mecano.gme.usherb.ca |Wine Mailing Lists| wrote: Robert North a écrit: This concerns the documentation on thw www.winehq.com website, if it's out of date, then this post may be irrelevant. In the Wine Developer's Guide In Section 8.1.4, The Service thread Says there exists a service thread, that is implemented in: scheduler/services.c. It also says this thread is used to support the X11 driver's event loop. Firstly, I cannot find the scheduler/services.c file. [Snip irrelevant stuff] From http://cvs.winehq.org/cvsweb/wine/scheduler/Attic/services.c: Revision 1.14 FILE REMOVED Removed service thread support. Guess it answer why you can't find scheduler/services.c. Somebody else than me can probably tell you why, or what replaced it. Vincent Now why didn't I think of doing a CVS search ;-) Did a google on the winehq site, and found that Alexandre wanted to remove it, but not why. I'll just have to wait for further replies. Thanks -Rob.
Re: Whither fnt2bdf?
Dan Kegel [EMAIL PROTECTED] writes: Does that mean Wine can natively handle .fnt fonts (which X libraries can't natively, I believe) as client side X fonts? My understanding is that FreeType can support bitmap fonts, but that it's not implemented in Wine yet; Huw can give you the details. Anyway most of the need for fnt2bdf was to convert the Windows standard fonts, and these are basically all TrueType now. I suppose Wine would need some user-space app to manage these fonts, then? I guess we could have a font control panel at some point, but there isn't that much to manage anyway. As long as the font files are somewhere on the font path everything should just work. -- Alexandre Julliard [EMAIL PROTECTED]
Re: more HEAP_strdupAtoW removals
Matthew Davison [EMAIL PROTECTED] wrote:
On Thu, 2003-01-23 at 01:36, Dmitry Timoshkov wrote:
@@ -760,24 +774,26 @@
BOOL WINAPI OpenPrinterA(LPSTR lpPrinterName,HANDLE *phPrinter,
LPPRINTER_DEFAULTSA pDefault)
{
- LPWSTR lpPrinterNameW = HEAP_strdupAtoW(GetProcessHeap(),0,lpPrinterName);
+ UNICODE_STRING lpPrinterNameW;
+ UNICODE_STRING usBuffer;
+ RtlCreateUnicodeStringFromAsciiz(lpPrinterNameW,lpPrinterName);
PRINTER_DEFAULTSW DefaultW, *pDefaultW = NULL;
BOOL ret;
Are you sure that mixed data declarations/function call will be accepted
by any C compiler out there? I doubt that even gcc will accept this.
well, im pretty sure gcc takes this, but ill change it anyway.
thanks.
And I can tell you that Visual C is happy to compile this if the file has
a .cpp ending but will bark for .c files ;-(.
Rolf Kalbermatter
Re: Whither fnt2bdf?
Alexandre Julliard wrote: Dan Kegel [EMAIL PROTECTED] writes: Does that mean Wine can natively handle .fnt fonts (which X libraries can't natively, I believe) as client side X fonts? My understanding is that FreeType can support bitmap fonts, but that it's not implemented in Wine yet; Huw can give you the details. Anyway most of the need for fnt2bdf was to convert the Windows standard fonts, and these are basically all TrueType now. I wonder whether people still want to run applications that are packaged with their own Windows bitmap fonts. I think I run into that periodically. It would be interesting to work out how to support those properly under Wine, even though they're obsolete. I suppose Wine would need some user-space app to manage these fonts, then? I guess we could have a font control panel at some point, but there isn't that much to manage anyway. As long as the font files are somewhere on the font path everything should just work. Since the average user can't deal with font paths, this little font control panel will be important. Maybe even required for wine1.0, who knows. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
Re: Whither fnt2bdf?
On Thu, Jan 23, 2003 at 10:21:12AM -0800, Alexandre Julliard wrote: Dan Kegel [EMAIL PROTECTED] writes: Does that mean Wine can natively handle .fnt fonts (which X libraries can't natively, I believe) as client side X fonts? My understanding is that FreeType can support bitmap fonts, but that it's not implemented in Wine yet; Huw can give you the details. Anyway most of the need for fnt2bdf was to convert the Windows standard fonts, and these are basically all TrueType now. Wine doesn't handle fnts quite yet. However I've just added the necessary functions to FreeType to enable Wine to get hold of all the information it needs and hopefully I'll get time to finish the Wine side of things soon. The fonts we're missing out on are System, FixedSys, Terminal, Courier, Small Fonts, MS Sans Serif and MS Serif (note there's also a Microsoft Sans Serif, but that's TrueType and should work already). There are also 3 'stroke' fonts called Modern, Roman and Script; FreeType doesn't support this format yet, but they're as ugly as hell so probably won't be missed. I suppose Wine would need some user-space app to manage these fonts, then? I guess we could have a font control panel at some point, but there isn't that much to manage anyway. As long as the font files are somewhere on the font path everything should just work. Right. We'll need to add support for using libfontconfig soon - that'll mean we don't have to set up a font path manually. Huw.
Re: App works almost perfectly, but one MDI screen won't draw
Mike Hearn wrote: So then it becomes a matter of figuring out where they should be generated. Yeah, that's the big that usually gets me :) Are they the sort of messages that should be generated by Wine or the app? By Wine. In general, I have found message bugs relatively straightforward to fix. What happens if the app doesn't call BeginPaint in a WM_PAINT handler. Is that an API violation, or are there reasons for it? MSDN had an explanation that seemed to suggest that in certain unusual circumstances you didn't need to call it, but I don't remember exactly what. Yea, I want to try to figure out the exceptions and add something to silence those messages. In this case, they appear to be a red herring. Looking at SPY++, the WM_NCPAINT and WM_ERASEBACKGROUND messages should have been sent prior to posting the WM_PAINT message. But more studying to come. It is a bit of a mystery to me why the call is bad; it is a call directly from the app. I wonder if the wrong function is being called for some reason. But that is something I will look into later. How common is it for apps to actually make bad API calls? QuickTime seemed to do that, is it rare or not? I don't really know. From the looks of this one, I cannot believe the app was written this incorrectly, so the bug must be something more subtle. I think I am going to have to resort to disassembling the small portion of the app that makes the call to figure out what is happening. Fortunately, the location shows up just fine in winedbg when it crashes, so that makes things easier.
Re: Whither fnt2bdf?
Huw Davies wrote: Does that mean Wine can natively handle .fnt fonts (which X libraries can't natively, I believe) as client side X fonts? My understanding is that FreeType can support bitmap fonts, but that it's not implemented in Wine yet; Huw can give you the details. Anyway most of the need for fnt2bdf was to convert the Windows standard fonts, and these are basically all TrueType now. Wine doesn't handle fnts quite yet. However I've just added the necessary functions to FreeType to enable Wine to get hold of all the information it needs and hopefully I'll get time to finish the Wine side of things soon. Woo-hoo! I guess we could have a font control panel at some point, but there isn't that much to manage anyway. As long as the font files are somewhere on the font path everything should just work. Right. We'll need to add support for using libfontconfig soon - that'll mean we don't have to set up a font path manually. Yes! libfontconfig support in Wine will be wonderful, it'll mean that any fonts the user adds in the control panel in Linux will automatically be available in Wine, and possibly vice-versa (!). - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
Sacrifice demo sound.dll
Hi all! I've tried the Sacrifice demo and it complains about sound.dll. Indeed it uses its own 32-bit sound.dll which lies in its directory. Apparently the dll seems to conflict with our 16-bit windows sound.dll I've joined a small log. I tried to add a sound entry in the [DllOverrides] section in the config file to force the native to be loaded first but that does not help. Any idea ? Thanks in advance. Christian. trace:module:GetModuleFileNameA F:\Sacrifice\Sacrifice.exe trace:module:MODULE_GetLoadOrder looking for F:\Sacrifice\sound.dll trace:module:GetModuleFileNameA F:\Sacrifice\Sacrifice.exe trace:module:open_app_key searching 'F:\Sacrifice\sound' in AppDefaults\Sacrifice.exe\DllOverrides trace:module:MODULE_GetLoadOrder got hardcoded default b,n for F:\\Sacrifice\\sound.dll trace:module:MODULE_LoadLibraryExA Trying built-in 'F:\Sacrifice\sound.dll' err:module:BUILTIN32_LoadLibraryExA loaded .so but dll sound.dll still not found - 16-bit dll or version conflict. warn:module:MODULE_LoadLibraryExA Loading of builtin DLL F:\Sacrifice\sound.dll failed (error 193). warn:module:MODULE_LoadLibraryExA Failed to load module 'F:\Sacrifice\sound.dll'; error=193
Re: RtlpWaitForCriticalSection?
Dan Kegel wrote: Christian Costa wrote: All the static CRITICAL_SECTIONs in Wine DLLs have names. The only unnamed ones are those that are initialized at runtime. It is what I said! No? :-) I guess I missed part of what you said, sorry. To give these a name, we'd either have to convert them to static initialization, or change InitializeCriticalSection to somehow generate a name from the caller's program counter. What about writing a new macro that initializes the name in the CRITICAL_SECTION struct. . InitializeCriticalSection(crit); SET_CRITICAL_SECTION_NAME(crit,name); Hmm. Seems to be the Wine DLL sources should try to avoid stuff that doesn't compile under Windows. That said, we could provide a header file that defined SET_CRITICAL_SECTION_NAME in Windows, and made it do nothing. If CRITICAL_SECTION_INIT compiles why not SET_CRITICAL_SECTION_NAME ? Furthermore, we could be real sneaky, and make that header file turn InitializeCriticalSection into a macro that called the real InitializeCriticalSection, then called SET_CRITICAL_SECTION_NAME, so no source changes would be needed to get the name in there, maybe. In that case our InitializeCriticalSection macro would have one more parameter (the name) than the real function. I personaly think this will confused people more than an optional (but preferable for debugging) macro. Christian.
Re: Windows API database
David Miller wrote: I would be interested in knowing more about the goals of this project. Don't consider me officially working on such a thing just yet. I have no real perl experience, but would like to learn. First I'd like to know more about what I'm up against. I'm not sure what project you're talking about, but I can make a few wild guesses... 1. Is there a specific set of dll's and exe's we want included in the database or does it need to scan and gather a list of all dll and exe files? That would suggest a clean OS install is necessary. Sure, a clean OS install is probably good. Many of the APIs exposed by even the clean OS install may not be needed if no application calls them, but it's hard to know that in advance. We might want to also scan applications to see what APIs they actually use, but that's real hard. 2. What information should be in the database? (OS ver, name of dll or exe, name of imported dll, APIs and whether they are imported or exported, etc.) Maybe use the same format as we use in the souce tree? e.g. scanning advapi32.dll should produce something that looks very much like http://cvs.winehq.com/cvsweb/wine/dlls/advapi32/advapi32.spec?rev=1.32 3. Will a single MySQL table do or does it need to be a relational database with multiple tables? IMHO no SQL is needed. The database should be plain text files checked into CVS. 4. Anything else you can tell me about this task? Compare with other standards which provide lists of API's, for example: http://www.linuxbase.org/spec/ http://www.unix.org/ http://www.ecma.ch/ecma1/STAND/ECMA-234.HTM to get some ideas. Of course, these are formatted all fancily, and cover different operating systems, but the goal is similar: to provide an authoritative list of APIs. Ideally, the result could be part of a submission to a standards body. (See also http://www.kegel.com/remedy/remedy2.html#fix.info ) - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
Re: RtlpWaitForCriticalSection?
Christian Costa wrote: Hmm. Seems to be the Wine DLL sources should try to avoid stuff that doesn't compile under Windows. That said, we could provide a header file that defined SET_CRITICAL_SECTION_NAME in Windows, and made it do nothing. If CRITICAL_SECTION_INIT compiles why not SET_CRITICAL_SECTION_NAME ? It doesn't compile under MSVC, I bet. But I haven't tried it, perhaps it does. Furthermore, we could be real sneaky, and make that header file turn InitializeCriticalSection into a macro that called the real InitializeCriticalSection, then called SET_CRITICAL_SECTION_NAME, so no source changes would be needed to get the name in there, maybe. In that case our InitializeCriticalSection macro would have one more parameter (the name) than the real function. Nope. It wouldn't. We would construct the name from __FILE__ and __LINE__. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
Re: dos4gw stub exec failed
On Wednesday 22 January 2003 19:16, Jukka Heinonen wrote: If you get those games to work under dos32a you will probably find out that Wine SVGA support is lacking. That is something I have considered to fix if I can find the time to do it. Hmm, I considered doing VGA and SVGA stuff for some time but I lack meaningful doc(about vga and svga stuff) and a place to start. If you could provide both maybe I could do some bits of it. Ciao Enrico [EMAIL PROTECTED]
Re: RtlpWaitForCriticalSection?
Dan Kegel wrote: Christian Costa wrote: Hmm. Seems to be the Wine DLL sources should try to avoid stuff that doesn't compile under Windows. That said, we could provide a header file that defined SET_CRITICAL_SECTION_NAME in Windows, and made it do nothing. If CRITICAL_SECTION_INIT compiles why not SET_CRITICAL_SECTION_NAME ? It doesn't compile under MSVC, I bet. But I haven't tried it, perhaps it does. Furthermore, we could be real sneaky, and make that header file turn InitializeCriticalSection into a macro that called the real InitializeCriticalSection, then called SET_CRITICAL_SECTION_NAME, so no source changes would be needed to get the name in there, maybe. In that case our InitializeCriticalSection macro would have one more parameter (the name) than the real function. Nope. It wouldn't. We would construct the name from __FILE__ and __LINE__. - Dan So you suggest to not set a name ? What happened if there are two or more critical sections in the same source file, a file that has changed. Having no name make things harder to distinguish them in a log. OK, it is a little paranoid. :-) Christian
Re: Sacrifice demo sound.dll
Christian Costa wrote: Hi all! I've tried the Sacrifice demo and it complains about sound.dll. Indeed it uses its own 32-bit sound.dll which lies in its directory. Apparently the dll seems to conflict with our 16-bit windows sound.dll I've joined a small log. I tried to add a sound entry in the [DllOverrides] section in the config file to force the native to be loaded first but that does not help. Any idea ? Thanks in advance. Christian. trace:module:GetModuleFileNameA F:\Sacrifice\Sacrifice.exe trace:module:MODULE_GetLoadOrder looking for F:\Sacrifice\sound.dll trace:module:GetModuleFileNameA F:\Sacrifice\Sacrifice.exe trace:module:open_app_key searching 'F:\Sacrifice\sound' in AppDefaults\Sacrifice.exe\DllOverrides trace:module:MODULE_GetLoadOrder got hardcoded default b,n for F:\\Sacrifice\\sound.dll trace:module:MODULE_LoadLibraryExA Trying built-in 'F:\Sacrifice\sound.dll' err:module:BUILTIN32_LoadLibraryExA loaded .so but dll sound.dll still not found - 16-bit dll or version conflict. warn:module:MODULE_LoadLibraryExA Loading of builtin DLL F:\Sacrifice\sound.dll failed (error 193). warn:module:MODULE_LoadLibraryExA Failed to load module 'F:\Sacrifice\sound.dll'; error=193 Setting an AppDefault does help, if you give the full path. /Johan Gill, [EMAIL PROTECTED]
Re: RtlpWaitForCriticalSection?
Dan Kegel wrote: Christian Costa wrote: In that case our InitializeCriticalSection macro would have one more parameter (the name) than the real function. Nope. It wouldn't. We would construct the name from __FILE__ and __LINE__. So you suggest to not set a name ? What happened if there are two or more critical sections in the same source file, a file that has changed. Having no name make things harder to distinguish them in a log. OK, it is a little paranoid. :-) It would have the filename and line number as the name... that would be enough to let you distinguish between locks. And it even lets you know if you have the right sources, 'cause otherwise the line number won't match :-) The chief advantage, though, is that it gets us automatically generated names with no source changes, at least for static calls. (Won't help with ones done via GetProcAddr, but that's ok.) Is there any calls done via GetProcAddr in wine sources ? I guess not. In this case, CRITICAL_SECTION_INIT should be update, at least to have the line number. :-) So, if everyone agree. That 's fine for me. :-) Would you submit a patch that handle that ? - Dan
Re: Windows API database
Oh, ok. Cross-referencing DLL imports and exports. Yeah, that sounds like a job for a simple perl script. All you need to output is DLL name and what DLLs it imports from. Just generate a flat text file for starters, then later postprocess that into an ascii tree or graph. It's going to be a messy little graph, I bet. - Dan Dave Miller wrote: The project I am considering is mentioned on the contributing page here: http://fgouget.free.fr/wine/contributing-en.shtml. (Build a database of Windows APIs and dependencies) It sounds like less work to simply create text files containing the imports and exports, although I think the point is partially for the results to be easily cross referenced by developers. Hence the suggestion of a database of some kind. I've considered scanning applications as well. If I have any success with the Windows APIs I may try tackling that at some point as well. - Original Message - From: Dan Kegel [EMAIL PROTECTED] To: David Miller [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, January 23, 2003 3:38 PM Subject: Re: Windows API database David Miller wrote: I would be interested in knowing more about the goals of this project. Don't consider me officially working on such a thing just yet. I have no real perl experience, but would like to learn. First I'd like to know more about what I'm up against. I'm not sure what project you're talking about, but I can make a few wild guesses... 1. Is there a specific set of dll's and exe's we want included in the database or does it need to scan and gather a list of all dll and exe files? That would suggest a clean OS install is necessary. Sure, a clean OS install is probably good. Many of the APIs exposed by even the clean OS install may not be needed if no application calls them, but it's hard to know that in advance. We might want to also scan applications to see what APIs they actually use, but that's real hard. 2. What information should be in the database? (OS ver, name of dll or exe, name of imported dll, APIs and whether they are imported or exported, etc.) Maybe use the same format as we use in the souce tree? e.g. scanning advapi32.dll should produce something that looks very much like http://cvs.winehq.com/cvsweb/wine/dlls/advapi32/advapi32.spec?rev=1.32 3. Will a single MySQL table do or does it need to be a relational database with multiple tables? IMHO no SQL is needed. The database should be plain text files checked into CVS. 4. Anything else you can tell me about this task? Compare with other standards which provide lists of API's, for example: http://www.linuxbase.org/spec/ http://www.unix.org/ http://www.ecma.ch/ecma1/STAND/ECMA-234.HTM to get some ideas. Of course, these are formatted all fancily, and cover different operating systems, but the goal is similar: to provide an authoritative list of APIs. Ideally, the result could be part of a submission to a standards body. (See also http://www.kegel.com/remedy/remedy2.html#fix.info ) - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
Re: RtlpWaitForCriticalSection?
Alexandre Julliard wrote: Christian Costa [EMAIL PROTECTED] writes: In this case, CRITICAL_SECTION_INIT should be update, at least to have the line number. :-) So, if everyone agree. That 's fine for me. :-) Would you submit a patch that handle that ? As discussed recently, CRITICAL_SECTION_INIT should be removed since it's not in the standard headers. So you probably don't want to start changing it now... OK, maybe I'll make this patch remove CRITICAL_SECTION_INIT, too. Thanks! - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
Re: RtlpWaitForCriticalSection?
Christian Costa [EMAIL PROTECTED] writes: In this case, CRITICAL_SECTION_INIT should be update, at least to have the line number. :-) So, if everyone agree. That 's fine for me. :-) Would you submit a patch that handle that ? As discussed recently, CRITICAL_SECTION_INIT should be removed since it's not in the standard headers. So you probably don't want to start changing it now... -- Alexandre Julliard [EMAIL PROTECTED]
Re: Packagers Guide Update #5
Hi Tom, On Thu, 23 Jan 2003, Tom Wickline wrote: [...] Index: documentation/packaging.sgml === RCS file: /opt/cvs-commit/wine/documentation/packaging.sgml,v retrieving revision 1.12 diff -u -r1.12 packaging.sgml --- documentation/packaging.sgml 24 Jan 2003 00:49:05 - 1.12 +++ documentation/packaging.sgml 24 Jan 2003 04:24:53 - @@ -1512,6 +1512,8 @@ ;ShowDotFiles = 1 ShellLinker = wineshelllink +# wineconf Hmmm, anything of the form xxx is a tag sgml so the above will not work very well. You should use: # lt;wineconfgt; I noticed another problem. This section is in a simple para tag. That means that linefeeds are not significant and everything can be bunched together. I think what's needed is to replace the para tags with screen tags. With these two changes it should work great. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Dieu dit: M-x Lumière. Et la lumière fut.
Re: Doccumetation issue: The Service Thread Does it exist?
On Thu, 23 Jan 2003, Robert North wrote: This concerns the documentation on thw www.winehq.com website, if it's out of date, then this post may be irrelevant. In the Wine Developer's Guide In Section 8.1.4, The Service thread Says there exists a service thread, that is implemented in: scheduler/services.c. It also says this thread is used to support the X11 driver's event loop. Firstly, I cannot find the scheduler/services.c file. Yeah, the service thread is no more. Everything it did is now done more or less synchronously, in the thread that needs the functionality, instead of having another thread do it (or sometimes by shifting more functionality into the wineserver). Secondly from my reading of the x11drv code, the X11 event loop is serviced for every call of to X11DRV_MsgWaitForMultipleObjectsEx, which is inturn called by MsgWaitForMultipleObjectsEx, and GetMessage. Therefore, whichever thread is active will service the X11 event queue. Almost; each thread has its own display and X11 event queue now, where the messages that this thread is interested in gets posted. That way there's no need for a process-wide queue or an independent service thread to process it, instead the thread can check its own thread-specific queue whenever it's appropriate for it to do so. It also appears, because each thread has it's own XDisplay object that messages created by a X11 window will only be picked up in the thread that created the window. That's right. It even fits the Win32 model better, as there, messages to a window are always sent to the thread that created the window.
Re: Whither fnt2bdf?
I guess we could have a font control panel at some point, but there isn't that much to manage anyway. As long as the font files are somewhere on the font path everything should just work. Right. We'll need to add support for using libfontconfig soon - that'll mean we don't have to set up a font path manually. Yes! libfontconfig support in Wine will be wonderful, it'll mean that any fonts the user adds in the control panel in Linux will automatically be available in Wine, and possibly vice-versa (!). This tool could also be used to just see the installed fonts and check if they work. Maybe like that the error messages of not finding fonts go down as you can check first if the font is really there and working or not. bye Fabi
