Re: Windows Debugging Tools under Wine: Could not inject logging thread into process
Dan Kegel [EMAIL PROTECTED] wrote: Ah, but there I hit a roadblock; it gives the error Could not inject logging thread into process. Very likely that's due a stubbed CreateRemoteThread. Shucks, shouldn't wine support advanced windows debugging techniques? :-) Sure, when somebody implements all the missing functionality in Wine :-) P.S. Have you managed to run logger and logviewer under Windows? -- Dmitry.
Some ddraw / GDI palette problem
Hi all, In 'old' D3D games, a lot of textures are created paletted... And each of these texture has its own DDraw palette object. And thus each has some GDI memory allocated. This means that after some time, we run out of GDI Heap space due to all these palettes created there : trace:ddraw:Main_DirectDraw_CreatePalette (0x4038ff48)-(0044,0x406b1340,0x406b1978,(nil)) trace:palette:CreatePalette entries=256 err:local:LOCAL_GetBlock not enough space in GDI heap 01b7 for 1052 bytes Now that problem is fixed in one game (it was due to some bad reference counting is some D3D code fixed in patch 79), but if ever it happens in yet another game, is it possible to increase this space ? Lionel -- Lionel Ulmer - http://www.bbrox.org/
Mac OS X/Darwin port of Wine
Hi Gang. A few weeks ago when I thought how cool it would be to marry Wine and Bochs to run Windows progams on Mac OS X Darwin, I checked around, including this list, and didn't find any activity. So I opened a SourceForge project to focus on just that goal: http://darwine.sf.net After I uploaded the home page tonight, I checked here again and found this topic had just come up last week! I don't know yet whether it makes sense to maintain a separate discussion and/or repository for this purpose. Seems like it would at least be useful during active initial work and then perhaps phase out. In any case, the resource is ready-to-use and I'ld like to hear from others interested in this port. Jim
Re: argv[0] needs to be an absolute path
Dan == Dan Kegel [EMAIL PROTECTED] writes:
Dan Uwe Bonnes wrote:
Dan == Dan Kegel [EMAIL PROTECTED] writes:
Dan The C program main(int argc, char **argv) { puts(argv[0]); }
Dan outputs an absolute path on Windows, but sometimes outputs a
Dan relative path on Wine. This causes the commandline $ wine d:setup
Dan to fail to find its files properly if it uses the basename of
Dan argv[0]. One example of this is msvc4.0 (although it only tries
Dan this if an earlier method fails, so there's another bug
Dan lurking). ..
Dan The same problem exists for programs launched from other wine
Dan programs, e.g. from inside wcmd. That's another code path, and I
Dan couldn't find a one-line fix for that one. - Dan
Did you check that it is CreateProcess that adds the absolute path?
I would guess the MS C Library will do it.
Dan Not quite sure how to check. Can you suggest a way?
Run with relay and snoop on builtin and native msvcrt. Eventually instrument
the builtin msvcrt with more debugging output.
Fiddling with CreateProcess needs good throught.
Dan I have not as yet fiddled with CreateProcess, only with the code
Dan that starts off the initial process when you run Wine, I think.
There has been discussion on that subject before. Did you check that your
problems is unrelated?
But don't take my arguments to serious;-)
Bye
--
Uwe Bonnes[EMAIL PROTECTED]
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
- Tel. 06151 162516 Fax. 06151 164321 --
Re: Mac OS X/Darwin port of Wine
Jim White wrote: A few weeks ago when I thought how cool it would be to marry Wine and Bochs to run Windows progams on Mac OS X Darwin, I checked around, including this list, and didn't find any activity. So I opened a SourceForge project to focus on just that goal: http://darwine.sf.net After I uploaded the home page tonight, I checked here again and found this topic had just come up last week! I don't know yet whether it makes sense to maintain a separate discussion and/or repository for this purpose. Seems like it would at least be useful during active initial work and then perhaps phase out. Sounds like a plan to me. Hopefully your Wine tree won't drift out of sync with the main one like so many Linux kernel port trees do. Maybe you could use the overlay system, where the only files in the alternate tree are those that don't exist in the main tree... Have fun! - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com
Re: Update: Wine Mozilla
Steven Edwards wrote: I will be lending those guys a hand with the port. Mostly the work seems to be done, they just need a gentle nudge to get it in the tree (I hope :)). As always, your comments and suggestions are highly appreciated. when/if I ever get more time I will try to help. I just got married so my time to work on wine/reactos/mingw has gone to /dev/null for about another month. btw: nice work on visual-mingw. Thanks Steven __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com Congratulations! Definitely worth the break...
Re: NT4 SP 6a entries
Ok, if you want to try it its there : http://msdn.microsoft.com/downloads/default.asp?url=/downloads/sample.asp?url=/msdn-files/027/001/829/msdncompositedoc.xml I don't know... of course, ultimately, the answer will always be: yes there is another way to find out if it's SP6a :( Anyone able to check my work, however, by comparing against their SP6a box? It's an interesting result. If .net framework is a free download (that doesn't require me to sacrifice my first born to Steve Balmer), then I'll check it out... -- gmt It does not take a majority to prevail ... but rather an irate, tireless minority, keen on setting brushfires of freedom in the minds of men. --Samuel Adams, Patriot = 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, chapter 15. ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
Re: Windows Debugging Tools under Wine: Could not inject loggingthread into process
Dmitry Timoshkov wrote: Have you managed to run logger and logviewer under Windows? Yes! They work fine on WinXP. (The docs imply they'll run on win9x as well, but the installer begs to differ.) And it's an eye-opener. It's really cool to see the log of what apps are doing under real windows. I now see I have to revise my argv[0] must be absolute patch again, for instance. Off to try building the wine tests with msvc4.0 under wine... I need to verify my hunch that the regression test I just added will fail under windows xp. - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com
Re: sharpdevelop and .NET
--- tom potts [EMAIL PROTECTED] a écrit : Sylvain I cant get on the list from home but I tried copying mscoree.dll and sharpdevelop got as far as asking for some registry settings to be set!! lol :) that was an evidence ! otherwise microsoft wouldn't give a 20 Mb file to download. I tried installing the redistributable but I need IE5.01 or higher and the M$ download fails under wine! I beleive I have a CD install at work so I'll try that on monday and then try installing .Net again. shouldnt fail... check the wine-users archive. many work has been done to make this possible. if this really fails, make a bygreport on wine-users and set these entries. this will an ie6 installed. [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer] Build=62800 Version=6.0.2800.1106 W2kVersion=6.0.2800.1106 IntegratedBrowser=dword:0001 MkEnabled=Yes All I want is a good IDE for .NET/Mono on Linux and then I can help to get Mono up and running Tom understood ;) does mono already run .NET ? = 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, chapter 15. ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
problem using msvcmaker to build conformance test suite project file
http://www.winehq.com/Docs/wine-devel/testing-windows.shtml says: Run msvcmaker to generate Visual C++ project files for the tests. ... $ ./tools/winapi/msvcmaker --no-wine I did that in my cvs wine directory, and all I got was .: searching for /\.spec$/ .: searching for /^Makefile.in$/ internal: options.pm: member W0B5 does not exists Um, did I do something wrong? Or is there a bug in msvcmaker? I'm on Red Hat 8.0, btw. - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com
Re: Windows Debugging Tools under Wine: Could not inject logging thread into process
do you mean you manage to install the MSI service ? 2. to fix the can't execute msiexec.exe error, copy /dos/c/windows/system/msi* ~/c/windows/system = 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, chapter 15. ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
RE: IE browsing local files
Mike Hearn wrote: Also, a bit OT this one, but I've been told that the MS EULA in Office XP forbids running it on anything other than Windows. Is this true, and if so, is it legal for them to say this? Microsoft was convicted a monopoly. AFAIK, according to the Sherman Act, Microsoft is not allowed to restrict their products to another of which they detain a monopoly. Thus they cannot restrict Office XP to Windows. Luís Marques
Re: argv[0] needs to be an absolute path
Uwe Bonnes wrote: Did you check that it is CreateProcess that adds the absolute path? I would guess the MS C Library will do it. Dan Not quite sure how to check. Can you suggest a way? Run with relay and snoop on builtin and native msvcrt. Eventually instrument the builtin msvcrt with more debugging output. (I assume by eventually you mean possibly, given that your native tongue is german...) Fiddling with CreateProcess needs good throught. Dan I have not as yet fiddled with CreateProcess, only with the code Dan that starts off the initial process when you run Wine, I think. There has been discussion on that subject before. Did you check that your problems is unrelated? Can't find it in the archive. Can you send me the URL? But don't take my arguments to serious;-) I'm more worried about the fact that I haven't run the regression tests on native Windows -- my first run of microsoft's api logger under winxp suggests that argv[0] isn't always an absolute path there! (Yeah, that's easy to check without fancy tools, but I ran the fancy tools to watch ShellExecuteA, and happened to notice it.) Also, I should probably run them with native msvcrt under wine as you suggest. I guess I should vow never to post a patch until I have a conformance test to check it, and have run all conformance tests under both Wine and at least one version of Windows (maybe both win9x and winxp to be safe). - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com
Re: sharpdevelop and .NET
Hi, Sharpdevelop won't run on wine for a long time (perhaps even never). It is a 100% .NET app. The app will run on mono, a free .NET implementation, when they are done with Windows.Forms. Windows.Forms will be implemented using WineLib. When it fully functions Sharpdevelop will natively run on Linux (or any other OS supported by mono and WineLib). I wouldn't run MS .NET framework on Wine. Really look at www.go-mono.net for the mono project. Use Eclipse or some other tool as the IDE. Good Luck, Roderick Colenbrander On Saturday 04 January 2003 19:00, Sylvain Petreolle wrote: --- tom potts [EMAIL PROTECTED] a écrit : Sylvain I cant get on the list from home but I tried copying mscoree.dll and sharpdevelop got as far as asking for some registry settings to be set!! lol :) that was an evidence ! otherwise microsoft wouldn't give a 20 Mb file to download. I tried installing the redistributable but I need IE5.01 or higher and the M$ download fails under wine! I beleive I have a CD install at work so I'll try that on monday and then try installing .Net again. shouldnt fail... check the wine-users archive. many work has been done to make this possible. if this really fails, make a bygreport on wine-users and set these entries. this will an ie6 installed. [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer] Build=62800 Version=6.0.2800.1106 W2kVersion=6.0.2800.1106 IntegratedBrowser=dword:0001 MkEnabled=Yes All I want is a good IDE for .NET/Mono on Linux and then I can help to get Mono up and running Tom understood ;) does mono already run .NET ? = 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, chapter 15. ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
Re: Windows Debugging Tools under Wine: Could not inject loggingthread into process
Sylvain Petreolle wrote: do you mean you manage to install the MSI service ? 2. to fix the can't execute msiexec.exe error, copy /dos/c/windows/system/msi* ~/c/windows/system I dunno. All I know is that copying all the msi* files from my real windows/system directory to my fake windows/system directory (and also copying cabinet.dll and using it) made the installer work under cvs wine. So I guess yes. Is that unusual? - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com
RE: problem using msvcmaker to build conformance test suite project file
http://www.winehq.com/Docs/wine-devel/testing-windows.shtml says: Run msvcmaker to generate Visual C++ project files for the tests. ... $ ./tools/winapi/msvcmaker --no-wine I did that in my cvs wine directory, and all I got was .: searching for /\.spec$/ .: searching for /^Makefile.in$/ internal: options.pm: member W0B5 does not exists Um, did I do something wrong? Or is there a bug in msvcmaker? There is nothing wrong with msvcmaker on my computer. The error above is very strange, nothing reasonable in the script that I think of can have caused it. I'm on Red Hat 8.0, btw. It can be some sort of name collision when the Perl modules are imported. My guess is that one (or more) of the imported modules happens to depend on a module named options which causes a name collision.
[D3D 78] Small patch to get Tomb Raider 3 to work
Do you know if tomb raider needs absolutely OpenGL to work ? Mine fails because NVidia driver makes bad access to the memory :/ = 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, chapter 15. ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
Re: Mac OS X/Darwin port of Wine
A few weeks ago when I thought how cool it would be to marry Wine and Bochs to run Windows progams on Mac OS X Darwin, I checked around, including this list, and didn't find any activity. This issue comes up a few times a year (isn't it in a FAQ somewhere?) Anyway, take a look at these threads: http://kt.zork.net/wine/wn20020830_133.html#3 http://bugs.winehq.com/show_bug.cgi?id=44 http://www.winehq.com/hypermail/wine-devel/2000/11/0004.html http://www.winehq.com/hypermail/wine-devel/2000/11/0077.html The fact that you're using Bochs does make it unique, but you may still glean some useful info from those links. -brian vincent
Re: [D3D 78] Small patch to get Tomb Raider 3 to work
On Sat, Jan 04, 2003 at 07:28:26PM +0100, Sylvain Petreolle wrote: Do you know if tomb raider needs absolutely OpenGL to work ? Mine fails because NVidia driver makes bad access to the memory :/ No idea if Tomb Raider 3 still has a software rasterizer or not. I will try on my box at home when I come back and will tell you if it works here with my NVIDIA drivers :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Mac OS X/Darwin port of Wine
This issue comes up a few times a year (isn't it in a FAQ somewhere?) Anyway, take a look at these threads: Yeah, this is one of the most persistant 'Wine dream' around :-) I had once a long discussion with a fellow hacker on this subject (going into the likes of using Valgrind's virtualization engine to output non-X86 code to do dynamic translation and so on). We agreed that before starting with Wine, one could start with running, for example, Linux/x86 binaries on Linux/PPC. That would already validate the fact that you can draw the line at one point and from there run such an heterogenous environment. It's a very nice subject... A pitty it has such a low importance (seeing how X86 dominates the desktop market). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: problem using msvcmaker to build conformance test suite projectfile
Patrik Stridvall wrote: http://www.winehq.com/Docs/wine-devel/testing-windows.shtml says: Run msvcmaker to generate Visual C++ project files for the tests. ... $ ./tools/winapi/msvcmaker --no-wine I did that in my cvs wine directory, and all I got was .: searching for /\.spec$/ .: searching for /^Makefile.in$/ internal: options.pm: member W0B5 does not exists Aha. Caught by internationalization. The workaround is LANG=C export LANG ./tools/winapi/msvcmaker --no-wine I guess the FAQ needs updating... or the tool needs fixing... I suspect the easiest fix would be to wrap msvcmaker with LANG=C export LANG BTW, this is only one of many things that breaks when non-C locales are used. Others I know of: * 'man' when displayed in xterm or konsole (see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=75089 where Red Hat says they will not support xterm, and also https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=75642) * all text processing utils are 10x or more slower (makes it hard to grep through large log files) * sort gives nonintuitive results (not a bug, just very suprising) - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com
Re: Mac OS X/Darwin port of Wine
Lionel Ulmer wrote: I had once a long discussion with a fellow hacker on this subject (going into the likes of using Valgrind's virtualization engine to output non-X86 code to do dynamic translation and so on). We agreed that before starting with Wine, one could start with running, for example, Linux/x86 binaries on Linux/PPC. That would already validate the fact that you can draw the line at one point and from there run such an heterogenous environment. Hey, that's a good idea. Then you could install and run x86 linux packages, if you were really lucky. Might be useful for running proprietary packages where they don't bother to rebuild for linux/ppc. - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com
enhancement request - can msvcmaker generate a Makefile?
Hi, I only have msvc4.0. It can't load the output of msvcmaker. I suppose I should buy current msvc, or modify msvcmaker myself to output a makefile instead of a project file. That's an idea... has anyone tried building the conformance tests with cl (i.e. microsoft's compiler's commandline interface)? - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com
Re: Windows Debugging Tools under Wine: Could not inject logging thread into process
of course not. but im trying to install .NET framework and its asking for msi update, that fail, even with these files installed. I dunno. All I know is that copying all the msi* files from my real windows/system directory to my fake windows/system directory (and also copying cabinet.dll and using it) made the installer work under cvs wine. So I guess yes. Is that unusual ? = 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, chapter 15. ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
wxWindows: it's now official (almost)
Hi folks, Last night I had nothing better to do than to cleanup my wxWindows patch. The entire thing is less than 500 lines! This says quite a few things about the maturity of our headers. The changes to the build system are just a few lines changed in src/makeg95.env. In fact, most of those are just documentation changes, and convenience things. *All* interesting changes are just: CC=winegcc CXX=winegcc -xc++ WINDRES=wrc Needless to say, I am so happy! : Below I've included a diffstat of the patch (to give you an idea how few things I had to change), and the patch itself (first to show how trivial the changes are, and second in the hope that my experience doing this port can be of some use to someone else). The exact same patch (with the only difference being that it has only 2 lines of context for the unified diff, to conform to the wxWindows patch guidelines) will be submitted for inclusion in the official wxWindows tree in the next 10 minutes. But I figured you guys should be the first to know, so here it is! :) Enjoy! diffstat wine.diff include/wx/filefn.h |2 +- include/wx/longlong.h|1 + include/wx/msw/gccpriv.h |4 ++-- include/wx/msw/setup0.h |2 +- include/wx/platform.h|2 +- include/wx/sckaddr.h |2 +- src/common/datetime.cpp |2 +- src/common/dynarray.cpp |1 + src/common/encconv.cpp |1 + src/common/filefn.cpp|2 +- src/common/list.cpp |1 + src/common/mimecmn.cpp |6 +++--- src/common/sckaddr.cpp |4 ++-- src/common/sckipc.cpp|2 +- src/common/string.cpp|1 + src/common/wxchar.cpp|2 +- src/jpeg/jmorecfg.h |3 +++ src/makeg95.env | 24 +--- src/msw/app.cpp |2 +- src/msw/dialup.cpp |1 + src/msw/fontenum.cpp |2 +- src/msw/gsocket.c|4 ++-- src/msw/ole/automtn.cpp |1 + src/png/pngconf.h|8 ++-- 24 files changed, 56 insertions(+), 24 deletions(-) Index: include/wx/filefn.h === RCS file: /pack/cvsroots/wxwindows/wxWindows/include/wx/filefn.h,v retrieving revision 1.63 diff -u -r1.63 filefn.h --- include/wx/filefn.h 2002/12/07 15:41:11 1.63 +++ include/wx/filefn.h 2003/01/04 19:32:59 @@ -75,7 +75,7 @@ // Microsoft compiler loves underscores, feed them to it #if defined( __VISUALC__ ) \ -|| ( defined(__MINGW32__) wxCHECK_W32API_VERSION( 0, 5 ) ) \ +|| ( defined(__MINGW32__) !defined(__WINE__) wxCHECK_W32API_VERSION( 0, 5 ) +) \ || ( defined(__MWERKS__) defined(__WXMSW__) ) // functions #define wxClose _close Index: include/wx/longlong.h === RCS file: /pack/cvsroots/wxwindows/wxWindows/include/wx/longlong.h,v retrieving revision 1.44 diff -u -r1.44 longlong.h --- include/wx/longlong.h 2002/12/04 13:58:18 1.44 +++ include/wx/longlong.h 2003/01/04 19:33:00 @@ -63,6 +63,7 @@ #define wxLongLongFmtSpec _T(I64) #elif (defined(SIZEOF_LONG_LONG) SIZEOF_LONG_LONG = 8) || \ defined(__MINGW32__) || \ +defined(__GNUC__) || \ defined(__CYGWIN__) || \ defined(__WXMICROWIN__) || \ (defined(__DJGPP__) __DJGPP__ = 2) Index: include/wx/platform.h === RCS file: /pack/cvsroots/wxwindows/wxWindows/include/wx/platform.h,v retrieving revision 1.9 diff -u -r1.9 platform.h --- include/wx/platform.h 2002/12/07 12:36:03 1.9 +++ include/wx/platform.h 2003/01/04 19:33:00 @@ -137,7 +137,7 @@ #define __HPUX__ #endif /* HP-UX */ -#if defined(__CYGWIN__) +#if defined(__CYGWIN__) || defined(__WINE__) #if !defined(wxSIZE_T_IS_UINT) #define wxSIZE_T_IS_UINT #endif Index: include/wx/sckaddr.h === RCS file: /pack/cvsroots/wxwindows/wxWindows/include/wx/sckaddr.h,v retrieving revision 1.16 diff -u -r1.16 sckaddr.h --- include/wx/sckaddr.h2002/08/31 11:29:11 1.16 +++ include/wx/sckaddr.h2003/01/04 19:33:01 @@ -101,7 +101,7 @@ }; #endif -#if defined(__UNIX__) (!defined(__WXMAC__) || defined(__DARWIN__)) +#if defined(__UNIX__) !defined(__WINE__) (!defined(__WXMAC__) || +defined(__DARWIN__)) #include sys/socket.h #ifndef __VMS__ # include sys/un.h Index: include/wx/msw/gccpriv.h === RCS file: /pack/cvsroots/wxwindows/wxWindows/include/wx/msw/gccpriv.h,v retrieving revision 1.7 diff -u -r1.7 gccpriv.h --- include/wx/msw/gccpriv.h2002/12/29 19:37:08 1.7 +++ include/wx/msw/gccpriv.h2003/01/04 19:33:02 @@ -3,7 +3,7 @@ #ifndef _WX_MSW_GCCPRIV_H_ #define _WX_MSW_GCCPRIV_H_ -#if defined( __MINGW32__ ) !defined( HAVE_W32API_H ) +#if defined( __MINGW32__ ) !defined(__WINE__)
interesting crash in msvc6.0 setup
Since msvcmaker doesn't support msvc4.0, I'm trying to install msvc6.0 under wine. (Yeah, I know, I should run it under windows, but I'm stubborn.) Interestingly, the setup program puts itself in the background. This means you have to be careful to check with ps that you don't have old wines laying around from the last run, and when logging, you have to make sure all wine processes have exited, else your log file isn't complete yet. Unfortunately, setup fails fairly early. When emulating win9x, it fails before presenting a dialog box -- with a page fault reading from a file handle returned from CreateFile. It looks like it's doing an assembly string search on the Windows file structure pointed to by the handle! I wonder why. Maybe it was an easy way to prevent people from running under Wine :-) We may have to hack wine to make handles be valid pointers; I wonder what magic bytes setup is looking for there. When emulating winnt or winxp, it gets a bit further, but dies with a null pointer access. Oddly enough, adding --debugmsg +relay lets it proceed. It insists on installing Microsoft VM for Java, then tries to reboot. Restarting wine d:setup (this time without --debugmsg) continues properly for a while, but eventually crashes. Whenever it crashes in winnt/xp, it leaves one or more windowless wcmd's running the following script: :Repeat del E:\vs60wiz.exe if exist E:\vs60wiz.exe goto Repeat del C:\WINDOWS\DEL4056.BAT in a loop, chewing up huge amounts of CPU time. -- Dan Kegel Linux User #78045 http://www.kegel.com
CorelDraw 4 almost working
Dear friends, I managed to run CorelDraw4 at home. Without any Windows already installed from which to borrow DLL's. Just what I've got from MS website. OK, I have a valid CorelDraw4 license and I want to use it. CorelDraw crash when I want to click on menus. Specifically it crash when it encounter to access OLEGETCLIPBOARD from ole2.dll and/or DLLGETCLASSOBJECT This are wine_stubs. Is someone kind enough to implement them just as little stubs, just to not have CorelDraw crashed? This functions need aditional functionality to be implemented or these are standalone? I dont' have programming expertise, but I promise to be a good betatester. kind regards, -- Claudiu Costin, [EMAIL PROTECTED] Linux-KDE Romania http://www.ro.kde.org
Menu problems
Guys, All wxWindows examples exhibit a strange menu problem: upon startup, the main window has no menu, even if it should have. However, upon resize, the menu appears. Is this a known bug? -- Dimi.
WIP RPC test code (RFC): rpc_K01-pre2.diff
OK, this is my a preliminary cut at what an RPC test might look like. It also fixes a couple of wine bugs/missing functionalities that I noticed along the way. Several problems with this patch exist, all of them somewhat trivial. I'll divide these into categories for your amusement: PROBLEMS I HOPE TO SOLVE BEFORE SUBMITTING THIS PATCH o Failure in the child process doesn't cause failure of the test (is there someone else who has this solved for their test whose code I can borrow?) o rpcss.exe.so runs from the INSTALLED wine, not from the build tree!! This is totally unacceptable, but I'm not sure what would be a wise way to solve the problem. I need to change the way rpcss gets invoked by rpcrt4.dll. The best I can think of so far, would be to provide some global override (via a function call, I guess) for where rpcss.exe.so should be found, and then use this feature to ensure that during testing, rpcss.exe.so is invoked from the build tree instead of from the PATH environment variable. Any thoughts on this? o Doesn't actually do much real testing yet (this is just because I haven't finished the code yet, no problem here at all, really). PROBLEMS THAT IM WILLING TO TOLERATE FOR THE MOMENT o Had to comment out the exception handling code in the generated _c and _s files. o Some warnings are generated unless a few trivial things get changed in the generated _c and _s files. o Had to make every unit compiled into my test into a separate test (any way to turn this off for some units? For now I just added the func_filename function that testlist.c is looking for). These are marked as /* appease testlist.c */ below. AN UNCLASSIFIABLE PROBLEM Finally, there is the issue that I had to rename the stub functions in stringinput_c. This is pretty damn awful, because unlike the other issues, it doesn't stem from functionality that is missing in wine, so fixing wine still doesn't solve it. I don't know if its solvable or not. The problem stems from the fact that the entire test suite for rpcrt4 compiles into a single .exe.so file. Unless there is some way to override this arrangement, that same .exe.so must be both the client and the server. This is why I have stub_ShutdownServer, for example, instead of ShutdownServer (which is already defined to be the manager routine!) One of the following would allow me to solve this elegantly: o There's an acceptable way for me to tell the autocrap to generate multiple .exe.so's per dll test... is there? o There's a way to tell midl to deal with these namespace issues automagically so that the same .exe can be it's own client and server without a namespace conflict anyone know of such a feature? o Some other solution exists that I haven't thought of... note that the fixme, below: +/* StringInput manager routines (server-side implementations) + * FIXME: I had to prefix manager_ to these because otherwise + *we somehow ended up in NTDLL.sqrt!!! WTH?? + */ is incorrect (its a remnant of an attempt to solve this the converse way, renaming stuff in stringinput_s instead of stringinput_c.), and should be ignored. Blech. HOPEFULLY NOT A PROBLEM It also would be nice if some kind soul who knows the testing build incantations could run this new test under real windows and let me know if it actually works there. Thanks for your input. Here's the patch (X11): -- diff -ur -x CVS -x 'bigdif*' -x autom4te.cache ../wine.test/dlls/rpcrt4/ndr_midl.c ./dlls/rpcrt4/ndr_midl.c --- ../wine.test/dlls/rpcrt4/ndr_midl.c 2002-12-05 15:05:46.0 -0600 +++ ./dlls/rpcrt4/ndr_midl.c2003-01-03 21:25:50.0 -0600 @@ -214,6 +214,7 @@ pStubMsg-RpcMsg = pRpcMsg; pStubMsg-Buffer = pRpcMsg-Buffer; pStubMsg-BufferLength = pRpcMsg-BufferLength; + pStubMsg-BufferEnd = pStubMsg-Buffer + pStubMsg-BufferLength; /* FIXME: determine the proper return value */ return NULL; @@ -236,8 +237,9 @@ return NULL; stubmsg-BufferLength = stubmsg-RpcMsg-BufferLength; - stubmsg-BufferEnd = stubmsg-BufferStart = 0; - return (stubmsg-Buffer = (unsigned char *)stubmsg-RpcMsg-Buffer); + stubmsg-Buffer = stubmsg-BufferStart = (unsigned char *)stubmsg-RpcMsg-Buffer; + stubmsg-BufferEnd = stubmsg-Buffer + stubmsg-BufferLength; + return (stubmsg-Buffer); } /*** * NdrFreeBuffer [RPCRT4.@] @@ -247,7 +249,7 @@ TRACE((pStubMsg == ^%p): wild guess.\n, pStubMsg); I_RpcFreeBuffer(pStubMsg-RpcMsg); pStubMsg-BufferLength = 0; - pStubMsg-Buffer = (unsigned char *)(pStubMsg-RpcMsg-Buffer = NULL); + pStubMsg-Buffer = pStubMsg-BufferEnd = (unsigned char *)(pStubMsg-RpcMsg-Buffer += NULL); } / diff -ur -x CVS -x 'bigdif*' -x autom4te.cache ../wine.test/dlls/rpcrt4/tests/Makefile.in ./dlls/rpcrt4/tests/Makefile.in ---
Re: interesting crash in msvc6.0 setup
On Saturday 04 January 2003 02:42 pm, Dan Kegel wrote: :Repeat del E:\vs60wiz.exe if exist E:\vs60wiz.exe goto Repeat del C:\WINDOWS\DEL4056.BAT It's probably relying on the file being locked. I wonder, is it niced in Windows? Lame. -- gmt It does not take a majority to prevail ... but rather an irate, tireless minority, keen on setting brushfires of freedom in the minds of men. --Samuel Adams, Patriot
Re: WIP RPC test code (RFC): rpc_K01-pre2.diff
o Failure in the child process doesn't cause failure of the test (is there someone else who has this solved for their test whose code I can borrow?) couldn't you test the output of GetExitProcess (and ensure that when a test fails, we somehow return an error code) ? o rpcss.exe.so runs from the INSTALLED wine, not from the build tree!! This is totally unacceptable, but I'm not sure what would be a wise way to solve the problem. I need to change the way rpcss gets invoked by rpcrt4.dll. The best I can think of so far, would be to provide some global override (via a function call, I guess) for where rpcss.exe.so should be found, and then use this feature to ensure that during testing, rpcss.exe.so is invoked from the build tree instead of from the PATH environment variable. Any thoughts on this? what about an environment variable ? we already use something like this for the wineserver (WINESERVER), the wine console (WINECONSOLE)... why not rpcss (WINERPCSS) ? o There's a way to tell midl to deal with these namespace issues automagically so that the same .exe can be it's own client and server without a namespace conflict anyone know of such a feature? there isn't is ATM however, MS' midl has a /prefix option that does just what you need sounds like the way to go (another solution would be to put either client or server in a DLL (in fact a wine builtin DLL) so that you separate the name space between to two A+ -- Eric Pouech
Re: interesting crash in msvc6.0 setup
Greg Turner wrote: On Saturday 04 January 2003 02:42 pm, Dan Kegel wrote: :Repeat del E:\vs60wiz.exe if exist E:\vs60wiz.exe goto Repeat del C:\WINDOWS\DEL4056.BAT It's probably relying on the file being locked. I wonder, is it niced in Windows? Lame. Hmm. I guess I could log how the setup program created that process... I wonder if this is related to the fact I can run the program with relay on, but not relay off. Maybe with relay on, the file doesn't get deleted until after the last time it's needed...? - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com
Re: WIP RPC test code (RFC): rpc_K01-pre2.diff
On Saturday 04 January 2003 03:58 pm, Eric Pouech wrote: o Failure in the child process doesn't cause failure of the test (is there someone else who has this solved for their test whose code I can borrow?) couldn't you test the output of GetExitProcess (and ensure that when a test fails, we somehow return an error code) ? yes. (duh :) ) o rpcss.exe.so runs from the INSTALLED wine, not from the build tree!! This is totally unacceptable, but I'm not sure what would be a wise way to solve the problem. I need to change the way rpcss gets invoked by rpcrt4.dll. The best I can think of so far, would be to provide some global override (via a function call, I guess) for where rpcss.exe.so should be found, and then use this feature to ensure that during testing, rpcss.exe.so is invoked from the build tree instead of from the PATH environment variable. Any thoughts on this? what about an environment variable ? we already use something like this for the wineserver (WINESERVER), the wine console (WINECONSOLE)... why not rpcss (WINERPCSS) ? hmmm... will take a look at those, thanks. o There's a way to tell midl to deal with these namespace issues automagically so that the same .exe can be it's own client and server without a namespace conflict anyone know of such a feature? there isn't is ATM however, MS' midl has a /prefix option that does just what you need sounds like the way to go neato. sounds like a guaranteed winner :) (another solution would be to put either client or server in a DLL (in fact a wine builtin DLL) so that you separate the name space between to two nice, also, maybe nicer... but surely this does not belong in ./dlls? Will the makebeastie let me put it somewhere discreet like ./dlls/mydll/tests/dlls? I kind of like the latter, also, because it allows me to kick around gazillions of conflicting namespaces, if need be. Anyhow, between the two of these I will surely find a winner. Thanks so much! You know how it goes, the mental bugzapper gets silently shut down by the Universal Power Glitchifier sometimes, I think it's back up again... -- gmt It does not take a majority to prevail ... but rather an irate, tireless minority, keen on setting brushfires of freedom in the minds of men. --Samuel Adams, Patriot
Re: Mac OS X/Darwin port of Wine
Dan Kegel wrote: Lionel Ulmer wrote: We agreed that before starting with Wine, one could start with running, for example, Linux/x86 binaries on Linux/PPC. That would already validate the fact that you can draw the line at one point and from there run such an heterogenous environment. Hey, that's a good idea. Then you could install and run x86 linux packages, if you were really lucky. Might be useful for running proprietary packages where they don't bother to rebuild for linux/ppc. Yes, it would be terrific if someone were to do some porting for Linux/PPC. Wine and Bochs certainly work quite well with Linux. For my part, I plan to start with a trial port to Darwin/x86. If those two things happened in parallel, that would save a lot of time and definitely bring more expertise to bear on the many issues. Jim
Re: Mac OS X/Darwin port of Wine
Brian Vincent wrote: This issue comes up a few times a year (isn't it in a FAQ somewhere?) Anyway, take a look at these threads: Yes it is a bit of a FAQ, and the answers have mostly been along the lines of just use Winelib for non-Intel machines. Now it can be ... and checkout the Darwine BOF. Thanks for the links! Lionel Ulmer wrote: It's a very nice subject... A pitty it has such a low importance (seeing how X86 dominates the desktop market). Supposedly Mac OS X already has the largest installed base of any single *nix distribution and certainly is ahead of Linux on the desktop. So there are easily as many potential users of Wine for Mac OS X as Wine for X86-whatever. And Virtual PC has been popular successful. Dan Kegel wrote: Sounds like a plan to me. Hopefully your Wine tree won't drift out of sync with the main one like so many Linux kernel port trees do. Yep, keeping things in sync will be important. In checking out Winehq distrbution, I see that updates revolve arond the monthly tarballs. So that's where we'll start and try to keep up-to-date with that. Thanks for the encouragment! Jim
Re: Windows 2000 conformance tests
On Fri, 3 Jan 2003, Dave Miller wrote: I notice the status page has a couple of empty spaces remaining under win 2000. I suspect this is due to my report being somewhat unreadable, so I want to point out the results for these tests were included. The message in the archive is here: http://www.winehq.com/hypermail/wine-devel/2002/12/0994.html. All of the tests which are missing a status passed, with only user32/win providing any output beyond the 0 failures message. Thanks. I updated the page. The problem is that there are way too many tests that fail and that makes missing an item more likely and maintaining the page harder :-( -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ May your Tongue stick to the Roof of your Mouth with the Force of a Thousand Caramels.
Re: RESENT: running confirmance tests, question
On Fri, 3 Jan 2003, Sylvain Petreolle wrote: Looking at http://fgouget.free.fr/wine/tests-en.shtml, I downloaded ran the precompiled tests. Are them updated to ensure results in sync with the current CVS ? I have just uploaded a new version of the test binaries to the above location. Before that version the binaries contained lots of patches that were not yet in CVS because I compiled them from my standard Wine tree. Now I am using a separate Wine tree so the binaries are compiled from a clean CVS tree. Also, now the page will tell you when the winetests.zip file has last been updated. Currrently it reads: winetests.zip -- Sunday, 05-Jan-2003 04:32:51 MET -- 1.1M So the tests should match Wine's CVS as of 2003/01/05, and the file is 1.1MB in size. Is there a way to compile tests under Cygwin ? Looking into doc doesnt say that. I'm not sure about Cygwin but it's theoretically possible to cross-compile them on Linux to generated Windows binaries. However there were issues with that last time I tried: * the binaries failed to work on Win9x * just tried now and I get: i586-mingw32msvc-gcc dsound.cross.o testlist.cross.o -o dsound_crosstest.exe -L../../../dlls -ldsound -luser32 -lkernel32 -lm ../../../dlls/libmsvcrt.a(ds00425.o)(.text+0x0): multiple definition of `atexit' /usr/lib/gcc-lib/i586-mingw32msvc/3.2/../../../../i586-mingw32msvc/lib/crt2.o(.text+0x230):/home/ron/devel/debian/mingw32-runtime/mingw32-runtime-2.2/build_dir/src/mingw-runtime-2.2/crt1.c:241: first defined here ../../../dlls/libmsvcrt.a(ds00305.o)(.text+0x0): multiple definition of `_onexit' /usr/lib/gcc-lib/i586-mingw32msvc/3.2/../../../../i586-mingw32msvc/lib/crt2.o(.text+0x250):/home/ron/devel/debian/mingw32-runtime/mingw32-runtime-2.2/build_dir/src/mingw-runtime-2.2/crt1.c:249: first defined here What data should be reported when seeing invalid test in current results on the web page (running XP here) ? Good question. Thanks for askingg. I added the following to the page: These tests are conformance tests which means their main function is to describe the behavior of Windows APIs, and then to allow us to verify that Wine behaves like the test says. So obviously if a test fails on Windows its description of the Windows API behavior is incorrect and is useless as far as testing the correctness of Wine. Thus in the 'Wine' column I am marking any test that fails on a Windows platform as 'incorrect'. It must be fixed first. Then we can consider the results of running the test on Wine. So basically what needs to be done for 'incorrect tests' (previously 'invalid tests') is to fix the test so that it works on Windows and send the patch to wine-patches. Then the tests can be run again on the various Windows platforms and if it checks out on all of them its result under Wine can be considered. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Linux: It is now safe to turn on your computer.
Windows XP conformance test update 1/5
Not much to report this time but there is something... strange. kernel32/drive reported the following. C:\winetestskernel32_test.exe drive drive.c:113: Test failed: GetDiskFreeSpaceA(Z:\): ret=0 GetLastError=53 drive.c:165: Test failed: GetDiskFreeSpaceW(Z): ret=0 GetLastError=53 drive: 156 tests executed, 0 marked as todo, 2 failures. Previously this test passed, so I rebooted to see if the problem went away. After reboot the kernel32 test clamed not to be a valid win32 application. Turns out the size was 0 bytes. I re-extracted the zip file and ran kernel32/drive again. This time is passed. I have not seen the failure before but I did run into the not a valid win32 application message before, and the file size was 0 bytes. Normally I would suspect a virus to produce that sort of problem, but I've only seen this happen to the kernel32_test.exe file. I will attempt to find out if it can be reproduced and how. I have an XP laptop as well so I'll try to verify it is not a system specific problem. oleaut32/safearray reports 8 failures but the page only shows 4 failures. C:\winetestsoleaut32_test.exe safearray safearray.c:137: Test failed: SAC(20,1,[1,0]), result 8, expected 0 safearray.c:143: Test failed: SAGE for vt 20 returned elemsize 8 instead of expected 0 safearray.c:159: Test failed: copy of SAC(20,1,[1,0]), result 8, expected 0 safearray.c:162: Test failed: SAGE for vt 20 returned elemsize 8 instead of expected 0 safearray.c:137: Test failed: SAC(21,1,[1,0]), result 8, expected 0 safearray.c:143: Test failed: SAGE for vt 21 returned elemsize 8 instead of expected 0 safearray.c:159: Test failed: copy of SAC(21,1,[1,0]), result 8, expected 0 safearray.c:162: Test failed: SAGE for vt 21 returned elemsize 8 instead of expected 0 safearray: 958 tests executed, 0 marked as todo, 8 failures. Also I don't see urlmon/generated on the status page at all. It passed. C:\winetestsurlmon_test.exe generated generated: 4 tests executed, 0 marked as todo, 0 failures.
Handle table? win2k internals doc?
On the off chance that MSVC6's installer is cheating and reading the handle table entries directly by dereferencing file handles, I started wondering whether wine needed to make all its handles look a bit more like windows handles. What's the best source of info about how Windows formats its handles and arranges its handle table? Inside Microsoft Windows 2000 by David A. Solomon and Mark Russinovich http://www.sysinternals.com/insidew2k.shtml seems like a good source of info. Is it worth the $35 for a budding wine hacker? The Windows 2000 DDK is probably a good source, http://www.microsoft.com/ddk/W2kDDK.asp but for some reason, http://download.microsoft.com/download/win2000ddk/install/combined-8-00/nt5/en-us/win2kddk.exe is a broken link. - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com
Re: interesting crash in msvc6.0 setup
Uwe Bonnes wrote: Dan == Dan Kegel [EMAIL PROTECTED] writes: Dan Whenever it crashes in winnt/xp, it leaves one or more windowless Dan wcmd's running the following script: Dan :Repeat del E:\vs60wiz.exe if exist E:\vs60wiz.exe goto Repeat Dan del C:\WINDOWS\DEL4056.BAT Dan in a loop, chewing up huge amounts of CPU time. Try my patch Cc: [EMAIL PROTECTED] Subject: Re: [RESENT] Batch support for CreateProcess (2 of 3) Hey, that seems to get rid of the leftover wcmd's! - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com
Re: Removing (HANDLE)NULL casts (2)
On January 4, 2003 10:28 pm, Francois Gouget wrote:
A few handle types escaped the script the first time around. So here is
an updated version that will catch them. The updated version will also
catch casts of NULL to LP{C,W,wC}STR and LPVOID.
Why not just use 0 instead of NULL? Does it make any difference?
--
Dimi.
Re: console handling
On January 4, 2003 04:32 pm, Eric Pouech wrote: this patch fixes a couple of issues in the console handling (but shouldn't help Lionel Sylvain with the issues they reported on wd) Hi Eric, Do you have any plans to reorganize wineconsole a bit so that you don't need allocate a bitmap as big as the entire buffer, but rather one as big as the displayed screen only? This way we can have 3000-5000 line scroll buffers (as I have in my konsole, rxvt, xterm, etc.) -- Dimi.
