Re: Implementation of 'start', take 2
The /w is the easier to implement. But not /w. I'm not sure we really need all those other options. We really only need to offer the same options as Microsoft's start.exe does. They _are_ needed. Actually you cant take winefile, right click and execute a custom action like install a .inf / execute an autorun.inf. Sure, I'd like to add cygstart's extra options, but let's get a working start with the right license first. shouldn't winedefault.reg implement these, as we provide notepad ? Hey, good point. I'll see if I can include that in the next version of my patch. = Sylvain Petreolle [EMAIL PROTECTED] 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
Implementation of start.exe, take 3
Changes since take 2:
* internationalized
* can be built with MSVC6.0; resulting .exe works in both Windows and Wine
* winelib app now installed by wineinstall
* winedefault.reg now has entries needed to make 'start foo.txt' work
Remaining issue I could use help with:
* 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!
I suspect it's worth submitting to wine-patches until that
issue is resolved.
Again, to those who are confused why I didn't just use cygstart,
cygstart's license seems to be an issue, and cygstart doesn't
implement one of the four options in the real Windows start.exe,
so I plowed ahead with my own version. We can add options from
Cygstart later.
- Dan
--
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
Index: configure.ac
===
RCS file: /home/wine/wine/configure.ac,v
retrieving revision 1.122
diff -u -r1.122 configure.ac
--- configure.ac15 Jan 2003 00:50:48 - 1.122
+++ configure.ac18 Jan 2003 08:11:26 -
@@ -1519,6 +1519,7 @@
programs/regtest/Makefile
programs/rpcss/Makefile
programs/rundll32/Makefile
+programs/start/Makefile
programs/uninstaller/Makefile
programs/view/Makefile
programs/wcmd/Makefile
Index: winedefault.reg
===
RCS file: /home/wine/wine/winedefault.reg,v
retrieving revision 1.61
diff -u -r1.61 winedefault.reg
--- winedefault.reg 19 Dec 2002 21:16:56 - 1.61
+++ winedefault.reg 18 Jan 2003 08:11:26 -
@@ -2838,3 +2838,18 @@
LongDistanceRule= 8WFG
Name=Uzbekistan
SameAreaRule=G
+
+#
+# Entries to get ShellExecute to map .txt files to notepad
+#
+
+[HKEY_CLASSES_ROOT\.txt]
+@=txtfile
+Content Type=text/plain
+
+[HKEY_CLASSES_ROOT\txtfile\shell\open\command]
+@=C:\\WINDOWS\\NOTEPAD.EXE %1
+
+[HKEY_CLASSES_ROOT\txtfile\shell\print\command]
+@=C:\\WINDOWS\\NOTEPAD.EXE /p %1
+
Index: programs/Makefile.in
===
RCS file: /home/wine/wine/programs/Makefile.in,v
retrieving revision 1.33
diff -u -r1.33 Makefile.in
--- programs/Makefile.in4 Jan 2003 02:52:05 - 1.33
+++ programs/Makefile.in18 Jan 2003 08:11:26 -
@@ -19,6 +19,7 @@
regtest \
rpcss \
rundll32 \
+ start \
uninstaller \
view \
wcmd \
@@ -43,6 +44,7 @@
regsvr32 \
rpcss \
rundll32 \
+ start \
uninstaller \
wcmd \
wineboot \
@@ -73,6 +75,7 @@
# Symlinks to apps that we want to run from inside the source tree
SYMLINKS = \
+ start.exe \
rpcss.exe \
wcmd.exe \
wineconsole.exe \
@@ -136,6 +139,9 @@
winhelp.exe$(DLLEXT): winhelp/winhelp.exe$(DLLEXT)
$(RM) $@ $(LN_S) winhelp/winhelp.exe$(DLLEXT) $@
+
+start.exe$(DLLEXT): start/start.exe$(DLLEXT)
+ $(RM) $@ $(LN_S) start/start.exe$(DLLEXT) $@
wcmd/wcmd.exe$(DLLEXT): wcmd
wineconsole/wineconsole.exe$(DLLEXT): wineconsole
Index: tools/wineinstall
===
RCS file: /home/wine/wine/tools/wineinstall,v
retrieving revision 1.50
diff -u -r1.50 wineinstall
--- tools/wineinstall 5 Dec 2002 19:05:44 - 1.50
+++ tools/wineinstall 18 Jan 2003 08:11:26 -
@@ -101,6 +101,7 @@
function create_windows_directories {
for tdir in $CROOT/windows $CROOT/windows/system \
+ $CROOT/windows/command \
$CROOT/windows/Start Menu $CROOT/windows/Start Menu/Programs \
$CROOT/Program Files $CROOT/Program Files/Common Files \
$CROOT/windows/Profiles $CROOT/windows/Profiles/Administrator \
@@ -129,6 +130,7 @@
#puts windows applications replacements to windows directories,
#configures them
function configure_wine_applications {
+ link_app start$CROOT/windows/command/start.exe
link_app notepad $CROOT/windows/notepad.exe
link_app regedit $CROOT/windows/regedit.exe
link_app rundll32 $CROOT/windows/rundll32.exe
--- /dev/null 2002-08-30 16:31:37.0 -0700
+++ programs/start/Makefile.in 2003-01-17 23:25:49.0 -0800
@@ -0,0 +1,15 @@
+TOPSRCDIR = @top_srcdir@
+TOPOBJDIR = ../..
+SRCDIR= @srcdir@
+VPATH = @srcdir@
+MODULE= start.exe
+APPMODE = cui
+IMPORTS = shell32 user32
+
+C_SRCS = start.c
+
+RC_SRCS = rsrc.rc
+
+@MAKE_PROG_RULES@
+
+### Dependencies:
--- /dev/null 2002-08-30 16:31:37.0 -0700
+++ programs/start/start.c 2003-01-18 00:04:53.0 -0800
@@ -0,0 +1,190 @@
+/*
+ * Start a program using ShellExecuteEx, optionally wait for it to finish
+ * Compatible with Microsoft's c:\windows\command\start.exe
+ *
+ * Copyright 2003
Re: * Hack * for Wine-20030115 DOSFS_Hash on Solaris 8 x86
Hi ! On Fri, Jan 17, 2003 at 08:40:30PM -0500, John Wehle wrote: wine photoed reports it can't find GIFIMP32.FLT (and friends) which prevents images from being imported. The trace is: trace:dosfs:DOSFS_GetFullName LC:\\PROGRA~1\\COMMON~1\\MICROS~1\\GRPHFLT\\GIFIM P32.FLT (last=0) trace:dosfs:DOSFS_FindUnixName /dos,LPROGRA~1\\COMMON~1\\MICROS~1\\GRPHFLT\\GIF IMP32.FLT trace:dosfs:DOSFS_ToDosFCBFormat (LPROGRA~1\\COMMON~1\\MICROS~1\\GRPHFLT\\GIFIM P32.FLT, df621770) trace:dosfs:DOSFS_OpenDir /dos ... trace:dosfs:DOSFS_ReadDir Read: long_name: LProgram Files, short_name: (null) trace:dosfs:DOSFS_FindUnixName checking LPROGRA~1LPROG~FBU What happens is DOSFS_Hash hashes Program Files in an unexpected fashion which prevents DOSFS_FindUnixName from realizing it matches PROGRA~1 . The enclosed * hack * allows wine photoed to load images. It is * not * the correct answer. One possible approach is to modify DOSFS_OpenDir_Normal to generate proper short names after it has read all the directory entries. Hmm, somehow I don't think this is a proper solution. The reasoning being that you probably have a Windows partition in your Wine install with that ~1 path buried somewhere in the registry or so. And IMHO if the registry contains such a setting (*from installation only* - a program most likely wouldn't create a ~1 .3 shortcut pathname on its own !), then we are SOL and probably should keep it like that instead of adding hacks that probably don't improve the code a whole lot. Instead, people should install the program via Wine, thus gaining proper registry keys with proper 8.3 *Wine* hashing during the install via Wine ! We simply don't seem to have a way to have a *fixed* mapping of long filenames to the ~1 shortcuts used in Windows; that's why we need our hashing. (someone correct me if I'm wrong about this issue !) Or maybe I'm wrong and we should indeed try to cope even with such a pretty hopeless situation. Oh, and I just realized that maybe yet another patch from you might get rejected ;-\ (although I'm grateful for the discussion about that issue) Andreas Mohr P.S.: Please CC me on followup discussions - I'm not on wine-devel currently.
how to make a proper .diff
Hi, I have what may be a stupid question but im going to ask it :) If im working on lets say packaging.sgml and I finish one section and make a diff against cvs. Then should I refresh my packaging.sgml from cvs and start on section #2 ? This is what I have done... Because if I keep working on the same file the diff grows and I would send the same patch over and over.. So I am doing this the correct way ? Tom
Re: how to make a proper .diff
On Sat, 18 Jan 2003, Tom Wickline wrote: Hi, I have what may be a stupid question but im going to ask it :) If im working on lets say packaging.sgml and I finish one section and make a diff against cvs. Then should I refresh my packaging.sgml from cvs and start on section #2 ? This is what I have done... Because if I keep working on the same file the diff grows and I would send the same patch over and over.. So I am doing this the correct way ? What I usually do is that I edit the diff. If the sections you work on are disjoint, then that's easy, just submit the hunks (the @@ sections) that are relevant. Another option that I believe other people use is copy the file when they submit the first patch and then diff against that instead of cvs. So for instance: cp packaging.sgml packaging.sgml.20030119 # work on packaging.sgml diff -u packaging.sgml.20030119 packaging.sgml cvs.diff Of course, if Alexandre commits your patch to CVS, then you don't need to play these tricks. Just do a 'cvs update' to retrieve the latest version from CVS. Usually the merge will happen automatically since you will have exactly the same things as what's in CVS. If not you will have some manual merging to do, but that's not really hard. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ The nice thing about meditation is that it makes doing nothing quite respectable -- Paul Dean
Re: Implementation of start.exe, take 3
On Saturday 18 Jan 2003 08:44, Dan Kegel wrote: Remaining issue I could use help with: * 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! Use a backslash on the end of each line to escape the LF. Look at programs/wcmd/wcmdrc.rc for an example. Dave
Running Wine with a Windows install
I have hit a small road block in updating the Packagers Guide and i'm in need of a little help here :) Section 3.3 : http://www.winehq.com/Docs/wine-pkg/pkg-winpartition.shtml Talks about useing files from an installation of the actual Microsoft Windows operating system. And as I dont have Windows on this box and I only have Win2000 on my second HD at this time I am not sure if this section is out of date. And what the differances between 9x and NT, 2K, XP are. So if you have Windows on your box or if you run Wine with Windows can you send me the path to the .dat files .ini file and system dlls ? In the future is this going to be done for the user by a config script ? One more question while im at it :)) I sent a patch to wine-patches about 6 hours ago and its still not listed how long does this take ? are the patches moderated before being posted ? Tom
Fwd: patch for GetFileTitleW: illegal call to GetFileTitleA 3ed
Thanks to Alexandre Julliard. He pointed out to me the
right method, and I hope this patch is the correct
one.
ChangeLog:
-dlls/commdlg/filetitle.c
implemented GetFileTitleW
GetFileTitleA now is a call to GetFileTitleW
liuspider
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
Index: dlls/commdlg/filetitle.c
===
RCS file: /home/wine/wine/dlls/commdlg/filetitle.c,v
retrieving revision 1.12
diff -u -r1.12 filetitle.c
--- dlls/commdlg/filetitle.c31 May 2002 23:25:45 - 1.12
+++ dlls/commdlg/filetitle.c18 Jan 2003 14:13:02 -
@@ -3,6 +3,7 @@
*
* Copyright 1994 Martin Ayotte
* Copyright 1996 Albrecht Kleine
+ * Copyright 2003 liuspider
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
@@ -24,10 +25,10 @@
#include winbase.h
#include winnls.h
#include commdlg.h
+#include wine/unicode.h
+#include winternl.h
#include wine/debug.h
-#include heap.h /* Has to go */
-
WINE_DEFAULT_DEBUG_CHANNEL(commdlg);
#include cdlg.h
@@ -38,19 +39,41 @@
*/
short WINAPI GetFileTitleA(LPCSTR lpFile, LPSTR lpTitle, UINT cbBuf)
{
- int i, len;
+int ret,totalW;
+UNICODE_STRING strWFile;
+LPWSTR lpWTitle;
+totalW = cbBuf * sizeof(WCHAR);
+RtlCreateUnicodeStringFromAsciiz(strWFile, lpFile);
+lpWTitle = RtlAllocateHeap( GetProcessHeap(), 0, totalW);
+ret = GetFileTitleW(strWFile.Buffer, lpWTitle, totalW);
+if (!ret){
+WideCharToMultiByte( CP_ACP, 0, lpWTitle, -1, lpTitle, cbBuf, NULL, NULL );
+}
+RtlFreeUnicodeString( strWFile );
+RtlFreeHeap( GetProcessHeap(), 0, lpWTitle );
+return ret;
+}
+
+/***
+ * GetFileTitleW (COMDLG32.@)
+ *
+ */
+short WINAPI GetFileTitleW(LPCWSTR lpFile, LPWSTR lpTitle, UINT cbBuf)
+{
+ int i, len;
+WCHAR brkpoint[] = {'*','[',']'};
TRACE((%p %p %d); \n, lpFile, lpTitle, cbBuf);
if(lpFile == NULL || lpTitle == NULL)
return -1;
- len = strlen(lpFile);
+ len = strlenW(lpFile);
if (len == 0)
return -1;
- if(strpbrk(lpFile, *[]))
+ if(strpbrkW(lpFile, brkpoint))
return -1;
len--;
@@ -70,34 +93,14 @@
if(i == -1)
i++;
- TRACE(--- '%s' \n, lpFile[i]);
+ TRACE(--- '%s' \n, debugstr_w(lpFile[i]));
- len = strlen(lpFile+i)+1;
+ len = strlenW(lpFile+i)+1;
if(cbBuf len)
return len;
- strncpy(lpTitle, lpFile[i], len);
+ strncpyW(lpTitle, lpFile[i], len);
return 0;
-}
-
-
-/***
- * GetFileTitleW (COMDLG32.@)
- *
- */
-short WINAPI GetFileTitleW(LPCWSTR lpFile, LPWSTR lpTitle, UINT cbBuf)
-{
- LPSTR file = HEAP_strdupWtoA(GetProcessHeap(), 0, lpFile); /* Has to go */
- LPSTR title = HeapAlloc(GetProcessHeap(), 0, cbBuf);
- short ret;
-
- ret = GetFileTitleA(file, title, cbBuf);
-
-if (cbBuf 0 !MultiByteToWideChar( CP_ACP, 0, title, -1, lpTitle, cbBuf ))
-lpTitle[cbBuf-1] = 0;
- HeapFree(GetProcessHeap(), 0, file);
- HeapFree(GetProcessHeap(), 0, title);
- return ret;
}
Launch a unix process from wcmd?
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). So, I have batch file that I run under wine to invoke MIDL and get the output I want; My question is: is there some way I can invoke my unix shell script from my .bat file in wine under wcmd? If not, perhaps we should squeeze this functionality into Dan's start.exe implementation? How would you feel about this, Dan? 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, -- gmt Everything that is really great and inspiring is created by the individual who can labor in freedom. --Albert Einstein
Re: Launch a unix process from wcmd?
the real cmd.exe has, and supports many more options in win2k version. the builtins commands have been expanded, like the for. --- Greg Turner [EMAIL PROTECTED] a écrit : 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). So, I have batch file that I run under wine to invoke MIDL and get the output I want; My question is: is there some way I can invoke my unix shell script from my .bat file in wine under wcmd? If not, perhaps we should squeeze this functionality into Dan's start.exe implementation? How would you feel about this, Dan? 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, = Sylvain Petreolle [EMAIL PROTECTED] 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
Heap* in memory/heap.c
While checking why my new shiny man pages for HeapAlloc and friends didn't get generated, I found something weird. The functions HeapAlloc, HeapFree, (...) are redirected to ntdll equivalents RtlAllocateHeap, RtlFreeHeap, (...). There are more functions that are of return RtlXXX(args); type but are not forwarded in kernel32.spec. My questions: * Should the forwardings be added for the rest of functions ? * What about documenting them (and changing c2man.pl to support it) ? -- Michal Miroslaw
Check for block device in DRIVE_ReadSuperblock
I thought, that this may be useful to somebody ... If this patch
were here before it would save me a few hours searching why every
program hanged on commdlg open/save file dialogs ...
I'm sending it here because I'm not sure whether I should be more/less
paranoid and stat() the file before open() or not, or even if this
check really should go into this function.
Decide. ;)
Changelog: [MQ] Add check for block device in DRIVE_ReadSuperblock
Index: files/drive.c
===
RCS file: /home/wine/wine/files/drive.c,v
retrieving revision 1.83
diff -u -r1.83 drive.c
--- files/drive.c 13 Jan 2003 20:44:13 - 1.83
+++ files/drive.c 18 Jan 2003 02:05:38 -
@@ -623,20 +623,36 @@
int fd;
off_t offs;
int ret = 0;
+struct stat stat_buf;
if (memset(buff,0,DRIVE_SUPER)!=buff) return -1;
if ((fd=open(DOSDrives[drive].device,O_RDONLY)) == -1)
{
- struct stat st;
if (!DOSDrives[drive].device)
ERR(No device configured for drive %c: !\n, 'A'+drive);
else
ERR(Couldn't open device '%s' for drive %c: ! (%s)\n,
DOSDrives[drive].device, 'A'+drive,
-(stat(DOSDrives[drive].device, st)) ?
+(stat(DOSDrives[drive].device, stat_buf)) ?
not available or symlink not valid ? : no permission);
ERR(Can't read drive volume info ! Either pre-set it or make sure the device
to read it from is accessible !\n);
PROFILE_UsageWineIni();
return -1;
+}
+
+/* MQ: I guess, we don't have to merge this call with the one above - some weird
+user
+ may try to swap the file before stat() and open() while we're not watching
+;)
+ OTOH if we open FIFO we're stuck anyway, so FIXME */
+if (fstat(fd, stat_buf) 0) {/* shouldn't happen since we just opened that
+file */
+ ERR(fstat() failed for opened device '%s' (drive %c:) ! IT SHOULDN'T HAPPEN
+!!!\n,
+ DOSDrives[drive].device, 'A'+drive);
+ ret = -1;
+ goto the_end;
+}
+if (!S_ISBLK(stat_buf.st_mode)) {
+ ERR(Device '%s' (drive %c:) is not a block device - check your config\n,
+ DOSDrives[drive].device, 'A'+drive);
+ ret = -1;
+ goto the_end;
}
switch(DOSDrives[drive].type)
Wine kernel acceleration module?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I just installed Total Annililation the other day (without expansions), it ran quite fast even on the bigger maps (e.g Seven Islands) then installed the Core Contingency and Battle Tatics expansions, and it was as slow as a 486 (not implying that Wine processes everything at 66Mhz, but Total Annilihation is a game that likes chewing up memory). Most notably, the mouse is quite slow. If we implemented a kernel module (keep in mind, it would have to be enabled in the kernel and wine config file so it doesn't make wine directly attached to Linux, e.g so people can port it easier to other Unixes), would that help speed up some DirectX games? (as Linux display drivers don't implement DirectX functions). There are other ways, Bug 176 (http://bugs.winehq.com/show_bug.cgi?id=176) suggested implementing a SDL backend, which is not a bad idea, as SDL also has sound support and since it forwards to DirectX on Windows, gives us some idea on what functions we need to implement. Gavriel State of Transgaming developed a SDL driver (http://www.winehq.com/hypermail/wine-devel/2002/01/0519.html). (which also asks, has anyone successfully used a SDL game under Wine?). My system is a RH 7.3 with a lot of packages from the rawhide repository (namely glibc-2.3), XFree86 build from a recent (= 4 days) CVS, Wine built from a 2 week old CVS sources, Duron (Thunderbird-cored) 800Mhz@840Mhz. - -- Mathew McBride [EMAIL PROTECTED] http://mcbridematt.dhs.org Jabber: mcbridematt on the jabber.org server -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iQCVAwUBPikHI5nKHiPoVMMhAQJp9wQAuFTcgW9aHfe52L/OcXtbLQfs+icGfrjD k95CRxxf8u/RYGxDEM2FBoJpG9K/tXLz1LlGryGCqOndNPIxWcUzz76sTpwgv8OK PTJYzonhfHBGsCMJ2RhBniurrJuzTDYhRtYOgiroYHJBnOITxGbxNWbKTy4KKCaT IZ8ahWhMM9o= =7S1V -END PGP SIGNATURE-
Re: Packaging Update $3
Tom Wickline wrote: ... I sent a patch 9 hours ago and it still has not shown up so im re-sending the patch. Ahh, well. To prevent that, you need to subscribe the email address you are using to the wine-patches list, otherwise it waits for me to get around to moderating it. Since your previous email appears to have been sent at about midnight my time, there was a bit of a wait before I saw it ;) If you already are subscribed under a different email address, it is perfectly ok to subscribe another. Just go into your user preferences after completing the subscription process and turn On Disable mail delivery to prevent getting multiple copies of postings sent to you.
Re: Wine kernel acceleration module?
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. --- Brian Vincent Copper Mountain Telecom [EMAIL PROTECTED]
multiline strings in .rc files (was: Implementation of start.exe,take 3)
davep wrote: On Saturday 18 Jan 2003 08:44, Dan Kegel wrote: Remaining issue I could use help with: * 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! Use a backslash on the end of each line to escape the LF. Look at programs/wcmd/wcmdrc.rc for an example. I did. 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. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
Re: Wine kernel acceleration module?
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. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
Re: Launch a unix process from wcmd?
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). So, I have batch file that I run under wine to invoke MIDL and get the output I want; My question is: is there some way I can invoke my unix shell script from my .bat file in wine under wcmd? If not, perhaps we should squeeze this functionality into Dan's start.exe implementation? How would you feel about this, Dan? 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? 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. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
Re: multiline strings in .rc files (was: Implementation of start.exe, take 3)
On Saturday 18 Jan 2003 19:29, Dan Kegel wrote: davep wrote: On Saturday 18 Jan 2003 08:44, Dan Kegel wrote: Remaining issue I could use help with: * 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! Use a backslash on the end of each line to escape the LF. Look at programs/wcmd/wcmdrc.rc for an example. I did. 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. I suspect it's a resource compiler thing. The history predates the mailing-list archives at winehq and also my own mail archive so it must be before 1999, but IIRC at that time the only resource compiler to support multi-line text was Borland's. At the time I was tinkering with WineLib applications and also working on wcmd, so I suggested to the developer of Wine's resource compiler that he follow the Borland convention. It seems that MS compilers now accept a similar but incompatible syntax (how unusual) which is the cause of your confusion. Dave
Re: multiline strings in .rc files (was: Implementation of start.exe,take 3)
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_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. 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
00 00 00 00 20 00 00 00 ff ff 00 00 ff ff 00 00 | ...|
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
0020 2a 00 00 00 20 00 00 00 ff ff 06 00 ff ff 07 00 |*... ...|
0030 00 00 00 00 00 10 09 04 00 00 00 00 00 00 00 00 ||
0040 00 00 00 00 00 00 00 00 00 00 05 00 78 00 78 00 |x.x.|
0050 0a 00 79 00 79 00 00 00 00 00 00 00 00 00 00 00 |..y.y...|
0060 00 00 00 00 00 00 00 00 00 00 00 00 ||
006c
$ wine /dos/c/Program\ Files/Microsoft\ Visual\ Studio/Common/MSDev98/bin/rc.exe /r /fo y.res rsrc.rc
$ hexdump -C y.res
00 00 00 00 20 00 00 00 ff ff 00 00 ff ff 00 00 | ...|
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
0020 28 00 00 00 20 00 00 00 ff ff 06 00 ff ff 07 00 |(... ...|
0030 00 00 00 00 30 10 09 04 00 00 00 00 00 00 00 00 |0...|
0040 00 00 00 00 00 00 00 00 00 00 04 00 78 00 78 00 |x.x.|
0050 79 00 79 00 00 00 00 00 00 00 00 00 00 00 00 00 |y.y.|
0060 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 - 1.22
+++ tools/wrc/parser.l 18 Jan 2003 21:20:42 -
@@ -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');
Re: multiline strings in .rc files (was: Implementation of start.exe, take 3)
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
Re: Launch a unix process from wcmd?
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
Re: multiline strings in .rc files (was: Implementation of start.exe,take 3)
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 Lstrings, 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
Re: Wine kernel acceleration module?
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. [EMAIL PROTECTED] http://www.transgaming.com/ Let the games begin
Re: Wine kernel acceleration module?
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
Re: Wine kernel acceleration module?
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 CreateProcessAsUserco... 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 [EMAIL PROTECTED]http://fgouget.free.fr/ War doesn't determine who's right. War determines who's left.
placeholder implementation of explorer.exe
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
