October 2001 - Wine-Devel - list.winehq.org

Re: usleep in winmm/wineoss audio

by Simon Britnell

--- eric pouech <eric.pouech(a)wanadoo.fr> wrote: > there may also some issues on SMP machines ? are you > both lucky SMP boxes users ? No SMP here. __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com

Oct. 24, 2001

Re: usleep in winmm/wineoss audio

by Simon Britnell

--- Francois Gouget <fgouget(a)free.fr> wrote: > Making Wine suid? No way! > And I don't have an SMP computer either (plus > that was on my laptop). > There has to be something else. I see that there's a ptrace change in the changelog for Linux 2.4.7 having to do with /proc and core dump permissions. Haven't grabbed the patch and looked into the issue yet. __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com

Oct. 24, 2001

Re: usleep in winmm/wineoss audio

by Francois Gouget

On Wed, 24 Oct 2001, eric pouech wrote: > > I have seen this error too. It seems it happens on Linux kernel 2.4.9 > > and up. When I switched back to 2.4.5 I stopped having problems. > there's been a security update on ptrace in 2.4.9 when attaching to > suid programs... Simon told me his wine wasn't suid, what about > yours ? there may also some issues on SMP machines ? are you both > lucky SMP boxes users ? Making Wine suid? No way! And I don't have an SMP computer either (plus that was on my laptop). There has to be something else. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Any sufficiently advanced Operating System is indistinguishable from Linux

Oct. 24, 2001

Re: usleep in winmm/wineoss audio

by eric pouech

> I have seen this error too. It seems it happens on Linux kernel 2.4.9 > and up. When I switched back to 2.4.5 I stopped having problems. there's been a security update on ptrace in 2.4.9 when attaching to suid programs... Simon told me his wine wasn't suid, what about yours ? there may also some issues on SMP machines ? are you both lucky SMP boxes users ? A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Oct. 24, 2001

Re: Shlwapi functions _29, _30, _31

by Alexandre Julliard

"Guy L. Albertelli" <galberte(a)neo.lrun.com> writes: > I assume that the differences may be due to revisions of the Unicode > standard, but that is an assumption only. Yes, there are some differences between our Unicode tables and the Windows ones. It shouldn't really matter, and if it does it's easy to fix. The important thing is to make sure everything uses the tables in libwine_unicode so that there is only one place to fix if necessary. -- Alexandre Julliard julliard(a)winehq.com

Oct. 24, 2001

Shlwapi functions _29, _30, _31

by Guy L. Albertelli

Alexandre, Thank you for simplifing these functions when you committed them. I thought you might want to know that they do act slightly differently from the versions in the native shlwapi.dll (version 5.50.4807.2300): _29 (iswspace) - extra TRUE for 0x1680, 0x202f _30 (iswblank) - missing TRUE for 0x3000 _31 (iswpunct) - missing TRUE for 0x00aa, 0x00b5, 0x00bb, 0x0192, 0x05ba - extra TRUE for 0x02df, 0x02ea-0x02ee, 0x0346-0x034e, 0x0361, 0x0488-0x0489, 0x058a, 0x0591-0x05a1, 0x05a3-0x05af, 0x05c4, 0x0653-0x0655 (+ probably many more - I stopped comparing here). I assume that the differences may be due to revisions of the Unicode standard, but that is an assumption only. Guy Albertelli <<galberte(a)neo.lrun.com>>

Oct. 24, 2001

Re: PATCH: revert version change

by Francois Gouget

On Tue, 23 Oct 2001, Marcus Meissner wrote: > Hi, > > There was following change to misc/version.c: > revision 1.44 > date: 2001/07/27 23:57:38; author: julliard; state: Exp; lines: +1 -1 > Bob Goodwin <goodie1(a)pacbell.net> > Fix the 16bit win95 version. > > This makes for instance InstallShield, that uses DOS3CALLs to check for win95, > report a Bad Windows Version. (Installer of Monkey Island 3) > > Reference wine-devel post is: > http://www.winehq.com/hypermail/wine-devel/2001/07/0085.html > > If there is a testprogram, I can still boot Windows 95... Ladislav Sladecek <lsla(a)post.cz> posted a program to check the 16bit version back in august: http://www.winehq.com/hypermail/wine-devel/2001/08/0275.html I think the revert is the right thing to do. And this is what I get on the Win95 computers I have access to. I also recently found that quite a few installers are not happy with 0x0304. I attached Ladislav's 16bit test application and also attached a application I wrote that dumps what the 32bit GetVersion and GetVersionEx return. Bob, how did you come up with 0x07000304? Was it from the Daggerfall application or from a windows computer? If the latter, then could you run the attached tests and report what the results? Here are the result of the tests I have done here: * Win95 (the original version): It does indeed return 0x5f03 in 16bit mode. The CSDVersion does not seem to match in 32bit mode: GetVersion: version = 0xc0000004 GetVersionInfoEx: size = 148 major = 4 minor = 0 build = 0x40003b6 platform = VER_PLATFORM_WIN32_WINDOWS CSDVersion= "" vs. "Win95" in Wine I don't know if this could cause problems. * Win98SE: Returns 0x5f03 in 16bit mode, like Wine. No problem in 16bit mode. In 32bit mode I get some discrepencies, probably because this is SE and not the original 98: GetVersion: version = 0xc0000a04 GetVersionInfoEx: size = 148 major = 4 minor = 10 build = 0x40a08ae vs. 0x40A07CE in Wine platform = VER_PLATFORM_WIN32_WINDOWS CSDVersion= " A " vs. "Win98" in Wine * NT4: Everything is fine. Tonight I hope to get results for Win2000 and WinXP. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ RFC 2549: ftp://ftp.isi.edu/in-notes/rfc2549.txt IP over Avian Carriers with Quality of Service

Oct. 24, 2001

Re: The big winsock patch

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > Make winsock.h and winsock2.h independent from the Unix headers > Make them compatible with both the Unix C headers and the MSVCRT > headers > Ensure compatibility with the Unix headers via the USE_WS_PREFIX macro > Add WINE_NOWINSOCK: prevents winsock.h from being included > from windows.h when defined > Add ws2tcpip.h, move definitions to the right header I don't like the WS_API preprocessor abuse. It would be much better to declare function prototypes and typedefs explicitly, even if it requires a bit more typing. Your solution makes it hard to find out what gets defined when, and will break tools that extract information from header files. -- Alexandre Julliard julliard(a)winehq.com

Oct. 23, 2001

Re: usleep in winmm/wineoss audio

by Francois Gouget

On Tue, 23 Oct 2001, Simon Britnell wrote: > > --- eric pouech <eric.pouech(a)wanadoo.fr> wrote: > > hmmm we should be able to attach to a waiting > > process (what was the error number you got when > trying > > to attach winedbg ?) > > error 5. This is the result of ptrace failing IIRC. I have seen this error too. It seems it happens on Linux kernel 2.4.9 and up. When I switched back to 2.4.5 I stopped having problems. Also I noticed that when winedbg failed to attach, gdb would fail to attach too. So I would say this does not look like a Wine bug, but more like a Linux kernel bug (or something that changed in an incompatible fashion (in a stable kernel)). -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ The software said it requires Win95 or better, so I installed Linux.

Oct. 23, 2001

Re: mediatype patch

by Ove Kaaven

On 23 Oct 2001, Alexandre Julliard wrote: > Ove Kaaven <ovehk(a)ping.uio.no> writes: > > > Save a disk file's media type in the server object. > > OK for the storing part, but why do you return it in the get_file_info > request? Shouldn't it rather be in something like get_mapping_info? Well, I considered that, but struct file is only defined in file.c, in mapping.c it's just an opaque structure that you can't dereference without getting undefined struct errors, so it was impossible to return such file info from get_mapping_info without changing (violating?) the current design in some way or adding ugliness. If design issues are at stake, I thought it'd be best to leave to you to do it your way.

Oct. 23, 2001

PATCH: add Win95 OSR2 to versions

by David Elliott

On 2001.10.23 13:55 Marcus Meissner wrote: > Hi, > > There was following change to misc/version.c: > revision 1.44 > date: 2001/07/27 23:57:38; author: julliard; state: Exp; lines: +1 > -1 > Bob Goodwin <goodie1(a)pacbell.net> > Fix the 16bit win95 version. > > This makes for instance InstallShield, that uses DOS3CALLs to check for > win95, > report a Bad Windows Version. (Installer of Monkey Island 3) > > Reference wine-devel post is: > http://www.winehq.com/hypermail/wine-devel/2001/07/0085.html > > If there is a testprogram, I can still boot Windows 95... > > Ciao, Marcus > > Changelog: > revert 16bit win95 version back to original value. Fixes > InstallShield installer version check. > Your changelog is incorrect.. That is actually the DOS version you are changing, not the Windows version. Furthermore, here is a patch to go along with this that implements Win95OSR2 version. I have had this in my tree for MONTHS but never submitted it. This is REQURIED for some programs because the DOS for OSR2 is 7.1 and the DOS for Win95 Gold (MSes term for the original relase) is 7.0. I think I added it specifically so I could run COMMAND.COM (well, at least get past incorrect DOS version). This goes true for all of the DOS utils from 95OSR2. Honestly, Win95OSR2 should have been called Windows 96 and released as an actual product, it is completely different from original win95 in many core areas (But not in any UI ways, hence MSes logic of well, nobody will notice the difference by looking at it, better keep it as the same product). Changelog: Add Windows 95 OSR2 version info -Dave P.S. Sorry about the extra .txt extension, seems that Balsa uses it to determine whether the file is application/octet-stream or text/plain and I wanted it to be text/plain (will figure this out later).

Oct. 23, 2001

Re: error at winelib program

by David Elliott

On 2001.10.23 14:34 Guilherme Kunz wrote: > Hi, > > All programs was compiled with winemaker. > > $ ./dlg32 > Segmentation fault (core dumped) > > $ gdb dlg32 core > GNU gdb 5.0 > .... > Core was generated by `./dlg32'. > Program terminated with signal 11, Segmentation fault. > Reading symbols from /usr/local/lib/libntdll.so...Segmentation fault > (core > dumped) > > $ winedbg dlg32 > Console: Making console complex (creating an xterm)... > xterm: unable to open font "vga", trying "fixed".... > passed master doesn't match slave name > > I am using: > gcc 2.96 > kernel 2.2.19 > mfc 4.2 compiled > wine by CVS 20011023 > > Any idea ?? What is the problem with winedbg ?? and gdb ?? i already had > tried with gcc 2.95 !! > Thank You Was this a clean compile of Wine or a CVS update? Have you changed other system configurations between compiling wine (i.e. upgraded the libc or other library)? If so you should try a make distclean (in any rate be sure config.cache is gone). Also, GCC 2.96 has issues. It is a great version of GCC if and only if you are sure you have the latest release of it from Red Hat. The first 2.96 had some major, major problems. The later releases from Red Hat are plenty good enough to compile the kernel (well, 2.4.x anyway). Although from the looks of it if you have 2.2.19 I am assuming that is the redhat release of that so I am assuming you also would have upgraded gcc. Also note that I think RH has released glibc 2.2.4 for ALL RH 7.x platforms. Upgrade all of this stuff, make distclean, and then ./configure ; make depend && make. Also, have you tried debugging a simpler case (i.e. add a NULL pointer dereference at various places in the wine init code (i.e. before it sets up its SIGSEGV handler for winedbg, since that seems to be what is going on here). There was also an issue with debugmsgs sometimes causing a coredump a few days ago which has since been fixed. -Dave

Oct. 23, 2001

Re: usleep in winmm/wineoss audio

by Simon Britnell

--- eric pouech <eric.pouech(a)wanadoo.fr> wrote: > hmmm we should be able to attach to a waiting > process (what was the error number you got when trying > to attach winedbg ?) error 5. This is the result of ptrace failing IIRC. I had previously been ferreting around in winedbg trying to implement debugmsg, which appears in the help, but isn't in dbg.y or debug.l My first attempt was less than stellar and I found other ways to attack the problem. __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com

Oct. 23, 2001

Re: usleep in winmm/wineoss audio

by Simon Britnell

--- eric pouech <eric.pouech(a)wanadoo.fr> wrote: > ok, so making the wavehdr playback synchronous > seems to trigger this bug... It seems that way. I'll investigate further this PM. > > some prior point in the execution. Any tips for > > rapid location of where it's being stored? > 1/ use a bt in winedbg to get back (or in some > calls) where the problem occured Yes, the bt is showing me code in homeworld.exe, which I've disassembled. The offending is a rep stosl to an address recovered from the heap immediately before use. The address being recovered is 0x0, hence the exception. There are no system calls immediately before it, and I'll need a large amount of time to pick through all the jumps in the preceeding code to find where that value is stored, I've explored the immediate 0x200 bytes of opcodes without sighting a call and 0x100 bytes or so of the callers code. I'm intending to pick through it some more tonight. > 2/ run with -debugmsg +relay to get the return values > from some calls (but it is likely that it'll interfere with > your program, as the -debugmsg +wave does) I'll try this with the synchronous wodWrite patch too. __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com

Oct. 23, 2001

ok.. narrowed down problems with solaris...

by Roger Fujii

after a whole bunch of head banging, I finally found out what is causing wine to crash (though I don't know what the fix is, but I figure I should ask first before doing more head banging. It turns out there are strange things happening in two places. The first problem is that it fails to work when compiled with the XFree86 (4.1.0) includes/libraries, but works if you compile/link against the openwindows libraries (or, at least, it works HERE). Note that the X server that is running is 4.1.0. I suppose this might be a threading issue (given how notoriously unsafe X is for multitheading). The second problem is that I could only get it working with the openwindows libraries if I truncate my font paths. So it looks like something goes awry when you have a LOT of fonts in the font path. When I started wine up with only 2 font dirs in my fontpath, it came up fine. My initial guess would be something to do with malloc/sbrk and all the mapping that is done with the dlls, but that's pure speculation on my part. Any comments? -r -- Roger Fujii <rmf(a)lookhere.com> Underemployed, and trying to keep it that way....

Oct. 23, 2001

Re: usleep in winmm/wineoss audio

by eric pouech

Simon Britnell wrote: > > --- eric pouech <eric.pouech(a)wanadoo.fr> wrote: > > after, rereading my old code, there's nothing wrong > > (at first glance) here some invocations (like close, > > reset) need to be synchronous > > (the calling thread blocks until the rendering > > thread is done with the message), some others (like > > adding a wavehdr for play back) > > are asynchronous, hence the difference > > I added a WaitForSingleObject late last PM as an > experiment. The results were ... interesting. > > The first thing I noticed was that my problem > attaching to the process went away, ie. winedbg > started to work. hmmm we should be able to attach to a waiting process (what was the error number you got when trying to attach winedbg ?) > The second thing that happened was > that the problem I experience went from being > intermittant to constant and now also invariably > throws a page fault exception (in the same place it > intermittantly threw an exception). ok, so making the wavehdr playback synchronous seems to trigger this bug... > Tracing back from > that page fault is proving difficult as the page fault > occurs with a value that's been stored on the heap at > some prior point in the execution. Any tips for rapid > location of where it's being stored? I suspect it's a > null return from a wine system call. well, usually you can: 1/ use a bt in winedbg to get back (or in some calls) where the problem occured 2/ run with -debugmsg +relay to get the return values from some calls (but it is likely that it'll interfere with your program, as the -debugmsg +wave does) -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Oct. 23, 2001

Re: SystemParametersInfo / GetSystemMetrics patches

by Alexandre Julliard

Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > Do you think it is better to do lazy loading for most > parameters? Yes definitely. > I'll think about it more. Originally I planned to > broadcast change notification across processes and use > the reload function in other process to refresh values > from registry. The problem with this approach is when > a parameter is changed without saving. A possibility could to create a volatile registry branch to save parameters that aren't permanently saved. This way they would be accessible from other processes. -- Alexandre Julliard julliard(a)winehq.com

Oct. 23, 2001

Re: mediatype patch

by Alexandre Julliard

Ove Kaaven <ovehk(a)ping.uio.no> writes: > Save a disk file's media type in the server object. OK for the storing part, but why do you return it in the get_file_info request? Shouldn't it rather be in something like get_mapping_info? -- Alexandre Julliard julliard(a)winehq.com

Oct. 23, 2001

Re: SystemParametersInfo / GetSystemMetrics patches

by Andriy Palamarchuk

--- Alexandre Julliard <julliard(a)winehq.com> wrote: > Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > > > The last week I submitted a few patches, including > a > > couple patches for these functions. > > > > The patches have not been committed yet. > > Is there anything wrong with them? > > I'm still not satisfied with the design. Having a > big reload function > is not a good idea IMO, you don't want to have to > load all parameters > on startup when most are never used. Do you think it is better to do lazy loading for most parameters? > Also we need a > way to make > parameter changes work across multiple processes. I'll think about it more. Originally I planned to broadcast change notification across processes and use the reload function in other process to refresh values from registry. The problem with this approach is when a parameter is changed without saving. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com

Oct. 23, 2001

Re: usleep in winmm/wineoss audio

by Simon Britnell

--- eric pouech <eric.pouech(a)wanadoo.fr> wrote: > after, rereading my old code, there's nothing wrong > (at first glance) here some invocations (like close, > reset) need to be synchronous > (the calling thread blocks until the rendering > thread is done with the message), some others (like > adding a wavehdr for play back) > are asynchronous, hence the difference I added a WaitForSingleObject late last PM as an experiment. The results were ... interesting. The first thing I noticed was that my problem attaching to the process went away, ie. winedbg started to work. The second thing that happened was that the problem I experience went from being intermittant to constant and now also invariably throws a page fault exception (in the same place it intermittantly threw an exception). Tracing back from that page fault is proving difficult as the page fault occurs with a value that's been stored on the heap at some prior point in the execution. Any tips for rapid location of where it's being stored? I suspect it's a null return from a wine system call. > so, back to square 1. can you at least trace the > program with > -debugmsg +wave (and still capture the hanging ?) Unfortunately, turning -debugmsg +wave on has so far made the problem go away. I'll have another couple of attempts this PM as its been quite intermittant. Also, it occurs to me to try -debugmsg +wave with the (broken) WaitForSingleObject patch I mentioned above. __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com

Oct. 23, 2001

Re: SystemParametersInfo / GetSystemMetrics patches

by Alexandre Julliard

Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > The last week I submitted a few patches, including a > couple patches for these functions. > > The patches have not been committed yet. > Is there anything wrong with them? I'm still not satisfied with the design. Having a big reload function is not a good idea IMO, you don't want to have to load all parameters on startup when most are never used. Also we need a way to make parameter changes work across multiple processes. -- Alexandre Julliard julliard(a)winehq.com

Oct. 23, 2001

SystemParametersInfo / GetSystemMetrics patches

by Andriy Palamarchuk

The last week I submitted a few patches, including a couple patches for these functions. The patches have not been committed yet. Is there anything wrong with them? Thanks, Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com

Oct. 23, 2001

error at winelib program

by Guilherme Kunz

Hi, All programs was compiled with winemaker. $ ./dlg32 Segmentation fault (core dumped) $ gdb dlg32 core GNU gdb 5.0 .... Core was generated by `./dlg32'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/libntdll.so...Segmentation fault (core dumped) $ winedbg dlg32 Console: Making console complex (creating an xterm)... xterm: unable to open font "vga", trying "fixed".... passed master doesn't match slave name I am using: gcc 2.96 kernel 2.2.19 mfc 4.2 compiled wine by CVS 20011023 Any idea ?? What is the problem with winedbg ?? and gdb ?? i already had tried with gcc 2.95 !! Thank You

Oct. 23, 2001

Re: RPCRT4 Uuid String functions

by Francois Gouget

On Tue, 23 Oct 2001, David Elliott wrote: [...] > > Actually there's quite a few *printf implementations in the Wine > > tree. Too many I would say. What's more, IIRC most of them are > > incomplete as they do not support %S and %C (Unicode for ANSI printfs, > > ANSI for Unicode printfs). I believe this whole thing needs a good > > cleanup... > > Ah, I knew I had entered a bug report for that one: > > http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=321 > > > > sscanf too may need some cleaning. Any volunteers? > > > > > Yes. I am good at stuff like this. It's easy, you look at the manpage and > implement it, and then go back and put in MS hacks. No design involved > there or trying to figure out MSes crappy design since it uses normal POSIX > semantics. Excellent. The lack of a %S bothered me when I tried to test CommandLineToArgvW but I did not have time to fix it. The next step will be to get a working getws :-) -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Hiroshima '45 - Czernobyl '86 - Windows '95

Oct. 23, 2001

Re: RPCRT4 Uuid String functions

by David Elliott

On 2001.10.22 18:28 Francois Gouget wrote: > On Mon, 22 Oct 2001, David Elliott wrote: > [...] > > Hmm, now that I am looking at this I guess the swprintf is defined in > NTDLL > > so I should just use that... WHOOPS, did a lot more coding than I had > to. > > > > I will rework this to use the much saner method and resend the patch > later > > tonight. > > > > Oh well, at least we got a free implementation of wcstoul out of it. > :-) > > > > If I am on the wrong track here, lemme know. Originally I had thought > that > > something like a printf function would only be declared in MSVCRT and > > didn't want to import that, but now that I am looking at it it seems > that > > MSVCRT only forwards to NTDLL. > > Actually there's quite a few *printf implementations in the Wine > tree. Too many I would say. What's more, IIRC most of them are > incomplete as they do not support %S and %C (Unicode for ANSI printfs, > ANSI for Unicode printfs). I believe this whole thing needs a good > cleanup... > Ah, I knew I had entered a bug report for that one: > http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=321 > > sscanf too may need some cleaning. Any volunteers? > > Yes. I am good at stuff like this. It's easy, you look at the manpage and implement it, and then go back and put in MS hacks. No design involved there or trying to figure out MSes crappy design since it uses normal POSIX semantics. Besides, a mostly working sscanf/sprintf (both normal and unicode) is kind of a requirement to write these functions correctly rather than rewrite part of sscanf as I did. > > Gotta get out of that UNIX mindset and into the windows one I guess. > > Preferably not ;-) > :-) True, but on the other hand I believe the higher level libraries should not require calling into POSIX unless absolutely necessary; i.e. being able to take a wine dll, compile it into a PE DLL and use it in real Windows would be kind of a cool thing. Obviously this is not possible everywhere, but for these particular RPCRT4 functions I see no reason why they should require more than what NTDLL provides (since NTDLL seems to provide basically everything, at least if it was completely implemented). > > -- > Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ > Any sufficiently advanced Operating System is indistinguishable from > Linux > What's the corrolary to that. Any crappy OS or GUI is indistinguishable from Windows? Should I dare say "See KDE for an example." :-/ -Dave

Oct. 23, 2001