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

PATCH: add Win95 OSR2 to versions
by David Elliott Oct. 23, 2001

Oct. 23, 2001

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).

1 0

error at winelib program
by Guilherme Kunz Oct. 23, 2001

Oct. 23, 2001

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

2 1

ok.. narrowed down problems with solaris...
by Roger Fujii Oct. 23, 2001

Oct. 23, 2001

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....

1 0

Re: SystemParametersInfo / GetSystemMetrics patches
by Alexandre Julliard Oct. 23, 2001

Oct. 23, 2001

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

1 0

Re: SystemParametersInfo / GetSystemMetrics patches
by Alexandre Julliard Oct. 23, 2001

Oct. 23, 2001

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

2 1

SystemParametersInfo / GetSystemMetrics patches
by Andriy Palamarchuk Oct. 23, 2001

Oct. 23, 2001

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

1 0

Re: RPCRT4 Uuid String functions
by David Elliott Oct. 23, 2001

Oct. 23, 2001

On 2001.10.21 18:34 David Elliott wrote: > This one should properly implement all of the Uuid*String[AW] functions > in > RPCRT4.DLL > > NOTE, this includes a bugfix to the existing UuidToStringA in that it > does > not allocate enough space to store the string it outputs. (it is short by > 2 > chars). > > -Dave > Noticed that Alexandre applied my NTDLL patch, but not this one. 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. Gotta get out of that UNIX mindset and into the windows one I guess. -Dave

2 3

Fix focus problem in cursor.exe
by Joshua Thielen Oct. 23, 2001

Oct. 23, 2001

This patch fixes a focus problem in cursor.exe. cursor.ese handles the WM_ACTIVATE message and since it does not call DefWindowProc when messages are handled, GetFocus is not called as it normally is in DefWndProc. Since no window (or the desktop window) has the focus, PERQDATA_GetFocusWnd will return 0 and the focus will not be switched in WINPOS_SetActiveWindow. This patch fixes the behavior so that the focus will still be switched to the activated window even if the PERQDATA_GetFocusWnd returns 0. modified files: windows/winpos.c change log: Switch focus to activated window even if no window previously had the focus. Joshua Thielen thielen(a)netprince.net

1 0

Re: The big winsock patch
by Gerard Patel Oct. 22, 2001

Oct. 22, 2001

At 10:52 AM 22/10/2001 -0700, you wrote: > That's my damn keyboard: nasty hardware :-) Well, if this patch makes it to the list, this version will be good enough for me. Gerard

1 0

Re: usleep in winmm/wineoss audio
by eric pouech Oct. 22, 2001

Oct. 22, 2001

Simon Britnell wrote: > > For some games (HomeWorld 1.05 being the one I'm > working on), a hang occurs where the system thrashes > on an ioctl SNDCTL_GETOSPACE returning with 0 > fragments available. The symptom went away when I > turned on --debugmsg +wave, so it seems to be some > kind of race. > > I've introduced a usleep(100); before returning FALSE > when there are no fragments available. This seems to > fix the problem. > > I'm not overly happy with this solution and I'm > examining the code with an eye to using poll/select to > handle this more efficiently. Any comments? there's already a wait operation in wodPlayer, so writeFragments shouldn't do any delay there may be a race somewhere, but this is not the way to fix it. are you sure that the 0 fragment is the cause of your issues ? (and not between the sender of wavehdr and the playback thread ?) A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

1 0