January 2003 - Wine-Devel - list.winehq.org

Re: placeholder implementation of explorer.exe

by Sylvain Petreolle

I think that Dan has a shorter and better solution. After all its easier to fix the existing code and write a wrapper than coding a new program. --- Jürgen_Schmied <j.schmied(a)t-online.de> a écrit : > Hi! > > I attached a small explorer like programm onto > http://bugs.winehq.com/show_bug.cgi?id=1227 > maybe we could port it into c code and include it into wine. > It might be a good starting point to start a full featured explorer > like > programm. > (And it's a good test for built in shell32) > > juergen > > > > > I collected my notes about getting msvc4's setup running under Wine > at > > http://www.kegel.com/linux/winelog.html > > I now have wordpad reading .wri files properly under Wine > > (needed for the "STL" button). The next problem is that > > the setup program does > > ShellExecute(..., "explorer.exe", ".", ...) > > to pop up an explorer window. > > > > Well, wine has Winefile, but not explorer.exe. It looks > > like the path of least resistance is for me to write a trivial > > little explorer.exe that just cd's to argv[1] and fires > > up winefile (which always operates on the current directory). > > I've written it, and I expect when I add the needed > > registry entry, it'll make msvc4's setup's "explore this cd" button > > work fine. > > > > Anyone think that'd be a bad thing to put into the Wine tree? > > - Dan > > > > -- > > Dan Kegel > > http://www.kegel.com > > > http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 > > > > > > > > > -- > juergen.schmied(a)debitel.net > FAX über T-Online Fax&Fon: 01805 060 334 316 35 (12Cent/Min) > > > ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus, in "Matrix". ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Jan. 19, 2003

Re: placeholder implementation of explorer.exe

by j.schmied＠t-online.de

Hi! I attached a small explorer like programm onto http://bugs.winehq.com/show_bug.cgi?id=1227 maybe we could port it into c code and include it into wine. It might be a good starting point to start a full featured explorer like programm. (And it's a good test for built in shell32) juergen > I collected my notes about getting msvc4's setup running under Wine at > http://www.kegel.com/linux/winelog.html > I now have wordpad reading .wri files properly under Wine > (needed for the "STL" button). The next problem is that > the setup program does > ShellExecute(..., "explorer.exe", ".", ...) > to pop up an explorer window. > > Well, wine has Winefile, but not explorer.exe. It looks > like the path of least resistance is for me to write a trivial > little explorer.exe that just cd's to argv[1] and fires > up winefile (which always operates on the current directory). > I've written it, and I expect when I add the needed > registry entry, it'll make msvc4's setup's "explore this cd" button > work fine. > > Anyone think that'd be a bad thing to put into the Wine tree? > - Dan > > -- > Dan Kegel > http://www.kegel.com > http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 > > > -- juergen.schmied(a)debitel.net FAX über T-Online Fax&Fon: 01805 060 334 316 35 (12Cent/Min)

Jan. 19, 2003

Re: Wine kernel acceleration module?

by Dan Kegel

Mathew McBride wrote: > I've been able to lock the entire machine simply by running > a DirectX game under Wine on the back of faulty X drivers! I can't recall if that's happened to me, but I know I've had X lock up so badly I had to telnet in and kill it. X drivers run with root privs :-( > (would a kernel module allow debugging of such problems via Kernel debugging > features?) IMHO none of our graphics stuff should be moved to the kernel; I don't think any of it's in wineserver anyway, is it? Shades of NT4.0 :-) - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Jan. 19, 2003

Re: Wine kernel acceleration module?

by Dan Kegel

Shachar Shemesh wrote: > Francois Gouget wrote: > >> Anyway, when compared to the shared memory server it seems to me that >> the main advantage of a kernel module is stability. It is my >> understanding (correct me if I'm wrong) that with the shared memory >> approach, a buggy (or malicious) Wine/Winelib application could crash >> all other Wine/Winelib applications using that server (at least only one >> user would be affected). >> > Whereas with the kernel module, it could panic the entire machine. Yepee!! That's only possible if there's a bug in the kernel module, whereas with the shared memory approach, it's possible even if the wineserver code is flawless. You are arguing against putting any code in the kernel. That would put you in the Mach camp, I think :-) - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Jan. 19, 2003

Re: VirtualDub cannot find its codecs

by Duane Clark

Waldeck Schutzer wrote: > ... > > Index: wine/dlls/msvideo/msvideo_main.c > =================================================================== > RCS file: /home/wine/wine/dlls/msvideo/msvideo_main.c,v > retrieving revision 1.45 > diff -r1.45 msvideo_main.c Please supply as diff -u, or better, create a ~/.cvsrc file that contains: cvs -z 3 update -PAd diff -u

Jan. 19, 2003

Re: Wine kernel acceleration module?

by Mathew McBride

On Sunday 19 January 2003 20:26, Shachar Shemesh wrote: > Francois Gouget wrote: > >Anyway, when compared to the shared memory server it seems to me that > >the main advantage of a kernel module is stability. It is my > >understanding (correct me if I'm wrong) that with the shared memory > >approach, a buggy (or malicious) Wine/Winelib application could crash > >all other Wine/Winelib applications using that server (at least only one > >user would be affected). > > Whereas with the kernel module, it could panic the entire machine. Yepee!! Sure about that?. I've been able to lock the entire machine simply by running a DirectX game under Wine on the back of faulty X drivers! (would a kernel module allow debugging of such problems via Kernel debugging features?) > > Shachar -- Mathew McBride matt(a)mcbridematt.dhs.org http://mcbridematt.dhs.org Jabber: mcbridematt on the jabber.org server

Jan. 19, 2003

Re: Wine kernel acceleration module?

by Shachar Shemesh

Francois Gouget wrote: >So you're better of with the kernel module if the bug is in the >application, and you're better of with shm if the bug is in the server. >Then it's a matter of which one is more likely. > I'm not in front of the sources at the moment. How big is the wineserver at the moment? If it's rather big (and I rather suspect it is), then it seems obvious which one is more likely. The windows apps are released apps that were working on Windows NT. The wineserver, on the other hand, is a piece of Alpha software that has not seen too much pounding into. I think that a bug in the server is MUCH MUCH MUCH more likely to happen. I think the best approach is a hybrid one. We have a kernel module that does only the bare minimum required in the kernel. Everything else is done using user-mode processes. This has several important advantages: 1. Bugs are much less likely to happen in the kernel area - less chances of blowing the entire machine away. 2. It becomes much easier to port the kernel to other platforms. 3. You can still, basically, do everything you did with a full fledged kernel wineserver. 4. Rebooting wine does not require rebooting the kernel (machine), or even unloading and reloading the kernel module. It is even, theoretically, possible to run several wineservers this way, though I'm not sure enough of the fine details to say that for sure. Shachar

Jan. 19, 2003

Re: resend: small DOS vga improvement

by Jukka Heinonen

Christian Costa wrote: > Andreas Mohr wrote: > > So until there is further information about how to do it properly, > > I'll just remove the vga_refresh reset in the VGA_IsTimerRunning() case, > > and of course this makes Turbo Pascal 6 usable (although screen update is > > a bit slower than IDA, most likely due to using int 10h instead of video > > mem and also probing I/O port 0x3da). > > Sure it will help your app but others that need video sync will not work > properly. :-) > > In your case, VGA_Poll_Text is called periodicaly and should be running > at 33 fps. > Since 33 fps is just half the standard speed (70Hz), all should be fine. > But is VGA_Poll_Text running at 33 fps? > I suspect this function is too slow (maybe due to the console code). Well, after some trivial searching, I found out that VGA register 0x3da reports vertical retrace, horizontal retrace and some light pen stuff: 1xxx = Vertical retrace in progress if set x1xx = Light pen switched on xx1x = Light pen trigger set xxx1 = Either vertical or horizontal retrace in progress if set The original code emulated vertical retrace handling more or less correctly. The patch by Andreas Mohr on the other hand emulates horizontal retrace. Unfortunately, in both cases the other retrace is emulated incorrectly. And I have no idea what to do with light pen bits. So, Andreas, as you now know how to do it properly, can you prepare a patch that: - handles both vertical and horizontal retrace (and does something with light pen) - works even before any VGA mode has been initialized - includes the above documentation about 0x3da bits (so that the next person messing with 0x3da does have some starting point) - does not use inlines unless it really makes a difference (getting screen to update a few milliseconds faster is not worth making the patch longer) -- Jukka Heinonen <http://www.iki.fi/jhei/>

Jan. 19, 2003

Re: Wine kernel acceleration module?

by Francois Gouget

On Sun, 19 Jan 2003, Shachar Shemesh wrote: > Francois Gouget wrote: > > >Anyway, when compared to the shared memory server it seems to me that > >the main advantage of a kernel module is stability. It is my > >understanding (correct me if I'm wrong) that with the shared memory > >approach, a buggy (or malicious) Wine/Winelib application could crash > >all other Wine/Winelib applications using that server (at least only one > >user would be affected). > > > Whereas with the kernel module, it could panic the entire machine. Yepee!! But of course that's true only if the kernel module has a bug. With the shared memory server any Windows application can crash all the others (but not the machine). To sum up, here's a table of what crashes based on the source of the bug: | Current | Kernel | Shm ------------------+---------------+----------------+-------------------- Bug in the server | Wine | Machine | Wine ------------------+---------------+----------------+-------------------- Bug in a Windows | Process | Process | Wine application | | | So you're better of with the kernel module if the bug is in the application, and you're better of with shm if the bug is in the server. Then it's a matter of which one is more likely. It's also a good argument for having the option to keep using the current server so that you can make the trade-off between speed and stability yourself. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ RFC 2549: ftp://ftp.isi.edu/in-notes/rfc2549.txt IP over Avian Carriers with Quality of Service

Jan. 19, 2003

Re: Wine kernel acceleration module?

by Shachar Shemesh

Francois Gouget wrote: >Anyway, when compared to the shared memory server it seems to me that >the main advantage of a kernel module is stability. It is my >understanding (correct me if I'm wrong) that with the shared memory >approach, a buggy (or malicious) Wine/Winelib application could crash >all other Wine/Winelib applications using that server (at least only one >user would be affected). > Whereas with the kernel module, it could panic the entire machine. Yepee!! Shachar

Jan. 19, 2003