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

Re: Eliminate excessive retries in GetFileVersionInfo(Size) (fwd)
by lawson_whitney＠juno.com March 15, 2001

March 15, 2001

Oops, I misdirected this to wine-patches before. Sorry. On Thu, 15 Mar 2001, Dmitry Timoshkov wrote: > Hello. > > This patch helps eliminate excessive retries in GetFileVersionInfo(Size). > > Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Return from GetFileVersionInfo(Size) if specified file found, > but VS_VERSION_INFO resource not. > Good day! Here we go again. This breaks my app (juno 2.0.11) with builtin ole32/oleaut32. Native ole32/oleaut32 are so full of deadbeef they sort of stink. I guess we don't need to panic yet. I can revert it locally until so I can get and send mail until I see if I (or someone) can make some builtin version resources that will satisfy this app. It installs its own oleaut32.dll and with this patch in it thinks the install is busted. Regards, Lawson It is better to be lucky than good. - J. A. Soucy ---

1 0

Re: winedefault patch
by Andreas Mohr March 15, 2001

March 15, 2001

On Wed, Mar 14, 2001 at 09:35:17PM +0100, Ove Kaaven wrote: > Wine won't load builtin dlls if a full path to a nonexistent file is > specified, so the default registry should probably not have a full path to > dplayx.dll. Some guy managed to start Settlers 3 after this was fixed... > > Log: > Removed path from dplayx registry entry, so that the builtin dplayx can be > loaded. Alexandre, please add a comment to winedefault.reg reminding people of this problem for future entries. Thanks ! -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.germany.net/100-30936/

1 0

Re: [PATCH] deferred trace
by Alexandre Julliard March 15, 2001

March 15, 2001

"Rob Farnum" <rfarnum(a)mindspring.com> writes: > I am not exactly sure what you mean by this. Do you mean to put the > code that would be in the dll, into the debugger, or to extend the > debugger in such a way that it can load dll's to enhance its > functionality, or something else? I mean that the code that would have been in the dll and loaded into Wine should be in the debugger instead. So for instance, instead of having a magic key (or X message) to switch tracing on, you'd have a debugger command 'set tracing on' that would poke into the Wine address space to do it. Since you can read/write memory, call functions (I think it's broken now but should be easy to fix), etc. from the debugger you can do everything from here and avoid the need to have any debugging code running inside the Wine process. > This would bypass the objection of intercepting a key, like F12, and > using it to generate a window list dump, and replace it with a > mechanism that uses the debugger own builtin functions to do that. Yes, exactly. > I think it is desirable to use as much of the existing debugger > functionality as possible, and to add an "elaborate mechanism in the > debugger" that allows it to be dynamically extended in > functionality. It would certainly be possible to load dlls inside the debugger itself to extend it; though maybe simply loading a batch file containing debugger commands may allow to do a lot of things already without requiring compiling new code. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: [PATCH] Version info for comctl32.dll
by Dmitry Timoshkov March 14, 2001

March 14, 2001

"gerard patel" <gerard.patel(a)asi.fr> wrote: > ChangeLog: > > * dlls/comctl32/rsrc.rc > Add version info. [...] > LANGUAGE LANG_NEUTRAL, SUBLANG_NEUTRAL > + > +1 VERSIONINFO > +FILEVERSION 4, 72, 0, 0 > +PRODUCTVERSION 4, 72, 0, 0 > +FILEFLAGSMASK VS_FFI_FILEFLAGSMASK > +FILEOS VOS_DOS_WINDOWS16 [...] > + VALUE "FileVersion", "0.01\000" [...] > + VALUE "ProductVersion", "1.00\000" I thought that include/wine/wine_common_ver.rc will serve as the quite reasonable defaults for all built-in Wine dlls. If not, it should be changed for ALL dlls in ONE place. Besides that: 1. I believe that version numbers should be equal in both numerical field and in the string value (0.01 != 4.72 and 1.00 != 4.72). 2. There is no need for excessive \000 at the end of the string value. 3. All well behaving programs do read "VarFileInfo"/"Translation" before retrieving other version information. LANGUAGE does nothing here. 4. Did you try to use my sample application showing version info? 5. Version resources in kernel, user, gdi for both 16 and 32-bit dlls could serve as an example of adding version resources into built-in dlls.

1 0

Re: [PATCH] deferred trace
by Alexandre Julliard March 14, 2001

March 14, 2001

"Rob Farnum" <rfarnum(a)mindspring.com> writes: > My current design is to have yet another dll that would register > itself as the handler for this XClientMessage, so that on reciept of > the XClientMessage, it is simply passed to this new dll. This dll > would implement whatever application specific debugging tools I > need, with only the bare minimum of support from wine needed. Since > the wine debugger already has quite a bit of the functionality that > is needed, it might be interesting if this method could be used to > effectively open a pipe and drive the wine debugger externally. What you should rather do IMO is to put your dll inside the debugger, and have the debugger drive Wine instead of the other way around. Then you can add all kinds of elaborate mechanisms in the debugger, and do anything you want without needing any cooperation from the running Wine process. -- Alexandre Julliard julliard(a)winehq.com

2 1

RE: Problems with WM_NCHITTEST and HTTRANSPARENT
by Patrik Stridvall March 14, 2001

March 14, 2001

> I'm currently having problems with this situation: > > Thread 1 owns some controls (modeless dialog box, actually) > > Thread 2 owns a window that covers the dialog (let's say it's like a > "skin" or something...) > > The window procedure for thread 2's window return HTTRANSPARENT in its > WM_NCHITTEST handler, so in theory mouse messages should get > passed down > to thread 1's controls. Now, what happens is this... [snip] > Any ideas on how to solve this, or whether it's supposed to work at all? I > think I could fix some games if this worked... otherwise I'll have to > think of some other way... >From MSDN: < HTTRANSPARENT < In a window currently covered by another window in the same thread < (the message will be sent to underlying windows in the same thread < until one of them returns a code that is not HTTRANSPARENT). Note "window in the same thread". So it seems that you (Wine) shouldn't pass down mouse messages to thread 1 in your example.

1 0

Problems with WM_NCHITTEST and HTTRANSPARENT
by Ove Kaaven March 14, 2001

March 14, 2001

I'm currently having problems with this situation: Thread 1 owns some controls (modeless dialog box, actually) Thread 2 owns a window that covers the dialog (let's say it's like a "skin" or something...) The window procedure for thread 2's window return HTTRANSPARENT in its WM_NCHITTEST handler, so in theory mouse messages should get passed down to thread 1's controls. Now, what happens is this... -Mouse message arrives at thread 2 -TranslateMouseMsg calls WINPOS_WindowFromPoint -WINPOS_WindowFromPoint sends a WM_NCHITTEST to window -Window procedure returns HTTRANSPARENT -WINPOS_WindowFromPoint finds the controls, and returns that -TranslateMouseMsg wakes owner of controls (thread 1) -Mouse message arrives at thread 1 -TranslateMouseMsg calls WINPOS_WindowFromPoint -Since the transparent window is not owned by the current thread, WINPOS_WindowFromPoint doesn't bother to send it a message, but rather returns HTCLIENT directly -WINPOS_WindowFromPoint returns the transparent window -TranslateMouseMsg wakes thread 2 Repeat. This blocks all further mouse input processing, by the way... Any ideas on how to solve this, or whether it's supposed to work at all? I think I could fix some games if this worked... otherwise I'll have to think of some other way...

1 0

Re: [PATCH] deferred trace
by gerard patel March 14, 2001

March 14, 2001

At 12:04 PM 14/03/2001 -0500, you wrote: >I remember wishing fondly for something like this when we were working >on WordPerfect, but never having the time to do it myself. FYI someone at Codeweavers has something much more sophistificated than my simple patch but from my understanding it's not ready for general use :-/ Gerard

2 1

Re: [PATCH] deferred trace
by Alexandre Julliard March 14, 2001

March 14, 2001

Gavriel State <gav(a)transgaming.com> writes: > I disagree - many of the bugs I encounter can happen well into the run > of a program. For example, debugging a dialog box in an app that comes > up only after a specific set of occurances. Having the ability to turn > on -debugmsg +all at will would make this kind of debugging much easier. My reply was more targeted at the dumping of the window handles; I don't deny switching tracing on or off would be useful, but it needs to be done in a more generic way. Also this can be done externally to Wine, so that we don't need to burden the core dlls with extra command-line options or magic key sequences. There are many ways of doing that; an output filter is very easy to do and would work in many situations; if you need more complex stuff you could do it from the debugger, or write a small app that uses the debug API to manipulate the tracing state. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: [PATCH] deferred trace
by Alexandre Julliard March 14, 2001

March 14, 2001

gerard patel <gerard.patel(a)asi.fr> writes: > 2) I don't see how I will get the window list I generate with > WIN_WalkWindows if there is no change at all in Wine - I should > have said that to cut in the trace size in not a goal per se, but a > mean to make debugging easier. > If I have to make a first run with full trace that I have to browse to see > what is the meaning of the window handles appearing in the trace, I lose > a lot of time. Having immediately a view of all existing windows is *very* > handy. I don't doubt it's very useful for the specific problem you are tracking; but it's hardly generic enough to be included in the main tree. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Heroes 3
by Andreas Mohr March 13, 2001

March 13, 2001

On Mon, Mar 12, 2001 at 07:06:03PM +0100, Rustan Rosen rustan(a)lysator.liu.se [AndiM/Usenet 01/2001] wrote: > I found this on wine-users, and have the same problem. I did as you said, > and have attatched the file. Good ! > I have tried to test different setups, and seem to have problems with > directx, it wants to install 6.1, which doesnt work, and then says my > system doesnt have directx ('failed' in a checklist). I use the latest > wine in debian unstable, from 5/3 2001. After checking for directx, it > seems to install fine, but then just hangs. After killing it, and running > wine HEROES3.EXE > from the installed directory, it gives the above message. Can you help? > Shall I ask someone else? > Shall I supply more data? Call kernel32.192: CreateFileA(418c1a11 "C:\\Program Files\\3DO\\Heroes3\\DATAh3sprite.lod",c0000000,00000003,405e6ce4,00000003,00000080,00000000) ret=00599971 fs=008f trace:string:lstrcpynA (0x405e6400, "/kul/musik/wine/fake_windows", 1024) Ret kernel32.192: CreateFileA() retval=ffffffff ret=00599971 fs=008f . . . Call user32.425: MessageBoxA(00000000,005dd4fc "Unable to initialize resources - possible disk problem.",005dd628 "Unexpected Program Termination",00000010) ret=004cef94 fs=008f Hmm. Does C:\\Program Files\\3DO\\Heroes3\\DATAh3sprite.lod exist ? Or maybe this should be DATA\\h3sprite.lod ?? Hmm. Let me check this. I smell some Wine problem... BTW, have you tried running http://home.germany.net/100-30936/download/winecheck ? Probably doesn't help here, though... ARGL: Call kernel32.414: GetFullPathNameA(005d78d0 ".\\DATA\\",00000104,405e6cdc,405e6ccc) ret=00599630 fs=008f trace:string:lstrcpynA (0x405e63d0, "/kul/musik/wine/fake_windows", 1024) trace:string:lstrcpynA (0x405e63ed, "Program Files/3DO/Heroes3", 995) trace:string:lstrcpynA (0x405e67d3, "PROG~FBU\\3DO\\HEROES3", 1021) trace:string:lstrcpynA (0x405e67d2, "/Program Files/3DO/Heroes3", 1021) trace:string:lstrcpynA (0x405e67ed, ".\\DATA\\", 995) trace:string:lstrcpynA (0x405e6cdc, "C:\\Program Files\\3DO\\Heroes3\\DATA", 260) Ret kernel32.414: GetFullPathNameA() retval=00000021 ret=00599630 fs=008f THAT's it !! GetFullPathNameA() is broken (clips trailing '\\'). Latest Wine release, BTW ? Or which one ? Oh well, something needs to be fixed then, I guess... ;-) Andreas Mohr

2 1

RE: The PEACE Project
by Patrik Stridvall March 13, 2001

March 13, 2001

> I don't know if you know about The PEACE Project: > > http://chiharu.haun.org/peace/ Now I do. :-) > What is PEACE? > > PEACE is a set of programs to run Win32 apps on NetBSD/i386 > (and other ports > in the future?) box. I see. > What is the difference from other Win32 emulators? > > Actually, PEACE is éWin32-compatible package' rather than > éemulator' because > different from Wine and WABI, And Wine isn't a "Win32-compatible package"? > PEACE does not have éemulator > executable'. > EXE files are directly executed from sh or csh. The above is IMHO a rather clintonesque use of the words emulator and executable. They hide the comparable code in NetBSD's dynamic linker instead. Not impressed, eventhough we could and probably should do that in the future. However if we hide the fact Wine is run, many user will not realize that it really is Wine's fault that their Win32 application crashes and say to their friends that Linux is unstable which gives Linux a bad reputation. We don't want that do we? So we probably shouldn't make it transparent at least not as long Wine still is alpha. > PEACE consists of the following 3 components: > > 1.In-kernel *.EXE loader Can't find the source but can't imagine it is very complicated. Probably somthing similar to what David Howells did for Linux. > 2.Dynamic linker for Windows *.DLLs Hmm, 233 lines of code including comments. Not very revolutionary. > 3.Win32 API implementation (i.e. core DLLs) This is supposed to do exact what Wine (Winelib) does. However it currently only implements a very small part of what Wine currently does as they admit... > How many Win32 API functions are implemented? > > Currentry, most APIs are NOT implemented. ... here In short this is just some Japanese guys trying to reinvent the wheel. I really can't understand why they don't cooperate with us in the Wine project instead.

6 5

Re: [PATCH] deferred trace
by gerard patel March 12, 2001

March 12, 2001

At 11:24 AM 10/03/2001 -0800, you wrote: >gerard patel <gerard.patel(a)asi.fr> writes: > >> This implements a way to not output the debug trace to disk until the >> user hits Alf + F12. The goal is to avoid too big trace files. > >I think it would be much better to do that with a small external >program that you pipe the debug output into. This way you can have >much more flexibility I don't see why. 2 other points : 1) I wonder if I will not lose in speed with this approach; it seems to be more efficient to stop the output ASAP, than to filter data after it has passed through a pipe. I have timed Bcb4 loading with Wine on my computer (K6-350) - without any trace : 48 seconds With a simple -debugmsg +win,+relay : - with my patch : 70 seconds -> 22 seconds overhead - with a redirection to /dev/null : 95 seconds -> 47 seconds overhead I don't know if a pipe would be more efficient that a redirection, though. 2) I don't see how I will get the window list I generate with WIN_WalkWindows if there is no change at all in Wine - I should have said that to cut in the trace size in not a goal per se, but a mean to make debugging easier. If I have to make a first run with full trace that I have to browse to see what is the meaning of the window handles appearing in the trace, I lose a lot of time. Having immediately a view of all existing windows is *very* handy. >, and you don't need to hardcode a specific key >that some apps may need. But my patch does not use the Alt+F12 key if the -dt command line option is not used. It's true that some apps use this key, but in this case it's only debugging that is affected because the app does something when I use this key. It has never been a problem until now. Maybe a signal could be used instead. Gerard

2 1

RE: The PEACE Project
by Patrik Stridvall March 12, 2001

March 12, 2001

> > > What is the difference from other Win32 emulators? > > > > > > Actually, PEACE is éWin32-compatible package' rather than > > > éemulator' because > > > different from Wine and WABI, > > > > And Wine isn't a "Win32-compatible package"? > > > > > PEACE does not have éemulator > > > executable'. > > > EXE files are directly executed from sh or csh. > > > > The above is IMHO a rather clintonesque use of the words > > emulator and executable. They hide the comparable code > > in NetBSD's dynamic linker instead. > > > > Clintonesque?? HAHAHAHAHAHAHAHAHAHAHA That's really good > dude! I guess it > follows in the tradition of words like "nasty". It follows the same tradition as the word quisling which means "A traitor that serves as the puppet of the enemy occuping his or her country." after Vidkun Quisling the notorius Norwegian traitor. Being clintonesque means "Deliberately distorting the meaning of a word or words in order to make somebody believe something that is not true." Compare Bill Clinton saying "I did not have sex with that woman" using a rather non standard definition of the word sex. In the case PEACE this might not have been deliberate, but because of ignorance, so perhaps the use of the word clintonesque was too harsh. > > Not impressed, eventhough we could and probably > > should do that in the future. > > > > I thought there was another kernel module running around that > loaded wine > for exe files. Used BINFMT_MISC or something? See Chad's mail. > > However if we hide the fact Wine is run, many user > > will not realize that it really is Wine's fault > > that their Win32 application crashes and say to > > their friends that Linux is unstable which gives > > Linux a bad reputation. We don't want that do we? > > > > So we probably shouldn't make it transparent at > > least not as long Wine still is alpha. > > > > Should there ever be a kernel module exe loader? The advantage of a kernel module loader is that you can do relocation on demand as well as having the ability to just discard such pages when memory is low instead of swapping them out. > Codeweavers is on the right track here, allowing users to > launch Windows > apps from gnome by creating a file association. Agreed. > > > PEACE consists of the following 3 components: > > > > > > 1.In-kernel *.EXE loader > > > > Can't find the source but can't imagine it is very complicated. > > Probably somthing similar to what David Howells did for Linux. > > > > I thought David's module was implementing the Wine in kernel > space (e.g. > part 3 of this). This part can be done with or without > having Wine in the > kernel. Not quite he is trying to implement the Wine _server_ in kernel space. ie approximately thoses things that requires some sort of intra-process communication. > > I really can't understand why they don't cooperate > > with us in the Wine project instead. > > I cannot either. I know that there is this whole thing about > wanting to > write your own code for stuff, but that is usually a waste of time. > Furthermore, the Wine project is developed in an extremely > open way by a lot > of very talented developers. It is a real shame to see > someone who could > obviously help out the Wine project going out and doing their > own program. > > Anyone can join the wine development team. Simply subscribe > to wine-devel > and wine-patches and start hacking. Because all patches go through > Alexandre before going into CVS every developer has basically > equal chances > of getting their patch into the tree (assuming that it is > following the > overall architecture goals of Wine). Indeed and if they prefer not to communicate in english, setting up a wine-devel-jp mailing list shouldn't be a problem. Most of the patches they send in will "speak" for itself without any or at least only a very short explaination. > Actually, I would say wine is an > extremely good example of the open source development process. > > There is also no licensing issue with Wine, it's under such a liberal > license that anyone can use it! Agreed.

1 0

RE: The PEACE Project
by Patrik Stridvall March 12, 2001

March 12, 2001

> > I really can't understand why they don't cooperate > > with us in the Wine project instead. > > That's exactly what I thought several weeks ago when I first > heard of it. > > Licensing issues might be the reason (I did not look at their > license !). They use the BSD license, unfortunately the one with the advertisment clause. However I don't imagine it will be a problem since there is very little if anything that they have implemented that we haven't implemented I long time ago already. Additional problem is that they use C++. :-) In short they have wasted a lot of effort for little or no gain. > Other than that I'm tired of YAW (Yet Another Windows, which is > the name of yet another windows package, coincidentally ;-) Indeed. I can understand people that start working with a project has a lot of ideas and the project leader rejects them and they grow tired and decide to do it themselves. However for a project like Wine most things really can't be done that many ways since it must be compatible with Windows so this shouldn't really be a very large problem. In this case perhaps they, being Japanse, felt uncomfortable with cooperating with english speaking people. I noticed that they have a Japanese only mailing list. Anyway we could always create a wine-devel-jp or whatever if that was a problem.

1 0

The PEACE Project
by Damjan Lango March 12, 2001

March 12, 2001

Hi, I don't know if you know about The PEACE Project: http://chiharu.haun.org/peace/ What is PEACE? PEACE is a set of programs to run Win32 apps on NetBSD/i386 (and other ports in the future?) box. What is the difference from other Win32 emulators? Actually, PEACE is `Win32-compatible package' rather than `emulator' because different from Wine and WABI, PEACE does not have `emulator executable'. EXE files are directly executed from sh or csh. Requirements More information PEACE consists of the following 3 components: 1.In-kernel *.EXE loader 2.Dynamic linker for Windows *.DLLs 3.Win32 API implementation (i.e. core DLLs) How many Win32 API functions are implemented? Currentry, most APIs are NOT implemented. (I'm not involved in that project, just found it on the web) ciao Damjan Lango

1 0

Re: RFC: client side implementation of async I/O
by Alexandre Julliard March 10, 2001

March 10, 2001

Michael McCormack <mccormac(a)aals27.alcatel.com.au> writes: > The patch can be further optimised, for example by keeping active asyncs in a > seperate list from inactive asyncs. i think it is more efficient because the > number of server calls and context switches is reduced. Reducing the number of server calls but making them more expensive is not necessarily a gain. Show me the numbers... > What i'm more interested in is whether having waiting clients running > concurrently with wineserver and those clients waking themselves from wait is > a good idea. I'm not sure it's a good idea, particularly if we want to support signals (which I think would be a good thing since it allows getting rid of the service thread). > Similarly, we could create a client side file handle cache that is alerted by > the wineserver when it becomes invalid. Before each fd is used, the cache > implementation would poll on the wineserver communication fd to confirm the > cache is valid, which would further improve the speed of file I/O. (a single > poll vs. a full server call) You'll probably still need a server call to find out about file locks at some point. And again you'll get in trouble if you want to support signals. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: [PATCH] deferred trace
by Alexandre Julliard March 10, 2001

March 10, 2001

gerard patel <gerard.patel(a)asi.fr> writes: > This implements a way to not output the debug trace to disk until the > user hits Alf + F12. The goal is to avoid too big trace files. I think it would be much better to do that with a small external program that you pipe the debug output into. This way you can have much more flexibility, and you don't need to hardcode a specific key that some apps may need. -- Alexandre Julliard julliard(a)winehq.com

1 0

Palette managing
by kenon＠go2.pl March 9, 2001

March 9, 2001

Hi In file windows/painting.c in function RealizePalette16 I found that line 1713: if (hWnd) SendMessageA( HWND_BROADCAST, WM_PALETTECHANGED, hWnd, 0L); broke some applications . When I comment it out - every things work well, but when I leave it some child-windows are displayed in improper place. I think this message should be sent only when used entry in COLOR_sysPal is replaced by new one (function X11DRV_PALETTE_SetMapping in line 907 when index == -1). Maciek Kaliszewski

1 0

Re: Edit control notification fix
by Andreas Mohr March 9, 2001

March 9, 2001

On Fri, Mar 09, 2001 at 03:52:56PM +0800, Dmitry Timoshkov wrote: > Hello. > > Andreas Mohr privately reported that some old 16-bit installer > started to not update its edit control after my patch entitled > "Do not notify parent of the Edit control on WM_SETTEXT when Edit > is part of the ComboBox." Investigation has shown that installer > has its main dialog window defined in resources, and DIALOG_GetControl16() > gets edit control with style ES_COMBO (0x200) defined there. > My first attempt to fix the trouble was to simply mask out not > allowed styles in the DIALOG_GetControl16(): i.e. for edit control > do style &= ~ES_COMBO. That hack cured the application, but Andreas Well, that's not exactly true. You did not do it "for edit control". You did it for *all* controls in DIALOG_GetControl16() (at least in the patch you sent me). That's why I objected. I just had to :) > didn't like that approach. After some thinking, I added yet another > test into my "Edit Control Test Suit". And here is the result of it. > > Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Do not send notification to parent of an edit control, > if parent is a child window. Remove old and not correct patch. OK. I can't really judge whether that's correct, as I'm not too much into these kinds of things. Hopefully it's correct :) Thanks again, Andreas Mohr

2 1

Re: Speeding up wineserver syncronization objects with shared memory
by Alexandre Julliard March 8, 2001

March 8, 2001

David Howells <dhowells(a)cambridge.redhat.com> writes: > Not so... The file offset must also be page aligned! OK, this has apparently changed in kernel 2.4; in kernel 2.2 block size alignment is enough. That's unfortunate, but I guess it was necessary to support large files or memory sizes. Then yes, in 2.4 your patch will be more useful. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Speeding up wineserver syncronization objects with shared memory
by Alexandre Julliard March 8, 2001

March 8, 2001

David Howells <dhowells(a)cambridge.redhat.com> writes: > My main gripe is the slow speed of access to files... Every Read/WriteFile > goes to the wineserver to convert the handle into a file descriptor and to > check for locking. The FD is then passed back over a UNIX domain socket, used > once and then closed. Note that we are no longer doing that in the latest versions; the file descriptor is only transferred once, and all further requests are done on a pipe which is faster than a socket. > Gavriel State <gav(a)transgaming.com> wrote: > > In my experience Alexandre far prefers incremental change to kind of > > approach you're taking. Using that kind of approach will improve the > > chances that your code will make it into Wine at some point. > > Hmmm... It's difficult to determine how to do it incrementally without making > for even more work, but I think I know what you mean. The kernel module itself may be hard to do incrementally, but you should really consider reusing the existing server API so that your module can be plugged in easily. For instance your module entry points should be the same as the server requests, and use the same request structures. > Context switching is the main element of it. Going to the wineserver and back > again just for a ReadFile() call or a Wait*() function incurs a fairly serious > penalty (particularly on an X86, I think). Plus there's no requirement for the > kernel to pass the remains of your timeslice to the wineserver and back > again. I still think that it should be possible to improve that by a small kernel hack. It will never be as fast as doing everything in the kernel of course, but it may just be fast enough to avoid the need to reimplement the whole server. > Look at the VM size of something like MS Word, and think of not having to > allocate buffers to store all those DLLs, thus eating a massive chunk out of > your machines total VM. Have you measured how many dirty pages you can avoid with your change? It seems to me that in most cases, when the dll is loaded at its preferred address, the number of pages made dirty by the fixups should be quite small anyway. -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: Speeding up wineserver syncronization objects with shared memory
by Alexandre Julliard March 8, 2001

March 8, 2001

Gavriel State <gav(a)transgaming.com> writes: > Looking at the kernel sources, it appears to be page-alignment, not > filesystem block size that mmap needs to match. Rereading old wine-devel > archives, it appears that the notion that the filesystem block size is > involved is either from a very old kernel, or a misreading of some kernel > comments. Page alignment is needed for the address in memory, not for the offset inside the file on disk; since section virtual addresses in PE files are always page-aligned the memory address is never a problem. The only problem comes from the alignment of the data inside the PE file, and this is where we only need block-size alignment to make mmap possible. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Speeding up wineserver syncronization objects with shared memory
by Alexandre Julliard March 7, 2001

March 7, 2001

David Howells <dhowells(a)cambridge.redhat.com> writes: > So this saves you the cost of the fd transfer net packet. Though you still > have to do the two context switches, which is my main contention. I suspect we are doing more than two switches (though I haven't proved it), which is why I think there is a margin for improvement. You'll obviously always have the context switch cost unless everything is in the kernel. > True, but I'd have thought that the context switches involved are still a cost > you can't get rid of so easily. Out of interest, how do you plan on doing the > locking stuff for Read/WriteFile? Cache it locally? It is unfortunate, but you > can't really make use of UNIX file locking, since this is mostly advisory and > as such doesn't actively stop read/write calls. Yes, we'll need to store the locks in the server and check them before each read/write (and probably also release them afterwards if necessary). There may be some optimisations possible, but we should probably do it the easy way first. > Seriously, though, whilst this'd be a lot easier in many ways (and it would > allow you to avoid the context-switch penalties), you wouldn't be able to take > full advantage of the available support in the kernel, which is more capable > than the standard UNIX userspace API suggests. I don't see why. I'm not suggesting keeping the current socket stuff, just reusing the structures. So basically instead of passing the address of the stack arguments (which is really ugly IMO) to your ioctl, you pass one of the server request structures. This allows your changes to be localized to wine_server_call and doesn't require changing any of the routines that make server calls. Obviously you'd need some more changes for a few calls like ReadFile/WriteFile, but most operations could switch to your mechanism without needing any change. You simply cannot require people to recompile all of Wine to use your module. > > I still think that it should be possible to improve that by a small > > kernel hack. It will never be as fast as doing everything in the > > kernel of course, but it may just be fast enough to avoid the need to > > reimplement the whole server. > > If you want to suggest exactly what you'd like to see as a hack... I don't know exactly, there are many ways of doing it; you can have a specialized fifo, a network protocol, an ioctl, etc. Basically any mechanism that ensures that we do the strict mimimum number of context switches and schedule() calls for a server call. And probably also a way to transfer chunks of memory from the client address space so that we don't need the shared memory area. > As far as I've observed (I've got Win2000 available), most Windows DLL's have > 512-byte (sector) alignment internally, _not_ 4096-byte (page) alignment for > the sections. This means that the separate sections can't be mmap'd (or else > they'd lose their required relative relationships): Actually the file alignment doesn't need to be 4096, it needs to match the filesystem block size. On a FAT filesystem the block size is 512 so Linux will happily mmap every section. On a 1k-block ext2 fs it will be able to mmap about 50% of them. > Also, since DLLs and EXEs are not compiled as PIC (the MSDEV compiler not > having such an option as far as I can recall), the fixup tables usually seem > to apply to just about every page in the code section. Only if the dll cannot be loaded at the preferred address, which shouldn't happen too often. I'm not saying your patch is useless, but I doubt the gain is as large as you seem to think. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Wineserver semantics
by Alexandre Julliard March 6, 2001

March 6, 2001

Ryan Cumming <bodnar42(a)bodnar42.dhs.org> writes: > What about having the file descriptor cache explictly invaildated? Like, > the server keeps track of which file descriptors the various wine > processes have cached, and if a process closes or performs some locking > operation on a file descriptor, all the other wine proceses that are using > that file descriptor are explictly notified. This way processes can assume > a file descriptor is valid unless told otherwise... would this be any > better performance-wise? Does it fit in to the wineserver architecture > nicely? ;) Not really; you'd either need to callback into the client, which creates a lot of synchronisation issues, or use a shared memory area which implies locking. Either way doesn't really fit in the current model. And as mentioned already we'll probably still need a server call on each file access to implement file locking. -- Alexandre Julliard julliard(a)winehq.com

1 0