- wine-devel - winehq.org

Re: audio.c converted from WaitForSingleObject to poll
by Ove Kaaven 01 Nov '01

01 Nov '01

On Wed, 31 Oct 2001, Simon Britnell wrote: > 2) Removes the need to calculate a sleep interval in > the wodPlayer main loop, as it loops only when dsp is > ready to be written or a command is ready to be > received. Well, it seems like a bad idea to make the player thread enter a busy loop when there isn't enough data to fill the device buffers, don't you think? (Well, though I'd like buffer complete notifications to happen more frequently than they do in Wine's current implementation, making the player thread use 100% CPU isn't the way...)

4 10

mmsystem.c callback thread patch.
by Simon Britnell 01 Nov '01

01 Nov '01

The patch I wrote for mmsystem.c doesn't fix my problem with HomeWorld, so back to the drawing board on that one. The patch fixes a problem that I've only ever seen in HalfLife while I was messing with the innards of wodPlayer and assumes that wodPlayer_Notify can trigger a callback into the application. If that assumption is invalid, please ignore the patch and let me know so I can look into it further. Note that this also changes the semantics of the callbacks because wodPlayer is not halted waiting for the callback to complete, __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com

1 0

Re: config.h reorg part 2: config.h includes
by François Gouget 01 Nov '01

01 Nov '01

François Gouget wrote: [...] > Changelog: > > François Gouget <fgouget(a)codeweavers.com> > > * console/xterm.c, [...] > windows/x11drv/clipboard.c > > Fix the #include order for config.h > Add #include "config.h" directives where needed > Fixes the FILE_OFFSET_BITS redefinition warnings on Solaris (part 2) There was a #include config.h missing in dlls/ddraw/mesa.c in the above patch. The attached patch fixes that. It complements part 2 (p20011031-config.diff) and must thus be applied before part 3 (p20011031-config2.diff) -- François Gouget fgouget(a)codeweavers.com Index: dlls/ddraw/mesa.c =================================================================== RCS file: /home/wine/wine/dlls/ddraw/mesa.c,v retrieving revision 1.3 diff -u -r1.3 mesa.c --- dlls/ddraw/mesa.c 2000/11/27 23:54:26 1.3 +++ dlls/ddraw/mesa.c 2001/11/01 07:51:07 @@ -3,6 +3,8 @@ This file contains all MESA common code */ +#include "config.h" + #include "windef.h" #include "wine/obj_base.h" #include "ddraw.h"

1 0

Re: L"YES" is a NO NO!!!
by Dmitry Timoshkov 01 Nov '01

01 Nov '01

"Francois Gouget" <fgouget(a)free.fr> wrote: > Wine cannot use Unicode strings literals. When you write L"YES" this > is a 32bit Unicode string, not a 16bit unicode string. This means that > when you pass it to lstrcmpiW, which expects 16bit Unicode strings like > all the APIs in Wine, what it sees is this: "Y\0E\0S\0\0\0". And this is > obviously different from "YES". > > > I guess it pays to check the warnings form time to time! Sure. Why not to change L'\0' to a simple 0 in your patch then? @@ -447,10 +451,10 @@ switch (type) { case REG_SZ: data[9] = L'\0'; /* set end of string */ ^^^^^^^^^^^^^^^ -- Dmitry.

2 1

Duplicate StrRetToStr function in commdlg
by Francois Gouget 01 Nov '01

01 Nov '01

Yes, yet another duplicated StrRetToStr function: COMDLG32_StrRetToStrNW in dlls/commdlg/filedlgbrowser.c. At least this time it says that it's a copy. I guess it would be better if the implementations were pointing to each other. It would at least make it easier to maintain. But this case is not as easy as the shell32 case: * first the implementation is slightly different: the SHFree is not commented out in this one. I don't think the difference is intentional. So who is right? * commdlg is not supposed to import shell32. But it already imports a couple of other functions from shell32 so why not this one? It would be better than have another inconsisten implementation. * except that StrRetToStrNW is not exported. It is StrRetToStrN which is exported. So is it ok to call StrRetToStrN? Is StrRetToStrNW really more correct? Well, here is a proposed patch that imports StrRetToStrN from shell32 via the already-in-place GPA mechanism and removes COMDLG32_StrRetToStrNW. Comments? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ La terre est une bêta...

1 0

LockFile - any words of warning?
by Bill Medland 31 Oct '01

31 Oct '01

I am going to have to implement the LockFile/UnlockFile functions. Does anyone have any words of warning? (Like it ain't as easy as calling fcntl) Bill

1 0

Re: Colour problems with latest DIB fix
by Gerard Patel 31 Oct '01

31 Oct '01

At 12:26 AM 31/10/2001 -0800, you wrote: > > Well, 0 is always wrong. So the previous code was always initializing >it to a wrong value. I was expecting descr.compression to be different >from BI_BITFIELDS which would give the expected 0xff0000, 0xff00 and >0xff. > What is the value of descr.compression? yes, it's 0 - big oops for me; I think I forgot to do a make at the top level :-(. Your patch is fixing the problem, thanks. Gerard

1 0

Re:(no subject)
by Eric Pouech 31 Oct '01

31 Oct '01

> The idea is to have a (new) thread which does nothing > but sit in a select and then generate wine events > whenever the select returns. Various sound system > events cause /dev/dsp to be added to or removed from > the select list so that it generates a (new) > WINE_WM_DSP_READY event. my point is that you don't need an extra thread for that you just need to make a windows handle from the unix fd (the one of /dev/dsp) and do a WaitOnMultipleObjects with 2 handles : - the /dev/dsp handle - the synchronization mechanism with all the wodXXX functions. A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle ____________________________________________________________ Faites un voeu et puis Voila ! www.voila.fr Avec Voila Mail, consultez vos e-mails sur votre mobile Wap.

2 1

Re: Colour problems with latest DIB fix
by Gerard Patel 31 Oct '01

31 Oct '01

At 05:50 PM 30/10/2001 -0800, you wrote: > > No no. Usually (0,0,0) means the default rgb layout. But if you >always go to asis in that case, then things will be wrong for users with >a bgr565 X configuration (should reverse in that case). > SetImageBits_* and GetImageBits_* should never get (0,0,0) as the >color masks. They don't know how to handle it and should not have to, >their callers are supposed to take care of that. > I think i found the source of the problem, some old code I had not >changed. Can you try the attached patch? I did and it does not change anything. I don't quite see how it could, since it does not seem better to not initialize data than initialize it to a wrong value :-) I tried ff0000/ff00/ff instead, with better success... Gerard

2 1

double key events
by Arjen Nienhuis 31 Oct '01

31 Oct '01

I test wine often with a game called Elastomania. Wine gets better over the years, but there is one problem that remains when playing that game: In the menus the cursor moves two positons on a key press. The biggest problem is that most of the menus have an odd number of items, so half of them are not reachable. This happens with all the versions of wine I have tested on al the platforms I tested it on. The game uses directx. The problem is not in that both the keyup AND keydown events are being interpreted, because the cursor moves twice at keydown. The cursor does not repeat when a key is held down longer. My not so very usefull guess is that the program tries to shut down some sort of messaging, but that doesnt't work with wine, and the program still listens to those events, and recieves them. Where do keyboard events go? this is the output when ran with no cmdline options: Could not stat /mnt/fd0 (No such file or directory), ignoring drive A: fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x40464254)->(00000000,00000008) fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x40386af8)->(00010021,00000013) fixme:x11drv:X11DRV_DDHAL_CreatePalette stub fixme:x11drv:X11DRV_DDHAL_CreatePalette stub fixme:x11drv:X11DRV_DDHAL_CreatePalette stub err:dinput:SysKeyboardAImpl_Unacquire \ Unacquiring a not-acquired device !!! here is a summary of the output when ran with: --debugmsg +key,+keyboard,+dinput it starts with tons of: KEYBOARD_MapDeadKeysys no character for dead keysym 0x00XXXX and X11DRV_KEYBOARD_DetectLayout matches=47, mismatches=0, score=94 X11DRV_KEYBOARD_DetectLayout Attempting to match against "United Sta... blablabla... then: X11DRV_InitKeyboard fixme:ddraw:Main_DirectDraw_SetCooperativeLevel DirectInputCreateA IDirectInputAImpl_CreateDevice keyboarddev_create_device Creating a Keyboard device (0x40464288) then tons of: IDirectInputDevice2AImpl_SetDataFormat then: IDirectInputDevice2AImpl_SetCooperativeLevel \ (this=0x40464288,0x00010021,0x00000006) DISCL_FOREGROUND DISCL_NONEXCLUSIVE it then does very often: X11DRV_MapVirtualKey ... wMapType=1 and uses the return values in: GetAsyncKeyState () which is always: -> 0 and then (at line 25711)... X11DRV_KeyEvent state = 0 X11DRV_KeyEvent KeyPress : keysym=20 (space), ascii chars=1 / 20 / ' ' X11DRV_KeyEvent keycode 0x41 converted to vkey 0x20 X11DRV_KeyEvent bScan = 0x39. queue_kbd_event wParam=0020, lParam=00390001, InputKeyState=81 TranslateMessage (WM_KEYDOWN, 0020, 00390001) TranslateMessage Translating key VK_SPACE (0020), scancode 39 X11DRV_ToUnicode (0020, 0039) : faked state = 0 X11DRV_ToUnicode Found keycode 65 (0x41) X11DRV_ToUnicode Translating char 0x20 from code page 28591 to unicode X11DRV_ToUnicode ToUnicode about to return 1 with char 20 TranslateMessage 1 -> PostMessage(WM_CHAR) TranslateMessage (WM_CHAR, 0020, 00390001) I pressed the space bar! among 'failing' GetAsyncKeyStates is now GetAsyncKeyState (20) -> 8001 GetAsyncKeyState (20) -> 8000 GetAsyncKeyState (20) -> 8000 GetAsyncKeyState (20) -> 8000 GetAsyncKeyState (20) -> 8000 and then: X11DRV_KeyEvent state = 0 X11DRV_KeyEvent KeyRelease : keysym=20 (space), ascii chars=1 / 20 / ' ' X11DRV_KeyEvent keycode 0x41 converted to vkey 0x20 X11DRV_KeyEvent bScan = 0x39. queue_kbd_event wParam=0020, lParam=c0390001, InputKeyState=1 TranslateMessage (WM_KEYUP, 0020, C0390001) and yes: GetAsyncKeyState (20) -> 0 for the VK_UP that gets interpreted twice, the only diffrence is a call to X11DRV_ToUnicode that returns 0, so there is no: TranslateMessage (WM_CHAR... so for every keypress you get: ... GetAsyncKeyState -> 0 GetAsyncKeyState -> 0 keydown: X11DRV_KeyEvent queue_kbd_event TranslateMessage (WM_KEYDOWN... GetAsyncKeyState -> 8001 GetAsyncKeyState -> 8000 ... GetAsyncKeyState -> 8000 keyup: X11DRV_KeyEvent queue_kbd_event TranslateMessage (WM_KEYUP... GetAsyncKeyState -> 0 ... A demo of the game can be downloaded at http://www.elastomania.com

1 0

Re: Colour problems with latest DIB fix
by Gerard Patel 31 Oct '01

31 Oct '01

At 01:06 AM 30/10/2001 -0800, you wrote: <snip lot of explanations> First thanks for all this stuff, really enlightening. > This probably means that you have a 16bpp rgb565 screen. Which seems >normal. It also means that the Dib is a bgr888 Dib which does not exist >in Windows. So something weird is happening. Here are the interesting >kind of lines: > >trace:bitmap:X11DRV_DIB_SetImageBits Dib: depth=24 r=ff0000 g=ff00 b=ff >trace:bitmap:X11DRV_DIB_SetImageBits Bmp: depth=16/16 r=f800 g=7e0 b=1f > > This tells us that the Dib is a 24bpp dib and that it is an RGB dib, >the only kind of 24bit DIB in Windows. What tells us that it's an RGB >DIB is the r,g,b masks: the red color is encoded in the high bits of the >24bit value: 0xff0000. Then you hace the green, 0xff00, and the blue, >0xff, hence the rgb888 shorthand. > Similarly the 'Bmp', i.e. an XImage, is a 16bpp rgb image. Here you >will notice that the mask for the green color, 0x7e0, uses 6 bits >instead of just 5. This gives you the rgb565 denomination. > Finally we are in SetImage so we are converting the Dib into a Bmp, >i.e. from rgb888 to rgb565 so we will call Convert_888_to_565_asis >(since both are rgb). > Now I suspect that with your application the Dib masks don't look >like the above Congratulations, you are entirely right. As in many cases, Wine does not work because it is not tolerant to strange parameters Actually the dib masks are all equal to 0. Probably the correct fix is to assume an 'asis' (not reversed) conversion when the app does not set any mask. Gerard

3 2

Re:(no subject)
by Eric Pouech 30 Oct '01

30 Oct '01

> I had an idea for using poll or select (rather than > calculating expected play time and using a timeout) in > audio.c The idea is to have a thread that sits on a > select and dispatches a synthetic wine event (ie. > we'd make up a WM_DSP_READY event) when the select > returns. well, from a generic point of view this is something to be done however, I don't see where you'd like to dispatch the event to ? the playback thread in this case would have to wait on two different things: - the /dev/dsp fd (when the queue becomes non full) - the external events (play/pause/stop/quit) so you have to decide whether you use unix or Windows sync mechanisms here. unix would be more effective, but a bit harder to do. Windows would be nice (you just need to call the wine server request to create from a unix fd into a windows handle and wait on it. A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle ____________________________________________________________ Faites un voeu et puis Voila ! www.voila.fr Avec Voila Mail, consultez vos e-mails sur votre mobile Wap.

2 1

Anyone compiled Borland OWL (Object Windows Library) with winelib ?
by Grzegorz Prokopski 30 Oct '01

30 Oct '01

Hi ! I am unable to find this information in wine-devel archives, so I decided to ask here. Q1: Have You heard about anyone who compiled Borland OWL (Object Windows Library) based project with winelib ? Yeah - I know it is an old library and Borland C++ 5.02 is the last version released a few years ago and without future updates. Anyway I have a project which IS written in OWL and need to check how hard will it be to make it working under Linux without rewriting it all. I belive I have the sources for complete OWL of course. Q2: With You expirience what would You say to that statment: If my OWL-based program works under Wine it should be convertable to winelib. How true is that statment ? Q3: I have read docs about using winelib and seen that there is MS Visual C++ mentioned many times. Does MS VC++ have some kind of support in winemake or in winelib itself ? Does OWL case differ much from MS VC++ ? Thank You for Your answers. Grzegorz Prokopski

2 3

re: dde problems
by Josh Duncan 30 Oct '01

30 Oct '01

Eric, thanks for the pointers. I removed the ms versions of the user32, kernel32 dlls. I have attached a log file, containing the last ~100 lines of wine execution. (the command I ran was "wine --debugmsg +dde,+relay --managed ./LOGOS.EXE") am I doing something wrong if wine locks up my computer about half of the time that I try running this app? sometimes I can go back to a virtual console and kill the wine processes(which in turn kills X, annoying but not so bad since xdm kicks in), but often I have to reach for the power button. --Josh On Tue, Oct 30, 2001 at 07:45:05AM -0500, wine-devel-request(a)winehq.com wrote: > Send wine-devel mailing list submissions to > wine-devel(a)winehq.com > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.winehq.com/mailman/listinfo/wine-devel > or, via email, send a message with subject or body 'help' to > wine-devel-request(a)winehq.com > > You can reach the person managing the list at > wine-devel-admin(a)winehq.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of wine-devel digest..." > > > Today's Topics: > > 1. Re:problems with dde, I think... (Eric Pouech) > 2. Re: Colour problems with latest DIB fix (=?iso-8859-1?Q?Fran=E7ois?= Gouget) > 3. Re:(no subject) (Eric Pouech) > > --__--__-- > > Message: 1 > Date: Tue, 30 Oct 2001 09:56:56 +0100 > Subject: Re:problems with dde, I think... > From: "Eric Pouech"<eric.pouech(a)voila.fr> > To: duncan(a)msmd.net > Cc: wine-devel(a)winehq.com > > > I can get the "library" window to show up when running wine, and the initial > > "quick tip" window, but when I click the close button of the tip window wine > > encounters an exception. I believe the exception is in user32.dll, in the > > ddeuninitialize16 function. This is going from my memory of the one time I was > > able to attach to the wine process to catch the exception. > well you have to be sure of that... you can always trace with -debugmsg +dde,+relay and see what gives (and post the 100 lines before the exception is thrown) > > > I attempted copying the kernel32, user32 dll's from a win98 machine into my wine > > dir, but this did not help. > never do that. native kernel, user and gdi DLL won't work under wine. > A+ > > --------------- > Eric Pouech > (http://perso.wanadoo.fr/eric.pouech/) > The future will be better tomorrow, > Vice President Dan Quayle > > > ____________________________________________________________ > Faites un voeu et puis Voila ! www.voila.fr > Avec Voila Mail, consultez vos e-mails sur votre mobile Wap. > > > > --__--__-- > > Message: 2 > Date: Tue, 30 Oct 2001 01:06:35 -0800 > From: =?iso-8859-1?Q?Fran=E7ois?= Gouget <fgouget(a)codeweavers.com> > To: Gerard Patel <gerard.patel(a)nerim.net> > CC: wine-devel(a)winehq.com > Subject: Re: Colour problems with latest DIB fix > > Gerard Patel wrote: > > > > At 12:53 PM 29/10/2001 -0800, you wrote: > > > > >> Anyway, the attached patch is displaying the failing picture correctly. > > >> What do you think ? > > > > > > If I apply your patch, then I see that the red and blue are exchanged > > >when I run vnc as: > > > vncserver :1 -geometry 800x600 -depth 16 -pixelformat bgr565 > > > > Could you explain a bit more what you are doing ? I would like to > > try the same but I don't see how to do it. > > I guess you don't know about VNC then. Here's a description of VNC. > VNC is a pretty cool open-source application which lets you access a > computer remotely, kind of like X but different :-) It is composed of > two parts, a server and a client. > The command above starts an VNC X server. This X server is not using > any graphics card because it is not actually displaying anything. It > just uses a chunk of memory to store the 'screen'. Because of that you > can use about any pixel representation. In the above I specified that I > wanted a 800x600 screen in 16 bits per pixel with the red, green and > blue components in BGR order. > Once you have this server, you can start the client as 'xvncviewer > :1'. This connects to the above VNC server and creates an 800x600 window > that shows you what is displayed in that X server. The client can be run > on the same computer or on another. Because the client/server protocol > involves exchanging bitmap chunks the client is very simple and can run > on about any platform. So you can access the above VNC server from an > Windows computer if you want. > There is also a VNC server for Windows. And this leads to one of the > most interesting applications of VNC: remotely controlling a Windows > computer. From another Windows computer, from any Unix platform, I > believe there's even a client for PalmOS! > > Anyway, by playing with the -depth and -pixelformat options you can > test Wine as if it were running into all sorts of X servers. > > > > Also, if you use vnc to test, did you consider the possibility that vnc > > could have a bug somewhere ? > > There's always that possibility but the results I get with VNC (based > on XFree 3.3.6) are consistent with those I get from the > neomagic&permedia drivers of XFree 4.1.0. > > > [...] > > I had (of course) a number of problems with your app. > > First on my current computer - a Mandrake 8, with Xfree 4, > > your procedure ran fine until it tried to link the thing and then it > > reported that WinMain was missing. I changed in your code > > 'main' to 'WinMain' and all was well. > > Sorry about that. By default winemaker assumes that applications are > graphical applications. So it created a .spec file with "mode guiexe" > and "init WinMain" instead of "mode cuiexe" and "init main". > > > > I tried then to do the same on my other computer (Suse 6.1 with > > Xfree 3.3 and a hand-compiled glibc 2.1.3). No joy. Configure > > always failed with libwine.so failing to find symbols like dlclose > > and the like. I did not figure out what is happening, I just > > copied the binary from my other box and it worked. > > That's strange. It should be investigated... > > > > As for the results, what I see is 11 lines of 13 blocks of 4 colors : > > black, red, green, blue. I guess that when you speak of red and > > blue exchanged, you mean that in one of these blocks the red > > and blue lines are exchanged, right ? > > Yes. > > > > What is strange is that on both of my computers the display > > of your app is the same with or without my patch. No line > > exchanged that I can see. > > This probably means that you have a 16bpp rgb565 screen. Which seems > normal. It also means that the Dib is a bgr888 Dib which does not exist > in Windows. So something weird is happening. Here are the interesting > kind of lines: > > trace:bitmap:X11DRV_DIB_SetImageBits Dib: depth=24 r=ff0000 g=ff00 b=ff > trace:bitmap:X11DRV_DIB_SetImageBits Bmp: depth=16/16 r=f800 g=7e0 b=1f > > This tells us that the Dib is a 24bpp dib and that it is an RGB dib, > the only kind of 24bit DIB in Windows. What tells us that it's an RGB > DIB is the r,g,b masks: the red color is encoded in the high bits of the > 24bit value: 0xff0000. Then you hace the green, 0xff00, and the blue, > 0xff, hence the rgb888 shorthand. > Similarly the 'Bmp', i.e. an XImage, is a 16bpp rgb image. Here you > will notice that the mask for the green color, 0x7e0, uses 6 bits > instead of just 5. This gives you the rgb565 denomination. > Finally we are in SetImage so we are converting the Dib into a Bmp, > i.e. from rgb888 to rgb565 so we will call Convert_888_to_565_asis > (since both are rgb). > Now I suspect that with your application the Dib masks don't look > like the above. > > Actually I have a buffer overflow patch to send for the new DIB code. > I don't think it's related but then, who knows. I will try to send it > tomorrow morning. > > > > > As for The Sims, if you can also check the -debugmsg +bitmap output > > >and make sure it's coherent. > > > > I don't have The Sims... I use a little freeware app that is not available > > from the internet anymore, unfortunately :-/. > > Do you think you could send this freeware app to me? Would I be able > to run it without too much trouble? > > > -- > François Gouget > fgouget(a)codeweavers.com > > > --__--__-- > > Message: 3 > Date: Tue, 30 Oct 2001 10:09:05 +0100 > Subject: Re:(no subject) > From: "Eric Pouech"<eric.pouech(a)voila.fr> > To: ughbash(a)yahoo.com > Cc: wine-devel(a)winehq.com > > > I had an idea for using poll or select (rather than > > calculating expected play time and using a timeout) in > > audio.c The idea is to have a thread that sits on a > > select and dispatches a synthetic wine event (ie. > > we'd make up a WM_DSP_READY event) when the select > > returns. > well, from a generic point of view this is something to be done > however, I don't see where you'd like to dispatch the event to ? > the playback thread in this case would have to wait on two different things: > - the /dev/dsp fd (when the queue becomes non full) > - the external events (play/pause/stop/quit) > so you have to decide whether you use unix or Windows sync mechanisms here. unix would be more effective, but a bit harder to do. Windows would be nice (you just need to call the wine server request to create from a unix fd into a windows handle and wait on it. > > A+ > --------------- > Eric Pouech > (http://perso.wanadoo.fr/eric.pouech/) > The future will be better tomorrow, > Vice President Dan Quayle > > > ____________________________________________________________ > Faites un voeu et puis Voila ! www.voila.fr > Avec Voila Mail, consultez vos e-mails sur votre mobile Wap. > > > > > --__--__-- > > _______________________________________________ > wine-devel mailing list - wine-devel(a)winehq.com > http://www.winehq.com/mailman/listinfo/wine-devel > > > End of wine-devel Digest

2 1

Re: Colour problems with latest DIB fix
by Gerard Patel 30 Oct '01

30 Oct '01

At 12:53 PM 29/10/2001 -0800, you wrote: >> Anyway, the attached patch is displaying the failing picture correctly. >> What do you think ? > > If I apply your patch, then I see that the red and blue are exchanged >when I run vnc as: > vncserver :1 -geometry 800x600 -depth 16 -pixelformat bgr565 Could you explain a bit more what you are doing ? I would like to try the same but I don't see how to do it. Also, if you use vnc to test, did you consider the possibility that vnc could have a bug somewhere ? > Without the patch everything is fine. I also checked the formula and >I see nothing wrong with it (as long as you are on a little endian >computer, but you don't have a big endian x86, do you? ;-). Never heard that Amd is doing that :-) > So the question is why doesn't it work on your system. Can you run >The Sims (I assume it's with that the problem happens) with a +bitmap >trace? Then look for cases where either the bmp or the dib has >"depth=24". Then check the masks to see if they make sense. For example, >do they match what you know of your X server. You may also put a trace >in Convert_888_to_565_reverse and check that it is invoked at the right >time. Do they have a bgr888 dib (unsupported in windows AFAIK, but, >except for 1 or 2 shortcuts, supported in Wine)? Maybe it is the DIB >masks that are wrong. That's a bit involved for this evening :-/ > Also it would be great if you could run my test application and check >whether it displays fine. The line to watch for is the sixth line >(rgb888 dib to 565 rgb/bgr bmp and back). I had (of course) a number of problems with your app. First on my current computer - a Mandrake 8, with Xfree 4, your procedure ran fine until it tried to link the thing and then it reported that WinMain was missing. I changed in your code 'main' to 'WinMain' and all was well. I tried then to do the same on my other computer (Suse 6.1 with Xfree 3.3 and a hand-compiled glibc 2.1.3). No joy. Configure always failed with libwine.so failing to find symbols like dlclose and the like. I did not figure out what is happening, I just copied the binary from my other box and it worked. As for the results, what I see is 11 lines of 13 blocks of 4 colors : black, red, green, blue. I guess that when you speak of red and blue exchanged, you mean that in one of these blocks the red and blue lines are exchanged, right ? What is strange is that on both of my computers the display of your app is the same with or without my patch. No line exchanged that I can see. > As for The Sims, if you can also check the -debugmsg +bitmap output >and make sure it's coherent. I don't have The Sims... I use a little freeware app that is not available from the internet anymore, unfortunately :-/. And again, that's a bit complex for today. I'll try later. Gerard

2 1

Re:problems with dde, I think...
by Eric Pouech 30 Oct '01

30 Oct '01

> I can get the "library" window to show up when running wine, and the initial > "quick tip" window, but when I click the close button of the tip window wine > encounters an exception. I believe the exception is in user32.dll, in the > ddeuninitialize16 function. This is going from my memory of the one time I was > able to attach to the wine process to catch the exception. well you have to be sure of that... you can always trace with -debugmsg +dde,+relay and see what gives (and post the 100 lines before the exception is thrown) > I attempted copying the kernel32, user32 dll's from a win98 machine into my wine > dir, but this did not help. never do that. native kernel, user and gdi DLL won't work under wine. A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle ____________________________________________________________ Faites un voeu et puis Voila ! www.voila.fr Avec Voila Mail, consultez vos e-mails sur votre mobile Wap.

1 0

problems with dde, I think...
by Josh Duncan 30 Oct '01

30 Oct '01

Hi all, I'm a little new to the list, so please be forgiving if I'm asking old questions. I've tried to do some research on the net and list archives to see if my questions have been answered before. I'm trying to run a program called Logos, which is a reference system for Biblical texts and other various study materials. It has a two-(independent)-windowed type interface, with a list of reference materials in one window("library"), and a workspace-type window containing subwindows with the texts of individual books. I can get the "library" window to show up when running wine, and the initial "quick tip" window, but when I click the close button of the tip window wine encounters an exception. I believe the exception is in user32.dll, in the ddeuninitialize16 function. This is going from my memory of the one time I was able to attach to the wine process to catch the exception. I attempted copying the kernel32, user32 dll's from a win98 machine into my wine dir, but this did not help. after doing this, I could not run winedbg either, as it exits giving me the following error: err:win32:PE_fixup_imports No implementation for kernel32.dll.0(wine_get_unix_file_name) imported from winedbg, setting to 0xdeadbeef This error occurs even after removing the two dlls. If anyone can give me advice about how to fix this, I'll try to post up the winedbg results of running the program(backtrace, et al) I know that some people have mentioned dde being broken between apps, I don't know if this is the case for this app, because when I was able to do a winedbg "walk process" it only listed one w-process, with 4 w-threads running. I have attached my wine config file, any advice would be greatly appreciated. (Also, if this email should have gone to the wine-users list, please let me know) I'm using the wine-20011029.i386.rpm from LinuxEasy, linked off of the winehq.org download page. sincerely, Josh Duncan not that it matters, but a pic of the two windows I can produce are at http://www.msmd.net/logos.jpg I'd try and show a pic of the other window, but the system gets so unstable that it can hard-lockup the machine, I think this is a cpu-spinning-in-signal handler problem but I couldn't get you a log right now to prove it.

1 0

Re: problem with virtualdub.
by Roger Fujii 29 Oct '01

29 Oct '01

Nerijus Baliunas wrote: > On Mon, 29 Oct 2001 17:04:51 +0000 Gerard Patel <gerard.patel(a)nerim.net> wrote: > > GP> The web site says that this executable is compressed with a tool called UPX. This > GP> seems to be the reason for the problem, as the original program is compiled with > GP> Ms VC++ - not a very exotic tool. > You can unpack it with upx, even under Linux - http://upx.sourceforge.net/. well, this indeed seems to be part of the problem. Decompressing it makes it go further, but still dies. > GP> I tried a hack for that and virtualdub got further; however, I see that it is > GP> trying to load avicap32.dll and this is not going to work - even under Linux > I remember I was able to start Virtual Dub with wine (maybe a year ago), but don't > remember if it worked. BTW, just yesterday TAKESHIMA Hidenori added stub for avicap32. really? Doesn't seem to be in cvs yet... Looks like it's getting upset about not finding StdChannelMask, but this is just a guess. -r

1 0

(no subject)
by Simon Britnell 29 Oct '01

29 Oct '01

I had an idea for using poll or select (rather than calculating expected play time and using a timeout) in audio.c The idea is to have a thread that sits on a select and dispatches a synthetic wine event (ie. we'd make up a WM_DSP_READY event) when the select returns. wodPlayer could then do an infinite wait and the select could be turned on or off when starting and ending playing. >From my relatively naive view a generic mechanism like this (ie. one that converts async IO selects into wine events) would be a good feature to have from a performance and code tidiness point of view. One caveat is that we'd need to ensure nothing evil happened if somebody sent the synthetic event from somewhere other than the select waiter. Comments? Am I missing something? __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com

1 0

Re: problem with virtualdub.
by Gerard Patel 29 Oct '01

29 Oct '01

At 05:17 PM 26/10/2001 -0400, you wrote: > >there seems to be a funky problem with virtualdub >(http://virutaldub.sourceforge.net). Get differing >results between solaris and linux, but both seems to >fail before the app comes up. > >Under solaris, it seems like something is screwed up >with the loader - when it tries to load the binary, >it dies in dump_exports because what's at pe_exports >is just garbage. Not sure where it's dying under >linux (probably the same place) - don't have a devel >environment there (yet). > >Nothing unusual seems to happen before it gets there >(both solaris/linux binaries run sol.exe and other stuff just fine). >My suspicion is that the IMAGE_DIRECTORY_ENTRY_EXPORT data isn't pointing to what >wine thinks is there, but would like someone who knows more >about the loader to say something.... > >can anyone help shed more light onto this? > >-r > Yes, I have looked at this application. It loads fine under Windows - however, both dependancy walker and the Nt quick viewer are not happy with it (one displays that there is a format error in the exe, the other loops and finally crashes) The web site says that this executable is compressed with a tool called UPX. This seems to be the reason for the problem, as the original program is compiled with Ms VC++ - not a very exotic tool. I think that a fix could be to detect a corrupted header in dump_exports and to not try to display anything if numberoffunctions is not coherent with the export section size. I tried a hack for that and virtualdub got further; however, I see that it is trying to load avicap32.dll and this is not going to work - even under Linux ;:-) Gerard

2 1

Re: Colour problems with latest DIB fix
by Gerard Patel 29 Oct '01

29 Oct '01

At 02:18 PM 21/10/2001 -0700, you wrote: > >Johan Gill wrote: >> >> Since the big DIB fix, red and blue are exchanged in some cases, >> for example in the install program for The Sims. >> >> This happens in both depth 16 and depth 24. > > Could you give me some more information about your X server (version, >driver)? I see a very similar problem with my X server : 4.03 that comes with my Mandrake 8, graphic card is a Sis 6326. I had tested your patch before it was committed BTW but I failed to notice the problem :-/ Anyway, the attached patch is displaying the failing picture correctly. What do you think ? Gerard

2 1

struct thread in server/thread.h
by Gerald Pfeifer 29 Oct '01

29 Oct '01

In server/thread.h we have a definition of struct thread. Unfortunately, though, this clashes with struct thread as defined in /usr/include/sys/thread.h on FreeBSD 5.x and probably other systems (Solaris) as well. How should this be addressed? Would any of you mind fixing this? (If it's okay to just rename struct thread to struct winethread, I'm volunteering to handle that, else it'd be great could one of the experts have a look!) Gerald -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

1 0

Wine and Starcraft
by geschrader 29 Oct '01

29 Oct '01

I've been pecking away attempting to track down why the current wine build won't run Starcraft. When it starts up I get the effect that I playfully refer to as the TSOD (Technicolor Screen Of Death). What I've found is that if all of the references to gdi_display in X11DRV_DDHAL_SetPalEntries( ) are replaced with thread_display( ) then it actually starts up and looks pretty good. However, the keyboard and mouse don't work so this is at best a partial fix. I'm pretty sure that this is on the right track since X11DRV_XF86DGA2_CreatePalette( ) uses thread_display( ) to make the palette that is eventually given to X11DRV_DDHAL_SetPalEntries( ). The only other function in dlls/x11drv/x11ddraw.c that uses gdi_display is X11DRV_DDHAL_DestroyPalette( ). Should thread_display( ) be used there also? How is gdi_display related to the display returned by thread_display( )? Both are used in quite a few places but they're obviously not the same thing. Can anybody give me some hints on what might be happening with the keyboard and mouse? Thanks much, ges

1 0

FindWindow, WaitforSingleObject and Deadlock
by Uwe Bonnes 28 Oct '01

28 Oct '01

Hallo, I reported before, some applications of the quicklogic suite starts some watchdog application and hangs at this state. I tracked this down to the following sequence of events: - master application starts, sets up an event and resets the event - master application starts the watchdog - as soon as CreateProcess return, the Master application calls WaitForSingleObject with infinite timeout on that event - watchdog application starts and calls FindWindow. This is translated in a GetWindowText Call and finally SendMessageW (WM_GETTEXT) is called - Master application never awakes from waiting for the WaitForSingleObject Event and so never processes the SendMessage and Findwindow in the watchdog never returns I found two things relates to this deadlock in the API description: For WaitForSingleObject: "Use caution when calling the wait functions and code that directly or indirectly creates windows. If a thread creates any windows, it must process messages. Message broadcasts are sent to all windows in the system. A thread that uses a wait function with no time-out interval may cause the system to become deadlocked" so the latter behaviour seems right. But GetWindowText seems to expect such a deadlock: "If the target window is owned by the current process, GetWindowText causes a WM_GETTEXT message to be sent to the specified window or control. If the target window is owned by another process and has a caption, GetWindowText retrieves the window caption text. If the window does not have a caption, the return value is a null string. This behavior is by design. It allows applications to call GetWindowText without hanging if the process that owns the target window is hung." Sending the WM_GETTEXT only for local windows in the FindWindow loop makes the application continue and at some point the event is triggered. How should wine handle that case? Sould the caption be stored on the server? I it perhaps already? Bye Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Free Software: If you contribute nothing, expect nothing --

1 0

wine nolonger accepts mIRC dcc's
by mdew 27 Oct '01

27 Oct '01

when someone attempts to send you a file... i receive this in my status window. [06:12] DCC Get of sample_files.zip from Joe_dude: * Break: at one stage, wine+mirc did work..

1 1

WINE and Haxial programs
by haxial 27 Oct '01

27 Oct '01

Hi There My company produces a few programs that run on Windows and MacOS. Some of the users of these programs have been experimenting using WINE to run the programs on Linux. This is what they have been saying: "the KDX server runs FLAWLESSLY, 100% perfect, better than solitaire runs" However, there is one caveat to the above: I'm told that text input doesn't work when running KDX using WINE on Linux. I was wondering if I would be able to work with WINE developers in making KDX run perfectly on Linux using WINE. I think you would find this to be an easier task than usual because KDX only uses a *minimal* amount of windoze APIs. For example, KDX implements it's own GUI, it does not use the windoze API for that. Also, KDX even implements it's own graphics routines, it does not use the windoze GDI functions (except for the final step of getting the images onto the screen). KDX loads no obscure DLL's, it's just a single .exe file. It does not use MDI or any crap like that. It does not access the registry. It does not use MFC. So I think it would be much easier for WINE than your average windoze program. Which probably explains why it's already running well, except there is some bug, probably a minor little thing, that is preventing text input from working. The website is: http://www.haxial.com Thanks.

1 0

ReadFile behaviour on COMs
by Mike McCormack 27 Oct '01

27 Oct '01

Hey Uwe, There is still a number of problems with the COMM code that i am slowly fixing. They are: * comm ports opened without FILE_FLAG_OVERLAPPED don't use (any) read and write timeouts (patch in the works) * comm timeouts don't work 100% correctly * WaitCommEvent only works for EV_RXCHAR (difficult to solve correctly) Sounds like your problem might be related to #2. There are a few special cases for the values in the COMMTIMEOUTS structure that aren't being dealt with at the moment. Could you please post a -debugmsg +file,+comm trace and i'll have a look at it on Monday. Additionally, if the software is available online somewhere, please post a link to it. Mike ps. when you say the right byte, you mean the first byte, right? > Hallo, > > somebody showed me an application speaking to a device > connected to the serial port. The application failed after some > successfull communication steps. As the protocoll is available > in some other (open source programm) we could see that the > program requested two bytes from the device , but ReadFile only > delivered one byte (with that byte beeing the right one of the > expected two byte sequence). > > I suspect ReadFile to be the culprit. While the api description > tells to read all requested bytes ( beside of real errors), our > implementation happilies returns fewer bytes than requested. In > the case of COM devices, all timeouts of the SetCommTimeout > structure should be checked two. > > Anyone with an implementaion for that? > > Bye > -- > Uwe Bonnes ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

problem with virtualdub.
by Roger Fujii 26 Oct '01

26 Oct '01

there seems to be a funky problem with virtualdub (http://virutaldub.sourceforge.net). Get differing results between solaris and linux, but both seems to fail before the app comes up. Under solaris, it seems like something is screwed up with the loader - when it tries to load the binary, it dies in dump_exports because what's at pe_exports is just garbage. Not sure where it's dying under linux (probably the same place) - don't have a devel environment there (yet). Nothing unusual seems to happen before it gets there (both solaris/linux binaries run sol.exe and other stuff just fine). My suspicion is that the IMAGE_DIRECTORY_ENTRY_EXPORT data isn't pointing to what wine thinks is there, but would like someone who knows more about the loader to say something.... can anyone help shed more light onto this? -r

1 0

Re: none
by Alexandre Julliard 26 Oct '01

26 Oct '01

Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > Ok, how about this: > Each system parameter has "is_loaded" flag which shows > whether the parameter is loaded or not. Parameters, > stored directly in SysParametersInfo are loaded from > registry only when they are requested and the flag is > "false", after the loading the flag is set to "true". > On interprocess notification of the parameter change > the corresponding parameter flag is set to "false". > The parameter will be reloaded when it is requested > the next time. Yes, something like this would work. > Are there any existing implementations of > communication between Wine processes I can use as an > example? You want to use some variant of SendMessage in this case, probably a broadcast SendNotifyMessage with an internal message code (adding a WM_WINE_ case in dlls/user/message.c). > Do you still think it is better don't affect X > settings from Wine? Yes. > While we are on this - what about other my patch - > "hello5.c"? It fixes a warning and an error message I > got when I tried to compile hello5.c. The error depends on the compiler version. You should check the DUMMYUNIONNAME defines if you want to make it work for all platforms. I'm not sure it's worth the trouble though. -- Alexandre Julliard julliard(a)winehq.com

1 0

(no subject)
by Andriy Palamarchuk 26 Oct '01

26 Oct '01

Alexandre Julliard wrote: > Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > > >>Do you think it is better to do lazy loading for most >>parameters? >> > > Yes definitely. Ok, how about this: Each system parameter has "is_loaded" flag which shows whether the parameter is loaded or not. Parameters, stored directly in SysParametersInfo are loaded from registry only when they are requested and the flag is "false", after the loading the flag is set to "true". On interprocess notification of the parameter change the corresponding parameter flag is set to "false". The parameter will be reloaded when it is requested the next time. Parameters, backed by GetSystemMetrics are processed differently. These parameters are always loaded. They are reloaded right away on interprocess change notification. We can't do lazy loading because GetSystemMetrics returns its values from system metrics array and we don't want to complicate this function. I'm going to implement the flags as a bit array. Index constants for this array will be defined separately. >>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. Thank you for the idea. Are there any existing implementations of communication between Wine processes I can use as an example? Disregard the patches "SystemParametersInfo / GetSystemMetrics", "SPI_GET/SETBORDER". I'll implement the discussed above changes and resubmit them. Do you still think it is better don't affect X settings from Wine? Please let me know. While we are on this - what about other my patch - "hello5.c"? It fixes a warning and an error message I got when I tried to compile hello5.c. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com

1 0

ReadFile behaviour on COMs
by Uwe Bonnes 26 Oct '01

26 Oct '01

Hallo, somebody showed me an application speaking to a device connected to the serial port. The application failed after some successfull communication steps. As the protocoll is available in some other (open source programm) we could see that the program requested two bytes from the device , but ReadFile only delivered one byte (with that byte beeing the right one of the expected two byte sequence). I suspect ReadFile to be the culprit. While the api description tells to read all requested bytes ( beside of real errors), our implementation happilies returns fewer bytes than requested. In the case of COM devices, all timeouts of the SetCommTimeout structure should be checked two. Anyone with an implementaion for that? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

(no subject)
by Mike McCormack 26 Oct '01

26 Oct '01

Hi Andreas, i had a bit more free time, so i tracked down the rendering problem in NetTerm a bit more. The problem occurs after SelectVisRgn16 is called with the same region as that currently selected in the DC. (eg. dc->hVisRgn == hrgn ). I made a dodgy patch to fix the problem by incrementing the reference count of the region in this case, but i don't know how to fix it properly, because i don't know much about region handling. With the dodgy patch, NetTerm's windows paints properly. Perhaps perhaps you or somebody has a better way to fix the problem? Mike Andreas Mohr wrote: > On Tue, Oct 09, 2001 at 11:35:39AM +1000, Mike McCormack wrote: > > > > Hi All, > > > > i'm trying to solve a comms problem in NetTerm > > http://www.securenetterm.com/ but i've run into another problem. > > > > The rendering in NetTerm fails almost completely. I > > Yep, I strongly suspect a reference count problem here, too. > ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Re: cursor visibility problem
by Alexandre Julliard 25 Oct '01

25 Oct '01

Ove Kaaven <ovehk(a)ping.uio.no> writes: > In Alexandre's new windowing architecture, we have in > dlls/x11drv/window.c, line 119, this: > > attr->cursor = X11DRV_GetCursor( display, GlobalLock16(GetCursor()) ); > > Problem: what if ShowCursor(FALSE) is called to hide the cursor *before* > the window was created? Yup, GetCursor still returns the current (arrow) > cursor, so the new window gets associated with a visible cursor, though > the app would expect the cursor to remain hidden. Yes, cursor handling has some problems right now. It also needs to be a lot more clever about setting the cursor on child windows, and not walk the full list of top-level windows on every SetCursor. It will be fixed eventually, but it's not my top priority right now. -- Alexandre Julliard julliard(a)winehq.com

1 0

cursor visibility problem
by Ove Kaaven 25 Oct '01

25 Oct '01

In Alexandre's new windowing architecture, we have in dlls/x11drv/window.c, line 119, this: attr->cursor = X11DRV_GetCursor( display, GlobalLock16(GetCursor()) ); Problem: what if ShowCursor(FALSE) is called to hide the cursor *before* the window was created? Yup, GetCursor still returns the current (arrow) cursor, so the new window gets associated with a visible cursor, though the app would expect the cursor to remain hidden. Diablo II is currently known to suffer from this problem... it has too many cursors visible. I haven't come up with a very clean solution to this... ideas?

1 0

winelib works only in debugmsg mode
by Guilherme Kunz 25 Oct '01

25 Oct '01

Hi, I have compiled a program with mfc using winemaker and when a run the program "./dlg" show a messagebox "Could not get address of WinMain", i am linking the mfc static mode. but when i run "./dlg --debugmsg +all &> debug.log" the program run right. gcc 2.96.85 kernel 2.2.19 Any idea ?? Thank you. Guilherme Kunz

1 0

Re: wine/memory virtual.c
by Alexandre Julliard 25 Oct '01

25 Oct '01

Ove Kaaven <ovehk(a)ping.uio.no> writes: > Well, though I haven't tested it yet (working on other stuff right now), > if it works for you, it'll work for me. I haven't really tested it either, but I'll commit it and we'll see... -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: wine/memory virtual.c
by Alexandre Julliard 25 Oct '01

25 Oct '01

Alexandre Julliard <julliard(a)winehq.com> writes: > It's used at least in debug events, so yes it's possible that the > debugger will try to use the handle to read the file. Probably better > to close it completely when on removable media; and we'll need to do > this for dlls too. I'll try to come up with something. OK how about this? Index: loader/pe_image.c =================================================================== RCS file: /opt/cvs-commit/wine/loader/pe_image.c,v retrieving revision 1.99 diff -u -r1.99 pe_image.c --- loader/pe_image.c 2001/10/02 17:49:20 1.99 +++ loader/pe_image.c 2001/10/24 19:39:21 @@ -667,6 +667,12 @@ if (nt->FileHeader.Characteristics & IMAGE_FILE_DLL) { + if (hFile) + { + UINT drive_type = GetDriveTypeA( wm->short_filename ); + /* don't keep the file handle open on removable media */ + if (drive_type == DRIVE_REMOVABLE || drive_type == DRIVE_CDROM) hFile = 0; + } SERVER_START_REQ( load_dll ) { req->handle = hFile; Index: scheduler/process.c =================================================================== RCS file: /opt/cvs-commit/wine/scheduler/process.c,v retrieving revision 1.162 diff -u -r1.162 process.c --- scheduler/process.c 2001/10/03 18:40:10 1.162 +++ scheduler/process.c 2001/10/24 19:39:22 @@ -327,6 +327,17 @@ lstrcpynA( main_exe_name, full_argv0, sizeof(main_exe_name) ); } + if (main_exe_file) + { + UINT drive_type = GetDriveTypeA( main_exe_name ); + if (drive_type == DRIVE_REMOVABLE || drive_type == DRIVE_CDROM) + { + /* don't keep the file handle open on removable media */ + CloseHandle( main_exe_file ); + main_exe_file = 0; + } + } + /* Retrieve entry point address */ entry = (LPTHREAD_START_ROUTINE)((char*)current_process.module + PE_HEADER(current_process.module)->OptionalHeader.AddressOfEntryPoint); Index: server/process.c =================================================================== RCS file: /opt/cvs-commit/wine/server/process.c,v retrieving revision 1.70 diff -u -r1.70 process.c --- server/process.c 2001/07/14 00:50:30 1.70 +++ server/process.c 2001/10/24 19:39:22 @@ -788,8 +788,9 @@ /* signal the end of the process initialization */ DECL_HANDLER(init_process_done) { - struct file *file; + struct file *file = NULL; struct process *process = current->process; + if (!process->init_event) { fatal_protocol_error( current, "init_process_done: no event\n" ); @@ -798,11 +799,10 @@ process->exe.base = req->module; process->exe.name = req->name; - if (req->exe_file && (file = get_file_obj( current->process, req->exe_file, GENERIC_READ ))) - { - if (process->exe.file) release_object( process->exe.file ); - process->exe.file = file; - } + if (req->exe_file) file = get_file_obj( current->process, req->exe_file, GENERIC_READ ); + if (process->exe.file) release_object( process->exe.file ); + process->exe.file = file; + generate_startup_debug_events( current->process, req->entry ); set_event( process->init_event ); release_object( process->init_event ); -- Alexandre Julliard julliard(a)winehq.com

2 1

ddraw fullscreen-app problem in latest CVS
by TAKESHIMA Hidenori 25 Oct '01

25 Oct '01

I can run some full-screen app in 2001/10/20 cvs. but, in the latest cvs, wine may crash in creating the fullscreen-primary surface... (I don't know why, but since wine-server protocol has been updated?????) ddrawtst.c is a minimal test program that crashes the latest cvs. My environment is: debian2.3-woody, XFree86-4.1.0-7. No permission to access /dev/kmem directly.

1 0

Re: Registry: Recursive key delete patch
by Gerard Patel 24 Oct '01

24 Oct '01

At 02:52 PM 24/10/2001 -0400, you wrote: > > This patch permits the recursive deletion of registry >keys that also contain subkeys. <snip> I think that the MSDN article about RegDeleteKey states that this is a win9x specific behaviour. Gerard

1 0

Re: ptrace differences in kernel 2.4.7
by Alexandre Julliard 24 Oct '01

24 Oct '01

eric pouech <eric.pouech(a)wanadoo.fr> writes: > well, you said the error was 5 (EIO), so this EPERM stuff > shouldn't be in cause No, 5 is the Windows code (ERROR_ACCESS_DENIED), which is what EPERM translates to. -- Alexandre Julliard julliard(a)winehq.com

1 0

IS6: Problem in ITypeInfo_fnGetContainingTypeLib
by Uwe Bonnes 24 Oct '01

24 Oct '01

Hallo, after clearing up my home brewn problems I tried the IS6 installer for Analog Devices Visual DSP one more time. No it proceeds much longer but crashes in ITypeInfo_fnGetContainingTypeLib trace:ole:SysAllocStringLen => 0x4043ac28 L"Comcat" trace:ole:SysAllocStringLen => 0x40452894 L"" trace:ole:SysFreeString (L"Comcat") trace:ole:VariantClear (0x41576850) <repeated with several adresses> trace:ole:VariantClear (0x415767e0) trace:ole:SysAllocStringLen => 0x4043ac28 L"<Data>" trace:ole:SysAllocStringLen => 0x4042d044 L"" trace:ole:SysFreeString (L"<Data>") trace:ole:SysFreeString (L"") trace:ole:PSOAStub_Invoke invoked method returned with HRESULT 00000000 trace:ole:TL_Marshal Marshaling 0x41576c40 trace:ole:ITypeInfo_fnGetNames (0x4041753c) memid=0x00000014 Maxname=16 trace:ole:SysAllocStringLen => 0x4043ac28 L"OpenCAB" trace:ole:SysAllocStringLen => 0x4043a174 L"File" trace:ole:SysAllocStringLen => 0x40436f24 L"pVal" trace:ole:SysFreeString (L"OpenCAB") trace:ole:TL_Marshal parameter 0 trace:ole:TL_Marshal name : L"File" trace:ole:SysFreeString (L"File") trace:ole:TL_Marshal type : 8 trace:ole:TL_Marshal flags : 01 trace:ole:TL_CleanupType freeing BSTR 0x40409fe4 trace:ole:SysFreeString (L"J:\\ad-vdsp\\ADI\\data1.hdr") trace:ole:TL_Marshal parameter 1 trace:ole:TL_Marshal name : L"pVal" trace:ole:SysFreeString (L"pVal") trace:ole:TL_Marshal type : 26 trace:ole:TL_Marshal flags : 0a trace:ole:TL_MarshalType dereferencing PTR 0x40415908 <= 0x41576c48 trace:ole:TL_MarshalType dereferencing PTR 0x41104844 <= 0x40415908 trace:ole:TL_MarshalType reftype: 2 wine: Unhandled exception, starting debugger... WineDbg starting... on pid 96ef3a0 <..>. No debug information in 32bit DLL 'X11DRV.DLL' (0x40ac2000) Unhandled exception: page fault on read access to 0x00000004 in 32-bit code (0x40a653f5). In 32-bit mode. 0x40a653f5 (ITypeInfo_fnGetContainingTypeLib+0x35 [typelib.c:4303] in liboleaut32.so): movl 0x4(%edx),%eax 4303 ITypeLib2_AddRef(*ppTLib); Wine-dbg>bt bt Backtrace: =>0 0x40a653f5 (ITypeInfo_fnGetContainingTypeLib+0x35(iface=0x4041753c, ppTLib=0x41576a38, pIndex=0x41576a3c) [typelib.c:4303] in liboleaut32.so) (ebp=41576a10) 1 0x40a6518d (ITypeInfo_fnGetRefTypeInfo+0xed(iface=0x4041753c, hRefType=0x2, ppTInfo=0x41576a70) [typelib.c:4209] in liboleaut32.so) (ebp=41576a40) 2 0x40a587e8 (TL_MarshalType+0x358(pStm=0x40409e38, pInfo=0x4041753c, pType=0x404178fc, args=0x41104844, first=0x0, is_iid=0x41576d18) [proxy.c:206] in liboleaut32.so) (ebp=41576a8c) 3 0x40a58729 (TL_MarshalType+0x299(pStm=0x40409e38, pInfo=0x4041753c, pType=0x404178b4, args=0x40415908, first=0x0, is_iid=0x41576d18) [proxy.c:181] in liboleaut32.so) (ebp=41576ae4) 4 0x40a58729 (TL_MarshalType+0x299(pStm=0x40409e38, pInfo=0x4041753c, pType=0x40417898, args=0x41576c48, first=0x0, is_iid=0x41576d18) [proxy.c:181] in liboleaut32.so) (ebp=41576b3c) 5 0x40a58e8a (TL_Marshal+0x24a(pStm=0x40409e38, pInfo=0x4041753c, pDesc=0x40417800, dwFlag=0x2, args=0x41576c48, res=0x0, is_iid=0x41576d18, id=0x41576d18) [proxy.c:358] in liboleaut32.so) (ebp=41576bc4) 6 0x40a5a249 (PSOAStub_Invoke+0x779(iface=0x40416e24, pMsg=0x41576d60, pChannel=0x40409d0c) [proxy.c:778] in liboleaut32.so) (ebp=41576d28) 7 0x409a219e (LRPC_process+0xce(chan=0x40409d0c) [compobj.c:1167] in libole32.so) (ebp=41576da0) 8 0x409a247f (LRPC_feed+0x23f(lClass=0x40408bd4, hPipe=0x58) [compobj.c:1245] in libole32.so) (ebp=41576e34) 9 0x409a25e0 (LRPC_server_thread+0x130(the_arg=0x40408bd4) [compobj.c:1269] in libole32.so) (ebp=41576f1c) 10 0x400e0cf8 (THREAD_Start+0x98 [thread.c:271] in libntdll.so) (ebp=41576f38) 11 0x400dfef8 (SYSDEPS_StartThread+0x38(teb=0x41587000) [sysdeps.c:72] in libntdll.so) (ebp=41576ff4) 12 0x40350baa (NTDLL.DLL.memcpy+0x5c64a in libc.so.6) (ebp=00000000) Can anything be done about that? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 3

Re: wine/memory virtual.c
by Alexandre Julliard 24 Oct '01

24 Oct '01

Ove Kaaven <ovehk(a)ping.uio.no> writes: > Since main_exe_file is apparently never used again anyway after > init_process_done, I've simply used the following hack to close the .exe > file on the wineserver side, assuming the server file object only needs to > exist to detect sharing violations, not for actually ever accessing the > file again: It's used at least in debug events, so yes it's possible that the debugger will try to use the handle to read the file. Probably better to close it completely when on removable media; and we'll need to do this for dlls too. I'll try to come up with something. -- Alexandre Julliard julliard(a)winehq.com

1 0

ptrace differences in kernel 2.4.7
by Simon Britnell 24 Oct '01

24 Oct '01

Having reviewed the changelog for Linux 2.4.7, I find that the ptrace attach code was amalgamated from many architecture dependant files into one function : ptrace_attach. This function differs from previous functions on i386 in that it returns EPERM if: 1) task->mm is NULL 2) task->pid <= 1 3) !task->mm->dumpable whereas pre 2.4.7 was !task->dumpable Further investigation shows that dumpable has been moved from task_struct to mm_struct. My investigation has not been sufficient to determine the final cause, but most things can be overridden by CAP_SYS_PTRACE, which I'll look into tomorrow PM. G'night all. __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com

2 1

InstallShield 6 - success
by Ove Kaaven 24 Oct '01

24 Oct '01

Apart from the two patches I just submitted to wine-patches, a stdole32.tlb from real Windows, and the registry entries in winedefault.reg, you need my interprocess com hacks, which I've now put on WineHQ: http://www.winehq.com/~ovek/install.diff The installation progress bar doesn't seem to display for some reason (might be a repaint issue or something else related to Alexandre's latest work, or something completely different, don't know), but anyway, even if it doesn't tell you its progress, it actually successfully installs now! I hope I can get enough time to structure that interprocess com stuff properly, so that it can work the way MS designed it, which involves RPCRT4.dll and friends...

6 5

Re: wine/memory virtual.c
by Ove Kaaven 24 Oct '01

24 Oct '01

On Tue, 23 Oct 2001, Alexandre Julliard wrote: > Modified files: > memory : virtual.c > > Log message: > Try to use read instead of mmap for files on removable media, so that > we don't need to keep the mapping handle open. OK, I see that you did this part too, which I hadn't submitted yet... but there's still one thing missing; the .exe file is still open inside the wineserver, still having two outstanding references: - main_exe_file in scheduler/process.c - process->exe.file in server/process.c Since main_exe_file is apparently never used again anyway after init_process_done, I've simply used the following hack to close the .exe file on the wineserver side, assuming the server file object only needs to exist to detect sharing violations, not for actually ever accessing the file again: --- server/process.c 2001/03/05 22:55:56 1.1.1.9 +++ server/process.c 2001/10/19 16:40:52 1.4 @@ -802,6 +802,8 @@ { if (process->exe.file) release_object( process->exe.file ); process->exe.file = file; + /* close the unix file, so the media the file was on can be changed */ + remove_select_user( (struct object *)file ); } generate_startup_debug_events( current->process, req->entry ); set_event( process->init_event ); Maybe you have a better way to do it?

1 0

Latest in the homeworld/wineoss saga.
by Simon Britnell 24 Oct '01

24 Oct '01

I've attacked homeworld for a couple of hours with IDA free and none of the places that set the value of the NULL pointer are remotely close to a waveOutWrite call. I've run -debugmsg +wave with and without the synchronous wodWrite patch. The results are fairly large so I won't send them unless you feel they're particularly useful. To summarise: Both have 2 wodOpen calls. Both produce "Oooch buffer underrun" messages. The synchronous wodWrite version does only one wodWrite and a large number of Oooch messages. The asynchronous one produces one Oooch per wodWrite. Here's a more detailed description of the fault, followed by a couple of ideas on what's really going wrong: -- DESCRIPTION OF STARTUP -- The game starts with a 2D animated Sierra online logo followed by an animated relic logo and then drops into the game menus which are 2D graphics. mode. There are 3 distinct behaviours by the game: 1) Immediately prior to playing the Sierra logo, the game produces an exception report complaining of a page fault referencing 0x0000000. The animation starts and plays behind the exception dialog, but there is no sound. If the exception dialog is ignored, it disappears when the game menu is drawn. The menus can be navigated until either the graphics mode is changed or the actual game is started at which time wine hangs. top shows 30% of CPU taken by each of two wine processes and a wineserver. Tracing with remote gdb shows WaitForSingleObject in the stack traces, when they can be seen (Usually by running gdb as root). I usually have trouble getting the correct symbols loaded. 2) As per (1) above, but no exception dialog appears. 3) The game starts and runs with sound. There is no hang. While writing this, I had an idea. More to follow in a later post :) __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com

2 2

Lindows
by Uwe Bonnes 24 Oct '01

24 Oct '01

Hallo, does anybody know more about "Lindows" than the sparse information they annouce on their webpage and the press releases? I don't think they reimplemented the win32 api, so I guess they use wine code. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

datacache bug
by giorgian 24 Oct '01

24 Oct '01

hi all, as i wrote few days ago, there's a problem with the DataCache_GetAdvise function in dlls/ole32/datacache.c: the call (this->sinkInterface)->lpVtbl->QueryInterface(this->sinkInterface, &IID_IAdviseSink, (void**)ppAdvSink); crashes since this->sinkInterface is NULL. executing the program with the --debugmsg +relay option i've seen that there are no calls to DataCache_SetAdvise before this call, the sinkInferface field is not initialized. but the program works well under M$window$. looking here and there in the source, i tried to replace this call with this->lpvtbl2->QueryInterface(this->lpvtbl2, &IID_IAdviseSink, (void**)ppAdvSink); i don't know why, but it works. ok, what should i do now to let the world know this? thanks -- Pietro Giorgianni, Icube s.r.l. (via Ridolfi, 15 - Pisa (Italy)) giorgian(a)icube.it

1 0

Re: PATCH: revert version change
by Francois Gouget 24 Oct '01

24 Oct '01

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

1 1

Re: usleep in winmm/wineoss audio
by Simon Britnell 24 Oct '01

24 Oct '01

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

3 8

Re: Shlwapi functions _29, _30, _31
by Alexandre Julliard 24 Oct '01

24 Oct '01

"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

1 0

Shlwapi functions _29, _30, _31
by Guy L. Albertelli 24 Oct '01

24 Oct '01

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

1 0

Re: The big winsock patch
by Alexandre Julliard 23 Oct '01

23 Oct '01

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

1 0

Re: mediatype patch
by Alexandre Julliard 23 Oct '01

23 Oct '01

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

2 1

PATCH: add Win95 OSR2 to versions
by David Elliott 23 Oct '01

23 Oct '01

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 23 Oct '01

23 Oct '01

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 23 Oct '01

23 Oct '01

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 23 Oct '01

23 Oct '01

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 23 Oct '01

23 Oct '01

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 23 Oct '01

23 Oct '01

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 23 Oct '01

23 Oct '01

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 23 Oct '01

23 Oct '01

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 22 Oct '01

22 Oct '01

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 22 Oct '01

22 Oct '01

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

Re: Improving Wine focus handling
by Alexandre Julliard 22 Oct '01

22 Oct '01

Jukka Heinonen <jhei(a)iki.fi> writes: > - There have recently been lots of changes in directory > wine/windows/x11drv and I'm not sure whether the changes > are over yet. Definitely not over, they are only starting ;-) > - Alexandre did mention that this fix is in his todo list, > perhaps he has already planned a better way to do this fix. Yes, I'm going to work on that as part of fixing window activation for shared handles. I'm hoping to start on it this week, so you probably don't want to spend too much time on this right now. > - Mouse clicks over non-active windows should not automatically > result into focus transfer. In these cases, Windows sends a special > message that makes certain that the window really wants to gain focus. I don't think you should change X focus on mouse clicks. That is up to the window manager to decide. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: The big winsock patch
by Gerard Patel 22 Oct '01

22 Oct '01

At 12:57 AM 22/10/2001 -0700, you wrote: > Whoops. The patch was malformed but in such a way that it still >applied cleanly (thus fooling me). But a subtential part of winsock.h >was not getting patched. The best is to revert the previous patch and >apply this one. > I am recompiling in a separate tree right now. At least sock.c should >compile fine... Yes, it compiles. However : err:module:BUILTIN32_dlopen failed to load .so lib for builtin ws2_32.dll: /home/gerard/win/wine/dlls/libws2_32.so: undefined symbol: WSOCK32_gethostbyaddr err:module:PE_fixup_imports Module (file) ws2_32.dll (which is needed by wsock32.dll) not found err:module:load_library can't load wsock32.dll err:module:BUILTIN32_LoadLibraryExA loaded .so but dll wsock32.dll still not found Gerard

1 0

Re: The big winsock patch
by Gerard Patel 22 Oct '01

22 Oct '01

At 08:39 PM 21/10/2001 -0700, you (Francois Gouget) wrote: > > This patch fixes the issues listed in bug #118: gcc -c -I. -I. -I../include -I../include -g -O2 -Wall -mpreferred-stack-boundary=2 -D__WINE__ -D_REENTRANT -I/usr/X11R6/include -o sock.o sock.c In file included from ../include/winsock2.h:30, from sock.c:44: ../include/winsock.h:630:2: #endif without #if This on my stock Mandrake 8 - gcc 2.96, glibc 2.2.2 if it matters Gerard

1 0

Colour problems with latest DIB fix
by Johan Gill 21 Oct '01

21 Oct '01

Since the big DIB fix, red and blue are exchanged in some cases, for example in the install program for The Sims. This happens in both depth 16 and depth 24. /Johan Gill, johane(a)lysator.liu.se

2 2

MCI Question -- sound problem
by raddy 21 Oct '01

21 Oct '01

Hello guys. I've had a problem for a week already, and ive tried #winehq but they told me to suscribe to winedevel list so here i am. The problem is with sound support. Ive been able to make counter-strike (half-life game mod) run perfectly on my system, i have network support, opengl support and it all works perfectly ...still, i have no sound. (forgot to say that no sound in ANY applications i run besides this game) I have no previous windows installation, so i grabbed a system.ini file from a working windows 98 system. I also copied all mci* files from a working Windows installation in order to fix my problem but it seems it did not work. I have ALSA installed in a 2.4 kernel (soon 2.4.12). The errors the game prompts me are all about not being able to use the MCI system for playback ( i believe that means the mci wave driver for playing wav files ). Another weird thing is that THERE IS some sound while browsing the game menus (whenever i click in any menu option ) once i accept the error messages. Still, when the real thing starts its all muted. A strange thing i noticed is that my ~/.wine/config file didnt have any mci files in any of its config tags, but other people did, so i added them. using the native and builting options: "mcicda.drv" = "builtin, native" "mciseq.drv" = "builtin, native" "mciwave.drv" = "builtin, native" "mciavi.drv" = "native, builtin" "mcianim.drv" = "native, builtin" Yes, in my override tag. So, im no wine expert at all, but it seems Wine isnt using *at all* my windows 98 mci drivers located in wines c:\windows\system directory. Please, id rather need instant help, the linux gamers require gamming hours daily. Btw, ive downloaded the last source targz file from your site, and i was unable to make Winsock support work at all, ive heard of another guy that had the same problem, so i made him download the previous one and worked as it did for me too. Please check that out. Feel free to check out my cave at : http://community.core-sdi.com/~raddy/ Have a nice day, raddy .-

4 7

(WHOOPS, forgedaboudit) Re: Fix crash with certain debugmsgs
by David Elliott 21 Oct '01

21 Oct '01

On 2001.10.21 16:41 David Elliott wrote: [snip] > I noticed that most everything else in the file uses get_info() instead > of > calling NtCurrentTeb()->debug_info directly. And since the issues was > that > debug_info was NULL and it seems the get_info tackles this by creating it > this seemed to be the proper fix. > > -Dave > Looks like someone else noticed this too, and had a slightly better fix -Dave

1 0

datacache
by giorgian 21 Oct '01

21 Oct '01

Hi all, I'm working on a program under Wine. It works well using the Microsoft's OLE32, but we *absolutely* need it to work without it. The program crashes little after starting, inside the DataCache_GetAdvise function (in datacache.c), on the instruction: IAdviseSink_QueryInterface(this->sinkInterface, &IID_IAdviseSink, (void**)ppAdvSink); I tried to find out the problem, but I only understood that the structure this (created by the macro _ICOM_THIS_From_IViewObject2(DataCache, iface) ) is corrupted: this->sinkInterface is NULL. Can anybody help? (at least tell me if there's some explanation on the datacache.c file) thank you -- Pietro Giorgianni - Icube s.r.l. Via Ridolfi, 15 Pisa (Italy) giorgian(a)icube.it

2 1

Improving Wine focus handling
by Jukka Heinonen 21 Oct '01

21 Oct '01

In order to make Wine ICCCM compliant and to fix focus livelock problems, it is necessary for Wine to use WM_TAKE_FOCUS protocol. This makes it necessary to stop using override-redirect for non-transient windows. I have included below a patch that does both of these things. The patch seems to work fine even with full-screen games and it does make Wine focus handling to cooperate a lot better with window managers. However, I feel reluctant to submit this patch to wine-patches, at least before I do get some feedback about the patch. Here are some notes about the patch: - Done against the latest Wine cvs tree, file wine/dlls/ntdll/debugtools.c has some bugs that might need to be fixed first, though. - There have recently been lots of changes in directory wine/windows/x11drv and I'm not sure whether the changes are over yet. - Alexandre did mention that this fix is in his todo list, perhaps he has already planned a better way to do this fix. - Menus do work but activating them makes parent window lose focus. This does not look particularly nice. - It is highly likely that every single case of Wine using XSetInputFocus breaks ICCCM compliance. These need fixing. - It might be a good idea to make X11DRV_SetFocus call EVENT_TakeFocus, since there seems to be much shared code. - Mouse clicks over non-active windows should not automatically result into focus transfer. In these cases, Windows sends a special message that makes certain that the window really wants to gain focus. However, I don't think this is very important thing to do. Index: wine/windows/x11drv/event.c =================================================================== RCS file: /home/wine/wine/windows/x11drv/event.c,v retrieving revision 1.112 diff -u -r1.112 event.c --- wine/windows/x11drv/event.c 2001/10/18 21:38:59 1.112 +++ wine/windows/x11drv/event.c 2001/10/21 12:26:07 @@ -42,6 +42,7 @@ extern Atom wmProtocols; extern Atom wmDeleteWindow; +extern Atom wmTakeFocus; extern Atom dndProtocol; extern Atom dndSelection; @@ -116,7 +117,59 @@ static INPUT_TYPE current_input_type = X11DRV_INPUT_ABSOLUTE; static BOOL in_transition = FALSE; /* This is not used as for today */ +/*********************************************************************** + * EVENT_TakeFocus + */ +static void EVENT_TakeFocus( HWND hWnd, XAnyEvent *event, Time time ) +{ + XWindowAttributes win_attr; + BOOL bIsDisabled; + Window focusWindow; + HWND focusHandle; + + TRACE("called, X11 window is %08lx, window handle is %04x.\n", + event->window, hWnd); + + if (!hWnd) return; + + bIsDisabled = GetWindowLongA( hWnd, GWL_STYLE ) & WS_DISABLED; + + /* If the window has been disabled, + * revert the X focus back to the last focus window. This is to disallow + * the window manager from switching focus away while the app is + * in a modal state. + */ + if (bIsDisabled) + focusWindow = glastXFocusWin; + else + focusWindow = event->window; + + wine_tsx11_lock(); + + /* Change focus only if focus window is registered and viewable. */ + if (XFindContext( event->display, focusWindow, winContext, (char **)&focusHandle ) || + !XGetWindowAttributes( event->display, focusWindow, &win_attr ) || + (win_attr.map_state != IsViewable)) + { + wine_tsx11_unlock(); + return; + } + + TRACE("Set X11 focus to: %08lx\n", focusWindow); + XSetInputFocus( event->display, focusWindow, RevertToParent, time ); + + wine_tsx11_unlock(); + + glastXFocusWin = focusWindow; + if (focusHandle != GetForegroundWindow()) + { + TRACE("Set foreground window to: %04x\n", focusHandle); + SetForegroundWindow( focusHandle ); + } +} + + /*********************************************************************** * process_events */ @@ -274,6 +327,7 @@ break; case ButtonPress: + EVENT_TakeFocus(hWnd, (XAnyEvent*)event, ((XButtonEvent*)event)->time); X11DRV_ButtonPress( hWnd, (XButtonEvent*)event ); break; @@ -354,39 +408,6 @@ */ static void EVENT_FocusIn( HWND hWnd, XFocusChangeEvent *event ) { - WND *pWndLastFocus; - XWindowAttributes win_attr; - BOOL bIsDisabled; - - if (!hWnd) return; - - bIsDisabled = GetWindowLongA( hWnd, GWL_STYLE ) & WS_DISABLED; - - /* If the window has been disabled and we are in managed mode, - * revert the X focus back to the last focus window. This is to disallow - * the window manager from switching focus away while the app is - * in a modal state. - */ - if ( Options.managed && bIsDisabled && glastXFocusWin) - { - /* Change focus only if saved focus window is registered and viewable */ - wine_tsx11_lock(); - if (XFindContext( event->display, glastXFocusWin, winContext, - (char **)&pWndLastFocus ) == 0 ) - { - if (XGetWindowAttributes( event->display, glastXFocusWin, &win_attr ) && - (win_attr.map_state == IsViewable) ) - { - XSetInputFocus( event->display, glastXFocusWin, RevertToParent, CurrentTime ); - wine_tsx11_unlock(); - return; - } - } - wine_tsx11_unlock(); - } - - if (event->detail != NotifyPointer && hWnd != GetForegroundWindow()) - SetForegroundWindow( hWnd ); } @@ -397,10 +418,7 @@ */ static void EVENT_FocusOut( HWND hWnd, XFocusChangeEvent *event ) { - /* Save the last window which had the focus */ - glastXFocusWin = event->window; if (!hWnd) return; - if (GetWindowLongA( hWnd, GWL_STYLE ) & WS_DISABLED) glastXFocusWin = 0; if (event->detail != NotifyPointer && hWnd == GetForegroundWindow()) { @@ -1252,6 +1270,10 @@ EVENT_DropFromOffiX(hWnd, event); else if (event->data.l[0] == DndURL) EVENT_DropURLs(hWnd, event); + } + else if (event->message_type == wmProtocols && ((Atom)event->data.l[0]) == wmTakeFocus) + { + EVENT_TakeFocus(hWnd, (XAnyEvent*)event, (Time)event->data.l[1]); } else { #if 0 Index: wine/dlls/x11drv/window.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/window.c,v retrieving revision 1.27 diff -u -r1.27 window.c --- wine/dlls/x11drv/window.c 2001/10/18 21:38:59 1.27 +++ wine/dlls/x11drv/window.c 2001/10/21 12:27:57 @@ -44,6 +44,7 @@ Atom wmChangeState = None; Atom kwmDockWindow = None; Atom _kde_net_wm_system_tray_window_for = None; /* KDE 2 Final */ +Atom wmMotifHints = None; static LPCSTR whole_window_atom; static LPCSTR client_window_atom; @@ -109,7 +110,7 @@ if (managed) win->dwExStyle |= WS_EX_MANAGED; else win->dwExStyle &= ~WS_EX_MANAGED; - attr->override_redirect = !managed; + attr->override_redirect = 0; // FIXME: true for transient windows (menus) attr->colormap = X11DRV_PALETTE_PaletteXColormap; attr->save_under = ((win->clsStyle & CS_SAVEBITS) != 0); attr->cursor = None; @@ -332,6 +333,16 @@ wine_tsx11_lock(); + /* motif hints */ + if(!(win->dwExStyle & WS_EX_MANAGED)) + { + INT32 hints[5] = {2,0,0,0,0}; + XChangeProperty( display, data->whole_window, + wmMotifHints, wmMotifHints, + 32, PropModeReplace, + (char*)hints, 5 ); + } + /* wm protocols */ i = 0; protocols[i++] = wmDeleteWindow; @@ -594,8 +605,8 @@ winContext = XUniqueContext(); wmProtocols = XInternAtom( display, "WM_PROTOCOLS", False ); wmDeleteWindow = XInternAtom( display, "WM_DELETE_WINDOW", False ); -/* wmTakeFocus = XInternAtom( display, "WM_TAKE_FOCUS", False );*/ - wmTakeFocus = 0; /* not yet */ + wmTakeFocus = XInternAtom( display, "WM_TAKE_FOCUS", False ); + wmMotifHints = XInternAtom( display, "_MOTIF_WM_HINTS", False ); dndProtocol = XInternAtom( display, "DndProtocol" , False ); dndSelection = XInternAtom( display, "DndSelection" , False ); wmChangeState = XInternAtom (display, "WM_CHANGE_STATE", False); -- Jukka Heinonen <http://www.iki.fi/jhei/>

1 0

Remote Windows Registry API and other Win32 APIs now available
by Luke Kenneth Casson Leighton 19 Oct '01

19 Oct '01

hi there, i thought i'd put up a more eye-catching subject line. to clarify: yes, that's right, FreeDCE has a set of remote Win32 APIs. see http://dcerpc.net for details. if anyone would like to help get these integreated into wine, please contact me for more information. luke

1 0

Re: Page faults and instruction emulation
by Alexandre Julliard 19 Oct '01

19 Oct '01

Ove Kaaven <ovehk(a)ping.uio.no> writes: > Well, perhaps it could depend on the windows version somehow... No, you really don't want to have the layout of core data structures depend on the version. > Maybe... I was just concerned whether you'd like Wine to be subject to > lawsuits or something (reverse engineering, trade secrets, DMCA, > whatever... not that the kernel driver is really complex, though). > Also, I was afraid some games might refuse to work with --winver nt40 I don't think lawsuits should be a problem, as long as we make a reasonable effort to implement the correct functionality and not just fake it. Of course there's always a risk that someone will sue, but these days the risk exists as soon as you release 3 lines of code. We really should move towards an NT-like architecture as much as possible; this is where Windows is going too, and it's the only one we have a chance of making work 100% correctly. We'll never be able to implement the full brokenness of the Win95 "architecture" anyway, so it's better to concentrate on the things that we can make work right. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: File media type
by Alexandre Julliard 19 Oct '01

19 Oct '01

Ove Kaaven <ovehk(a)ping.uio.no> writes: > But since to do this, MapViewOfFile needs to know the media type, and the > file name is only known in CreateFile, I apparently need to store the > media type in the wineserver object to accomplish this. > > Would changing the wineserver protocol in this way be a good idea? It's certainly a possibility. It would be nice to be able to tell directly from the file descriptor, so that we wouldn't depend on the user getting the drive specifications right. But I can't think of a Unix function that would allow doing this cleanly. -- Alexandre Julliard julliard(a)winehq.com

3 2

Re: wine/port.h #include fixes
by Roger Fujii 19 Oct '01

19 Oct '01

> It's slowly coming around (Francois recent patches are key), > but we still have some fairly serious issues. Is this in? As of 10/17, it still blows up in NtCurrentTeb(). What does this function do? - is it trying to use a protected instruction? (in x86 instruction knowledge is pretty dated). > You've hit the first issue - being sure to use the > GNU tool chain. yup... want to try tackling that once I get the program to at least come up... > Doing a cvs update and trying again (after, of course, > Alexandre commits Francois' recent patches) may > bring you more joy. a bold statement.. :) I presume that you don't have to install it to test it out, right? (so long as I have LD_LIBRARY_PATH set to dlls:.). I take it that someone does have something that works on solx86? -r

3 6

Re: wine/port.h #include fixes
by Alexandre Julliard 19 Oct '01

19 Oct '01

Roger Fujii <rmf(a)lookhere.com> writes: > well, I think more to the point is that something says what > steps need to be done to run a specific version. The current > instructions just say to set LD_LIBRARY_PATH, which isn't > really correct. So, just for the record, all you have to do > is set LD_LIBRARY_PATH to srcdir:srcdir/dlls and WINESERVER > to srcdir/server/wineserver? Or do you need access to things > like winebuild? To make absolutely sure you don't pick anything from the configured prefix directory, you have to set WINESERVER, WINELOADER, WINEDLLPATH and LD_LIBRARY_PATH. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Page faults and instruction emulation
by Alexandre Julliard 19 Oct '01

19 Oct '01

Ove Kaaven <ovehk(a)ping.uio.no> writes: > I know of two Wine architecture issues that must be resolved before the > anti-debugger check can succeed in win95 mode. > > 1. it checks that teb->debug_context (TEB offset 0x20) is zero. In Wine, > it isn't (the NT pid is stored there), so this check fails. > > Is it possible to change Wine's TEB structure to fix this? It would probably break some of the NT native dlls. > 2. it messes with the IDT. It uses the sidt instruction and tries to > change the INT5 vector (BOUND exception vector), later to try to execute a > BOUND and expect this vector to be branched to, all protected with > exception handlers. Now, this would actually be possible for Wine to > emulate, even though sidt is not a privileged instruction. The idea is > that sidt returns an address to kernel space, where all access is > prohibited, hence causing page faults. Wine could trap these, and then > emulate the faulting instruction by operating on a fake IDT instead. And > then the segfault caused by BOUND could then look up the fake IDT entry, > and call the vector therein. > > But to emulate an instruction from Wine's pre-exception page fault handler > (VIRTUAL_HandleFault()), the current context must be passed along to it, > so VIRTUAL_HandleFault and all Wine handlers that can be registered with > VIRTUAL_SetFaultHandler must get an extra parameter. Is this too > objectionable to do? The extra parameter is not that bad, but having to do full emulation of all instructions accessing memory, plus the complete IDT handling, is going to lead to major ugliness. Wouldn't it be possible to somehow emulate the kernel driver to make the NT version work? That would be much cleaner. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: wine/port.h #include fixes
by Alexandre Julliard 19 Oct '01

19 Oct '01

Fran�ois Gouget <fgouget(a)codeweavers.com> writes: > Should Wine really try the installed prefix first? It seems to me > that it should try it last instead. After all, if you change the path > you would expect your change to have an effect, no? No, you don't want changing the PATH suddenly to start breaking your applications. > Plus checking the > installed prefix first assumes that whichever version of wine is started > (e.g. /home/fgouget/bin/wine) is the same as that of > /usr/bin/wineserver! Yes of course, if you compiled it with /usr/bin as prefix it assumes that /usr/bin is where its wineserver is. If you don't want that you have to change the prefix, or set WINESERVER explicitly. -- Alexandre Julliard julliard(a)winehq.com

2 1

Page faults and instruction emulation
by Ove Kaaven 19 Oct '01

19 Oct '01

As we all know, some (kinda worthless) "copy protection" software exist out there that doesn't work under Wine. Some of these work under win9x and winNT by using a different set of techniques for each OS. The winNT code installs a kernel driver, so I'm mainly interested in the win95 code, which only messes with Win95 internals to check that no debugger is snooping, before proceeding. I know of two Wine architecture issues that must be resolved before the anti-debugger check can succeed in win95 mode. 1. it checks that teb->debug_context (TEB offset 0x20) is zero. In Wine, it isn't (the NT pid is stored there), so this check fails. Is it possible to change Wine's TEB structure to fix this? 2. it messes with the IDT. It uses the sidt instruction and tries to change the INT5 vector (BOUND exception vector), later to try to execute a BOUND and expect this vector to be branched to, all protected with exception handlers. Now, this would actually be possible for Wine to emulate, even though sidt is not a privileged instruction. The idea is that sidt returns an address to kernel space, where all access is prohibited, hence causing page faults. Wine could trap these, and then emulate the faulting instruction by operating on a fake IDT instead. And then the segfault caused by BOUND could then look up the fake IDT entry, and call the vector therein. But to emulate an instruction from Wine's pre-exception page fault handler (VIRTUAL_HandleFault()), the current context must be passed along to it, so VIRTUAL_HandleFault and all Wine handlers that can be registered with VIRTUAL_SetFaultHandler must get an extra parameter. Is this too objectionable to do? Alexandre?

1 0

File media type
by Ove Kaaven 18 Oct '01

18 Oct '01

I'm trying to think of a way to make multi-CD installers work under Wine. Right now, the hardest part is that when the installers tell you to change discs, the Setup.exe file mappings are still open. I'm thinking of making Wine not map the file, but read it straight into RAM, if the executable to be mapped is on removable media. But since to do this, MapViewOfFile needs to know the media type, and the file name is only known in CreateFile, I apparently need to store the media type in the wineserver object to accomplish this. Would changing the wineserver protocol in this way be a good idea? Index: server/protocol.def =================================================================== RCS file: /cvsroot/winex/wine/server/protocol.def,v retrieving revision 1.5 diff -u -r1.5 protocol.def --- server/protocol.def 2001/10/13 20:20:06 1.5 +++ server/protocol.def 2001/10/18 22:50:29 @@ -505,6 +505,7 @@ unsigned int sharing; /* sharing flags */ int create; /* file create action */ unsigned int attrs; /* file attributes for creation */ + int mediatype; /* media type file is on */ VARARG(filename,string); /* file name */ @REPLY handle_t handle; /* handle to the file */ @@ -527,6 +528,7 @@ @REPLY int fd; /* file descriptor */ int type; /* the type of file */ + int mediatype; /* media type file is on */ @END #define FD_TYPE_INVALID 0 #define FD_TYPE_DEFAULT 1

2 1

Re: Use the debugmsg for the pthread FIXME messages.
by Alexandre Julliard 18 Oct '01

18 Oct '01

"Medland, Bill" <Bill.Medland(a)accpac.com> writes: > I am fed up with the pthread fixmes; we ought at least to be able to turn > them off with debugmsg. This will crash and burn if glibc calls a pthread function before ntdll has been properly initialized. Besides, the messages are annoying on purpose: to motivate someone to implement the missing functions... -- Alexandre Julliard julliard(a)winehq.com

1 0

lsarpc.idl API
by Luke Kenneth Casson Leighton 18 Oct '01

18 Oct '01

Mail-Followup-To: tng-technical(a)samba-tng.org, lsa-dev(a)lists.dcerpc.net, freedce-dev(a)lists.dcerpc.net, samba-ntdom(a)samba.org, samba-technical(a)samba.org, wine-dev(a)winehq.com User-Agent: Mutt/1.2.4i X-original-sender: lkcl(a)samba-tng.org Precedence: bulk Reply-To: tng-technical(a)lists.dcerpc.org X-list: tng-technical thanks to matty for the lsarpc.idl file: it compiles in dceidl (slightly modified) and we're away! client-side header file and API is generated _automatically_ by dceidl, for immediate use with freedce libraries. porting of TNG's srv_lsa_nt.c can now take place if anyone's interested. volunteers, anyone? luke p.s. we also have winreg.idl so that means that the Reg* API is also automatically available for immediate use. if anyone's interested.

1 0

Wine press : Safedisc by Transgaming
by Gerard Patel 18 Oct '01

18 Oct '01

http://www.businesswire.com/cgi-bin/f_headline.cgi?bw.101701/212902145&ticke r=MVSN Gerard

1 0

Re: RtlEnterCriticalSection
by Marcus Meissner 18 Oct '01

18 Oct '01

On Thu, Oct 18, 2001 at 12:22:10AM +0200, Michael Marxmeier wrote: > After encountering timeout messages from > RtlEnterCriticalSection i had a look at it. > > Since interlocked_inc() should never return zero > the following patch is likely necessary. > I was unable to test this as now wine crashes with > a segmentation fault (which also terminates gdb). That is a sign that your patch is faulty. Any number of threads can increase this counter, it only succeeds if the count is really 0 before the call. (0 meaning the critical section is completely unlocked). If it is any other number, it is either a recursive enter or a different thread. Ciao, Marcus > Michael > > --- critsection.c.orig Wed Oct 17 23:24:13 2001 > +++ critsection.c Thu Oct 18 00:04:32 2001 > @@ -233,7 +233,7 @@ > */ > NTSTATUS WINAPI RtlEnterCriticalSection( RTL_CRITICAL_SECTION *crit ) > { > - if (interlocked_inc( &crit->LockCount )) > + if (interlocked_inc( &crit->LockCount ) != 1) > { > if (crit->OwningThread == GetCurrentThreadId()) > { > >

2 2

Re: SystemParametersInfo / GetSystemMetrics
by Alexandre Julliard 18 Oct '01

18 Oct '01

Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > One more question while we are on it. > We are going to check whether X settings correspond to > our settings only on initialization and reload > requests and are not going to do the check in "Get" > logic, right? Yes; in fact I'd argue that we shouldn't care at all about X settings in most cases, except maybe to get initial values. For instance if the app remaps mouse buttons, or changes mouse threshold or whatever, you don't want to apply this to the whole X session IMO. If users want to reconfigure X behavior, they have to use the X configuration programs. -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: MDI FindWndPtr fix
by Alexandre Julliard 18 Oct '01

18 Oct '01

Mike McCormack <mike_mccormack(a)start.com.au> writes: > i think i fixed that one too in the patch... there's probably similar > problems in other files, since WIN_GetPtr and WIN_FindWndPtr seem do > basically the same thing, but one reference counts and one doesn't. i > think we're going to see WIN_GetPtr disappear eventually... maybe. No, it is WIN_FindWndPtr and the whole reference counting that is going to disappear. The reference counting is needed only when we give control to the application while holding the window lock, and this is something we should never do. Another difference is that WIN_GetPtr returns a special value for windows belonging to another process, to force us to think about this case and handle it properly. -- Alexandre Julliard julliard(a)winehq.com

1 0

Problem with kernel32 on SPARC solaris 8.0
by Mrugan 18 Oct '01

18 Oct '01

I am trying to link kernel32 and ntdll libraries to my source code on SPARC Solaris 8.0. My executable does not exit. It gets stuck after spawning 4 threads. The gdb trace is as below: Starting program: /export/home/mrugan/src/HACore/HaNuanceChannelComRCE/nuancetest.exe warning: Lowest section in /usr/lib/libintl.so.1 is .hash at 00000074 warning: Lowest section in /usr/lib/libw.so.1 is .hash at 00000074 [New LWP 1] [New LWP 2] [New LWP 3] [New LWP 4] ^C Program received signal SIGINT, Interrupt. 0xff19b390 in ___lwp_cond_wait () from /usr/lib/libc.so.1 (gdb) where #0 0xff19b390 in ___lwp_cond_wait () from /usr/lib/libc.so.1 #1 0xff192c08 in _lwp_cond_wait () from /usr/lib/libc.so.1 #2 0xfef8c2f0 in _lrw_wrlock () from /usr/lib/libthread.so.1 #3 0xff3bdacc in ?? () #4 0xff3c34f0 in ?? () #5 0xff3b29a0 in ?? () #6 0xff0863c8 in __DTOR_END__ () from /opt/wine/dlls/libkernel32.so #7 0xff02e140 in frame_dummy () from /opt/wine/dlls/libkernel32.so #8 0xff02cf80 in _init () from /opt/wine/dlls/libkernel32.so #9 0xff3bada0 in ?? () #10 0xff3baa18 in ?? () #11 0xff3c4da0 in ?? () #12 0xff3b2958 in ?? () (gdb) inf thr 8 Thread 3 0xfef8d948 in _reap_wait () from /usr/lib/libthread.so.1 7 Thread 2 (LWP 2) 0xff19ad50 in _signotifywait () from /usr/lib/libc.so.1 6 Thread 1 (LWP 1) 0xff19b390 in ___lwp_cond_wait () from /usr/lib/libc.so.1 * 5 LWP 1 0xff19b390 in ___lwp_cond_wait () from /usr/lib/libc.so.1 4 LWP 4 0xff19b390 in ___lwp_cond_wait () from /usr/lib/libc.so.1 3 LWP 3 0xff1988f4 in door_restart () from /usr/lib/libc.so.1 2 LWP 2 0xff19ad50 in _signotifywait () from /usr/lib/libc.so.1 * 1 LWP 1 0xff19b390 in ___lwp_cond_wait () from /usr/lib/libc.so.1 Note that I had to hit cntl-C to come out of thread message. I guess this is happening because kernel32 tries to use thread library. Is there any way I can make it use pthread or is there any other solution to this? Any help will be greatly appreciated Thanks Mrugan

1 1

RE: Q: Unimplemented control 256 for VxD device VNETBIOS
by Patrik Stridvall 18 Oct '01

18 Oct '01

> > NETBIOS.VXD. I propose you run with --debugmsg > +relay,+snoop,+vxd and try > > to decipher what is going on before that failing VXD call. > In the easiest > > Done. Please find the messages in the attachement. I shrinked > the 7 MB > file to those lines around the error message. But because I'm a > Windows's internal newbie it'll take me some hours to understand the > messages. But anyhow I'll investigate the messages later but also any > help is very welcome. >From the attachment: < 0806a488:CALL netapi32.1: Netbios(<unknown, check return>) ret=1001de6e < 0806a488:CALL netbios.6: _Netbios(<unknown, check return>) ret=7f9c1026 [snip] < 0806a488:Call kernel32.CreateFileA(7f875000 "\\\\.\\VNETBIOS",c0000000,00000003,00000000,00000003,00000080,00000000) ret=7f8710a6 [snip] < 0806a488:Call kernel32.DeviceIoControl(00000070,00000100,405f193c,00000040,00000000,000000 00,00000000,00000000) ret=7f871b0d < fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS < 0806a488:Ret kernel32.DeviceIoControl() retval=00000000 ret=7f871b0d [snip] < 0806a488:RET netbios.6: _Netbios(405f193c) retval = 00000000 ret=7f9c1026 < 0806a488:RET netapi32.1: Netbios(405f193c) retval = 00000000 ret=1001de6e Good. It seems to work exactly the way I thought (or rather hoped) it would. Now we can presumably forget about the VxD and the undocumented NETBIOS DLL and concentrate on implementing the documented NETAPI32 DLL. It would be intresting to know what the content of NCB structure that Netbios takes as pointer to as argument. So the next step would be to make a Wine implementation of the NETAPI32.DLL with a stub with an appropriate TRACE to display to NCB structure. I don't think I have time do it is the next few days though. Can somebody else please do it? PS. On second thought perhaps we should make the NETAPI32.DLL just a forward to the NETBIOS.DLL. It seems from the trace above that the Netbios function in NETAPI32.DLL is the same function as _Netbios in NETAPI32.DLL and Netbios is the only function in NETAPI32 while NETBIOS have more functions eventhough they are AFAIK undocumented.

2 3

Q: Unimplemented control 256 for VxD device VNETBIOS
by Michael Riedel 18 Oct '01

18 Oct '01

I am going to migrate the EDA software environment from Windows NT to Linux but I have still some software components requireing Windows. That's why I use Wine. I own and use some software packages licensed to a valid MAC address (flexlm MAC based license) and the corresponding NIC is present in the Linux system. Using wine-20010824 I get the following message: fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device VNETBIOS I scanned the Web resources and studied the file 'win32/device.c' a little bit but I got no answers to my questions. Is there already a solution/implementation for this service? I am also ready to contribute (at least I hope I'm able to do so and it would be fun ;-) but I need some advice (docus, especially related to the VNETBIOS VxD and some general hints). I'm looking forward for any hints. Michael -- ---------------------------------------- mriedel(a)inova-semiconductors.de ----------------------------------------

3 3

Re: MDI FindWndPtr fix
by Mike McCormack 18 Oct '01

18 Oct '01

Hey Uwe, i think i fixed that one too in the patch... there's probably similar problems in other files, since WIN_GetPtr and WIN_FindWndPtr seem do basically the same thing, but one reference counts and one doesn't. i think we're going to see WIN_GetPtr disappear eventually... maybe. Mike > Mike> This fixes a reference counting problem with MDI. (tested with > Mike> Koala term) > > Hallo, > > aren't there more problems of that kind, e.g. in windows/mdi.c > MDIClientWndProc_common in the WM_CREATE path? > > Bye ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Re: SystemParametersInfo / GetSystemMetrics
by Andriy Palamarchuk 18 Oct '01

18 Oct '01

By mistake I sent the response to you directly, instead of the newsgroup. --- Alexandre Julliard <julliard(a)winehq.com> wrote: > Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > > > Do you mean we can keep GetSystemMetrics simple if > we don't use all > > these synchronizations? Use some hardcoded values, > maybe load from > > registry and that's it? > > You need the synchronizations, but this doesn't mean > sysmetrics have > to be more complex. All it means is that when > something changes in > registry or x11, the code that does the change has > to do a > SYSMETRICS_Set to update the sysmetrics. But the > sysmetrics themselves > don't need to know anything except how to get the > initial value. > > > I don't see big difference between > SystemParametersInfo and > > GetSystemMetrics data. Sometimes these are even > the same! Example - flag > > SHOWSOUNDS. It can be read by GetSystemMetrics and > read and set by > > SystemParametersInfo. > > Yes they are the same, that's why you can have the > registry update > code either in sysparams.c or in sysmetrics.c; and > since we want to > keep sysmetrics simple it has to be in sysparams.c. > > > The infrastructure I created is used to access and > update SHOWSOUNDS > > flag. Can you suggest how to implement it in other > way? > > The existing implementation is OK, what you need is > to add registry > update in sysparams.c upon SPI_SETSHOWSOUNDS, and > add a call to > SystemParametersInfo(SPI_GETSHOWSOUNDS) in > SYSMETRICS_Init. You do not > need to add any registry access in sysmetrics.c, > everything will be > done by SystemParametersInfo. Ok, I see. I'll change the code and resend the patch. One more question while we are on it. We are going to check whether X settings correspond to our settings only on initialization and reload requests and are not going to do the check in "Get" logic, right? Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com

1 0

RE: Q: Unimplemented control 256 for VxD device VNETBIOS
by Patrik Stridvall 18 Oct '01

18 Oct '01

> Michael> I'm looking forward for any hints. > > These FLEX LMs are always a problem. > > I guess, the license isn't bind to a physical dongle on the parallel > port. So one can conclude that the software tries to read the > MAC. This > probably happens in a NETBIOS.DLL call which then probably calls the > NETBIOS.VXD. I propose you run with --debugmsg > +relay,+snoop,+vxd and try > to decipher what is going on before that failing VXD call. In > the easiest > approach, you can build a fake builtin NETBIOS DLL, with the > appropriate > function returning the MAC in the first approach hardcoded or > really reading > it with OS calls. > > If running with --debugmsg +snoop crashes, I have a hack that may help > there. I have also patches for an empty NETBIOS dll. Why haven't you submitted it? Did Alexandre reject it? Having empty version of a standard DLL is almost always useful. Of course Wine should be configured to use the native DLL in the first place but still. > However I guess that this probably isn't enough to make FLEX LM happy. It is worth trying as well. However NETBIOS.DLL is not documented like NETAPI32 AFAIK is so it is more likely that it calls NETAPI32. Also note the NETAPI32 imports the NETBIOS.DLL function _Netbios so it would be a little strange if the application called NETBIOS directly but you never know. :-) Oh, well. Only one way to find out. Please do as Uwe suggest and run wine with --debugmsg +relay,+snoop,+vxd and post the result.

2 1

RE: Unimplemented control 256 for VxD device VNETBIOS
by Patrik Stridvall 18 Oct '01

18 Oct '01

> I am going to migrate the EDA software environment from Windows NT to > Linux but I have still some software components requireing Windows. > That's why I use Wine. I own and use some software packages > licensed to > a valid MAC address (flexlm MAC based license) and the > corresponding NIC > is present in the Linux system. > > Using wine-20010824 I get the following message: > > fixme:win32:DeviceIoControl Unimplemented control 256 for VxD device > VNETBIOS Given what you said above I wouldn't be entirely suprised if control 256 of VNETBIOS return the MAC address. However... > I scanned the Web resources and studied the file 'win32/device.c' a > little bit but I got no answers to my questions. Is there already a > solution/implementation for this service? I am also ready to > contribute > (at least I hope I'm able to do so and it would be fun ;-) but I need > some advice (docus, especially related to the VNETBIOS VxD and some > general hints). ... documentation for VxD:s is virtually non existant. Find out how VxD:s work generally involves low level reverse engineering. > I'm looking forward for any hints. Hmm. Reading MSDN... There is a DLL called NETAPI32.DLL that is not currentlu implemented in Wine that has a function Netbios that possible calls the VNETBIOS VxD. Perhaps implementing this DLL in Wine would help at least it would be better than trying the figure out what the VNETBIOS VxD does. The function Netbios in NETAPI32.DLL is at least documented. Hmm. Reading some more... Netbios has a command NCBASTAT that retreives the adapter status in a structure called ADAPTER_STATUS that has a field: UCHAR adapter_address[6]; // Specifies encoded address of the adapter. This might be the MAC address. Implementing this in Wine wouldn't be that hard. If Linux provides a way to get the MAC that is. I assume Linux does but I don't know how. Does anybody else know?

5 4

Re: MDI FindWndPtr fix
by Uwe Bonnes 18 Oct '01

18 Oct '01

>>>>> "Mike" == Mike McCormack <mike_mccormack(a)start.com.au> writes: Mike> This fixes a reference counting problem with MDI. (tested with Mike> Koala term) Hallo, aren't there more problems of that kind, e.g. in windows/mdi.c MDIClientWndProc_common in the WM_CREATE path? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Dinput mouse handling
by Alexandre Julliard 17 Oct '01

17 Oct '01

This patch changes the dinput mouse handling to use the WH_MOUSE_LL hook instead of referencing mouse driver internals. Since I'm not using dinput, could someone please give this a try? Index: dlls/dinput/mouse/main.c =================================================================== RCS file: /opt/cvs-commit/wine/dlls/dinput/mouse/main.c,v retrieving revision 1.9 diff -u -r1.9 main.c --- dlls/dinput/mouse/main.c 2001/10/02 18:45:46 1.9 +++ dlls/dinput/mouse/main.c 2001/10/17 19:49:59 @@ -17,7 +17,6 @@ #include "wingdi.h" #include "winerror.h" #include "windef.h" -#include "mouse.h" #include "winuser.h" #include "dinput.h" @@ -105,7 +104,7 @@ BYTE absolute; /* Previous position for relative moves */ LONG prevX, prevY; - LPMOUSE_EVENT_PROC prev_handler; + HHOOK hook; HWND win; DWORD dwCoopLevel; POINT mapped_center; @@ -226,10 +225,7 @@ if (This->data_queue != NULL) HeapFree(GetProcessHeap(),0,This->data_queue); - /* Install the previous event handler (in case of releasing an acquired - mouse device) */ - if (This->prev_handler != NULL) - MOUSE_Enable(This->prev_handler); + if (This->hook) UnhookWindowsHookEx( This->hook ); DeleteCriticalSection(&(This->crit)); /* Free the DataFormat */ @@ -318,40 +314,30 @@ return 0; } -/* Our private mouse event handler */ -static void WINAPI dinput_mouse_event( DWORD dwFlags, DWORD dx, DWORD dy, - DWORD cButtons, DWORD dwExtraInfo ) +/* low-level mouse hook */ +static LRESULT CALLBACK dinput_mouse_hook( int code, WPARAM wparam, LPARAM lparam ) { - long posX = -1, posY = -1; - DWORD keyState, xtime, extra; - SysMouseAImpl* This = (SysMouseAImpl*) current_lock; - - EnterCriticalSection(&(This->crit)); - /* Mouse moved -> send event if asked */ - if (This->hEvent) - SetEvent(This->hEvent); - - if ( !IsBadReadPtr( (LPVOID)dwExtraInfo, sizeof(WINE_MOUSEEVENT) ) - && ((WINE_MOUSEEVENT *)dwExtraInfo)->magic == WINE_MOUSEEVENT_MAGIC ) { - WINE_MOUSEEVENT *wme = (WINE_MOUSEEVENT *)dwExtraInfo; - keyState = wme->keyState; - xtime = wme->time; - extra = (DWORD)wme->hWnd; - - if (dwFlags & MOUSEEVENTF_MOVE) { - if (dwFlags & MOUSEEVENTF_ABSOLUTE) { - posX = (dx * GetSystemMetrics(SM_CXSCREEN)) >> 16; - posY = (dy * GetSystemMetrics(SM_CYSCREEN)) >> 16; + LRESULT ret; + MSLLHOOKSTRUCT *hook = (MSLLHOOKSTRUCT *)lparam; + SysMouseAImpl* This = (SysMouseAImpl*) current_lock; + + if (code != HC_ACTION) return CallNextHookEx( This->hook, code, wparam, lparam ); + + EnterCriticalSection(&(This->crit)); + /* Mouse moved -> send event if asked */ + if (This->hEvent) + SetEvent(This->hEvent); + if (wparam == WM_MOUSEMOVE) { if (This->absolute) { - if (posX != This->prevX) - GEN_EVENT(This->offset_array[WINE_MOUSE_X_POSITION], posX, xtime, 0); - if (posY != This->prevY) - GEN_EVENT(This->offset_array[WINE_MOUSE_Y_POSITION], posY, xtime, 0); + if (hook->pt.x != This->prevX) + GEN_EVENT(This->offset_array[WINE_MOUSE_X_POSITION], hook->pt.x, hook->time, 0); + if (hook->pt.y != This->prevY) + GEN_EVENT(This->offset_array[WINE_MOUSE_Y_POSITION], hook->pt.y, hook->time, 0); } else { /* Now, warp handling */ if ((This->need_warp == WARP_STARTED) && - (posX == This->mapped_center.x) && (posY == This->mapped_center.y)) { + (hook->pt.x == This->mapped_center.x) && (hook->pt.y == This->mapped_center.y)) { /* Warp has been done... */ This->need_warp = WARP_DONE; goto end; @@ -360,122 +346,73 @@ /* Relative mouse input with absolute mouse event : the real fun starts here... */ if ((This->need_warp == WARP_NEEDED) || (This->need_warp == WARP_STARTED)) { - if (posX != This->prevX) - GEN_EVENT(This->offset_array[WINE_MOUSE_X_POSITION], posX - This->prevX, xtime, (This->dinput->evsequence)++); - if (posY != This->prevY) - GEN_EVENT(This->offset_array[WINE_MOUSE_Y_POSITION], posY - This->prevY, xtime, (This->dinput->evsequence)++); + if (hook->pt.x != This->prevX) + GEN_EVENT(This->offset_array[WINE_MOUSE_X_POSITION], hook->pt.x - This->prevX, hook->time, (This->dinput->evsequence)++); + if (hook->pt.y != This->prevY) + GEN_EVENT(This->offset_array[WINE_MOUSE_Y_POSITION], hook->pt.y - This->prevY, hook->time, (This->dinput->evsequence)++); } else { /* This is the first time the event handler has been called after a GetData of GetState. */ - if (posX != This->mapped_center.x) { - GEN_EVENT(This->offset_array[WINE_MOUSE_X_POSITION], posX - This->mapped_center.x, xtime, (This->dinput->evsequence)++); + if (hook->pt.x != This->mapped_center.x) { + GEN_EVENT(This->offset_array[WINE_MOUSE_X_POSITION], hook->pt.x - This->mapped_center.x, hook->time, (This->dinput->evsequence)++); This->need_warp = WARP_NEEDED; } - if (posY != This->mapped_center.y) { - GEN_EVENT(This->offset_array[WINE_MOUSE_Y_POSITION], posY - This->mapped_center.y, xtime, (This->dinput->evsequence)++); + if (hook->pt.y != This->mapped_center.y) { + GEN_EVENT(This->offset_array[WINE_MOUSE_Y_POSITION], hook->pt.y - This->mapped_center.y, hook->time, (This->dinput->evsequence)++); This->need_warp = WARP_NEEDED; } } } - This->prevX = posX; - This->prevY = posY; + This->prevX = hook->pt.x; + This->prevY = hook->pt.y; - if (This->absolute) { - This->m_state.lX = posX; - This->m_state.lY = posY; - } else { - This->m_state.lX = posX - This->mapped_center.x; - This->m_state.lY = posY - This->mapped_center.y; - } - } else { - /* Mouse reporting is in relative mode */ - posX = (long) dx; - posY = (long) dy; - if (This->absolute) { - long aposX, aposY; - - aposX = This->m_state.lX + posX; - if (aposX < 0) - aposX = 0; - if (aposX >= GetSystemMetrics(SM_CXSCREEN)) - aposX = GetSystemMetrics(SM_CXSCREEN); - - aposY = This->m_state.lY + posY; - if (aposY < 0) - aposY = 0; - if (aposY >= GetSystemMetrics(SM_CYSCREEN)) - aposY = GetSystemMetrics(SM_CYSCREEN); - - if (posX != 0) - GEN_EVENT(This->offset_array[WINE_MOUSE_X_POSITION], aposX, xtime, (This->dinput->evsequence)++); - if (posY != 0) - GEN_EVENT(This->offset_array[WINE_MOUSE_Y_POSITION], aposY, xtime, (This->dinput->evsequence)++); - - This->m_state.lX = aposX; - This->m_state.lY = aposY; + This->m_state.lX = hook->pt.x; + This->m_state.lY = hook->pt.y; } else { - if (posX != 0) - GEN_EVENT(This->offset_array[WINE_MOUSE_X_POSITION], posX, xtime, (This->dinput->evsequence)++); - if (posY != 0) - GEN_EVENT(This->offset_array[WINE_MOUSE_Y_POSITION], posY, xtime, (This->dinput->evsequence)++); - - This->m_state.lX = posX; - This->m_state.lY = posY; + This->m_state.lX = hook->pt.x - This->mapped_center.x; + This->m_state.lY = hook->pt.y - This->mapped_center.y; } - } } - } else { - ERR("Mouse event not supported...\n"); - goto end; - } - - if (TRACE_ON(dinput)) { - if (dwFlags & MOUSEEVENTF_MOVE) - TRACE(" %ld %ld (%s)", posX, posY, - (dwFlags & MOUSEEVENTF_ABSOLUTE ? "abs" : "rel")); - - if ( dwFlags & MOUSEEVENTF_LEFTDOWN ) DPRINTF(" LD "); - if ( dwFlags & MOUSEEVENTF_LEFTUP ) DPRINTF(" LU "); - if ( dwFlags & MOUSEEVENTF_RIGHTDOWN ) DPRINTF(" RD "); - if ( dwFlags & MOUSEEVENTF_RIGHTUP ) DPRINTF(" RU "); - - if ( dwFlags & MOUSEEVENTF_MIDDLEDOWN ) DPRINTF(" MD "); - if ( dwFlags & MOUSEEVENTF_MIDDLEUP ) DPRINTF(" MU "); - - if (!(This->absolute)) DPRINTF(" W=%d ", This->need_warp); - - DPRINTF("\n"); - } + TRACE(" msg %x pt %ld %ld (W=%d)", + wparam, hook->pt.x, hook->pt.y, This->absolute && This->need_warp ); - - if ( dwFlags & MOUSEEVENTF_LEFTDOWN ) { - GEN_EVENT(This->offset_array[WINE_MOUSE_L_POSITION], 0xFF, xtime, (This->dinput->evsequence)++); - This->m_state.rgbButtons[0] = 0xFF; - } - if ( dwFlags & MOUSEEVENTF_LEFTUP ) { - GEN_EVENT(This->offset_array[WINE_MOUSE_L_POSITION], 0x00, xtime, (This->dinput->evsequence)++); - This->m_state.rgbButtons[0] = 0x00; - } - if ( dwFlags & MOUSEEVENTF_RIGHTDOWN ) { - GEN_EVENT(This->offset_array[WINE_MOUSE_R_POSITION], 0xFF, xtime, (This->dinput->evsequence)++); - This->m_state.rgbButtons[1] = 0xFF; - } - if ( dwFlags & MOUSEEVENTF_RIGHTUP ) { - GEN_EVENT(This->offset_array[WINE_MOUSE_R_POSITION], 0x00, xtime, (This->dinput->evsequence)++); - This->m_state.rgbButtons[1] = 0x00; - } - if ( dwFlags & MOUSEEVENTF_MIDDLEDOWN ) { - GEN_EVENT(This->offset_array[WINE_MOUSE_M_POSITION], 0xFF, xtime, (This->dinput->evsequence)++); - This->m_state.rgbButtons[2] = 0xFF; - } - if ( dwFlags & MOUSEEVENTF_MIDDLEUP ) { - GEN_EVENT(This->offset_array[WINE_MOUSE_M_POSITION], 0x00, xtime, (This->dinput->evsequence)++); - This->m_state.rgbButtons[2] = 0x00; - } + switch(wparam) + { + case WM_LBUTTONDOWN: + GEN_EVENT(This->offset_array[WINE_MOUSE_L_POSITION], 0xFF, + hook->time, This->dinput->evsequence++); + This->m_state.rgbButtons[0] = 0xFF; + break; + case WM_LBUTTONUP: + GEN_EVENT(This->offset_array[WINE_MOUSE_L_POSITION], 0x00, + hook->time, This->dinput->evsequence++); + This->m_state.rgbButtons[0] = 0x00; + break; + case WM_RBUTTONDOWN: + GEN_EVENT(This->offset_array[WINE_MOUSE_R_POSITION], 0xFF, + hook->time, This->dinput->evsequence++); + This->m_state.rgbButtons[1] = 0xFF; + break; + case WM_RBUTTONUP: + GEN_EVENT(This->offset_array[WINE_MOUSE_R_POSITION], 0x00, + hook->time, This->dinput->evsequence++); + This->m_state.rgbButtons[1] = 0x00; + break; + case WM_MBUTTONDOWN: + GEN_EVENT(This->offset_array[WINE_MOUSE_M_POSITION], 0xFF, + hook->time, This->dinput->evsequence++); + This->m_state.rgbButtons[2] = 0xFF; + break; + case WM_MBUTTONUP: + GEN_EVENT(This->offset_array[WINE_MOUSE_M_POSITION], 0x00, + hook->time, This->dinput->evsequence++); + This->m_state.rgbButtons[2] = 0x00; + break; + } TRACE("(X: %ld - Y: %ld L: %02x M: %02x R: %02x)\n", This->m_state.lX, This->m_state.lY, @@ -484,10 +421,11 @@ end: if (This->dwCoopLevel & DISCL_NONEXCLUSIVE) { /* pass the events down to previous handlers (e.g. win32 input) */ - if (This->prev_handler) - This->prev_handler(dwFlags, dx, dy, cButtons, dwExtraInfo); + ret = CallNextHookEx( This->hook, code, wparam, lparam ); } + else ret = 1; /* ignore message */ LeaveCriticalSection(&(This->crit)); + return ret; } @@ -503,10 +441,7 @@ if (This->acquired == 0) { POINT point; - - /* This stores the current mouse handler. */ - This->prev_handler = mouse_event; - + /* Store (in a global variable) the current lock */ current_lock = (IDirectInputDevice2A*)This; @@ -525,9 +460,9 @@ This->m_state.rgbButtons[1] = (GetKeyState(VK_MBUTTON) ? 0xFF : 0x00); This->m_state.rgbButtons[2] = (GetKeyState(VK_RBUTTON) ? 0xFF : 0x00); - /* Install our own mouse event handler */ - MOUSE_Enable(dinput_mouse_event); - + /* Install our mouse hook */ + This->hook = SetWindowsHookExW( WH_MOUSE_LL, dinput_mouse_hook, 0, 0 ); + /* Get the window dimension and find the center */ GetWindowRect(This->win, &rect); This->win_centerX = (rect.right - rect.left) / 2; @@ -564,9 +499,9 @@ if (This->acquired) { /* Reinstall previous mouse event handler */ - MOUSE_Enable(This->prev_handler); - This->prev_handler = NULL; - + if (This->hook) UnhookWindowsHookEx( This->hook ); + This->hook = 0; + /* No more locks */ current_lock = NULL; -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: fixed PROPSHEET_CreatePage if called with PSP_DLGINDIRECT
by Alexandre Julliard 17 Oct '01

17 Oct '01

Kai Morich <mail(a)kai-morich.de> writes: > is it realy neccessary to clone a writable dialog template only for > changing the dialog style ? wouldn't it be simpler to somehow pass > the information that the dialog is part of a property sheet to > DIALOG_CreateIndirect, e.g. by setting some wine specific > information on the dialog owner hwnd ? Yes, we clearly need to avoid copying the template. It should be possible to either set the style after the window is created, or trap the WM_CREATE or WM_INITDIALOG message and change the style there. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: SystemParametersInfo / GetSystemMetrics
by Alexandre Julliard 17 Oct '01

17 Oct '01

Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > Submitting the same patch in more digestable form - > put all the changes in one diff file. Thanks, it's *much* better this way. Splitting patches into different files makes them a pain to deal with. > Created new infrastructure for GetSystemMetrics and > SystemParametersInfo functions. Used it toto implement > processing for SPI_GET/SETBEEP, SPI_GET/SETSHOWSOUNDS > system parameters. Created unit test. I'm not sure the infrastructure for sysmetrics is really necessary. I'd prefer that all the registry handling remain in the sysparams handling, and have SYSMETRICS_Init call SystemParametersInfo to initialize the few metrics that need it. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: BUG: mouse_event does not move pointer for relative coordinates
by Andriy Palamarchuk 17 Oct '01

17 Oct '01

Andriy P wrote: > The attached test program moves pointer under Windows > NT. > > Under Wine the pointer changes position on move > request in absolute coordinates and does not move for > relative coordinates. <skipped> I tracked down the bug. The issue - in mouse_event the cursor position change occured _before_ the new position was calculated. Old coordinates were used and the latest change in the pointer position did not become effective. I'll submit a patch. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com

1 0

Windows-format metafiles
by Aric Stewart 17 Oct '01

17 Oct '01

Hello all, I am doing so work trying to flesh out he implementation of SetWinMetaFileBits and as such need documentation on Windows-format metafiles (not enhanced metafiles i have that) There must exist specs and documentation from old 3.1 days, but I am having no luck finding it. Does anyone have pointers as to where i could find a spec for the windows format metafiles to help me out? thanks -aric

3 2

Re: PATCH: wine_dbgstr_an()
by Andreas Mohr 17 Oct '01

17 Oct '01

On Tue, Oct 16, 2001 at 10:58:01PM +0200, Johan Gill wrote: > Relay tracing would crash if it came upon a function call with an invalid > pointer as a parameter. > + return "(invalid)"; Hmm, is there any reason why you just return "(invalid)" ? IMHO this can be very misleading, as some programs use strings such as "invalid", "NOT_VALID" or whatever to have something to compare against to check for a valid return. Furthermore it doesn't indicate at all that this string content originates from within wine due to an invalid function argument. I'd use something like: "WINE RELAY: invalid string pointer !" or so. And, even better, sprintf() the string pointer value into a static buffer to be used as a replacement, so that the output of this buffer looks like: "WINE RELAY: invalid string pointer 0x00045213 !". -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

1 0

Re:Pajama Sam 2 and other games
by Eric Pouech 16 Oct '01

16 Oct '01

regarding the sound issues, there still may be some races in the buffer playback. however, there's no specification of sound latency under windows (how many buffers shall be queued in advance to ensure proper playback...). So, there's no guarantee on Wine right now of the latency to expect (in fact, I assume that wine's latency may be higher that Windows one, however I didn't check it). Which means that some program may run fine under windows and have some "holes" in their playback under wine. However, what's less understandable is that the program hangs (or at least doesn't provide any new sound) could run the program with -debugmsg +wave,+mmsys and send me the compreseed output. (BTW, if you want to look at the code, it's in dlls/winmm/wineoss/audio.c) A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle __________________________________________________________ Faites un voeu et puis Voila ! www.voila.fr Pendant tout l'été, gagnez une Ford Ka sur Voila Gratter ! http://cybergrattage.voila.fr/voila

1 0

Pajama Sam 2 and other games
by Ori Pessach 16 Oct '01

16 Oct '01

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I've been trying to run several games from Humongous Entertainment under wine 20011007, installed from an RPM. They run, except for a couple of problems: The first problem is that the sound pauses sometimes. While the sound is paused, the animation animation still plays. It seems like the introduction of a new sound into the mix makes it more likely for the sound to pause. Eventually, the sound will die completely, with the message: err:wave:wodPlayer_Message buffer overflow !? written to stdout. The game will halt at that point, hanging wine. At that point I can do a 'killall wine', and rerun it. The second problem is with the cursor: When you pick up an object, the games modify the cursor to a picture of the object. This doesn't work under wine, and the cursor just disappears. It reappears when you drop the object. The games seem to use the WaveOut API's to play sounds, and the background music is a PCM, not MIDI. From my days writing similar games, I remember that the only way to have low-latency sound mixing using WaveOut was to stop and restart the device, feeding it fresh buffers with the new sounds mixed in. If none of this rings a bell with anybody, I don't mind taking a look at the sound code, to try to figure out what's broken. The cursor problem probably has something to do with trying to create a cursor object from a color bitmap, but I'm just guessing. I'm not even sure what the cursor is supposed to look like, as I've never ran the games under Windows... Any ideas? Thanks, Ori Pessach -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7zG/wRWZDICaLP5ERAktsAKDLW/1hnRwJVfAExvOj24tMtvULogCg+RsA UcS6RDI6knfCr/yKeVYZVas= =zg/k -----END PGP SIGNATURE----- _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

1 0

Re: wine/port.h #include fixes
by Roger Fujii 15 Oct '01

15 Oct '01

fgouget(a)codeweavers.com wrote: > Doing this (except for port.h) I have a tree that builds on Solaris > with no _FILE_OFFSET_BITS warning. So if the above sounds good, I have > patches that are almost ready. > does this build run on solaris? I've been trying for the last couple of days to get the beast to run (compiles ok), but it segfaults in various places (currently in NtCurrentTeb()). This in on a solaris 8 dual CPU unit. This is using gas/gld (results were worse with as/ld). Any pointers on debugging this thing? Thanks. -r -- Roger Fujii <rmf(a)lookhere.com> Underemployed, and trying to keep it that way....

2 2

Messy diff
by Johan Gill 15 Oct '01

15 Oct '01

I found that there were problems with --debugmsg=+relay when hitting a function call with an invalid pointer as parameter. wine_dbgstr_an() would try to dereference the pointer, resulting in a crash. Here's a patch for it. If anything is done the wrong way, please comment on it. /Johan Gill, johane(a)lysator.liu.se

1 0

RE: wine/port.h #include fixes
by Patrik Stridvall 15 Oct '01

15 Oct '01

> François Gouget wrote: > > > > This is a followup on the previous config.h patch, this > time tackling > > the wine/port.h case. > > Hmmm, I see it has been applied to CVS already. But I'm > not too happy > with it anymore :-/ > > I found a problem with 'dlls/winsock/async.c' and > 'dlls/winsock/socket.c' and the DELETE macro. > * DELETE is defined in winnt.h > * DELETE is also defined by a socket-related Solaris header > (arpa/nameser_compat.h, included indirectly) > * so winnt.h undefs DELETE and then defines our value Yes. That is a problem. ERR IIRC is another problem on Solaris. That is why #include "debugtools.h" is always done after all other includes. > * 'wine/port.h' includes 'winnt.h'. So if we include it > first and then > include the Solaris header we get a redefinition error. No it doesn't. At least not any longer. >From "cvs log include/wine.h": < revision 1.15 < date: 2001/07/26 21:43:29; author: julliard; state: Exp; lines: +1 -1 < Patrik Stridvall <ps(a)leissner.se> < Removed inclusion of winnt.h because the porting layer shouldn't < include Windows specific stuff. Note that as the comment says we shouldn't include Windows specific stuff in the porting layer. > One possible solution would be to handle DELETE differently, e.g. > prefix it in Wine, and not prefix it for Winelib, or something like > that. But wine/port.h is not the only header that needs to include > 'config.h'. There is also: > > cdrom.h console.h > ts_shape.h ts_xf86dga.h ts_xf86dga2.h ts_xf86vmode.h ts_xlib.h > ts_xpm.h ts_xresource.h ts_xshm.h ts_xutil.h ts_xvideo.h > wine_gl.h > x11drv.h > > I think it would be wrong to move all these #includes so that they > are first. Plus for the ts_*.h headers I am not sure it would be very > good. Also #including config.h in these is a bit pointless > since we know > that the file including them will need to include config.h too. Sounds reasonable. > So I propose the following instead: > * config.h has no multiple include protection. Add one > (__WINE_CONFIG_H > macro). > * modify the above headers so that they don't include config.h but > contain the following instead: > #ifndef __WINE_CONFIG_H > # error You must include config.h to use this header > #endif > This will make sure that no-one forgets to include config.h when > necessary. > * modify all files that include the above headers so that > they include > config.h as the first header. This actually requires relatively little > work. That is probably a good idea. > * do the same for port.h > * debugtools.h also uses config.h because it needs NO_DEBUG_MSGS and > NO_TRACE_MSGS. Modify configure.in so that these are put on > the command > line instead. They are not the of the same nature as the other macros > anyway: they are completely system independent. Also this will make it > possible to use the Wine debug macros in Winelib applications. Then > debugtools.h will no longer need to #include config.h. This cuts the > number of files causing trouble in about half. That is probably a good idea too. > * there are 3 other files that #include config.h for no good reason > that I can see: gdi.h, heap.h and thread.h. Remove the #includes from > there. Anyway, winapi_check ensures that all the .c files that need > config.h already include it directly. Yes. However that algoritm (or rather heuristics) that decide this is not perfect but it catch most of the cases and the compiler catches a few more and the linker most (all?) of the rest. > * maybe modify winapi_check to make sure that no header file includes > 'config.h' (this would be the frosting on the cake) This is easy. I will do that if Alexandre accept a patch what requires this. > Doing this (except for port.h) I have a tree that builds on Solaris > with no _FILE_OFFSET_BITS warning. So if the above sounds good, I have > patches that are almost ready. Ah. Good.

1 0

Re: wine/port.h #include fixes
by François Gouget 15 Oct '01

15 Oct '01

François Gouget wrote: > > This is a followup on the previous config.h patch, this time tackling > the wine/port.h case. Hmmm, I see it has been applied to CVS already. But I'm not too happy with it anymore :-/ I found a problem with 'dlls/winsock/async.c' and 'dlls/winsock/socket.c' and the DELETE macro. * DELETE is defined in winnt.h * DELETE is also defined by a socket-related Solaris header (arpa/nameser_compat.h, included indirectly) * so winnt.h undefs DELETE and then defines our value * 'wine/port.h' includes 'winnt.h'. So if we include it first and then include the Solaris header we get a redefinition error. One possible solution would be to handle DELETE differently, e.g. prefix it in Wine, and not prefix it for Winelib, or something like that. But wine/port.h is not the only header that needs to include 'config.h'. There is also: cdrom.h console.h ts_shape.h ts_xf86dga.h ts_xf86dga2.h ts_xf86vmode.h ts_xlib.h ts_xpm.h ts_xresource.h ts_xshm.h ts_xutil.h ts_xvideo.h wine_gl.h x11drv.h I think it would be wrong to move all these #includes so that they are first. Plus for the ts_*.h headers I am not sure it would be very good. Also #including config.h in these is a bit pointless since we know that the file including them will need to include config.h too. So I propose the following instead: * config.h has no multiple include protection. Add one (__WINE_CONFIG_H macro). * modify the above headers so that they don't include config.h but contain the following instead: #ifndef __WINE_CONFIG_H # error You must include config.h to use this header #endif This will make sure that no-one forgets to include config.h when necessary. * modify all files that include the above headers so that they include config.h as the first header. This actually requires relatively little work. * do the same for port.h * debugtools.h also uses config.h because it needs NO_DEBUG_MSGS and NO_TRACE_MSGS. Modify configure.in so that these are put on the command line instead. They are not the of the same nature as the other macros anyway: they are completely system independent. Also this will make it possible to use the Wine debug macros in Winelib applications. Then debugtools.h will no longer need to #include config.h. This cuts the number of files causing trouble in about half. * there are 3 other files that #include config.h for no good reason that I can see: gdi.h, heap.h and thread.h. Remove the #includes from there. Anyway, winapi_check ensures that all the .c files that need config.h already include it directly. * maybe modify winapi_check to make sure that no header file includes 'config.h' (this would be the frosting on the cake) Doing this (except for port.h) I have a tree that builds on Solaris with no _FILE_OFFSET_BITS warning. So if the above sounds good, I have patches that are almost ready. -- François Gouget fgouget(a)codeweavers.com

1 0

Re: [Fwd: file inheritance]
by Alexandre Julliard 13 Oct '01

13 Oct '01

eric pouech <eric.pouech(a)wanadoo.fr> writes: > this patch hasn't been committed yet > is there any issue Alexandre ? None, except that the patch conflicts with Mike's changes that I committed a few days ago. I was hoping you would submit an updated patch so I wouldn't have to merge it myself ;-) -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: olepicture.c patch
by Francois Gouget 13 Oct '01

13 Oct '01

Wouldn't this be better (do the trick inside the #ifdef HAVE_JPEGLIB_H): #ifdef HAVE_LIBJPEG /* This is a hack, so jpeglib.h does not redefine INT32 and the like*/ #define XMD_H #ifdef HAVE_JPEGLIB_H +# define UINT16 JPEG_UINT16 # include <jpeglib.h> +# undef UINT16 #endif #endif -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ If it stinks, it's chemistry. If it moves, it's biology. If it does not work, It's computer science.

1 0

Re: added missing CloseHandle
by eric pouech 13 Oct '01

13 Oct '01

Kai Morich wrote: > > * dlls/shell32/shell.c > Kai Morich <mail(a)kai-morich.de> > InternalExtractIcon16 forgot to close file handle > > p.s. that's the reason why my last mail had no attachment, because the mailprogram couldn't open the still opened attachment file since we don't use the handle afterwards, it seems like OF_EXIST as a flag to OpenFile would be a much better way to handle this my 2 cents A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

1 0

Re: Don't TRACE NULL strings
by Dmitry Timoshkov 13 Oct '01

13 Oct '01

"FranГois Gouget" <fgouget(a)codeweavers.com> wrote: > - TRACE("(%p %p %x)\n",pidl,szOut,uOutSize); > + TRACE("(%p %p %x)\n",pidl,debugstr_a(szOut),uOutSize); ^^ ^^^^^^^^^^^^^^^^^ Please recheck for pointer format vs. string argument mismatches. -- Dmitry.

1 0

Re: PATCH: Fix LoadCursor() under win9x
by Marcus Meissner 13 Oct '01

13 Oct '01

On Fri, Oct 12, 2001 at 03:16:04PM +0200, Johan Gill wrote: > LoadCursor() should return 0 if we emulate win9x and the second parameter > is an invalid pointer. > + if (HIWORD(name)) > + if (GetVersion() & 0x80000000) /* win9x */ > + if (IsBadReadPtr(name, 4)) > + return 0; This code is unclean: It should not check for versions. It should not use IsBadReadPtr(), but IsBadStringPtrA(). It should not use IsBad* functions, but an exception handler. I would suggest the patch below. Ciao, Marcus Changelog: Handle bad pointer arguments to LoadImageA() (and functions calling LoadImageA) with an exception handler. Index: cursoricon.c =================================================================== RCS file: /home/wine/wine/windows/cursoricon.c,v retrieving revision 1.35 diff -u -r1.35 cursoricon.c --- cursoricon.c 2001/10/05 19:38:14 1.35 +++ cursoricon.c 2001/10/12 16:50:03 @@ -36,6 +36,7 @@ #include "wingdi.h" #include "wine/winbase16.h" #include "wine/winuser16.h" +#include "wine/exception.h" #include "heap.h" #include "palette.h" #include "bitmap.h" @@ -2174,14 +2175,29 @@ * FIXME: implementation lacks some features, see LR_ defines in winuser.h */ +/* filter for page-fault exceptions */ +static WINE_EXCEPTION_FILTER(page_fault) +{ + if (GetExceptionCode() == EXCEPTION_ACCESS_VIOLATION) + return EXCEPTION_EXECUTE_HANDLER; + return EXCEPTION_CONTINUE_SEARCH; +} + HANDLE WINAPI LoadImageA( HINSTANCE hinst, LPCSTR name, UINT type, INT desiredx, INT desiredy, UINT loadflags) { HANDLE res; LPWSTR u_name; - if (HIWORD(name)) u_name = HEAP_strdupAtoW(GetProcessHeap(), 0, name); - else u_name=(LPWSTR)name; + __TRY { + if (HIWORD(name)) u_name = HEAP_strdupAtoW(GetProcessHeap(), 0, name); + else u_name=(LPWSTR)name; + } + __EXCEPT(page_fault) { + SetLastError( ERROR_INVALID_PARAMETER ); + return 0; + } + __ENDTRY res = LoadImageW(hinst, u_name, type, desiredx, desiredy, loadflags); if (HIWORD(name)) HeapFree(GetProcessHeap(), 0, u_name); return res;

2 2

winemaker
by lawson_whitney＠juno.com 13 Oct '01

13 Oct '01

Good day! I like winemaker, but it frustrates me. Given a standard wine installation (from source in /oof/wine, ./configure, make depend && make, make install) and a little winelib program with a handmade .spec file in subdirectory wlp, and the command winemaker --nosource-fix --console --nogenerated-specs \ --single-target toj2 wlp why does it make a configure script that can find -lwine, but can not find -lntdll - ? They are both in /usr/local/lib ... checking whether we can build a Linux dll... yes checking whether we need to define __i386__... no checking for g++ -fpermissive option... yes checking for g++ -fno-for-scope option... yes checking for windef.h header... /usr/local/include/wine checking for -lwine... checking for libntdll.so... configure: error: Could not find the Wine dlls (libntdll.so) The Winelib program is responsible to bring you this letter, but I had to hand-hack some scripts to get it to compile. Well, it may take me a while, but you or I will solve it. Regards, Lawson ---oof---

2 6

Re: PATCH: Fix LoadCursor() under win9x
by Alexandre Julliard 12 Oct '01

12 Oct '01

Andreas Mohr <u4t5s0yq1001(a)sneakemail.com> writes: > Using your exception handler, LoadCursor() *always* returns 0 > on invalid parameter, which is WRONG in the NT 4 case > since it continues program execution without crashing. > > --> GetVersion() is required, check was (nearly) right IMHO. > Probably the best solution would be to use both an exception handler and > call GetVersion() on exception. Come on Andreas, we've been through this before. A version check must be added *only* when there is a real-life application that demonstrably depends on the version difference for proper behavior. So if you want the version check you'll have to show us an application that needs the crash in order to work right... -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: winebuild and circular DLL dependencies
by Alexandre Julliard 12 Oct '01

12 Oct '01

eric pouech <eric.pouech(a)wanadoo.fr> writes: > well, I think we need to differentiate two things: > - circular deps in normal imports > - circular refs of DLLs for delayed imports I consider that both are wrong. I think it's important to maintain proper layers and ensure that dll dependencies always go in one direction. Of course this is not always possible thanks to Microsoft design (or lack of it); but in the cases where we need to hack something I want it to be very explicit that something unusual is going on. If we make it so that any dll can easily import any other one, we'll quickly end up with an inextricable mess of cross-dll dependencies, simply because adding an import in the spec file for any dll that you may need is so much easier than having to use GetProcAddress and think about minimizing inter-dll calls because they are a pain to do. So there aren't really technical reasons we cannot do it, the issue is enforcing a structure by not making it too easy to do things the wrong way. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: winebuild and circular DLL dependencies
by Alexandre Julliard 12 Oct '01

12 Oct '01

Ove Kaaven <ovehk(a)ping.uio.no> writes: > Well, can this be done with delayed imports yet? I have a situation here > where ole32 imports stuff from rpcrt4 (windows uses delayed imports for > that), and rpcrt4 imports stuff from ole32 (again, windows uses delayed > imports). It would be nice if I could use the winebuild delayed import > mechanism to achieve this, instead of doing it manually with callout > tables and stuff... but I suppose winebuild has to be changed to read > the .spec files instead of using nm on compiled libraries... anyone > working on it? No, and I don't think it's a desirable feature, it's too error-prone. Besides, circular dependencies are really something to avoid, so it must not be too easy to do... (what does rpcrt4 need from ole32 BTW?) -- Alexandre Julliard julliard(a)winehq.com

3 2

BUG: mouse_event does not move pointer for relative coordinates
by Andriy P 12 Oct '01

12 Oct '01

The attached test program moves pointer under Windows NT. Under Wine the pointer changes position on move request in absolute coordinates and does not move for relative coordinates. I found out that variables PosX and PosY ARE updated in queue_mouse_event in windows/input.c. Can somebody give me a hint where to go from there? I don't see further any difference in processing between absolute and relative movement. In case somebody will fix this bug, don't worry about different relative distance reported under Windows and in Wine. I alredy fixed that part and will submit the patch soon. Thanks, Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com

1 0

Re:winebuild and circular DLL dependencies
by Eric Pouech 12 Oct '01

12 Oct '01

well, I must have this somewhere in my tree, but didn't publish it because Alexandre was somehow reluctant to use this type of features (not the reading of missing symbols from .spec files, but the circular deps). Alexandre, any "new" comments ? A+ > Well, can this be done with delayed imports yet? I have a situation here > where ole32 imports stuff from rpcrt4 (windows uses delayed imports for > that), and rpcrt4 imports stuff from ole32 (again, windows uses delayed > imports). It would be nice if I could use the winebuild delayed import > mechanism to achieve this, instead of doing it manually with callout > tables and stuff... but I suppose winebuild has to be changed to read > the .spec files instead of using nm on compiled libraries... anyone > working on it? > > > > --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle __________________________________________________________ Faites un voeu et puis Voila ! www.voila.fr Pendant tout l'été, gagnez une Ford Ka sur Voila Gratter ! http://cybergrattage.voila.fr/voila

1 0

winebuild and circular DLL dependencies
by Ove Kaaven 12 Oct '01

12 Oct '01

Well, can this be done with delayed imports yet? I have a situation here where ole32 imports stuff from rpcrt4 (windows uses delayed imports for that), and rpcrt4 imports stuff from ole32 (again, windows uses delayed imports). It would be nice if I could use the winebuild delayed import mechanism to achieve this, instead of doing it manually with callout tables and stuff... but I suppose winebuild has to be changed to read the .spec files instead of using nm on compiled libraries... anyone working on it?

1 0

Re: Nasty Evil Memory Fragmentation fix
by Alexandre Julliard 11 Oct '01

11 Oct '01

Ove Kaaven <ovehk(a)ping.uio.no> writes: > Not that much. Wine's allocator already implements the *features* of that > allocator (boundary tags, bins), it just doesn't implement all the > *strategies* used for selecting which free block to allocate memory from > (though the only big things we lack there is "best fit" and "wilderness > preservation", the latter of which Alexandre talked about). Well, we do have (almost) best fit, that's the only reason for having multiple free lists. It's just that we probably need more bins sizes to make it really useful. > We just need > to make sure Wine's free block selection routine uses the same strategies > as this allocator, and we'd get exactly the same performance as that > allocator, but without replacing the whole thing and sacrificing the > compatibility we have or introducing new bugs. Well, this depends how easy it is to plug the new allocator in; but if it doesn't require too many changes, it will certainly introduce less bugs than trying to tweak the existing code. Plus all the profiling work has been done already, which would have to be done on the Wine code. -- Alexandre Julliard julliard(a)winehq.com

1 0

FIXME:pthread_rwlock_rdlock
by 510045342665-0001＠t-online.de 11 Oct '01

11 Oct '01

Hi, I am running a compiler with wine. There are many fixme message that I can't switch off. What do they mean, is someone working on it, is the problem serious ? Not having them at stdout would be great :-) as the compiler output + wine fixmes get a little confusing... [scan1.c] FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock --Dirk

1 0

Re: Nasty Evil Memory Fragmentation fix
by Alexandre Julliard 11 Oct '01

11 Oct '01

Gavriel State <gav(a)transgaming.com> writes: > We ended up creating a new subheap every time one of these larger > blocks came along. The new space from the subheap then went to > the top of the freelist, so all the small allocations then filled > it up until the next large block allocation. IE: We never got a > chance to reuse freed blocks in older subheaps - at least not > very well. That's why we have multiple free lists. The code is using the Win95 values now, but there is no reason we couldn't add a few larger values in the HEAP_freeListSizes array, instead of creating a new mechanism. > Despite the workaround, we're still not too pleased with the current > heap allocator. It's quite slow, and still not as efficient as > it could be. It would probably be worth the effort to integrate > a new allocator - anyone know if there's a high-quality Wine-license- > compatible allocator out there? A new allocator would definitely be a good thing. This one was done the way it is in order to use a compatible memory layout, but it turns out this is not necessary so we could scrap it. -- Alexandre Julliard julliard(a)winehq.com

3 3

Re: fixed FILE_GetUnixHanlde for sockets
by Andreas Mohr 11 Oct '01

11 Oct '01

On Thu, Oct 11, 2001 at 06:53:33PM +0200, Kai Morich wrote: > added sock_get_info in server/sock.c (patch includes changelog) "Patch includes changelog". hmm, patch. which patch ? which changelog ? ;-) -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

1 0

SHGetSpecialFolderPathA and CSIDL_FOLDER_MASK
by Chris Green 11 Oct '01

11 Oct '01

I've been looking at this function, and I am starting to suspect we have the wrong definition of CSIDL_FOLDER_MASK (currently 0x00ff). What I've been seeing (eg. installing MS Office 97) seems to imply that only the lower 6 bits, rather than 8, are related to the folder, and the others are something else. Does anyone else think that the mask should be 0x003f? regards Chris _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

2 1

Re: Nasty Evil Memory Fragmentation fix
by Alexandre Julliard 11 Oct '01

11 Oct '01

Gavriel State <gav(a)transgaming.com> writes: > This still doesn't help us: as Ove points out, we still end up allocating > from newly created free blocks even if old blocks would suit us better. But you want to use new blocks in general. The exception is that you want to avoid using the uncommitted part at the end of the heap, and I agree we could do a special case for that. But it has nothing to do with the size of the block. > I've had a brief look at the code referenced by Adam Moss (found at > http://g.oswego.edu/dl/html/malloc.html), and it looks like it would > be a vast improvement over Wine's current Heap manager. It even has > Windows code that uses VirtualAlloc to reserve actual memory. Yes, that would certainly be better that tweaking the existing code. You may want to look at ptmalloc too, it's supposed to be better at multi-threading (at least to get some ideas, the license is not 100% compatible with ours). -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Nasty Evil Memory Fragmentation fix
by Alexandre Julliard 11 Oct '01

11 Oct '01

Ove Kaaven <ovehk(a)ping.uio.no> writes: > Well, after looking at some allocator algorithms, it seems to me there's > no reason to change neither the bin sizes nor the data structures. We just > have to change the free block selection algorithm - from my reading of the > code, right now it seems to always choose the *newest* (most recently > added) free block that's big enough. By changing it to always choose the > *oldest* free block instead, we'd already have a huge improvement. > (That's essentially the effect of Gav's patch, but only for big blocks, > but I suspect that could safely be done for *all* block sizes) I don't think that's a good idea. It's pretty bad for the cache and paging system to reuse oldest blocks first. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: wine/ include/win.h include/wine/server_protoc ...
by Gerard Patel 10 Oct '01

10 Oct '01

At 06:46 PM 10/10/2001 +0200, you wrote: >No the application does a SendMessage > >096ed3f8:Call user32.SendMessageA(ffffffff,0000c00c,00000000,00000000) ret=004141aa ffffffff = Broadcast message. Take a look at this /*********************************************************************** * broadcast_message_callback * * Helper callback for broadcasting messages. */ static BOOL CALLBACK broadcast_message_callback( HWND hwnd, LPARAM lparam ) { struct send_message_info *info = (struct send_message_info *)lparam; if (!(GetWindowLongW( hwnd, GWL_STYLE ) & (WS_POPUP|WS_CAPTION))) return TRUE; GetWindowLong does not work currently between processes. There are a lot to do for the whole of Apis to work between processes yes, but there is not so much remaining for this kind of installer to work IMO. Gerard

1 0

Buisness Apps
by Nick Hudson 10 Oct '01

10 Oct '01

Greetings, Has anyone got Quick Books Pro 2001 and ACT! 2000 to run on wine? In quick books I get this error when it goes to install it: fixme:ole:CoGetClassObject CLSCTX_LOCAL_SERVER not supported! and it says that the set up failed..... in ACT! 2001 I the install stalls out when I have to say what country I am in.... I have to ctrl+alt+F1 and do a killall to get rid of it. Also its not seeing my ethernet connection.... do I need to add anything to the config file to make this work right? I was trying to install IE over the web.... As far as I can tell it doesnt see that im on the network Thanks Nick Hudson

1 0

Re: wine/ include/win.h include/wine/server_protoc ...
by Alexandre Julliard 10 Oct '01

10 Oct '01

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > The WIN_FindWndPtr message flooded the xterm during install, so I supected > soething still wrong... There are still a *lot* of functions that need to be adapted for handles belonging to other processes, so yes if you run multiple processes right now you'll most likely get flooded with messages. Working on it... -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: wine/ include/win.h include/wine/server_protoc ...
by Alexandre Julliard 10 Oct '01

10 Oct '01

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > No the application does a SendMessage > > 096ed3f8:Call user32.SendMessageA(ffffffff,0000c00c,00000000,00000000) ret=004141aa > err:win:WIN_FindWndPtr window 1002a belongs to other process > err:win:WIN_FindWndPtr window 10021 belongs to other process > err:win:WIN_FindWndPtr window 10029 belongs to other process > 096ed3f8:Ret user32.SendMessageA() retval=00000001 ret=004141aa > 096ed3f8:Call user32.SendMessageA(ffffffff,0000c00d,00000000,00000000) ret=004141bc > err:win:WIN_FindWndPtr window 1002a belongs to other process > err:win:WIN_FindWndPtr window 10021 belongs to other process > err:win:WIN_FindWndPtr window 10029 belongs to other process > 096ed3f8:Ret user32.SendMessageA() retval=00000001 ret=004141bc > > 096ed3f8 is a process created with Winexec, so I expect it to be a > sibling. Why isn't the WindowsFunction of at least that process called? It will be called only if the process has created a top-level window. Could you check if this is the case? -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: CommandLineToArgvW fix
by Eric Pouech 10 Oct '01

10 Oct '01

just a last question (that I didn't check) what if the process name contains spaces like: C:\Program Files\foo\bar.exe what does Windows do ? returns in argv[0] "C:\Program" or "C:\Program Files". The later would also require testing of existence of the directories (doing a more semantical approach while current implementation is purely syntaxical) A+ > > > Here's another version that uses GlobalLock... > I also retested in Windows and I believe the comment about spaces was > wrong. > > > -- > Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ > It really galls me that most of the computer power in the world > is wasted on screen savers. > Chris Caldwell from the GIMPS project > http://www.mersenne.org/prime.htm > --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle __________________________________________________________ Faites un voeu et puis Voila ! www.voila.fr Pendant tout l'été, gagnez une Ford Ka sur Voila Gratter ! http://cybergrattage.voila.fr/voila

2 1

Re: wine/ include/win.h include/wine/server_protoc ...
by Gerard Patel 10 Oct '01

10 Oct '01

At 04:55 PM 10/10/2001 +0200, you wrote: . > Alexandre> Implemented inter-process FindWindow(). > >Shouldn't this avoid errors like these: >err:win:WIN_FindWndPtr window 1002a belongs to other process >err:win:WIN_FindWndPtr window 10021 belongs to other process >err:win:WIN_FindWndPtr window 10029 belongs to other process Handles of other process windows can be returned by FindWindow, yes. But current Wine returns them also in enumeration functions, like EnumWindows. A functions like SetCursor, when trying to set the cursor for all desktop children, triggers this kind of message. The error message shows that Wine development is not complete because some function fails between processes (in SetCursor case, it is X11DRV_get_whole_window), not necessarily a problem in FindWindow. Try to lookup the origin for the handles : it is a problem only if the app get them from a FindWindow call. Gerard

2 1

Re: Compiling WINE on solaris 7
by Jeremy White 10 Oct '01

10 Oct '01

> > First I thought this was a problem caused by the SUN as, but then I > installed the GNU as, and typed > "make clean; rm config.cache; configure && make depend && make" > but the problem remained. I suspect that the problem is that gcc is still invoking 'as' instead of 'gas'. My understanding is the only clean way to get gcc to use the GNU binutils is to rebuild it with such support. What we've done is very hackish, but seems to work - place symlinks called 'as', 'cc', and 'ld' that point to the respective GNU tools ahead of the 'normal' SUN tools in the PATH. HTH Jer

1 0

Re: wine/ include/win.h include/wine/server_protoc ...
by Uwe Bonnes 10 Oct '01

10 Oct '01

>>>>> "Alexandre" == Alexandre Julliard <julliard(a)winehq.com> writes: ... Alexandre> Implemented inter-process FindWindow(). Shouldn't this avoid errors like these: err:win:WIN_FindWndPtr window 1002a belongs to other process err:win:WIN_FindWndPtr window 10021 belongs to other process err:win:WIN_FindWndPtr window 10029 belongs to other process These errors still happens with the Quicklogic Installer. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Nasty Evil Memory Fragmentation fix
by Gavriel State 10 Oct '01

10 Oct '01

We just spent about 3 days tracking down a very subtle memory fragmentation problem in an app we're working on. The problem: App allocates lots of little blocks, then a few large blocks, then lots of little blocks. Throughout this process, many blocks would be freed from all over the heap. Repeat ad infinitum. We ended up creating a new subheap every time one of these larger blocks came along. The new space from the subheap then went to the top of the freelist, so all the small allocations then filled it up until the next large block allocation. IE: We never got a chance to reuse freed blocks in older subheaps - at least not very well. This fix addresses the problem by pushing 'large' freed blocks to the end of the free list, leaving 'small' blocks at the front, to be found sooner. The size of 'large' vs 'small' is tunable. Despite the workaround, we're still not too pleased with the current heap allocator. It's quite slow, and still not as efficient as it could be. It would probably be worth the effort to integrate a new allocator - anyone know if there's a high-quality Wine-license- compatible allocator out there? -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav(a)transgaming.com --- heap.c Wed Sep 26 19:11:21 2001 +++ /home/gavriels/transgaming/wine/memory/heap.c Tue Oct 9 23:53:15 2001 @@ -59,6 +59,8 @@ #define QUIET 1 /* Suppress messages */ #define NOISY 0 /* Report all errors */ +#define FREE_BLOCK_INSERTION_THRESHOLD 4096 + #define HEAP_NB_FREE_LISTS 4 /* Number of free lists */ /* Max size of the blocks on the free lists */ @@ -229,11 +231,11 @@ /*********************************************************************** - * HEAP_InsertFreeBlock + * HEAP_InsertFreeBlockAtFront * - * Insert a free block into the free list. + * Insert a free block into the front of the free list. */ -static void HEAP_InsertFreeBlock( HEAP *heap, ARENA_FREE *pArena ) +static void HEAP_InsertFreeBlockAtFront( HEAP *heap, ARENA_FREE *pArena ) { FREE_LIST_ENTRY *pEntry = heap->freeList; while (pEntry->size < pArena->size) pEntry++; @@ -244,6 +246,31 @@ pEntry->arena.next = pArena; } +/*********************************************************************** + * HEAP_InsertFreeBlockAtEnd + * + * Insert a free block into the end of the free list. + */ +static void HEAP_InsertFreeBlockAtEnd( HEAP *heap, ARENA_FREE *pArena ) +{ + FREE_LIST_ENTRY *pEntry = heap->freeList; + + /* Determine which free list contains blocks of the appropriate size. */ + while (pEntry->size < pArena->size) pEntry++; + + /* But we want to put this block on the end of said appropriate free list. + * So instead, find the list for the next size up, knowing that they are + * all connected. */ + if (++pEntry == heap->freeList+HEAP_NB_FREE_LISTS) + pEntry = heap->freeList; + + pArena->size |= ARENA_FLAG_FREE; + pArena->next = &pEntry->arena; + pArena->prev = pEntry->arena.prev; + + pArena->next->prev = pArena; + pArena->prev->next = pArena; +} /*********************************************************************** * HEAP_FindSubHeap @@ -372,7 +399,11 @@ /* Last, insert the new block into the free list */ pFree->size = size - sizeof(*pFree); - HEAP_InsertFreeBlock( subheap->heap, pFree ); + + if ((pFree->size & ARENA_SIZE_MASK) > FREE_BLOCK_INSERTION_THRESHOLD) + HEAP_InsertFreeBlockAtEnd( subheap->heap, pFree ); + else + HEAP_InsertFreeBlockAtFront( subheap->heap, pFree ); }

2 1

Fwd: Re: Remove annoying fatal_error() after wineserver crash
by Malte Starostik 10 Oct '01

10 Oct '01

Seems I'm too used to mailing lists which set Reply-to to the list... Am Wednesday 10 October 2001 01:15 schrieben Sie: > Malte Starostik <malte(a)kde.org> writes: > > not sure about the reason for that "the socket exists, but I can't > > connect" message, but IMHO it's pretty annoying. I hit this fatal_exit() > > very often while debugging reaktivate. And in such cases - or when > > starting an app from a desktop / startmenu icon - when wine's STDERR goes > > to ~/.xsession-errors instead of a shell, the user has no chance to > > figure why an app won't start. Well, long story, short patch which Works > > for Me (TM) but I don't know if there's anything wrong with doing this... > > The problem with this is that it creates a race condition and we may > end up with two servers running in the same directory, which is bad. > > The error message should only happen when a previous server has > crashed, which is a critical error (the server should never crash no > matter what the app does). In that case you should also have a core > file in the same directory as the socket, which you can use to debug > and fix the crash. Thanks for the hint, I'll try to reproduce it with an appropriate ulimit set. But right, an actual wineserver crash didn't happen in a while. Unfortunately I have some system instability currently, so many times the message was caused by a stale socket lying around after a solid lockup of my box. What tends to happen rather often though is that wineserver keeps running after I quit all windows/winelib apps and consumes 100% CPU. In some of such cases, it'll only die on SIGKILL, which also leaves a socket around. I agree that neither a system lockup nor a hanging wineserver should happen though :) Maybe there could be a wineserver.pid file in the same dir and only if the process identified therein doesn't exist anymore, the socket will be autoremoved? But after all it's not too big a problem, guess there are more important issues. -- Malte Starostik PGP: 1024D/D2F3C787 [C138 2121 FAF3 410A 1C2A 27CD 5431 7745 D2F3 C787]

2 1

Re: Remove annoying fatal_error() after wineserver crash
by Alexandre Julliard 09 Oct '01

09 Oct '01

Malte Starostik <malte(a)kde.org> writes: > not sure about the reason for that "the socket exists, but I can't connect" > message, but IMHO it's pretty annoying. I hit this fatal_exit() very often > while debugging reaktivate. And in such cases - or when starting an app from > a desktop / startmenu icon - when wine's STDERR goes to ~/.xsession-errors > instead of a shell, the user has no chance to figure why an app won't start. > Well, long story, short patch which Works for Me (TM) but I don't know if > there's anything wrong with doing this... The problem with this is that it creates a race condition and we may end up with two servers running in the same directory, which is bad. The error message should only happen when a previous server has crashed, which is a critical error (the server should never crash no matter what the app does). In that case you should also have a core file in the same directory as the socket, which you can use to debug and fix the crash. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: SHGetSpecialFolderPathA
by Chris Green 09 Oct '01

09 Oct '01

That's the last time _I_ send a patch in the early hours of the morning! I missed a few commas... This one is better... Index: include/shlobj.h =================================================================== RCS file: /home/wine/wine/include/shlobj.h,v retrieving revision 1.47 diff -u -3 -p -r1.47 shlobj.h --- include/shlobj.h 2000/09/26 00:00:59 1.47 +++ include/shlobj.h 2001/10/09 21:53:39 @@ -461,6 +461,9 @@ HRESULT WINAPI SHGetSpecialFolderLocatio #define CSIDL_SENDTO 0x0009 #define CSIDL_BITBUCKET 0x000a #define CSIDL_STARTMENU 0x000b +#define CSIDL_MYDOCUMENTS 0x000c +#define CSIDL_MYMUSIC 0x000d +#define CSIDL_MYVIDEO 0x000e #define CSIDL_DESKTOPDIRECTORY 0x0010 #define CSIDL_DRIVES 0x0011 #define CSIDL_NETWORK 0x0012 @@ -473,6 +476,7 @@ HRESULT WINAPI SHGetSpecialFolderLocatio #define CSIDL_COMMON_DESKTOPDIRECTORY 0x0019 #define CSIDL_APPDATA 0x001a #define CSIDL_PRINTHOOD 0x001b +#define CSIDL_LOCAL_APPDATA 0x001c #define CSIDL_ALTSTARTUP 0x001d #define CSIDL_COMMON_ALTSTARTUP 0x001e #define CSIDL_COMMON_FAVORITES 0x001f @@ -494,8 +498,17 @@ HRESULT WINAPI SHGetSpecialFolderLocatio #define CSIDL_COMMON_ADMINTOOLS 0x002f #define CSIDL_ADMINTOOLS 0x0030 #define CSIDL_CONNECTIONS 0x0031 +#define CSIDL_COMMON_MUSIC 0x0035 +#define CSIDL_COMMON_PICTURES 0x0036 +#define CSIDL_COMMON_VIDEO 0x0037 +#define CSIDL_RESOURCES 0x0038 +#define CSIDL_RESOURCES_LOCALIZED 0x0039 +#define CSIDL_COMMON_OEM_LINKS 0x003a +#define CSIDL_CDBURN_AREA 0x003b +#define CSIDL_COMPUTERSNEARME 0x003d #define CSIDL_FOLDER_MASK 0x00ff - +#define CSIDL_FLAG_PER_USER_INIT 0x0800 +#define CSIDL_FLAG_NO_ALIAS 0x1000 #define CSIDL_FLAG_DONT_VERIFY 0x4000 #define CSIDL_FLAG_CREATE 0x8000 Index: dlls/shell32/shellpath.c =================================================================== RCS file: /home/wine/wine/dlls/shell32/shellpath.c,v retrieving revision 1.56 diff -u -3 -p -r1.56 shellpath.c --- dlls/shell32/shellpath.c 2001/08/16 18:49:57 1.56 +++ dlls/shell32/shellpath.c 2001/10/09 21:53:41 @@ -660,7 +660,7 @@ static const CSIDL_DATA CSIDL_Data[] = "Desktop", "Desktop" }, - { /* CSIDL_INTERNET (??) */ + { /* CSIDL_INTERNET */ 0, 1, /* FIXME */ NULL, NULL, @@ -715,22 +715,22 @@ static const CSIDL_DATA CSIDL_Data[] = "Start Menu", "Start Menu" }, - { /* not known */ - 0, 0, + { /* CSIDL_MYDOCUMENTS */ + 0, 1, /* FIXME */ NULL, NULL, }, - { /* not known */ - 0, 0, + { /* CSIDL_MYMUSIC */ + 0, 1, /* FIXME */ NULL, NULL, }, - { /* not known */ - 0, 0, + { /* CSIDL_MYVIDEO */ + 0, 1, /* FIXME */ NULL, NULL, }, - { /* not known */ + { /* unassigned */ 0, 0, NULL, NULL, @@ -795,8 +795,8 @@ static const CSIDL_DATA CSIDL_Data[] = "PrintHood", "PrintHood" }, - { /* not known */ - 0, 0, + { /* CSIDL_LOCAL_APPDATA */ + 0, 0, /* FIXME */ NULL, NULL, }, @@ -904,6 +904,66 @@ static const CSIDL_DATA CSIDL_Data[] = 0, 1, /* FIXME */ NULL, NULL + }, + { /* unassigned 32*/ + 0, 0, + NULL, + NULL, + }, + { /* unassigned 33*/ + 0, 0, + NULL, + NULL, + }, + { /* unassigned 34*/ + 0, 0, + NULL, + NULL, + }, + { /* CSIDL_COMMON_MUSIC */ + 0, 0, /* FIXME */ + NULL, + NULL, + }, + { /* CSIDL_COMMON_PICTURES */ + 0, 0, /* FIXME */ + NULL, + NULL, + }, + { /* CSIDL_COMMON_VIDEO */ + 0, 0, /* FIXME */ + NULL, + NULL, + }, + { /* CSIDL_RESOURCES */ + 0, 0, /* FIXME */ + NULL, + NULL, + }, + { /* CSIDL_RESOURCES_LOCALIZED */ + 0, 0, /* FIXME */ + NULL, + NULL, + }, + { /* CSIDL_COMMON_OEM_LINKS */ + 0, 0, /* FIXME */ + NULL, + NULL, + }, + { /* CSIDL_CDBURN_AREA */ + 0, 0, /* FIXME */ + NULL, + NULL, + }, + { /* unassigned 3C */ + 0, 0, + NULL, + NULL, + }, + { /* CSIDL_COMPUTERSNEARME */ + 0, 0, /* FIXME */ + NULL, + NULL, } }; #undef HKCU @@ -926,7 +986,7 @@ BOOL WINAPI SHGetSpecialFolderPathA ( TRACE("0x%04x,%p,csidl=%lu,0x%04x\n", hwndOwner,szPath,csidl,bCreate); - if ((folder > CSIDL_CONNECTIONS) || (CSIDL_Data[folder].hRootKey == 0)) + if ((folder > CSIDL_COMPUTERSNEARME) || (CSIDL_Data[folder].hRootKey == 0)) { ERR("folder unknown or not allowed\n"); return FALSE; _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

1 0

Re: Service Pack Information in registry
by Nerijus Baliunas 09 Oct '01

09 Oct '01

On Mon, 8 Oct 2001 22:36:27 +0200 Stefan Leichter <Stefan.Leichter(a)camline.com> wrote: SL> Hello, SL> SL> during some investigations on CEMW i found a posting from Nerijus Baliunas SL> <nerijus(a)users.sourceforge.net> that contains the registry information to SL> make the installer of IE 4.0 thinking the SP3 is installed on a NT 4.0 system. SL> SL> Tschüß Stefan SL> SL> --- wine-20011004/winedefault.reg Fri Oct 5 13:12:57 2001 SL> +++ wine/winedefault.reg Mon Oct 8 22:25:33 2001 SL> @@ -100,6 +100,13 @@ SL> "OEMCP"="437" SL> SL> # SL> +# Win NT 4.0 with Service Pack 3 SL> +# SL> + SL> +[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Windows] SL> +"CSDVersion"="768" Maybe better to use "1536"? It means Service Pack 6. Regards, Nerijus

1 0

Half-Life hangs on "Loading"
by mdew 09 Oct '01

09 Oct '01

... warn:dosfs:DOSFS_FindUnixName 'ntdll.dll' not found in '/home/mdew/fake_windows/ SIERRA/Half-Life' warn:dosfs:DOSFS_FindUnixName 'ntdll.dll' not found in '/home/mdew/fake_windows/ Windows/System' warn:dosfs:DOSFS_FindUnixName 'ntdll.dll' not found in '/home/mdew/fake_windows/ Windows' warn:dosfs:DOSFS_FindUnixName 'ntdll.dll' not found in '/home/mdew/fake_windows/ Windows' warn:dosfs:DOSFS_FindUnixName 'ntdll.dll' not found in '/home/mdew/fake_windows/ Windows/System' warn:dosfs:DOSFS_FindUnixName 'ntdll.dll' not found in '/tmp' warn:dosfs:DOSFS_FindUnixName 'ntdll.dll' not found in '/home/mdew' FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock warn:file:CreateDirectoryA Error 'File exists' trying to create directory '/home /mdew/fake_windows/SAVE' warn:dosfs:DOSFS_FindUnixName '*.HL?' not found in '/home/mdew/fake_windows/SAVE ' warn:dosfs:DOSFS_FindUnixName 'pak1.pak' not found in '/home/mdew/fake_windows/S IERRA/Half-Life/valve' warn:file:CreateFileA Unable to get full filename from 'C:\SIERRA\Half-Life\valv e\pak1.pak' (GLE 2) warn:dosfs:DOSFS_FindUnixName 'custom.hpk' not found in '/home/mdew/fake_windows /SIERRA/Half-Life/valve' warn:file:CreateFileA Unable to get full filename from 'C:\SIERRA\Half-Life\valv e\custom.hpk' (GLE 2) warn:dosfs:DOSFS_FindUnixName 'palette.lmp' not found in '/home/mdew/fake_window s/SIERRA/Half-Life/valve/gfx' warn:gdi:GDI_GetObjPtr Invalid handle 0 warn:gdi:GDI_GetObjPtr Invalid handle 0 fixme:font:GetCharABCWidthsW (27f0,0000,00ff,0x41ccc8b4), returns slightly bogus values. warn:gdi:GDI_GetObjPtr Invalid handle 0 warn:gdi:GDI_GetObjPtr Invalid handle 0 fixme:font:GetCharABCWidthsW (27f8,0000,00ff,0x41ccd940), returns slightly bogus values. warn:gdi:GDI_GetObjPtr Invalid handle 0 warn:gdi:GDI_GetObjPtr Invalid handle 0 fixme:font:GetCharABCWidthsW (2800,0000,00ff,0x41cce9cc), returns slightly bogus values. warn:gdi:GDI_GetObjPtr Invalid handle 0 warn:gdi:GDI_GetObjPtr Invalid handle 0 fixme:font:GetCharABCWidthsW (2808,0000,00ff,0x41ccfa58), returns slightly bogus values. warn:dosfs:DOSFS_FindUnixName 'GameUI.dll' not found in '/home/mdew/fake_windows /SIERRA/Half-Life/valve/cl_dlls' warn:dosfs:DOSFS_FindUnixName 'cl_dlls\GameUI.dll' not found in '/home/mdew/fake _windows/SIERRA/Half-Life' warn:module:MODULE_LoadLibraryExA Failed to load module 'C:\WINDOWS\SYSTEM'; err or=0x00000002, FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock warn:module:BUILTIN32_dlopen cannot open .so lib for builtin client.dll: libclie nt.so: cannot open shared object file: No such file or directory FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock warn:win32:ELF_LoadLibraryExA failed to load libclient.so: libclient.so: cannot open shared object file: No such file or directory warn:dosfs:DOSFS_FindUnixName 'KERNEL32.dll' not found in '/home/mdew/fake_windo ws/SIERRA/Half-Life' warn:dosfs:DOSFS_FindUnixName 'KERNEL32.dll' not found in '/home/mdew/fake_windo ws/SIERRA/Half-Life' warn:dosfs:DOSFS_FindUnixName 'USER32.dll' not found in '/home/mdew/fake_windows /SIERRA/Half-Life' warn:dosfs:DOSFS_FindUnixName 'USER32.dll' not found in '/home/mdew/fake_windows /SIERRA/Half-Life' warn:dosfs:DOSFS_FindUnixName 'WINMM.dll' not found in '/home/mdew/fake_windows/ SIERRA/Half-Life' warn:dosfs:DOSFS_FindUnixName 'WINMM.dll' not found in '/home/mdew/fake_windows/ SIERRA/Half-Life' warn:dosfs:DOSFS_FindUnixName 'WSOCK32.dll' not found in '/home/mdew/fake_window s/SIERRA/Half-Life' warn:dosfs:DOSFS_FindUnixName 'WSOCK32.dll' not found in '/home/mdew/fake_window s/SIERRA/Half-Life' warn:dosfs:DOSFS_FindUnixName 'Bin/TrackerUI.dll' not found in '/home/mdew/fake_ windows/SIERRA/Half-Life/valve' warn:dosfs:DOSFS_FindUnixName 'sound/materials.txt' not found in '/home/mdew/fak e_windows/SIERRA/Half-Life/valve' warn:dosfs:DOSFS_FindUnixName 'sound/materials.txt' not found in '/home/mdew/fak e_windows/SIERRA/Half-Life/valve' warn:dosfs:DOSFS_FindUnixName 'sound/sentences.txt' not found in '/home/mdew/fak e_windows/SIERRA/Half-Life/valve' warn:dosfs:DOSFS_FindUnixName 'dsound.dll' not found in '/home/mdew/fake_windows /SIERRA/Half-Life' warn:dosfs:DOSFS_FindUnixName 'dsound.dll' not found in '/home/mdew/fake_windows /SIERRA/Half-Life' warn:dosfs:DOSFS_FindUnixName 'winmm.dll' not found in '/home/mdew/fake_windows/ SIERRA/Half-Life' warn:dosfs:DOSFS_FindUnixName 'winmm.dll' not found in '/home/mdew/fake_windows/ SIERRA/Half-Life' warn:dosfs:DOSFS_FindUnixName 'kernel32.dll' not found in '/home/mdew/fake_windo ws/SIERRA/Half-Life' warn:dosfs:DOSFS_FindUnixName 'kernel32.dll' not found in '/home/mdew/fake_windo ws/SIERRA/Half-Life' warn:dosfs:DOSFS_FindUnixName 'ntdll.dll' not found in '/home/mdew/fake_windows/ SIERRA/Half-Life' warn:dosfs:DOSFS_FindUnixName 'ntdll.dll' not found in '/home/mdew/fake_windows/ SIERRA/Half-Life' warn:dosfs:DOSFS_FindUnixName 'ntdll.dll' not found in '/home/mdew/fake_windows/ Windows/System' warn:dosfs:DOSFS_FindUnixName 'ntdll.dll' not found in '/home/mdew/fake_windows/ Windows' warn:dosfs:DOSFS_FindUnixName 'ntdll.dll' not found in '/home/mdew/fake_windows/ Windows' warn:dosfs:DOSFS_FindUnixName 'ntdll.dll' not found in '/home/mdew/fake_windows/ Windows/System' warn:dosfs:DOSFS_FindUnixName 'ntdll.dll' not found in '/tmp' warn:dosfs:DOSFS_FindUnixName 'ntdll.dll' not found in '/home/mdew' fixme:dsound:IDirectSoundImpl_SetCooperativeLevel (0x4040f398,00030048,3):stub err:ntdll:RtlpWaitForCriticalSection section 0x4040f71c "?" wait timed out, retr ying (60 sec) fs=0337 This is a fake windows install straight from the HL CD... using wine 20011004 sid debs.

1 1

using a webcam driver for windows
by Hrafnkell Eiríksson 09 Oct '01

09 Oct '01

Hi This might be a silly question, but would it be possible to use wine with a parallel port webcam driver and an windows application to show images to use a webcam in linux that only has windows suport? I'm thinking about how to get my Logitech QuickCam VC to work in linux :) I know that wine can to some extent access the parallel port in linux. I'm not very familiar with the inner workings of windows, but I guess the camera driver is something called .VxD? Would it be possible to let wine use that somehow? Or does wine not work at that low level? If it is possible to do this, is there something that a guy armed with a C compiler but almost no understanding of windows and wine internals can get working? Thanks Hrafnkell

1 0

Rendering problem in NetTerm
by Mike McCormack 09 Oct '01

09 Oct '01

Hi All, i'm trying to solve a comms problem in NetTerm http://www.securenetterm.com/ but i've run into another problem. The rendering in NetTerm fails almost completely. Its main window ends up with only the boarders drawn and will draw some toolbar buttons if i move the mouse over them. The following message appears repeatedly in the debug log: err:region:CombineRgn Invalid rgn=1096 i did a bit of tracing of the app and found that the region 1096 is created, used by a DC, destroyed, then used again. Is it possible that the reference count of the region is incremented when it is used in some way by a DC? A similar problem to the reference counting one Uwe Bonnes discovered (see message to this list on 16 Aug)? Mike >---------- Forwarded message ---------- >Date: Fri, 14 Sep 2001 18:41:04 -0300 >From: Raul Dias <chaos(a)swi.com.br> >Reply-To: wine-users(a)winehq.com >To: wine-users(a)winehq.com >Subject: wine serial support > >Hi, > >I use wine to run a terminal emulator (NetTerm). >It connects to a Linux Server (it was meant to run from windows) that runs a commerce software. > >This Linux commerce software sends the terminal emulator escape codes to interface with a >"ticket" printer attached to a serial port. > >The reason to go thru all this problem is that the printer has a proprietary, closed source driver >for windows only and interface only with netterm. > >With wine 20001026 this works greatfull. The application takes 3 seconds to startup >in a P133 machine. > >However, the serial communication part does not work with the later versions of wine >like 20010731. The application reports as if there is no serial port and wine complains >with some fixmes about comm support. > >Did wine suffered a big serial change over the last year? > >Now the important thing: >What can I do to help debug this problem (and make it work >on latest wine versions)? >Run it in the latest wine with --debugmsg +all is enough? > > >Regards, > >Raul Dias ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

2 1

Re: CommandLineToArgvW fix
by Alexandre Julliard 09 Oct '01

09 Oct '01

Francois Gouget <fgouget(a)free.fr> writes: > The problem is that CommandLineToArgvW is supposed to return a > pointer, not a handle. But I cannot do: > > hargv=GlobalAlloc(...); > argv=GlobalLock(hargv); > ... > return argv; Sure you can do that, as long as the allocation is GMEM_FIXED GlobalLock doesn't touch the lock count so you don't need to unlock it. It's basically just a glorified typecast. > Sigh. What a stupid memory API. Here I have to agree... -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: CommandLineToArgvW fix
by Alexandre Julliard 09 Oct '01

09 Oct '01

Francois Gouget <fgouget(a)free.fr> writes: > Grrr, HGLOBAL is not a void* pointer... yet => casts :-( GlobalLock would be better... -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: wine/windows painting.c
by Alexandre Julliard 08 Oct '01

08 Oct '01

Duane Clark <dclark(a)leewardfpga.com> writes: > This patch, despite being very simple, has the surprising affect of > causing names of files and icons in the file open dialog of one of my > apps to become invisible when I change directories. I can get individual > names to show up again if I click in the general area of the name, and > all of them show up if I click in the general area of where I know the > scrollbar to be (it is also invisible). Does this make any difference? Index: windows/painting.c =================================================================== RCS file: /opt/cvs-commit/wine/windows/painting.c,v retrieving revision 1.58 diff -u -r1.58 painting.c --- windows/painting.c 2001/10/05 19:47:42 1.58 +++ windows/painting.c 2001/10/08 20:19:22 @@ -712,8 +712,6 @@ if (flags & RDW_UPDATENOW) { - /* process pending events and messages before painting */ - MsgWaitForMultipleObjects( 0, NULL, FALSE, 0, QS_ALLINPUT ); if (wndPtr->hrgnUpdate) /* wm_painticon wparam is 1 */ SendMessageW( hWnd, (bIcon) ? WM_PAINTICON : WM_PAINT, bIcon, 0 ); } @@ -818,6 +816,11 @@ r.top, r.right, r.bottom, hrgnUpdate, flags ); } } + + + /* process pending events and messages before painting */ + if (flags & RDW_UPDATENOW) + MsgWaitForMultipleObjects( 0, NULL, FALSE, 0, QS_ALLINPUT ); /* prepare an update region in window coordinates */ -- Alexandre Julliard julliard(a)winehq.com

3 2

Re: Make serial fd blocking mode depend on FILE_FLAG_OVERLAPPED (Updated)
by lawson_whitney＠juno.com 08 Oct '01

08 Oct '01

On Mon, 8 Oct 2001, Mike McCormack wrote: > > Hi Eric, > > Same patch as before, with the inherit flag added back in to the > server protocol. > > Mike > > ChangeLog: > * make serial fd blocking mode depend on FILE_FLAG_OVERLAPPED > I don't expect this will bother juno version 2. If you get this, it doesn't. Lawson --- >> Build a better mousetrap, and the world will build a better mouse.>> - Proverbs of Hell Revisited

1 1

Re: PATCH: shut up pthread fixme
by Alexandre Julliard 08 Oct '01

08 Oct '01

Marcus Meissner <marcus(a)jet.franken.de> writes: > Changelog: > Remove the harmless and confusing pthread locking fixme messagess. Agreed for pthread_kill_other_threads_np, but I don't think the pthread_rwlock ones are really harmless. We should really do some kind of locking in there, we can't just ignore them. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: wine/windows painting.c
by Duane Clark 08 Oct '01

08 Oct '01

> ChangeSet ID: 1002311262337796173989773 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard@wine2. 01/10/05 15:47:42 > > Modified files: > windows : painting.c > > Log message: > Process pending events before sending WM_PAINT on RDW_UPDATENOW. > > Patch: http://cvs.winehq.com/patch.py?id=1002311262337796173989773 > This patch, despite being very simple, has the surprising affect of causing names of files and icons in the file open dialog of one of my apps to become invisible when I change directories. I can get individual names to show up again if I click in the general area of the name, and all of them show up if I click in the general area of where I know the scrollbar to be (it is also invisible). Duane

4 3

Re: CommandLineToArgvW fix
by Alexandre Julliard 08 Oct '01

08 Oct '01

Francois Gouget <fgouget(a)free.fr> writes: > On Mon, 8 Oct 2001, Malte Starostik wrote: > > > Don't free cmdline as the return values point into that string. It's the > > caller's responsibility to GlobalFree() this according to msdn. > > Ok, I tested my patch and it works. So I propose it here. If the caller is supposed to call GlobalFree on the returned value, it would be much cleaner to allocate it with GlobalAlloc. -- Alexandre Julliard julliard(a)winehq.com

1 0

CVS mirror
by davep 08 Oct '01

08 Oct '01

Checking CVS for the first time in several weeks today, I was surprised to discover that there had been no commits in all that time. Surprising since many changes had been discussed here over that period. Anyway I re-discovered that a long while ago I had put this in my /etc/hosts: 130.225.13.222 cvs.winehq.com presumably at a time when the main CVS was inaccessible. This address still holds a CVS repository for Wine but doesn't seem to be kept up to date. I hope no-one else has made the same mistake ;-) Dave Pickles

1 0

Re: CommandLineToArgvW fix
by eric pouech 08 Oct '01

08 Oct '01

Malte Starostik wrote: > > Don't free cmdline as the return values point into that string. It's the > caller's responsibility to GlobalFree() this according to msdn. I don't understand what you've done. cmdline is a copy of the passed lpCmdLine parameter used for getting the different bits of the argv, so it should be freed however, what's wrong with current implementation (hence your issues) is that when freeing cmdline the argv array points to garbage it means that the argv array and cmdline should be allocated in a single memory block suh that argv[i] points to the part of the string wouldn't the (completly untested but) attached patch work better ? A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle Index: dlls/shell32/shell32_main.c =================================================================== RCS file: /usr/share/cvs/cvsroot/wine/wine/dlls/shell32/shell32_main.c,v retrieving revision 1.85 diff -u -r1.85 shell32_main.c --- dlls/shell32/shell32_main.c 2001/10/03 18:42:16 1.85 +++ dlls/shell32/shell32_main.c 2001/10/08 18:06:34 @@ -1,3 +1,4 @@ + /* * Shell basics * @@ -88,15 +89,10 @@ return argv; } - /* to get a writeable copy */ - cmdline = HeapAlloc(GetProcessHeap(), 0, (strlenW(lpCmdline)+1) * sizeof(WCHAR)); - if (!cmdline) - return NULL; - strcpyW(cmdline, lpCmdline); argc=0; bcount=0; in_quotes=0; - s=cmdline; + s=(LPWSTR)lpCmdline; while (1) { if (*s==0 || ((*s==0x0009 || *s==0x0020) && !in_quotes)) { /* space */ @@ -122,7 +118,12 @@ } s++; } - argv=HeapAlloc(GetProcessHeap(), 0, (argc+1)*sizeof(LPWSTR)); + argv=HeapAlloc(GetProcessHeap(), 0, (argc+1)*sizeof(LPWSTR) + strlenW(lpCmdline) + 1); + if (!argv) + return NULL; + /* to get a writeable copy */ + cmdline = (LPWSTR)((char*)argv + (argc+1)*sizeof(LPWSTR)); + strcpyW(cmdline, lpCmdline); argc=0; bcount=0; @@ -178,7 +179,6 @@ if (numargs) *numargs=argc; - HeapFree(GetProcessHeap(), 0, cmdline); return argv; }

1 1

Fwd: Re: CommandLineToArgvW fix
by Malte Starostik 08 Oct '01

08 Oct '01

Sorry, meant reply-to-all ---------- Weitergeleitete Nachricht ---------- Subject: Re: CommandLineToArgvW fix Date: Mon, 8 Oct 2001 20:23:57 +0200 From: Malte Starostik <malte(a)kde.org> To: eric pouech <eric.pouech(a)wanadoo.fr> Am Monday 08 October 2001 20:08 schrieben Sie: > Malte Starostik wrote: > > Don't free cmdline as the return values point into that string. It's the > > caller's responsibility to GlobalFree() this according to msdn. > > I don't understand what you've done. > cmdline is a copy of the passed lpCmdLine parameter used for getting the > different bits of the argv, so it should be freed > however, what's wrong with current implementation (hence your issues) is > that when freeing cmdline the argv array points to garbage > it means that the argv array and cmdline should be allocated in a single > memory block suh that argv[i] points to the part of the string You're definately right, I mixed up argv with argv[i] there. > wouldn't the (completly untested but) attached patch work better ? Didn't test it either, will do so somewhen later, looks right to me. -- Malte Starostik PGP: 1024D/D2F3C787 [C138 2121 FAF3 410A 1C2A 27CD 5431 7745 D2F3 C787] -------------------------------------------------------

2 1

Re: Q&D rundll32 implementation
by Marcus Meissner 08 Oct '01

08 Oct '01

On Mon, Oct 08, 2001 at 11:14:00AM +0200, Malte Starostik wrote: > I'm currently trying to get the WMP installer running. One of the things it > needs is rundll32.exe. Attached is a very basic implementation of it. > However, it doesn't work out of the box, as it's lacking an .exe suffix which > the installer explicitly specifies. What's the preferred way to handle such > cases? Not that the installer would work, when it comes to the actual .inf > parsing, it hits the SetupAPI stubs and nothing is actually copied. > Do with it what you like. I do not see a reason we could not name a linux binary .exe in this case. Ciao, Marcus

1 0

Re: Make serial fd blocking mode depend on FILE_FLAG_OVERLAPPED
by Mike McCormack 08 Oct '01

08 Oct '01

Hi Eric, Probably a bit of overzealous use of occam's razor. It was being set to zero on the client side, and passed into the server. I wasn't quite sure what to do with it ... so i removed it. There's no harm in leaving it there i guess... Mike >hi Mike, > >I don't understand why you got read of the inherit flag in the protocol >definition for serial handles. Even, if security attribute isn't pass >around yet for file/comm port creation, it should be kept for comm port > >A+ >-- >--------------- >Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) >"The future will be better tomorrow", Vice President Dan Quayle ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Re: Make serial fd blocking mode depend on FILE_FLAG_OVERLAPPED
by eric pouech 08 Oct '01

08 Oct '01

Mike McCormack wrote: > > This patch causes a serial port's fd to be put into blocking mode if > FILE_FLAG_OVERLAPPED is not specified and non-blocking mode if it is. > > ReadFile should block on serial ports for non-overlapped reads. The > next step is to refuse overlapped reads and writes if the file isn't > opened with FILE_FLAG_OVERLAPPED specified. hi Mike, I don't understand why you got read of the inherit flag in the protocol definition for serial handles. Even, if security attribute isn't pass around yet for file/comm port creation, it should be kept for comm port A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

1 0

Re: err:edit:EDIT_LockBuffer no buffer ... please report
by lawson_whitney＠juno.com 08 Oct '01

08 Oct '01

On Sun, 7 Oct 2001 whit(a)giftie.alien.org wrote: > Well, ... yes. The err: goes away. File and directory names still > disappear from the winhelp file dialog (?) as they did before, but > still, if you select the right empty space, the operation proceeds to a > satisfying crash. If I thought that little err: was all that was wrong > with winhelp, that was silly of me. I _think_ this is a good patch. > > Regards, > > Lawson > ---cut here--- So as not to damn you with faint praise, I think winhelp is more nearly usable with this patch than without. I can actually select and see a topic in terminal.hlp before winhelp crashes. Lawson ---slowly, but with considerable uncertainty--- ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/web/.

1 0

err:edit:EDIT_LockBuffer no buffer ... please report
by lawson_whitney＠juno.com 08 Oct '01

08 Oct '01

Good day! Okay, I reported it, attached is an unexpurgated --debugmsg +edit trace of me trying to open the lcc-win/lccpub/bin/wedit.hlp file from ftp://ftp.mathematik.tu-darmstadt.de/pub/linux/bonnes/lcc-bin-alpha.tar.gz with wine's builtin winhelp program. Current cvs, no windows, no fat nor nt filesystems. Kernel 2.4.10 with devfs and devfsd. [DllOverrides] "*" = "builtin, so, native" I would be happy to make other traces, but probably this is easy to duplicate. Just to add insult to injury, I will attach a backtrace of winhelp trying to work with terminal.hlp (from wfw 3.11, I think). In case anyone is really short on things to debug. Regards, Lawson

2 2

Re: SetSystemMetrics
by Alexandre Julliard 07 Oct '01

07 Oct '01

Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > Files sysmetrics.c, sysmetrics.h: > Implementation of SetSystemMetrics function which sets data accessed by > GetSystemMetrics. Applied, but I renamed it to SYSMETRICS_Set. Internal functions should not be named the same way as exported APIs, otherwise people reading the code will think this is a standard Windows function. -- Alexandre Julliard julliard(a)winehq.com

2 1

dosmem
by Nog 05 Oct '01

05 Oct '01

In my quest to get helppc running and working in wine, I noticed that it tries to access the text mode buffer directly (b000, I think). This memory doesn't seem to be emulated in dosmem.c and my exploration into how to implement it were in vein. Could anybody please help? Anyway on another note, to get the program to exectute this far I had to add a hack to vga.c. What the program was doing, was, it waited until the light pen trigger was set, when it read the light pen trigger set (bit 1) from the vga status register (3da) and then it would wait until it was unset again. I've attached a patch to solve this problem, but its definatly not the right way of doing it, anyway see what you think. Index: vga.c =================================================================== RCS file: /home/wine/wine/msdos/vga.c,v retrieving revision 1.7 diff -u -r1.7 vga.c --- vga.c 2001/06/19 18:14:08 1.7 +++ vga.c 2001/10/04 17:54:02 @@ -31,6 +31,8 @@ typedef HWND WINAPI (*CreateWindowExAProc)(DWORD,LPCSTR,LPCSTR,DWORD,INT,INT, INT,INT,HWND,HMENU,HINSTANCE,LPVOID); static CreateWindowExAProc pCreateWindowExA; +int pentrigger = 0; + static void VGA_DeinstallTimer(void) { if (poll_timer) { @@ -333,6 +335,15 @@ we need to fake the occurrence of the vertical refresh */ ret=vga_refresh?0x00:0x08; vga_refresh=0; + + /* The light pen trigger is a bit tricky, programs want it set first + and then they wait until its unset agian */ + if(pentrigger == 1) { + pentrigger = 0; + ret += 0x5; + } + else + pentrigger = 1; break; default: ret=0xff;

3 4

OLE File Format Documentation
by Charles Wyble 05 Oct '01

05 Oct '01

Hello Everyone. My name is Charles Wyble, and I am working on an open-source library for reading/writing ole files. I want to get all the documentation/source code I can. So far, I have gotten things from: 1)John E. Adams(provided an ole-dump utility) 2)Martin Schwartz's document 3)libole2 4)The Filters Project I was wondering if the wine developers, have any source documentation to share? Also which modules contain the ole source code in CVS? If you are interested in the items I have gathered, I can post them to the list or an FTP/WEB site. ===== Charles Wyble God Bless jackshck(a)yahoo.com __________________________________________________ Do You Yahoo!? NEW from Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1

2 1

CVS, diffs, and a newbie (me)
by Daniel Sabo 04 Oct '01

04 Oct '01

What is the proper way to submit a patch to wine? Do you need a special password to use cvs commit or can you only mail in diffs? How do you make a propper diff (yeah, I'm really new at this)? If someone could just add the needed 'fi' to the end of tools/winelauncher.in I'd be happy too :).

2 1

Re:CVS, diffs, and a newbie (me)
by Eric Pouech 04 Oct '01

04 Oct '01

well there should be some info on www.winehq.com (development or tools part). basically, patches are generated with cvs diff -u and sent to wine-patches(a)winehq.com the project leader takes care of putting them into cvs A+ > What is the proper way to submit a patch to wine? Do you need a > special password to use cvs commit or can you only mail in diffs? > How do you make a propper diff (yeah, I'm really new at this)? > > If someone could just add the needed 'fi' to the end of tools/winelauncher.in > I'd be happy too :). > > > > --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle __________________________________________________________ Faites un voeu et puis Voila ! www.voila.fr Pendant tout l'été, gagnez une Ford Ka sur Voila Gratter ! http://cybergrattage.voila.fr/voila

1 0

Re: typelib patch 2
by Marcus Meissner 04 Oct '01

04 Oct '01

On Wed, Oct 03, 2001 at 04:35:14PM +0200, Ove Kaaven wrote: > As far as I can tell, the DISPATCH_METHOD flag shouldn't be masked out > in here... (Marcus, was there a reason for this?) No, I was just confused by the bad enum and lack of documentation mostly ;) Ciao, Marcus

1 0

Re: Resolving already resolved ordinal for Borland style imports
by Alexandre Julliard 03 Oct '01

03 Oct '01

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > Or is it an error that we call > PE_fixup_imports for the second time at all for an already resolved dll? Yes, we should never fixup a dll twice. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: typelib patch 2
by Uwe Bonnes 03 Oct '01

03 Oct '01

>>>>> "Ove" == Ove Kaaven <ovek(a)arcticnet.no> writes: ... Ove> With this patch, InstallShield6's user interface comes up. (It Ove> seems to start to fail in some shell stuff, though) With or without the installshield 6 patch on wine-devel? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

Re: cross-process EnableWindow
by Alexandre Julliard 03 Oct '01

03 Oct '01

"Bill Medland" <medbi01_1(a)accpac.com> writes: > I'm not trying to push; I'd just like to know. Does anyone have an idea how > long it will be before EnableWindow can enable a window in another process. It's not too far, basically all the needed infrastructure is in place now. Only I have had very little time lately to work on it. -- Alexandre Julliard julliard(a)winehq.com

2 1

Resolving already resolved ordinal for Borland style imports
by Uwe Bonnes 03 Oct '01

03 Oct '01

Hallo, some programm using a dll with Borland style imports crashes if the dll is loaded a second time. When PE_fixup_imports is called for the first time, resolving goes fine (_relay,+win32 log, with BON: -line additional, hopefully selfexplaining output) trace:win32:PE_LoadLibraryExA BON:D:\wine95\system\netapi32.dll trace:win32:dump_exports *******EXPORT DATA******* trace:win32:dump_exports Module name is NETAPI32.dll, 1 functions, 1 names trace:win32:dump_exports Ord RVA Addr Name 1 00001000 0x7fad1000 Netbios trace:win32:PE_fixup_imports Dumping imports list trace:win32:PE_LoadLibraryExA BON:D:\wine95\system\netbios.dll trace:win32:dump_exports *******EXPORT DATA******* trace:win32:dump_exports Module name is NETBIOS.dll, 6 functions, 6 names trace:win32:dump_exports Ord RVA Addr Name 1 00001a37 0x7f6f1a37 NetbiosAddthd 2 000019eb 0x7f6f19eb NetbiosDelete 3 00001a96 0x7f6f1a96 NetbiosDelthd 4 000019b1 0x7f6f19b1 NetbiosInitialize 5 0000186b 0x7f6f186b PostRoutineCaller 6 0000102e 0x7f6f102e _Netbios trace:win32:PE_fixup_imports Dumping imports list trace:win32:PE_fixup_imports Borland style imports used trace:win32:PE_fixup_imports BON:load_addr 7f6f0000 trace:win32:PE_fixup_imports BON:thunk 0x602c trace:win32:PE_fixup_imports BON:ordinal 6080 ^^^^ trace:win32:PE_fixup_imports BON:name KERNEL32.dll trace:win32:PE_fixup_imports BON:pe_name 0x7f6f6080 trace:win32:PE_fixup_imports BON:pe_name->Hint 94 trace:win32:PE_fixup_imports BON:pe_name->Name 0x7f6f6082 trace:win32:PE_fixup_imports --- EnterCriticalSection KERNEL32.dll.94 Now ordinal is replace by the function pointer in PE_fixup_imports. The second PE_LoadLibraryExA however goes astray, as it tries to resolve the function pointer as an ordinal in PE_fixup_imports. trace:win32:PE_LoadLibraryExA BON:D:\wine95\system\netapi32.dll trace:win32:dump_exports *******EXPORT DATA******* trace:win32:dump_exports Module name is NETAPI32.dll, 1 functions, 1 names trace:win32:dump_exports Ord RVA Addr Name 1 00001000 0x7fad1000 Netbios trace:win32:PE_fixup_imports Dumping imports list trace:win32:PE_LoadLibraryExA BON:D:\wine95\system\netbios.dll trace:win32:dump_exports *******EXPORT DATA******* trace:win32:dump_exports Module name is NETBIOS.dll, 6 functions, 6 names trace:win32:dump_exports Ord RVA Addr Name 1 00001a37 0x7f6f1a37 NetbiosAddthd 2 000019eb 0x7f6f19eb NetbiosDelete 3 00001a96 0x7f6f1a96 NetbiosDelthd 4 000019b1 0x7f6f19b1 NetbiosInitialize 5 0000186b 0x7f6f186b PostRoutineCaller 6 0000102e 0x7f6f102e _Netbios trace:win32:PE_fixup_imports Dumping imports list trace:win32:PE_fixup_imports Borland style imports used trace:win32:PE_fixup_imports BON:load_addr 7f6f0000 trace:win32:PE_fixup_imports BON:thunk 0x602c trace:win32:PE_fixup_imports BON:ordinal 4010d724 ^^^^^^^^ trace:win32:PE_fixup_imports BON:name KERNEL32.dll trace:win32:PE_fixup_imports BON:pe_name 0xbf7fd724 BON: 4010d724 086723f8:Call kernel32.UnhandledExceptionFilter(404b4b00) ret=00454633 What is the right solution? Only treat the value as an ordinal if it is smaller then 0x10000( I susbpect that an dll may only have 0xffff entries or the IMAGE_SNAP_BY_ORDINAL wouldn't work)? Or is it an error that we call PE_fixup_imports for the second time at all for an already resolved dll? Bye Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Free Software: If you contribute nothing, expect nothing --

1 0

Posic Support For Dos & Mac OS
by Lucien LaCroix 03 Oct '01

03 Oct '01

I've heard rumors of projects or programs that would enable Posix in dos, is this possible? There is one project that provides Posix support for Mac that I think everyone should be aware of. The address is at http://www.dsitri.de/projects/mac06/. I think this is an important page because there are many mac Users who would be glad to use Unix and *possibly* run WINE under it's engine. The text below is a quote from thier site. Based on the tools etc. that are given below, if someone could advise me what tools in 8minimum* are needed to compile the source code, then I will attempt it and let everyone know. PC Emulators are getting expensive and the only open-source Mac PC Emu (Bochs) is no longer being worked on, so we are stuck with an old copy. :) Mac06 ("Mac oh six"), is a POSIX library and a system kernel running on top of MacOS. Some features are: * UNIX like file system using HFS with full Finder integration * POSIX libc.a and #include headers, curses library * POSIX shell * commands like ll, cd, cat, xd, echo, find, fgrep, ... * software development package (assemblers, C compiler, linker) for Motorola 680x0, Power PC including AltiVec, Z80, Java Virtual Machine and others * communication package for TCP/IP (telnet, mail, ftp, ...) * runs MacOS native applications written with Think C/Symantec C++/MPW/Code Warrior * HTML based online manual Mac06 IDE is an Interactive Software Development Environment based on the Mac06 compilers with * Project Manager * Multitarget Build/Make function * Builtin Source File Editor * Drag&Drop User interface Do you want to 1. learn UNIX to prepare yourself for MacOS X? 2. have a very simple installation for a UNIX like system? 3. switch between MacOS (Finder) and a UNIX like system without rebooting? 4. run legacy software written for UNIX (C/C++ based on POSIX libraries) on a Mac? 5. have a low-end Mac (68k or PPC Performa) and want a simple solution to run UNIX? 6. have a Performa 5200 or 5300 on which neither MkLinux nor Linux68k will run? 7. do software development for embedded controllers (680x0, PowerPC, Z80, ARM, ...) on a Mac with familiar UNIX tools and POSIX libraries? Then, Mac06 ("Mac oh six"), the POSIX library and system kernel running on top of MacOS can be a solution for you. Features of Mac06 * Direct installation - just download-expand&run * Fully Finder-integrated UNIX like file system (based on HFS) * Shared CPU - processes run in parallel with MacOS * Command line shell based on POSIX.2 standard (currently supports only a subset) * Rich set of standard commands like sh, ll, cd, cat, xd, echo, find, fgrep, tar, uuencode, ... * Extensive HTML based online manual * High performance software development package for ANSI/ISO-C (includes generic assembler for 680x0, PowerPC&AlitVec, Z80, ARM, and others) with flexible make tool (mk) * Full libc and #include headers (mostly POSIX.1 and some POSIX.4 standard compatible) * Communication package for TCP/IP (telnet, ftp, mail, ...) * Full POSIX terminal support (/dev/console, /dev/tty are mapped to terminal windows - have a look at a screen shot) including terminal control (tcsetattr() etc.) * Full "curses" terminal driver library Upcoming: Features of Mac06 IDE * Direct installation - just download-expand&run * Full MacOS Dialog, Window and Menu based application (have a look at a screen shot) * Use Drag&Drop to add source files * Integrated Source File Editor capable of handling large files (>32000 characters) * Project Manager * Multi-Target (Programs and Libraries) projects * allows IMPORT of projects * Build/Make function fully compatible with the mk command System requirements * System 7.0 or later (tested on 7.5.5 and 8.5) * Mac with at least 68020 and 8 MB of RAM (tested intensively on a PowerBook 165 and a Performa 5200) * approx. 15 MB hard disk space _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

1 0

Re: wine/ dlls/user/message.c include/input.h wind ...
by Francois Gouget 02 Oct '01

02 Oct '01

On Tue, 2 Oct 2001, Alexandre Julliard wrote: [...] > Log message: > Merged mouse buttons states into the key state array. > Fixed confusion between queue state and async state. Is this normal? --- /opt/cvs-commit/wine/windows/input.c 2001/10/02 17:17:32 1.63 +++ /opt/cvs-commit/wine/windows/input.c 2001/10/02 18:54:00 1.64 + ((InputKeyStateTable[SwappedButtons ? VK_RBUTTON : VK_LBUTTON] & 0x80 ? MK_LBUTTON : 0) | \ + (InputKeyStateTable[SwappedButtons ? VK_LBUTTON : VK_LBUTTON] & 0x80 ? MK_RBUTTON : 0) | \ ^^^^^^^^^^ Shouldn't this be VK_RBUTTON? Or maybe it's me who's confused... -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Broadcast message : fin du monde dans cinq minutes, repentez vous !

1 0

PATCH: Wininet + gethostbyname problem
by Nikolas Zimmermann 02 Oct '01

02 Oct '01

Hi there, this patch fixes the shockwave activex control installer. 1. basically it calls gethostbyname("pinger.macromedia.com:80"); my patch just skips the :80 so that the gethostbyname call won't fail.... 2, it also fixes non-absolute urls before it made ugly things like pub/foobar/blah with my patch it's corrected to /pub/foobar... Trivial patch Bye Bye Niko -- Nikolas Zimmermann wildfox(a)kde.org

1 0

Re: OLEAUT32 patch
by Alexandre Julliard 02 Oct '01

02 Oct '01

Andreas Mohr <a.mohr(a)mailto.de> writes: > Alexandre: yes, I think a config file setting is needed, since we've had > an awful lot of problems with OLEAUT versioning already (I get one mail > about this problem every two weeks), so I suspect that programs are > pretty rigid about this. > If it actually turns out to be unnecessary, then we'll just be able > to remove it anyway. No, that's not how it works. Once we add the option we have no way of knowing if someone needs it or not, so we cannot remove it. So I have applied the patch without the option, and then if someone still complains we can add it (also it needs a better place in the config file, this BuildVersion_OLEAUT32 in the [wine] section is ugly). -- Alexandre Julliard julliard(a)winehq.com

1 0

can't debug mfc program
by Guilherme Kunz 02 Oct '01

02 Oct '01

Hi! I am trying compile a mfc program with winelib. Well, i compiled the part of mfc which i need for use the program whitout erros or unresolved functions and compiled the mfc program with the libmfc.so without errors or unresolved functions, but when i ran the mfc program hapned "Segmentation Fault". I tried use gdb and winedbg but i can't run these debuggers, with gdb happned "Segmentation Fault" with or without breakpoints in the begining of the source and winedbg write only the first line in the window and go out. i tried use strace and "--debugmsg +all". HeapAlloc HeapAlloc *killed* exit_code=0 #./program #Segmentation fault (core dump) #gdb program core #Reading symbols /usr/local/lib/libntdll.so ...... Segmentation fault (core dump) Thank You Guilherme guiok(a)ig.com.br _________________________________________________________ Oi! Você quer um iG-mail gratuito? Então clique aqui: http://registro.ig.com.br/

4 3

cross-process EnableWindow
by Bill Medland 01 Oct '01

01 Oct '01

I'm not trying to push; I'd just like to know. Does anyone have an idea how long it will be before EnableWindow can enable a window in another process. Bill

1 0

InstallShield 6 again (debuggers requested)
by Ove Kaaven 01 Oct '01

01 Oct '01

Here are some kludgy patches (against the current WineHQ CVS) that's supposed to make InstallShield 6 with its stupid interprocess COM sort of work, but it doesn't for some reason, probably because of something else in Wine that's broken... and because of a lack of time, I think I really need some debugging assistance. Most of these patches are too ugly to be submitted to the official wine as-is, I'll clean these parts up later, but probably not before InstallShield has been debugged and actually works with these hacks. To make this run, you need to copy stdole32.tlb from a real windows and put into c:\windows\system. Then run your favorite InstallShield 6 setup.exe and wait for it to crash. --debugmsg +ole is recommended. It crashes for me after about 25 remote method calls. If you find out why, let me know. Please.

3 7

DdeConnect errors while running setup.exe
by Ian D . Stewart 01 Oct '01

01 Oct '01

Dear Wine Developers, Due to resource constraints (75 MHz processor, 1.2 GB hard drive, 16 MB RAM), we recently replaced Windows98 on our daughter's PC with Linux Mandrake, using the IceWM window manager. It isn't quite as flashy as Windows, but it boots beyond the startup screen, which is more than can be said for Win98. Well, to make a long story short, I've installed and configured Wine following the instructions in the Wine User's Guide. Everything seems to be working properly, but when I attempted to run the setup.exe for 'Jim Henson Muppets Letters: Capital & Small', I received the following errors: err:ddeml:DdeConnect .. but no Server window available err:ddeml:DdeClientTransaction Invalid conversation handle err:ddeml:DdeClientTransaction Invalid conversation handle err:ddeml:DdeClientTransaction Invalid conversation handle fixme:ddeml:DdeUninitialize16 stub calling DdeUninitialize Following the recomendations in the Wine User's Guide, section 3.2 (Installing Wine Without Windows), I re-ran wine with --debug msg +module,+file. I didn't see anything in the trace that jumped out at me, but I've attached it here, just in case it means something to someone else. One last thing. The setup.exe appears to be a 16-bit app, originally designed for Windows 3.1. Not sure if that makes any difference or not. Any help in resolving this would be greatly appreciated. Regards, Ian D. Stewart -- "God may have mercy. We will not." --Senator John S. McCain (R-AZ)

2 1

Re: OLEAUT32 patch
by Dmitry Timoshkov 01 Oct '01

01 Oct '01

"Andreas Mohr" <a.mohr(a)mailto.de> wrote: > this is a rewrite of OaBuildVersion(). > Now we just return the highest version value possible (0xffff) and > have a config file option to tweak the version value to return if this > is causing problems. > Added docu for it, of course. I suspect too much of extra RegCloseKey(hkey) statements in OLEAUT32_GetAppKey() implementation. -- Dmitry.

1 0

Bug in CreateWindowEx
by Luke Stras 29 Sep '01

29 Sep '01

I'm trying to get Civ2 to run under wine (checked out via CVS today), and I've run into a particular problem. The installation is totally stand-alone -- all DLLs are built-in. I get an invalid page fault in X11DRV_GetDC [winpos.c:441], at the line which says: drawable = data->client_window Some debugger work shows that data is NULL. Now, the backtrace shows that we get *here* from a call to WIN_GetMinMaxInfo from CreateWindowEx [win.c:885]. The problem, as I see it, is that USER_Driver.pCreateWindow doesn't get called until [win.c:922] -- in other words, when the callback inside Civ2 receives the WM_GETMINMAXINFO, it tries acquiring a DC for some reason, and this causes the crash. Now, I don't know enough about how wine works internall to fix this. Can anyone provide any suggestions? -- Luke Stras <stras(a)utias.toronto.edu> "The meek can have the Earth; the rest of us have other plans" --Henry Spencer

1 0

installshield 6
by Daniel Walker 29 Sep '01

29 Sep '01

Is there a specific application that I should be attempting to install ? Or is there a specific version of stdole32.tlb that I need ? Daniel Walker

1 0

Re: InstallShield 6 again (debuggers requested)
by Gerard Patel 29 Sep '01

29 Sep '01

At 03:11 AM 29/09/2001 -0700, you wrote: >> Probably only that there's a problem with your setup. For example, perhaps >> you forgot to copy stdole32.tlb from real windows, as instructed? > > > No , I did that.. Well, did you import all the registry entries in winedefault.reg then ? Gerard

3 3

Re: fixme:pthread_kill_other_threads
by Eric Pouech 28 Sep '01

28 Sep '01

> 51145 096d4e18:Call x11drv.MsgWaitForMultipleObjectsEx(00000001,403faec4,ffffffff,00000000,00000000) ret=406c7efd can you check that at this point (DWORD*)0x403faec4 points to the handle of the event created above ? (0x7C IIRC) if it's the case, it means that the started program rely on some messages order to do some stuff the expected behavior would be for the second program to set the event (7c) under certain circumstances, which shall be triggered from a given message... A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle __________________________________________________ Voila vous propose une boite aux lettres gratuite sur Voila Mail: http://mail.voila.fr

4 4

fixme:pthread_kill_other_threads
by Uwe Bonnes 28 Sep '01

28 Sep '01

Hallo, I don't understand why pthread_kill_other_threads ist called when a programm creates a new process. With the pthread_kill_other_threads call, the starting process dies. This is a +relay,+server,+... log: trace:dosfs:DOSFS_GetFullName returning /home/dosd/cae/ql82/scs/TKWDOG.EXE = D:\CAE\QL82\SCS\TKWDOG.EXE 08068938: new_process( inherit_all=0, create_flags=67108864, start_flags=257, exe_file=200, hstdin=4, hstdout=8, hstderr=12, cmd_show=1, filename="D:\cae\ql82\scs\TKWDOG.EXE" ) 08068938: new_process() = 0 { info=204 } fixme:pthread_kill_other_threads_np 08068938: select( flags=12, cookie=0x405c5778, sec=1001624181, usec=913175, handles={204} ) 08068938: select() = PENDING 00000000: *fd* 0 -> 46 08625a70: *fd* 6 <- 46 08625a70: *fd* 8 <- 47 08625a70: init_thread( unix_pid=2070, teb=0x40127ce0, entry=(nil), reply_fd=6, wait_fd=8 ) 08625a70: init_thread() = 0 { pid=0x86259a0, tid=0x8625a70, boot=0, version=53 } This is an strace of that part: 1898 close(28) = 0 1898 chdir("/home/dosd/cae/ql82/scs") = 0 1898 write(2, "fixme:pthread_kill_other_threads"..., 36) = 36 1898 execve("/usr/local/bin/wine", ["/usr/local/bin/wine", "--", "tkwdog.exe"], [/* 57 vars */] <unfinished ...> and I think this relates to scheduler/process.c:fork_and_exec if (newdir) chdir(newdir); if (argv && envp) { if (!filename) { argv[1] = "--"; exec_wine_binary( argv, envp ); } else execve( filename, argv, envp ); } What can happen between chdir() and execve() to trigger the pthread_kill_other_threads() call? Bye Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Free Software: If you contribute nothing, expect nothing --

3 3

Re: _NET_WM_NAME support patch
by Dmitry Timoshkov 27 Sep '01

27 Sep '01

"Ilya Konstantinov" <wine-patches(a)future.shiny.co.il> wrote: > This patch adds a _NET_WM_NAME(UTF8_STRING) property to every window, > storing it's title in non-ambigous UTF8 encoding. This is a part of the > NET_WM standard. The UTF8 title feature is currently implemented only > by KWin (KDE's window manager), but is adopted by both GNOME and KDE > camps. @@ -746,12 +748,32 @@ BOOL X11DRV_SetWindowText( HWND hwnd, LP return FALSE; } WideCharToMultiByte(text_cp, 0, text, -1, buffer, count, NULL, NULL); + + count = utf8_wcstombs(text, strlenW(text), utf8_buffer, 0); Why didn't you use win32 call instead of a purely internal one? count = WideCharToMultiByte( CP_UTF8, 0, text, -1, NULL, 0, NULL, NULL ); utf8_buffer = HeapAlloc( GetProcessHeap(), 0, count ); count = WideCharToMultiByte( CP_UTF8, 0, text, -1, utf8_buffer, count, NULL, NULL ); -- Dmitry.

1 0

Problem in installation of Wine on SPARC Solaris 8.0
by Mrugan Bhorkar 27 Sep '01

27 Sep '01

I am trying to install Wine on UltraSPARC Solaris 8.0 using tools/wineinstall. The installation script fails at following point...... gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -D__WINE__ -D_REENTRANT -I/usr/openwin/include -o lex.ppl.o lex.ppl.c In file included from ./ppl.l:141: ../../include/config.h:486: warning: `_FILE_OFFSET_BITS' redefined /usr/include/sys/feature_tests.h:96: warning: this is the location of the previous definition ./ppl.l: In function `pplex': ./ppl.l:336: `pplval' undeclared (first use in this function) ./ppl.l:336: (Each undeclared identifier is reported only once ./ppl.l:336: for each function it appears in.) make: *** [lex.ppl.o] Error 1 Can anybody suggest how to fix this?? Thanks Mrugan __________________________________________________ Do You Yahoo!? Listen to your Yahoo! Mail messages from any phone. http://phone.yahoo.com

1 0

pthread_atfork and PTHREAD_FORK
by Bill Medland 26 Sep '01

26 Sep '01

Can someone tell me what we should have here? (It might be interesting to know how it's supposed to work too but that's beside the point). I had a case where pthread_atfork was being called with two null pointers, so it all blew up when PTHREAD_FORK tried to execute the code they pointed to. Is it legal for pthread_atfork to be called with null parameters (in which case I will correct PTHREAD_FORK, otherwise I'll assert the pointers). Bill

2 1

pthread_atfork problems
by Bill Medland 26 Sep '01

26 Sep '01

Any chance of a hand with this please? I have just traced a problem to the fact that __pthread_atfork is passed a couple of null pointers, which I presume is an illegal thing to do. Can anyone point me at the code that results in __pthread_atfork being called and/or explain why it would be called with null pointers? TIA Bill

1 0

Re: GetMessageTime
by Alexandre Julliard 26 Sep '01

26 Sep '01

"David Hammerton" <david(a)transgaming.com> writes: > BTW, One of the siderfects of this is: in dlls/x11drv/window.c line 1143, > GetMessageTime() is sometimes 0 (depends on the applicatoin, for example the > game Alice seems to make it return 0) - so the value sent to XSetInputFocus for > the time is too small, and hence X refuses to give the window focus. The real fix is that XSetInputFocus should not use GetMessageTime at all, this is only a temporary hack. To conform to the ICCCM the focus time should be based on the timestamp of a previous X event, and the focus should never be changed if we didn't receive an event. To do this right probably requires supporting the take focus protocol, as was discussed some time ago. -- Alexandre Julliard julliard(a)winehq.com

1 0

Getting Routing tables
by Robert Lunnon 26 Sep '01

26 Sep '01

In my pitiful attempt to hack on WINE I have come to an impasse. I have managed to find portable equivalents to get the interface name and the number of interfaces in winsock/wsock32 but I can't seem to find a portable way to get to the routing table. In Solaris (why I'm doing the hacking) there is a vague mention in the man pages of being able to get this info by reading /dev/ip but no information about how to actually do it. Can anyone provide a hint on how this can be done portably or to a multi-os implementation of netstat that might serve as an example. (Only netstat sources I have found are OS specific) Hurry because in desperation I am actually thinking of piping the output of netstat -r Thanks Bob

2 1

BeginPaint not called on WM_PAINT...
by Andreas Mohr 25 Sep '01

25 Sep '01

Hi all, the game Undying emits lots and lots of err:msg:DispatchMessageA BeginPaint not called on WM_PAINT for hwnd 20029! errors. This is because it simply does: 0806d2c8:Call user32.DispatchMessageA(406c29b0) ret=1090e313 0806d2c8:Call window proc 0x11001530 (hwnd=00020029,msg=WM_PAINT,wp=00000000,lp=00000000) 0806d2c8:Call user32.ValidateRect(00020029,00000000) ret=11107b57 0806d2c8:Ret user32.ValidateRect() retval=00000001 ret=11107b57 0806d2c8:Ret window proc 0x11001530 (hwnd=00020029,msg=WM_PAINT,wp=00000000,lp=00000000) retval=00000000 This seems to be perfectly legal in order to validate the whole window update rect (NULL) and thus prevent further WM_PAINTs. (as http://www.intrepidhero.com/articles/wgpfd_errata/part2.html hints) In short: the wine error message is erroneous in this case. The Wine check is: if (painting && wndPtr && (wndPtr->flags & WIN_NEEDS_BEGINPAINT) && wndPtr->hrgnUpdate) { ERR("BeginPaint not called on WM_PAINT for hwnd %04x!\n", msg->hwnd); So I assume that either a) some flag or so doesn't get updated properly by that ValidateRect() or b) the error message check condition is (slightly) wrong. Could someone please fix this ? This happened to #WineHQ nick Thunderbird with latest version of winex (20010824). -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

1 0

GetMessageTime
by David Hammerton 25 Sep '01

25 Sep '01

Hey, Durings my hunting down for why SetFocus wasnt always working, I have traced it back to a problem with GetMessageTime(). (which I have made a temporary fix for, haven't sent it to wine-patches because its not the 'right' way of fixing it) GetMessageTime() is supposed to return the time of the last message received by GetMessage(). But there are two cases where the time set (req->time) is 0 - and I can't fix it. If you turn your eyes to server/queue.c, around line 910 and 926 you will see the two times this value gets set to 0. Statically. I believe the only way to fix this is some sort of restructuring, since GetCurrentTime() (used by all other functions that set req->time) relies on a variable thats not available to the wine server. Anyone else have any suggestions? BTW, One of the siderfects of this is: in dlls/x11drv/window.c line 1143, GetMessageTime() is sometimes 0 (depends on the applicatoin, for example the game Alice seems to make it return 0) - so the value sent to XSetInputFocus for the time is too small, and hence X refuses to give the window focus. As I said i've written a small patch for this, I may send it to wine-patches if its worth it, but I really think that the source of the problem should be addressed more urgently. David. -- David Hammerton, web programmer TransGaming Technologies Inc. http://www.transgaming.com david(a)transgaming.com

1 0

NG: Wine and cyrillic input and output ?
by Dmitry Timoshkov 25 Sep '01

25 Sep '01

Hello all. This patch fixes a couple of problems with keyboard group switching reported in the news group: 1. Group switch had never worked before, if the keyboard has been switched outside of Wine. 2. I was clearly stated that Group switch is active if event->state & 0x2000, not event->state & 0x6000. Please test it on your local configurations and report back. If there will be no objections, I'll send it to wine-patches. Thanks. -- Dmitry.

2 3

GetClipboardData
by Dominik Strasser 25 Sep '01

25 Sep '01

Hello, with MS WinWord I am encountering the following problem: If there's something selected, GetClipboardData is called. In GetClipboardData, there is the line: HWND hWnd = (hWndClipWindow) ? hWndClipWindow : GetActiveWindow(); hWndClipWindow is 0, so GetActiveWindow() is called which also returns 0. I tracked this down to PERQDATA_GetActiveWnd returning 0. This leads later to "w" bening 0 which results in an X error calling XConvertSelection. It happens in all modes, desktop managed, non managed. Does anybody have any clues ? Dominik -- Dominik Strasser | Phone: +49 89 636-43691 SIEMENS AG | Fax: +49 89 636-42284 CT SE 4 | E-Mail:Dominik.Strasser@mchp.siemens.de Otto-Hahn-Ring 6 | D-81739 Muenchen | Room: 53-263

1 0

Callwave doesn't run
by Steven Walter 23 Sep '01

23 Sep '01

Is this a known problem? When I try to run the callwave install program, or the callwave program itself, I merely get: fixme:win32:PE_CreateModule Security directory ignored err:seh:start_debugger Couldn't start debugger (debugger/winedbg 134640112 24) (2) Read the Wine Developers Guide on how to set up winedbg or another debugger Is this a configuration error on my part? Either way, is there some information I need to give to get this fixed? I appreciate it. Thanks -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell Freedom is slavery. Ignorance is strength. War is peace. -- George Orwell

2 5

Re: wsprintf
by Alexandre Julliard 21 Sep '01

21 Sep '01

Jeremy White <jwhite(a)codeweavers.com> writes: > Okay, so it's a slow news day, and I feel like stirring up trouble. Bad boy... > I would argue that it is, in fact, counterintuitive, to have this > sort of comment solely in the change log. The only time I ever think > to look at a diff (or even the change log) is when something has broken > recently. Well, because *you* don't look at it doesn't mean it's not the right place, does it? <g> I look at the CVS history quite often, and I find that in many cases it's the best way to find out why things are done a certain way. I don't see any reason to duplicate this info inside the code itself; since we are using a source control system we might as well take advantage of it. Plus it guarantees the info is stored permanently, unlike a comment that may get moved or lost next time the code is changed. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: wsprintf
by Alexandre Julliard 21 Sep '01

21 Sep '01

Aric Stewart <aric(a)codeweavers.com> writes: > I think this is part of what the change log is for. > > Alexandre has committed the patch, i will ask him if he wants me to > document something further and submit another patch. I added a comment in wsprintf16 to make Andreas happy. But I agree that the change log (and cvs diff) is the best way to store this kind of information. -- Alexandre Julliard julliard(a)winehq.com

3 2

Re: re-implementing real mode interrupts
by Alexandre Julliard 21 Sep '01

21 Sep '01

Mike McCormack <mike_mccormack(a)start.com.au> writes: > For example, currently calling DeviceIoControl VWIN32_DIOC_DOS_INT_13 > on the VWIN32 device calls to the real mode interrupt INT 13. It could > be re-implemented so that INT_Int13Handler does a DeviceIoControl and > the low level disk access code moved into the VWIN32 device > implemetation. VWIN32_DIOC_DOS_INT_13 is not really different from int 13, so it wouldn't make much difference either way. Much better would be to implement the higher level calls that are needed to reimplement the DOS interrupts; for instance int 13 should use the IOCTL_DISK calls of DeviceIoControl, int 25/26 should be replaced by Win32 device access (CreateFile("\\.\PHYSICALDRIVEx")+Read/WriteFile), etc. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: wsprintf
by Andreas Mohr 21 Sep '01

21 Sep '01

On Thu, Sep 20, 2001 at 01:38:11PM -0500, Aric Stewart wrote: > The behavior for wsprintfA is different that for wsprintf16 in how it > handles NULLs being passed as character parameters. This patch fixes > that. Hmm, can't you add a small comment inside the code that actually mentions this remarkable difference ? I think we should make every effort possible to ensure that important differences between architectures are being preserved as well as possible. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany

2 1

Re: Better font charset handling
by Huw D M Davies 21 Sep '01

21 Sep '01

On Fri, Sep 21, 2001 at 03:46:29PM +0200, Nerijus Baliunas wrote: > On Wed, 19 Sep 2001 17:22:45 +0100 Huw D M Davies <h.davies1(a)physics.ox.ac.uk> wrote: > > HDMD> Huw D M Davies <hdavies(a)codeweavers.com> > HDMD> Use the font charset to obtain a codepage for A->W conversion in the > HDMD> text functions. > > HDMD> Index: objects/text.c > > HDMD> + case VISCII_CHARSET: > HDMD> + case TCVN_CHARSET: > HDMD> + case KOI8_CHARSET: > HDMD> + case ISO3_CHARSET: > HDMD> + case ISO4_CHARSET: > HDMD> + case ISO10_CHARSET: > HDMD> + case CELTIC_CHARSET: > HDMD> + /* FIXME: These have no place here, but becasue x11drv > HDMD> + enumerates fonts with these (made up) charsets some apps > HDMD> + might use them and then the FIXME below would become > HDMD> + annoying. Now we could pick the intended codepage for > HDMD> + each of these, but since it's broken anyway we'll just > HDMD> + use CP_ACP and hope it'll go away... > HDMD> + */ > HDMD> + cp = CP_ACP; > HDMD> + break; > > Why these are here? Because they do not have windows equivalents? > If so, at least KOI8 shouldn't be there (IMHO). AFAIK they're not Windows charsets, somebody has made up some numbers and added them to wingdi.h . The reason they're here at all is because the x11drv enumerates fonts with these charsets and I'm claiming that this is a bug, since no application can be expected to know that these numbers mean. Now there is a RUSSIAN_CHARSET and this gets handled by the TranslateCharsetInfo before the switch. Huw.

1 0

Re: Better font charset handling
by Nerijus Baliunas 21 Sep '01

21 Sep '01

On Wed, 19 Sep 2001 17:22:45 +0100 Huw D M Davies <h.davies1(a)physics.ox.ac.uk> wrote: HDMD> Huw D M Davies <hdavies(a)codeweavers.com> HDMD> Use the font charset to obtain a codepage for A->W conversion in the HDMD> text functions. HDMD> Index: objects/text.c HDMD> + case VISCII_CHARSET: HDMD> + case TCVN_CHARSET: HDMD> + case KOI8_CHARSET: HDMD> + case ISO3_CHARSET: HDMD> + case ISO4_CHARSET: HDMD> + case ISO10_CHARSET: HDMD> + case CELTIC_CHARSET: HDMD> + /* FIXME: These have no place here, but becasue x11drv HDMD> + enumerates fonts with these (made up) charsets some apps HDMD> + might use them and then the FIXME below would become HDMD> + annoying. Now we could pick the intended codepage for HDMD> + each of these, but since it's broken anyway we'll just HDMD> + use CP_ACP and hope it'll go away... HDMD> + */ HDMD> + cp = CP_ACP; HDMD> + break; Why these are here? Because they do not have windows equivalents? If so, at least KOI8 shouldn't be there (IMHO). HDMD> + default: HDMD> + FIXME("Can't find codepage for charset %d\n", lf.lfCharSet); HDMD> + break; Regards, Nerijus

1 0

Re: winsock socket.c patch fixes issues with halflife's multicasting
by Francois Gouget 21 Sep '01

21 Sep '01

On 21 Sep 2001, David Hammerton wrote: > it seems there we're a few (bugs/typos) in dlls/winsock/socket.c which > prevented binding of ports when using multicast, or something along those > lines. > heres a small patch which fixes it. Please, user -u when you do a diff: * it makes it easier to see what the patch changes * it makes it easier to find the location you changed in the file. None of my copies of socket.c match yours so all the line offsets are off * it is more robust if you want to apply the patch to a modified version of the file (translation Unified diff formats actually have a chance to apply properly, yours does not) So I suggest you put the following line in your .cvsrc: diff -u All this is also explained there: Wine Developper's Guide: "Submitting Patches" http://wine.codeweavers.com/docs/wine-devel/patches.shtml#PATCH-FORMAT That said I must appologize: I am the one who broke this piece of code. A very bad case of copy/paste. Sincere appologies. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ In theory, theory and practice are the same, but in practice they're different.

1 0

re-implementing real mode interrupts
by Mike McCormack 21 Sep '01

21 Sep '01

Hi, I was wondering if it would be a Good Thing to start re-implementing real mode interrupts using Win32 calls. For example, currently calling DeviceIoControl VWIN32_DIOC_DOS_INT_13 on the VWIN32 device calls to the real mode interrupt INT 13. It could be re-implemented so that INT_Int13Handler does a DeviceIoControl and the low level disk access code moved into the VWIN32 device implemetation. This would better seperate the DOS and Win32 implementations. Any thoughts? Mike ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel