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

Re: resend: small DOS vga improvement

by Christian Costa

Andreas Mohr wrote: >Hi all, > >please disregard my previous patch. > >I discovered that > > case 0x3da: > /* > * Read from this register resets register 0x3c0 address flip-flop. > */ > vga_address_3c0 = TRUE; > /* since we don't (yet?) serve DOS VM requests while VGA_Poll is running, > we need to fake the occurrence of the vertical refresh */ > ret=vga_refresh?0x00:0x0b; /* toggle video RAM and lightpen and VGA >refresh bits ! */ > if (VGA_IsTimerRunning()) > vga_refresh=0; > else >#endif > /* Also fake the occurence of the vertical refresh when no graphic > mode has been set */ > vga_refresh=!vga_refresh; > break; > >is WRONG since VGA_IsTimerRunning() is always true: > Not exactly! It is false before an application sets a video mode. > >VGA_InstallTimer gets called in both VGA_DoSetMode() (graphics) and >VGA_SetAlphaMode() (text). >(doh !) >Talk about too many people having done too many changes in one and the same >code part :-)) > > > >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). Christian. > > >

Jan. 19, 2003

placeholder implementation of explorer.exe

by Dan Kegel

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

Jan. 19, 2003

Re: Wine kernel acceleration module?

by Dan Kegel

Gavriel State wrote: > Each approach has its own merits - you'll note in our paper that we also > posted sources and design documentation for KWine, an alternative > wineserver kernel module design that keeps Win32 HANDLE objects > in a Linux file system. Yeah, thanks for posting that. I didn't have a chance to read the code, but I hope to sometime. > With a kernel module approach, hosting multiple wineserver environments > becomes more difficult. Yes, but I think that's a red herring. We don't need multiple wineserver environments, really, except in the same way that we need multiple linux environments (e.g. with chroot jails). > A kernel module also brings with it a number of > packaging issues, and would require significant work to be moved to > non-Linux OSes. Very much so. > Lastly, the kernel module approach requires an all-at-once > rewrite of the wineserver interactions, whereas the ShmServer can be > implemented on a call-by-call basis. Is that really true? There might be some way of bringing in the kernel module incrementally. You'd know better than me, but still... > About the only thing a kernel module > would have over the ShmServer on the performance front would be the ability > to do PE relocation fixups at page-in time, like Windows does. The value > of that feature is limited, IMHO. A kernel module may also have some > benefits from the security perspective. I suspect the kernel module would be better protected from wild memory accesses by the user processes as well. > Regardless of which one is better, it would be nice to see more interest > in this topic from other developers. If anyone else is interested in > collaborating on the ShmServer or kernel module approaches, that would > be great. Indeed. Thanks for your great work! - 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 Francois Gouget

On Sat, 18 Jan 2003, Gavriel State wrote: [...] > A kernel module may also have some benefits from the security > perspective. I am not sure a kernel module would be inherently better from a security point of vue: after all, the same module would handle all the users on the system. So there would be more risk that a user gains access to data he should not have access to. On the other hand it may also make it possible to implement CreateProcessAsUser&co... not that they are used much though. 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). That seems like a significant drawback. In either case though, to me it seems the two biggest obstacles are maintenance and compatibility: * if either approach requires duplicating (too much of) the server code, then the big question is whether there will be enough people interested for that alternate implementation to be maintained. * there are still signifcant changes in the server code. In my understanding there are still a number of things that are currently managed on a per-process basis and that should be managed by the server instead. Being able to easily switch from one implementation to another seems important to me. But this kind of compatibility requires that they remain in sync... that sort of brings us back to maintenance. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ War doesn't determine who's right. War determines who's left.

Jan. 19, 2003

Re: Wine kernel acceleration module?

by Gavriel State

Dan Kegel wrote: > Brian Vincent (C) wrote: > >> This issue has been discussed several times. If you >> dig in the WWN archives you'll find mentions of it >> going back a few years. Much more interesting was >> this post: >> >> http://www.winehq.com/hypermail/wine-devel/2002/12/0550.html >> >> The approach is a shared memory wineserver. > > I beg to differ. IMHO the kernel module approach > is the best. The PEACE team, for instance, is > going this route in their implementation of win32 > on BSD. Each approach has its own merits - you'll note in our paper that we also posted sources and design documentation for KWine, an alternative wineserver kernel module design that keeps Win32 HANDLE objects in a Linux file system. We spent some time on that as well before working on the ShmServer approach. With a kernel module approach, hosting multiple wineserver environments becomes more difficult. A kernel module also brings with it a number of packaging issues, and would require significant work to be moved to non-Linux OSes. Lastly, the kernel module approach requires an all-at-once rewrite of the wineserver interactions, whereas the ShmServer can be implemented on a call-by-call basis. About the only thing a kernel module would have over the ShmServer on the performance front would be the ability to do PE relocation fixups at page-in time, like Windows does. The value of that feature is limited, IMHO. A kernel module may also have some benefits from the security perspective. Regardless of which one is better, it would be nice to see more interest in this topic from other developers. If anyone else is interested in collaborating on the ShmServer or kernel module approaches, that would be great. Take care, -Gav -- Gavriel State, CEO & CTO TransGaming Technologies Inc. gav(a)transgaming.com http://www.transgaming.com/ Let the games begin

Jan. 19, 2003

Re: multiline strings in .rc files (was: Implementation of "start.exe", take 3)

by Dan Kegel

davep wrote: >>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tools/rc_ >>490l.asp says that \ is a simple line-continuation character. Thus \ at >>the end of a line in the .rc file should not insert a newline >>in the resource, I think. And it looks like our resource compiler >>is violating this. > >>After squinting at our source, I came up with a one-line patch >>to fix our resource compiler (attached). >>If that looks good, I can do a patch that fixes up all our .rc files >>that expected backslash to behave in a nonstandard way. > > > Right. I can't find reference in the documentation on Borland's way of > handling this, and in any case BC5 is long obsolete. Patching Wine's > resource compiler to work the way Win32 developers would expect looks like > the Right Thing. OK. I improved my patch to handle L"strings", and made it eat whitespace at the beginning of continued lines (that's what msvc6's rc does). Also update wcmd's rc file to match; none of the others looked like they desperately needed changing. To see the effect, blow away all your .res files before rebuilding, else make might not know to run wrc again. Patch submitted to wine-patches (filename backslash-2.patch). - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Jan. 19, 2003

Re: Launch a unix process from wcmd?

by Greg Turner

On Saturday 18 January 2003 02:35 pm, Dan Kegel wrote: > Greg Turner wrote: > > I am trying write scripts to mangle the output of MIDL. After MIDL > > runs, I need to do a tiny amount of post-processing using UNIX apps > > (convert from CRLF, for starters). > I just tried making a .bat file containing > > @echo off > echo hi > echo there > > and running it from unix with > > wcmd /c foo.bat > log > > Sure enough, log contained just the two lines > hi > there > > So I think you can already do that which you requested. indeed, you are right. perhaps i only tried "wcmd -- -c". silly me. -- gmt "Everything that is really great and inspiring is created by the individual who can labor in freedom." --Albert Einstein

Jan. 18, 2003

Re: multiline strings in .rc files (was: Implementation of "start.exe", take 3)

by davep

On Saturday 18 Jan 2003 21:45, Dan Kegel wrote: > > Something's fishy here. Our .rc files should be > > usable in both environments without change. > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tools/rc_ >490l.asp says that \ is a simple line-continuation character. Thus \ at > the end of a line in the .rc file should not insert a newline > in the resource, I think. And it looks like our resource compiler > is violating this. {snip} > After squinting at our source, I came up with a one-line patch > to fix our resource compiler (attached). > If that looks good, I can do a patch that fixes up all our .rc files > that expected backslash to behave in a nonstandard way. Right. I can't find reference in the documentation on Borland's way of handling this, and in any case BC5 is long obsolete. Patching Wine's resource compiler to work the way Win32 developers would expect looks like the Right Thing. Dave

Jan. 18, 2003

Re: Launch a unix process from wcmd?

by whitnl73＠juno.com

On Sat, 18 Jan 2003, Greg Turner wrote: > Alternatively, if I could invoke my .bat file from the UNIX > command-line, this would be just as good... but so far, the only way I > have found is to run "wcmd" and type. Does wcmd have some equivalent > to bash's "-c" command-line argument? Surely real cmd.exe has some > such feature? > > Thanks, > wcmd /c batfile you may put it in a shell script, if you like. output is to stdout (no window is created). Lawson -- ---oops--- Linux giftie 2.4.13 #1 Tue Oct 30 22:04:20 EST 2001 i586 unknown ________________________________________________________________ Sign Up for Juno Platinum Internet Access Today Only $9.95 per month! Visit www.juno.com

Jan. 18, 2003

Re: multiline strings in .rc files (was: Implementation of "start.exe", take 3)

by Dan Kegel

Dan Kegel wrote: >>> * multiline strings from resource file are displayed with extra newline >>> between lines in wine, but not in windows. To reproduce, build >>> either as winelib app or build under MSVC6, then run in wine; >>> usage message comes out double-spaced. Help! >> > Unfortunately, if I do > STRING_FOO, "This is a two-line \ > string" > it looks good in Wine, but it's run together on one line in Windows. > Conversely, if I do > STRING_FOO, "This is a two-line \n \ > string" > it looks good in Windows, but it's double-spaced in Wine. > > Something's fishy here. Our .rc files should be > usable in both environments without change. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tools/rc_4… says that \ is a simple line-continuation character. Thus \ at the end of a line in the .rc file should not insert a newline in the resource, I think. And it looks like our resource compiler is violating this. Compiling the stringtable entry 1, "xx\ yy" yields different results with our compiler and the one in vc6: $ tools/wrc/wrc rsrc.rc -o x.res $ hexdump -C x.res 00000000 00 00 00 00 20 00 00 00 ff ff 00 00 ff ff 00 00 |.... ...........| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 2a 00 00 00 20 00 00 00 ff ff 06 00 ff ff 07 00 |*... ...........| 00000030 00 00 00 00 00 10 09 04 00 00 00 00 00 00 00 00 |................| 00000040 00 00 00 00 00 00 00 00 00 00 05 00 78 00 78 00 |............x.x.| 00000050 0a 00 79 00 79 00 00 00 00 00 00 00 00 00 00 00 |..y.y...........| 00000060 00 00 00 00 00 00 00 00 00 00 00 00 |............| 0000006c $ wine /dos/c/Program\ Files/Microsoft\ Visual\ Studio/Common/MSDev98/bin/rc.exe /r /fo y.res rsrc.rc $ hexdump -C y.res 00000000 00 00 00 00 20 00 00 00 ff ff 00 00 ff ff 00 00 |.... ...........| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 28 00 00 00 20 00 00 00 ff ff 06 00 ff ff 07 00 |(... ...........| 00000030 00 00 00 00 30 10 09 04 00 00 00 00 00 00 00 00 |....0...........| 00000040 00 00 00 00 00 00 00 00 00 00 04 00 78 00 78 00 |............x.x.| 00000050 79 00 79 00 00 00 00 00 00 00 00 00 00 00 00 00 |y.y.............| 00000060 00 00 00 00 00 00 00 00 |........| After squinting at our source, I came up with a one-line patch to fix our resource compiler (attached). If that looks good, I can do a patch that fixes up all our .rc files that expected backslash to behave in a nonstandard way. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 Index: tools/wrc/parser.l =================================================================== RCS file: /home/wine/wine/tools/wrc/parser.l,v retrieving revision 1.22 diff -d -u -r1.22 parser.l --- tools/wrc/parser.l 15 Aug 2002 21:57:36 -0000 1.22 +++ tools/wrc/parser.l 18 Jan 2003 21:20:42 -0000 @@ -499,7 +499,8 @@ } <yystr>\\x[0-9a-fA-F] { yyerror("Invalid hex escape sequence '%s'", yytext); } -<yystr>\\[0-9]+ yyerror("Bad escape secuence"); +<yystr>\\[0-9]+ yyerror("Bad escape sequence"); +<yystr>\\\n ; /* backslash at end of line just continues string on next line */ <yystr>\\a addcchar('\a'); <yystr>\\b addcchar('\b'); <yystr>\\f addcchar('\f');

Jan. 18, 2003