- 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

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