January 2003 - Wine-Devel - list.winehq.org

Re: Sacrifice demo & sound.dll

by Johan Gill

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, johane(a)lysator.liu.se

Jan. 23, 2003

Re: RtlpWaitForCriticalSection?

by Christian Costa

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.

Jan. 23, 2003

Sacrifice demo & sound.dll

by Christian Costa

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

Jan. 23, 2003

Windows API database

by David Miller

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. 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. 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.) 3. Will a single MySQL table do or does it need to be a relational database with multiple tables? 4. Anything else you can tell me about this task?

Jan. 23, 2003

Re: Whither fnt2bdf?

by Dan Kegel

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

Jan. 23, 2003

Re: Whither fnt2bdf?

by Dan Kegel

Alexandre Julliard wrote: > Dan Kegel <dank(a)kegel.com> 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

Jan. 23, 2003

Re: App works almost perfectly, but one MDI screen won't draw

by Duane Clark

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.

Jan. 23, 2003

Re: Whither fnt2bdf?

by Huw Davies

On Thu, Jan 23, 2003 at 10:21:12AM -0800, Alexandre Julliard wrote: > Dan Kegel <dank(a)kegel.com> 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.

Jan. 23, 2003

Re: Whither fnt2bdf?

by Alexandre Julliard

Dan Kegel <dank(a)kegel.com> 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 julliard(a)winehq.com

Jan. 23, 2003

Re: Doccumetation issue: "The Service Thread" Does it exist?

by Robert North

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.

Jan. 23, 2003