- wine-devel - winehq.org

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

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