September 2005 - Wine-Devel

ntoskrnl patch, reviews/comments/suggestions wanted

by Ivan Leo Puoti

As Dmitry rightly pointed out, wine-devel is a good place to post stuff for help/comments/review, so here is an (almost) full diff of my tree against cvs. Without going as far as making wineserver a user mode ntoskrnl like mike_m suggested, this code allows kernel mode drivers to work decently in wine, naturally not many have been tested but it's a start. Alexadre's main complaint is that it's ugly to pass handles to ntoskrnl because it's a client process, currently we pass a pointer to a DEVICE_OBJECT, that obviously won't do but we're not sure what would do, suggestions are welcome. secdrv.sys from safedisc 1 works. Some code used to work around the anti debugger checks has been removed, so you can't run safedisc in winedbg with this patch. Running tools/make_requests and a full ./config.status && make depend && make is needed to build this patch. Ivan.

Sept. 6, 2005

Re: MSI: test creating a package

by Andreas Mohr

Hi, On Tue, Sep 06, 2005 at 03:21:55PM +0900, Mike McCormack wrote: > ChangeLog: > <aric(a)codeweavers.com> > <mike(a)codeweavers.com> > * test creating a package + res = MsiCloseHandle( suminfo); + ok( res == ERROR_SUCCESS , "Failed to close suminfo" ); + + + res = MsiCloseHandle( hPackage); + ok( res == ERROR_SUCCESS , "Failed to close package" ); +} Hmm, something seems to be missing here... Andreas

Sept. 6, 2005

Re: Some troubles with InstallShield

by Marcus Meissner

On Mon, Sep 05, 2005 at 10:21:17PM +0400, Vitaly Lipatov wrote: > Can anyone test PHP Expert Editor for install? It uses InstallShield > and install loop at message "File access denied." > > http://www.ankord.com/download/phpxedit_33.zip Installs fine here (except dialogbox at the end and that it requires ActiveX). Make sure no other InstallShield instances are running before starting the install. (killall wine-preloader) Ciao, Marcus

Sept. 6, 2005

Re: Web Server Back Online

by Saulius Krasuckas

* On Fri, 2 Sep 2005, Saulius Krasuckas wrote: > * On Thu, 1 Sep 2005, Jeremy Newman wrote: > > * On Thu, 2005-09-01 at 23:43 +0100, Richard Cohen wrote: > > > > > > Dont't you mean text/x-patch? > > > > Right, I added both. Since some pass it as text/x-patch, and some pass > > text/x-diff. > > Works fine for me. Big thanks. It stopped working nice for me again. The server returns "Content-Type: text/x-diff" in the HTTP headers, but somehow all my browsers started asking me about what should they do with such file. Any ideas, why? What have changed since then?

Sept. 6, 2005

Re: fake higher directx version

by Tom Wickline

On 9/5/05, Mike McCormack <mike(a)codeweavers.com> wrote: > > Christoph Frick wrote: > > > i am currently trying rFactor with WINE. the config programm wants dx9C > > - the current version with the last release version of wine is dx9B. > > where would i find this so i can fake a higher version? a naïve grep > > found nothing in my source. > > Have a look at the file: > > wine/dlls/d3d9/version.rc Wouldn't it be best to set all DX dlls to version 9.0c and have our registry setting the same, so everything is kept in sync ? Tom > > Mike > > > >

Sept. 5, 2005

Re: Suggestions for improvement of the emulator

by Dmitry Timoshkov

"Troy Rollo" <wine(a)troy.rollo.name> wrote: > Even as things are now there is a disincentive to new developers. Some > developers don't bother submitting patches because they feel it's too much > work to get them accepted, Right, if the patch is a pure hack, or of a bad quality, it won't be accepted. If you insists, that that should not be an obstacle for accepting patches, or even that the patches can be committed without review and approval, then you don't understand something. > and sometimes the patch doesn't get written at all > because there is not enough certainty that it will be accepted. Before you > suggest that this is speculative, I have one developer here who has made > patches to fix Wine bugs experienced at home and not submitted them for that > exact reason. That's not Alexandre's problem at all. You blame him, that he doesn't accept patches of poor quality, or doing wrong things, or not properly tested. > You can try getting guidance on what is likely to be accepted, > but again you run into a bandwidth problem with Alexandre - one person cannot > effectively give guidance to everybody who needs it, and such guidance as he > is able to give doesn't always help that much. That's why we have wine-devel. If in doubt, or need a guidance - ask there, not blame Alexandre that you don't know how to fix a bug, or implement an API, that's simply not professional. > The process requires that > developers risk their work amounting to nothing because it won't be accepted. This is true for any other project as well. > How many times have you seen people say that "Alexandre doesn't always know > what he wants, but he knows what he doesn't want"?. Not true. Alexandre almost always tells everyone that Wine needs to behave like Windows does, and if in doubt - implement it the same way as in Windows. The only problem which arises with that aproach is that we often don't know how some functionality is done in low level in Windows. Alexandre sometimes doesn't know either, but that's not the reason to blame him for that. > That perception is partly > due to the fact that it is impossible for one person to take the time to > really understand what is wanted for every area of Wine that is being worked > on at any one time (humans are linear, it limits them). That's a pure speculation, I won't say more. -- Dmitry.

Sept. 5, 2005

Re: Need ideas about ntoskrnl

by Mike McCormack

Vitaliy Margolen wrote: > We need ntoskrnl to run some subset of drivers on wine. Notably cd protection > drivers. They are not a hardware drivers, but a means to access something that > is not accessible from user space. So in a sense ntoskrnl is just a process to > run those drivers in, and send/receive requests to/from those drivers. > > You need to keep in mind that this is a kernel level, so some things will not > work, and some things have to work that normally do not in the user space. Also > ntoskrnl for windows _is_ what wineserver for wine. I think that the only way to make device drivers work properly is to eliminate wineserver completely, and make it what it really wants to be, which is a user mode implementation of ntoskrnl, something like User Mode Linux. That would require being able to write to a process's memory from the ntoskrnl, which is what your really need to implement ReadFile and WriteFile so device driver can work properly. That project is really beyond the scope of Wine... but an interesting one none the less :) Mike

Sept. 5, 2005

Re: fake higher directx version

by Mike McCormack

Christoph Frick wrote: > i am currently trying rFactor with WINE. the config programm wants dx9C > - the current version with the last release version of wine is dx9B. > where would i find this so i can fake a higher version? a naïve grep > found nothing in my source. Have a look at the file: wine/dlls/d3d9/version.rc Mike

Sept. 5, 2005

Re: Suggestions for improvement of the emulator

by Troy Rollo

On Tue, 6 Sep 2005 09:59, Ivan Leo Puoti wrote: > committed. Also I've recently noticed that very few of the patches being > submitted are being committed, mainly because Alexandre appears to be > *very* busy with some work (mac support maybe?), He may well be very busy with something else, but at this stage there is also the 0.9 deadline looming, which, doing things by the book, prevents high risk patches from going in. This is something that could be alleviated with branches, but CVS branching is, by today's standards, ugly and cumbersome. The area you are working in is of course something that Alexandre would likely keep in his area even in the event of delegation of parts, but with delegation of other areas he would hopefully have more time to consider the options for moving your stuff forward.

Sept. 5, 2005

Re: Suggestions for improvement of the emulator

by Ivan Leo Puoti

Troy Rollo wrote: > The process requires that > developers risk their work amounting to nothing because it won't be accepted. > How many times have you seen people say that "Alexandre doesn't always know > what he wants, but he knows what he doesn't want"?. That's a problem vitaly and I now have, ntoskrnl can run kernel mode drivers just fine (Ok, it has for months but only recently it's started using real device handles), but Alexandre doesn't like some things about it and doesn't have any alternative solutions, so we're sort of stuck with 4100 lines of working code, but no immediate prospect of getting them committed. Also I've recently noticed that very few of the patches being submitted are being committed, mainly because Alexandre appears to be *very* busy with some work (mac support maybe?), so dependencies of ntoskrnl that could go in now are still pending approval, the result is development isn't as fast as it could be because we aren't sure what to do next, have no indication of what really needs to be changed in our code, and we have to wait several days to know if what little we have submitted is ok, and when you've got loads of patches that depend on each other that is a bit of an issue. Ivan.

Sept. 5, 2005

Re: Suggestions for improvement of the emulator

by Troy Rollo

On Mon, 5 Sep 2005 20:30, Francois Gouget wrote: > What makes you say that? > What would need changing to efficiently accomodate more developpers? I should preface this by saying that I don't mean any criticism or offence by this. You asked the question and the following reflects my observations of current limits to the development model and what would have to be changed to improve scalability. That doesn't mean the model has not served well thus far or with the available pool of developers to date. Having to pipe all the changes through one person limits scalability. Until recently the facilities didn't even exist for supporting the maximum scalability using that model (distributed branching), and even though they exist now few people are using them and they are not integrated into the central commit process. Even as things are now there is a disincentive to new developers. Some developers don't bother submitting patches because they feel it's too much work to get them accepted, and sometimes the patch doesn't get written at all because there is not enough certainty that it will be accepted. Before you suggest that this is speculative, I have one developer here who has made patches to fix Wine bugs experienced at home and not submitted them for that exact reason. You can try getting guidance on what is likely to be accepted, but again you run into a bandwidth problem with Alexandre - one person cannot effectively give guidance to everybody who needs it, and such guidance as he is able to give doesn't always help that much. The process requires that developers risk their work amounting to nothing because it won't be accepted. How many times have you seen people say that "Alexandre doesn't always know what he wants, but he knows what he doesn't want"?. That perception is partly due to the fact that it is impossible for one person to take the time to really understand what is wanted for every area of Wine that is being worked on at any one time (humans are linear, it limits them). I suspect the current model is either at or near its limits. It would certainly not cope with a significant number of commercial outfits putting in a serious level of contribution, nor does it encourage them to make the attempt. To scale better you would need to divide the project into different areas of responsibility and have multiple committers. You could have overall guidelines, but you'd need to be willing to trust the managers of each area to make final decisions in that area - even so far as to let them make mistakes and let them learn from those mistakes. Almost every subdirectory of "dlls" could in principle be a separate area of responsibility with a separate group of committers, although it might be more convenient to have more-or-less related subdirectories under the umbrella of a single group. Each group responsible for an area would need to be prepared to give advice to people working on some patch in that area that if followed would make it virtually certain that the patch would be accepted. A supporting facility you would probably need would likely include either separate mailing lists for each sub-project (things get lost in wine-devel *now*) with consolidated read-only lists for people who want a convenient way of watching all of the discussions or a shift to an NNTP heirarchy with mailing gateways. These structures are nothing new - most of the really big projects work this way - look at Gnome, KDE, and for the insane end of the scale, Debian. Even with the Linux kernel, which is the only project that I am aware of that is comparable in size and follows a similar model to Wine, there appears to me to be some greater division of responsibility. This is all relevant, of course, only *if* significant expansion of the pool of developers is a desirable goal.

Sept. 5, 2005

Re: Suggestions for improvement of the emulator

by Evil

Mike Hearn wrote: >On Mon, 05 Sep 2005 11:30:41 -0700, Hiji wrote: > > >>>Firstly, Wine is not an emulator, it it a binary loader and an >>>implementation of the Win32 API. >>> >>> >>Bingo. It irritates me when people call Wine an emulator. ALEX, did you >>know that Wine stands for "Wine Is Not an Emulator"?? >> >> > >It's playing with words. I happen to think it is an emulator and I usually >call it that ;) > >thanks -mike > > So a Chevy is a Ford emulator, because it can use the same gas, right? No, of course not. Now, if the gas had to be converted to a completely different substance before it could power the car, then it would probably be an emulator. WINE doesn't change the gas, it's just an engine add-on that just lets you burn unleaded or diesel. And so ends "Lousy Analogy Theater". We now return you to your normal program, already in progress. -J

Sept. 5, 2005

Re: [Now ns7] Dragon ns8 problem

by wino＠piments.com

On Mon, 05 Sep 2005 15:23:26 +0200, Jean Magnan de Bornier <jean(a)bornier.net> wrote: > As root, "ps ax | grep wine", and then looking at pid numbers, kill all > of > the /usr/bin/wine-preloader processes (there were four or five of them), > one after the other. Then as user, wineboot worked. Wonder if this is > usual? Yes I seem to remember having to kill off some wine-preloader processes after failures but not sure if it was in this same context. BTW try pgrep ;) > Never mind, now the issue is to have sound; the volume check does not complete as for now. Again I think this was covered in earlier posts but I seem to recall wine not being able to control the recording level. I set it to a suitable level before starting NS IIRC and it got through to the dictation training OK. Depending on your hardware and mixer software you should make sure you over-driving the sound by putting sliders at 100% and take care not to confuse mike input and the mike capture settings. 'mik' seems to be the ammount of the mike input that is fed back to the output mixer and is independant of the mike capture level. It is mike capture you need for NS. > Strangely, as I have the french version, the text I'm supposed to read for volume check is in english?? What's strange about that? Most software works that way ! I am still running wine-20050524 that I used with NS7, and that worked well. It may be useful to post the version you are using for the record . Glad to hear you're getting somewhere. 8)

Sept. 5, 2005

Re: kernel32: get ExitProcess to call NtTerminateProcess

by Ivan Leo Puoti

Eric Pouech wrote: > I don't see why you need to return something. If NtTerminateProcess() > fails, then just call exit(status). More importantls a function declared as void shoulnd't ever return anything, I'll send a new patch. Ivan.

Sept. 5, 2005

Re: kernel32: get ExitProcess to call NtTerminateProcess

by Eric Pouech

Ivan Leo Puoti a écrit : > As NtTerminateProcess alredy exists in ntdll, there's no reason to call > wineserver directly. > > Ivan. I don't see why you need to return something. If NtTerminateProcess() fails, then just call exit(status). A+ -- Eric Pouech

Sept. 5, 2005

Some troubles with InstallShield:solved

by Robbert Xerox

Hahaha, Wine is just great, patch that just came in : http://www.winehq.org/pipermail/wine-patches/2005-September/020456.html seems to fix the problem.... ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

Sept. 5, 2005

Re: Suggestions for improvement of the emulator

by Mike Hearn

On Mon, 05 Sep 2005 11:30:41 -0700, Hiji wrote: >> Firstly, Wine is not an emulator, it it a binary loader and an >> implementation of the Win32 API. > > Bingo. It irritates me when people call Wine an emulator. ALEX, did you > know that Wine stands for "Wine Is Not an Emulator"?? It's playing with words. I happen to think it is an emulator and I usually call it that ;) thanks -mike

Sept. 5, 2005

Some troubles with InstallShield

by Robbert Xerox

Using native comctl32 makes the installer proceed; is this also caused by theming patches that got in? See for example http://bugs.winehq.org/show_bug.cgi?id=3241 ___________________________________________________________ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com

Sept. 5, 2005

Re: Suggestions for improvement of the emulator

by Tim Schmidt

> What makes you say that? > What would need changing to efficiently accomodate more developpers? > > I'm asking because I don't see a problem with the current organisation > but I may be missing something. If there are issues it's best to get > them out in the open so we can work on fixing them. Perhaps he is refering to Alexandre... You know, like Linus, he doesn't scale. I don't see that as a problem for quite some time though. --tim

Sept. 5, 2005

Re: Suggestions for improvement of the emulator

by Hiji

> Firstly, Wine is not an emulator, it it a binary > loader and an > implementation of the Win32 API. Bingo. It irritates me when people call Wine an emulator. ALEX, did you know that Wine stands for "Wine Is Not an Emulator"?? Hiji __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

Sept. 5, 2005

Some troubles with InstallShield

by Vitaly Lipatov

Can anyone test PHP Expert Editor for install? It uses InstallShield and install loop at message "File access denied." http://www.ankord.com/download/phpxedit_33.zip -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

Sept. 5, 2005

Re: dinput force feedback header detection

by Daniel Remenak

The patch to fix that error is at http://www.winehq.org/pipermail/wine-patches/attachments/20050903/636b08f6/… The headers are correctly detected but the use of the constants was not protected. --Daniel Remenak On 9/5/05, Jesse Allen <the3dfxdude(a)gmail.com> wrote: > Hi I got this compile error from current cvs: > > make[2]: Entering directory `/home/jesse/.local/build/wine/dlls/dinput' > gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ > -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 > -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o > joystick_linuxinput.o joystick_linuxinput.c > joystick_linuxinput.c: In function `alloc_device': > joystick_linuxinput.c:305: error: `FF_STATUS_STOPPED' undeclared > (first use in this function) > joystick_linuxinput.c:305: error: (Each undeclared identifier is > reported only once > joystick_linuxinput.c:305: error: for each function it appears in.) > joystick_linuxinput.c: In function `joy_polldev': > joystick_linuxinput.c:726: error: `EV_FF_STATUS' undeclared (first use > in this function) > joystick_linuxinput.c: In function `JoystickAImpl_EnumEffects': > joystick_linuxinput.c:1182: warning: unused variable `dei' > joystick_linuxinput.c: In function `JoystickWImpl_EnumEffects': > joystick_linuxinput.c:1266: warning: unused variable `dei' > make[2]: *** [joystick_linuxinput.o] Error 1 > make[2]: Leaving directory `/home/jesse/.local/build/wine/dlls/dinput' > make[1]: *** [dinput] Error 2 > make[1]: Leaving directory `/home/jesse/.local/build/wine/dlls' > make: *** [dlls] Error 2 > > > Apparently the linux/input.h version 2.4.31 does not have support for > force feedback. I've installed headers for 2.6.12.5 and now have it > compiled. So something might need to be done to improve detection, > else others still running 2.4 will get this error. > > Jesse > > >

Sept. 5, 2005

dinput force feedback header detection

by Jesse Allen

Hi I got this compile error from current cvs: make[2]: Entering directory `/home/jesse/.local/build/wine/dlls/dinput' gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o joystick_linuxinput.o joystick_linuxinput.c joystick_linuxinput.c: In function `alloc_device': joystick_linuxinput.c:305: error: `FF_STATUS_STOPPED' undeclared (first use in this function) joystick_linuxinput.c:305: error: (Each undeclared identifier is reported only once joystick_linuxinput.c:305: error: for each function it appears in.) joystick_linuxinput.c: In function `joy_polldev': joystick_linuxinput.c:726: error: `EV_FF_STATUS' undeclared (first use in this function) joystick_linuxinput.c: In function `JoystickAImpl_EnumEffects': joystick_linuxinput.c:1182: warning: unused variable `dei' joystick_linuxinput.c: In function `JoystickWImpl_EnumEffects': joystick_linuxinput.c:1266: warning: unused variable `dei' make[2]: *** [joystick_linuxinput.o] Error 1 make[2]: Leaving directory `/home/jesse/.local/build/wine/dlls/dinput' make[1]: *** [dinput] Error 2 make[1]: Leaving directory `/home/jesse/.local/build/wine/dlls' make: *** [dlls] Error 2 Apparently the linux/input.h version 2.4.31 does not have support for force feedback. I've installed headers for 2.6.12.5 and now have it compiled. So something might need to be done to improve detection, else others still running 2.4 will get this error. Jesse

Sept. 5, 2005

Need ideas about ntoskrnl

by Vitaliy Margolen

We need ntoskrnl to run some subset of drivers on wine. Notably cd protection drivers. They are not a hardware drivers, but a means to access something that is not accessible from user space. So in a sense ntoskrnl is just a process to run those drivers in, and send/receive requests to/from those drivers. You need to keep in mind that this is a kernel level, so some things will not work, and some things have to work that normally do not in the user space. Also ntoskrnl for windows _is_ what wineserver for wine. User space programs talk to these drivers in the following way: 1. At the start up, driver creates symbolic link in "\DosDevices\something". 2. Program calls CreateFile("\\.\something",..) to get a handle to the device. 3. Uses ReadFile/WriteFile/DeviceIoControl on that handle. (For now we need only DeviceIoControl. Read/Write could be added later.) Here is a list of the most pressing problem and the way to solve them. Any ideas and comments will be greatly appreciated, Vitaliy. Problems: 1. Open handle to a device - NtCreateFile. 2. Call DeviceIoControl on a device. (This also includes (1) since we need to know that this is not a cdrom, vxd or something else.) 3. Resolve user space handle to the DEVICE_OBJECT. (Assuming that we don't call ntoskrnl through wineserver). Solutions for (1): 1.1. Use a hack to determine that passed name is a device name. (Device names don't have colon in them). 1.2. Check against all possible names other then device names. (A:..Z:, etc.) 1.3. Try it last if all else fails. (since name spaces don't intersect this should work.) 1.4. Use object manager to lookup the name to find out what is it. (Unless we open all handles using this method it will add one extra wineserver call.) Solutions for (2): ntdll->ntoskrnl 2.1. Use named pipe to communicate with ntoskrnl process. Pass commands over the pipe in internal format. 2.2. Use UNIX IPC to talk to ntoskrnl. (pipe, socket, etc.) ntdll->wineserver->ntoskrnl 2.3. Call wineserver which will call ntoskrnl using 2.1. or 2.2. 2.4. Call wineserver which will call ntoskrnl using proper IoXXX functions from ntoskrnl to create an IRP. ntoskrnl will process them and notify wineserver when call is complete. (This is the most complicated and closer represents what windows does. There are still a problem communicating to ntoskrnl. It is probably the way to go in the future. But that will require number of things implemented which are not trivial.) Solutions for (2): MSDN quote: "Note that handles are not used for accessing device objects or driver objects." 3.1. Use wineserver to resolve handle to some internal identifier and pass it to ntoskrnl. 3.2. Pass handle and calling process id (pid, global handle, etc.) to ntoskrnl. ntoskrnl will call wineserver to resolve handle to internal id. (This handle will have to be either cached, or it will have to be created for every call.) 3.3. (requires 2.3. or 2.4.) Wineserver will resolve handle and pass internal id to ntoskrnl. (Unless we want wineserver do much more than that.)

Sept. 5, 2005

Re: Need help debugging a memory corruption bug in shfldr_unixfs.c

by Duane Clark

Duane Clark wrote: > > As of the current CVS, the problem seems to have disappeared for me. It > is not clear to me what patch fixed it. > Oops, spoke too soon. Still there.

Sept. 5, 2005