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

Re: [WINEALSA] Add Midi IN support

by Marcus Meissner

On Fri, Jan 09, 2004 at 12:03:10PM +0000, Mike Hearn wrote: > On Thu, 08 Jan 2004 16:46:53 -0800, Alexandre Julliard wrote: > > You should not use alloca in Wine, it's not portable enough. > > Could we take the glib implementation of alloca and stick it into > libwine_port? IIRC in glib it uses the system implementation unless it's > not good enough or missing, in which case it provides an emulation. And I always thought alloca was a compiler builtin. But why not just use HeapAlloc() ? Ciao, Marcus

Jan. 9, 2004

Re: [WINEALSA] Add Midi IN support

by Mike Hearn

On Thu, 08 Jan 2004 16:46:53 -0800, Alexandre Julliard wrote: > You should not use alloca in Wine, it's not portable enough. Could we take the glib implementation of alloca and stick it into libwine_port? IIRC in glib it uses the system implementation unless it's not good enough or missing, in which case it provides an emulation.

Jan. 9, 2004

Re: shell shorcuts

by Subhobroto Sinha

One day thus spake Martin Fuchs: >I am working on the ReactOS Explorer, which uses Wine's shell32 implementation. >We already have made many bugfixes and estensions to the shell link and other >shell32 code. One of those extensions is the implementation of control panel in >shell namespace I am already aware of that (thanks to Steve), and I would appreciate if someone could send me the changes/patches to shell32 by the ReactOS team (even if the source does not compile) so I can have a look.. Perhaps you can send me a zip of the ReactOS shell32 directory (keep the makefiles and .defs out - send just the real source :) ) ? That will be nice >Well, I think it's because it has been defined wrong. I am currently using this >definition: >#define SCF_UNICODE 0x80 (instead of 0x1000) >This is at least compatible to links of WIN95 (ANSI strings) and WIN XP (UTF16 strings). >I did not yet test any other operating system versions. With this corrected >defintion and a few more extensions Stream_LoadString() works pretty well >on ReactOS. Hmm..., I KNOW 'SCF_UNICODE' is NOT 0x1000 in the first place, but why do you say it's 0x80 ? Going by the copyrights, Marcus Meissner and Juergen Schmied did the initial job, and perhaps one of them put this value. I don't know about Juergen, but I have tremendous faith in Marcus (I use SuSE you see ;) ), and there MUST have been some reason why 'SCF_UNICODE' got the value 0x1000, although it seems to be wrong ! Hence, please consolidate your assigning it 0x80 with some examples/hexedits so that I can answer when I get grilled ;) However, I think that we should ALL handle strings as Unicode internally, and convert to ANSI when required, and NOT the other way round. Hence, we will be compatible with Win98/ME/2K/XP, as that's what M$ does... If you see my code carefully, you will notice that EVERYTHING is handled as Unicode internally. The flag 'SCF_UNICODE' is used to test the bit mask and determine if the .lnk is serialized in Unicode or not... I am pretty sure that Windows >95 handle EVERYTHING in Unicode, and thus a wrong value of 'SCF_UNICODE' will ONLY mess up Win95 .lnk files ! If you can consolidate your defining 'SCF_UNICODE' as 0x80, I will ONLY be too happy to incorporate that, else those still using Win95 (?) may suffer, as Win95 handles strings as ANSI and not Unicode... Will send Alexandre my patch within the next few days as no one has objected to it being messy, so take the last chance ;) BTW Martin, great work with ROSExplorer, keep at it, and one day WINE will have a complete Desktop with shell namespaces ! Regards Subhobroto Sinha

Jan. 9, 2004

Re: deadlock on some X environments

by Ferenc Wagner

Khm. Now I've got X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 15 (X_QueryTree) Resource id in failed request: 0x4003ac Serial number of failed request: 258 Current serial number in output stream: 258 err:ntdll:RtlpWaitForCriticalSection section 0x40ac0700 "../../../src/dlls/x11drv/x11drv_main.c: X11DRV_CritSection" wait timed out in thread 000a, blocked by 0009, retrying (60 sec) wine: Unhandled exception (thread 000a), starting debugger... err:win32:_EnterSysLevel (0x408b0b00, level 2): Holding 0x4096f340, level 3. Expect deadlock! err:win32:_EnterSysLevel (0x408b0b00, level 2): Holding 0x4096f340, level 3. Expect deadlock! err:win32:_EnterSysLevel (0x408b0b00, level 2): Holding 0x4096f340, level 3. Expect deadlock! err:win32:_EnterSysLevel (0x408b0b00, level 2): Holding 0x4096f340, level 3. Expect deadlock! err:win32:_EnterSysLevel (0x408b0b00, level 2): Holding 0x4096f340, level 3. Expect deadlock! err:ntdll:RtlpWaitForCriticalSection section 0x40ac0700 "../../../src/dlls/x11drv/x11drv_main.c: X11DRV_CritSection" wait timed out in thread 000a, blocked by 0009, retrying (60 sec) err:seh:EXC_DefaultHandling Unhandled exception code c0000194 flags 0 addr 0x401a56e0 But I can't reproduce it. Feri.

Jan. 9, 2004

Re: uxtheme and unicode INI files

by Alexandre Julliard

Kevin Koltzau <kevin(a)plop.org> writes: > Or would it be preferable that I stick with the way windows does it > (by duplicating the ini file loading within uxtheme) and do all the > processing in memory? Yes that would be much better. Parsing a .ini file is not hard, and in the end it's probably less code than what you would have to do to reuse the existing profile parser. -- Alexandre Julliard julliard(a)winehq.com

Jan. 9, 2004

Re: Allow runtime control of the number of X11 fonts

by Alexandre Julliard

Bill Medland <billmedland(a)mercuryspeed.com> writes: > No idea. > > Can you pass something to XListFonts to say "no maximum"? I guess INT_MAX would work, though I haven't tried it. If it doesn't work we can keep the current limit, but then double it and retry until we get all fonts. > It seemed that a trace message that told the client to change a compile-time > constant wasn't much help. So I made the change. That was ages ago. (It > didn't actually help; there were other issues; I don't remember). > > Anyway, if you don't want it then throw it away. Well, if you encountered the problem we might as well fix it. And I agree the message is pretty much useless, we should do better than that. -- Alexandre Julliard julliard(a)winehq.com

Jan. 9, 2004

Re: Allow runtime control of the number of X11 fonts

by Bill Medland

On January 8, 2004 04:45 pm, Alexandre Julliard wrote: > Bill Medland <billmedland(a)mercuryspeed.com> writes: > > Bill Medland (billmedland(a)mercuryspeed.com) > > Allow runtime increase in the maximum number of fonts processed. > > Do we really need a config parameter for that? Actually, do we really > need a limit at all? No idea. Can you pass something to XListFonts to say "no maximum"? I had a client who actually (seemed to) fell over that limit (using x terminals etc.). It seemed that a trace message that told the client to change a compile-time constant wasn't much help. So I made the change. That was ages ago. (It didn't actually help; there were other issues; I don't remember). Anyway, if you don't want it then throw it away. -- Bill Medland mailto:billmedland(a)mercuryspeed.com http://webhome.idirect.com/~kbmed

Jan. 9, 2004

uxtheme and unicode INI files

by Kevin Koltzau

I've submitted this patch once with no luck, but I've got a question that may affect my need to use this patch (or one similar) Msstyles store a few INI files within the style that define various properties of the theme. Windows duplicates all the .ini file processing within uxtheme.dll, I would prefer to not do this (hence this patch) however, what are the feelings of temp files being generated from resources in a style while its being loaded (which would be needed to use the GetPrivateProfile* family of functions)? Or would it be preferable that I stick with the way windows does it (by duplicating the ini file loading within uxtheme) and do all the processing in memory?

Jan. 9, 2004

Re: deadlock on some X environments

by Ferenc Wagner

Alexandre Julliard <julliard(a)winehq.org> writes: > OK, there's a known locking problem in Xrender in Xfree > 4.2, so that's why (in fact there are many Xrender bugs in > that version, you may want to upgrade). The terminals aren't mine, and as you may already know I'm using 4.1, which is flawless, so I'm safe. > Anyway, we'll probably have to get rid of XInitThreads for > now, and leave Linux threading a few more years to catch > up. After all Windows has only had working threads for > what, 10 years now. Sigh... Smelling some sarcasm here... right? >> Btw, is something wrong with my LoadStringA tests? > > I'll move it back up in the queue. Thanks, I've seen the commit. Feri. :)

Jan. 9, 2004

Re: [WINEALSA] Add Midi IN support

by Alexandre Julliard

Christian Costa <titan.costa(a)wanadoo.fr> writes: > + int npfd; > + struct pollfd *pfd; > + > + npfd = snd_seq_poll_descriptors_count(midiSeq, POLLIN); > + pfd = (struct pollfd *)alloca(npfd * sizeof(struct pollfd)); You should not use alloca in Wine, it's not portable enough. -- Alexandre Julliard julliard(a)winehq.com

Jan. 9, 2004

Re: Allow runtime control of the number of X11 fonts

by Alexandre Julliard

Bill Medland <billmedland(a)mercuryspeed.com> writes: > Bill Medland (billmedland(a)mercuryspeed.com) > Allow runtime increase in the maximum number of fonts processed. Do we really need a config parameter for that? Actually, do we really need a limit at all? -- Alexandre Julliard julliard(a)winehq.com

Jan. 9, 2004

Re: deadlock on some X environments

by Uwe Bonnes

>>>>> "Ferenc" == Ferenc Wagner <wferi(a)afavant.elte.hu> writes: Ferenc> Ferenc Wagner <wferi(a)afavant.elte.hu> writes: >> Alexandre Julliard <julliard(a)winehq.org> writes: >> >>> What X version are you running? >> XFree86 4.2.0. Ferenc> This is the server version on the terminal. Wine is linked with Ferenc> xlibs_4.1.0-16woody1. Ouch! That sounds like reporting a bug win wine-1999xxxx ... Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Jan. 9, 2004

Re: deadlock on some X environments

by Ferenc Wagner

Ferenc Wagner <wferi(a)afavant.elte.hu> writes: > Alexandre Julliard <julliard(a)winehq.org> writes: > >> What X version are you running? > > XFree86 4.2.0. This is the server version on the terminal. Wine is linked with xlibs_4.1.0-16woody1.

Jan. 8, 2004

Re: deadlock on some X environments

by Alexandre Julliard

Ferenc Wagner <wferi(a)afavant.elte.hu> writes: > XFree86 4.2.0. Tell me if you are interested in further > logs or whatever. OK, there's a known locking problem in Xrender in Xfree 4.2, so that's why (in fact there are many Xrender bugs in that version, you may want to upgrade). Anyway, we'll probably have to get rid of XInitThreads for now, and leave Linux threading a few more years to catch up. After all Windows has only had working threads for what, 10 years now. Sigh... > Btw, is something wrong with > my LoadStringA tests? They pass here... No, it just got drowned out by other patches. I'll move it back up in the queue. -- Alexandre Julliard julliard(a)winehq.com

Jan. 8, 2004

Re: Broken Mandrake packages

by Mike Hearn

On Thu, 2004-01-08 at 22:44, Alexandre Julliard wrote: > Well, it could maybe be added as an option, but I don't think it would > work in all cases, since it will necessarily add different constraints > on the layout (for instance you need to hardcode that the dlls are in > ../lib/wine relative to the binary, which may or may not be what you > want). Sure, that's understood. The idea of this is purely that for programs that follow the FHS and have a standard layout we can easily make the binary relocatable. It wouldn't replace the existing search mechanisms. thanks -mike

Jan. 8, 2004

Re: Broken Mandrake packages

by Alexandre Julliard

Mike Hearn <mike(a)theoretic.com> writes: > Would you accept a patch to use this code on Linux systems to figure out > where to load the DLLs from? That way Wine can be installed to any > prefix and it works automatically, no need for wrapper scripts or > anything like that. Well, it could maybe be added as an option, but I don't think it would work in all cases, since it will necessarily add different constraints on the layout (for instance you need to hardcode that the dlls are in ../lib/wine relative to the binary, which may or may not be what you want). -- Alexandre Julliard julliard(a)winehq.com

Jan. 8, 2004

Re: reading relay log

by Jakob Eriksson

Ferenc Wagner wrote: > Hi, > >I feel rather stupid, but need help understanding this. I >managed to screw up winetest so that it runs into trouble. >The relay trace goes like (indented by examine-relay) > > I don't understand why it crashes... if it is any help here is a very simple program with two threads: http://vmlinux.org/jakov/uptime/ http://vmlinux.org/jakov/uptime/uptime.cpp http://vmlinux.org/jakov/uptime.zip Jakobi

Jan. 8, 2004

Re: deadlock on some X environments

by Ferenc Wagner

Alexandre Julliard <julliard(a)winehq.org> writes: > Ferenc Wagner <wferi(a)afavant.elte.hu> writes: > >> Making progress. The thing does not depend on time or >> weather, but instead on the terminal I'm using. Different X >> extensions, color depth, whatever. On --debugmsg +all logs > > Probably yet another Xlib locking bug, try commenting out the > XInitThreads call in x11drv_main.c to see if it makes a > difference. Yes, it does, the programs runs normally with that line commented out. > What X version are you running? XFree86 4.2.0. Tell me if you are interested in further logs or whatever. I will probably submit this code now that I know the error is elsewhere. Btw, is something wrong with my LoadStringA tests? They pass here... Feri.

Jan. 8, 2004

Re: Broken Mandrake packages

by Mike Hearn

On Thu, 2004-01-08 at 22:06, Alexandre Julliard wrote: > Actually there used to be a reason to do that, when dlls needed to be > in the Unix library path to get loaded properly. The default was to > add symlinks in /usr/lib, but it wasn't very clean to have a bunch of > dlls in there so it made sense for packages to put everything in > /usr/lib/wine instead and change ld.so.conf. However this is fixed > now, and today there's no reason to change the standard layout. While we're on the topic, it seems that Wine figures out where the dlls are either by using a compiled in macro or by read an environment variable. As part of my other project, we developed a small piece of C that reads /proc to determine the prefix of any given ELF object so it becomes possible to make binary relocatable Linux programs easily. Would you accept a patch to use this code on Linux systems to figure out where to load the DLLs from? That way Wine can be installed to any prefix and it works automatically, no need for wrapper scripts or anything like that. thanks -mike

Jan. 8, 2004

Re: dll name length (was: Windows dll replacement with Linux library)

by Dan Timis

Thanks. I will try it and tell you if it worked. It may take a couple of weeks since we are frantically preparing for a trade show, then going to the trade show. Dan On Thursday, January 8, 2004, at 07:38 AM, Dimitrie O. Paun wrote: > On January 6, 2004 10:04 pm, Dan Timis wrote: >> I finally figured out what my problem was. If the name of the library >> is "USBUtils" it works, if it is "USBDeviceUtils" it doesn't. >> Actually >> the max length I can use is 11 characters. That is probably 15 >> characters including ".dll" >> >> In my config file all filesystems are "win95" The version is "nt40" >> >> Is there any way to configure wine to support longer names? > > Eric is right, I've run into the same problem (with visual-mingw) > some time ago. He fixed it way back in Sep, 2004, with this patch: > > http://www.winehq.org/hypermail/wine-patches/2003/09/0174.html > > If you can't update to something newer, this patch is trivial > to backport in your tree. Please let us know if it helped. > > -- > Dimi. >

Jan. 8, 2004

Re: Broken Mandrake packages

by Alexandre Julliard

Mike Hearn <mike(a)theoretic.com> writes: > The problem with this is that it's different to the layout used by the > source installs, so giving tech support on #winehq etc becomes that much > harder. It seems to be different simply for the sake of being different. Actually there used to be a reason to do that, when dlls needed to be in the Unix library path to get loaded properly. The default was to add symlinks in /usr/lib, but it wasn't very clean to have a bunch of dlls in there so it made sense for packages to put everything in /usr/lib/wine instead and change ld.so.conf. However this is fixed now, and today there's no reason to change the standard layout. -- Alexandre Julliard julliard(a)winehq.com

Jan. 8, 2004

Re: Broken Mandrake packages

by Ivan Leo Murray-Smith

> These are all libraries that belong to /usr/lib. > All others (<dllname>.dll.so dlls must go to /usr/lib/wine/). > > libwine.so will look and find them in /usr/lib/wine/ by default when trying to load them. > > There is NO need to add /usr/lib/wine to ld.so.conf! OK, I'll change this in this months build. Ivan.

Jan. 8, 2004

Re: Broken Mandrake packages

by Mike Hearn

On Thu, 2004-01-08 at 21:10, Ivan Leo Murray-Smith wrote: > libs are in /usr/lib/wine and dlls are in /usr/lib/wine/dlls, not adding > /usr/lib/wine to ld.so.conf causes wine to fail, as it doesn't find > ntdll.dll.so. Works here. I only have /opt/wine/lib in my ld.so.conf, which doesn't contain any of the dlls. > There are alternative solutions, but this looks good to me, keeps > dirs tidy and has always worked. The problem with this is that it's different to the layout used by the source installs, so giving tech support on #winehq etc becomes that much harder. It seems to be different simply for the sake of being different.

Jan. 8, 2004

Re: Broken Mandrake packages

by Marcus Meissner

On Thu, Jan 08, 2004 at 10:10:59PM +0100, Ivan Leo Murray-Smith wrote: > > Hmm, OK. I don't know which this person was using. Why is /usr/lib/wine > > even added to ld.so.conf though, surely that isn't necessary? Only > > libwine needs to be in the linker path. > libs are in /usr/lib/wine and dlls are in /usr/lib/wine/dlls, not adding > /usr/lib/wine to ld.so.conf causes wine to fail, as it doesn't find > ntdll.dll.so. There are alternative solutions, but this looks good to me, keeps > dirs tidy and has always worked. No! rpm -ql wine ... /usr/lib/libwine.so /usr/lib/libwine.so.1 /usr/lib/libwine_unicode.so /usr/lib/libwine_unicode.so.1 /usr/lib/libwine_uuid.a These are all libraries that belong to /usr/lib. All others (<dllname>.dll.so dlls must go to /usr/lib/wine/). libwine.so will look and find them in /usr/lib/wine/ by default when trying to load them. There is NO need to add /usr/lib/wine to ld.so.conf! Ciao, Marcus

Jan. 8, 2004

Re: Broken Mandrake packages

by Ivan Leo Murray-Smith

> Hmm, OK. I don't know which this person was using. Why is /usr/lib/wine > even added to ld.so.conf though, surely that isn't necessary? Only > libwine needs to be in the linker path. libs are in /usr/lib/wine and dlls are in /usr/lib/wine/dlls, not adding /usr/lib/wine to ld.so.conf causes wine to fail, as it doesn't find ntdll.dll.so. There are alternative solutions, but this looks good to me, keeps dirs tidy and has always worked. Ivan.

Jan. 8, 2004