October 2002 - Wine-Devel - list.winehq.org

Re: CxxFrameHandler problem
by John K. Hohm April 11, 2003

April 11, 2003

Alexandre Julliard <julliard(a)winehq.com> wrote: > Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > > > Appended program uses CxxFrameHandler and crashes in wine with builtin > > msvcrt, but not with native. Compile as Release version and include the > MFC > > dll. Can somebody compile for Alexandre? Alexandre, is this a start or do > > you need something complete? > > That's a start, yes, thanks. I'll need a more complete example with > nested try blocks, destructors all over the place, typed exceptions, > etc. to make sure I understand all the compiler internal structures; > but I can at least try to make that simple case not crash... Although this may duplicate effort, I am familiar with several strange combinations of exception handling that I know work with Visual C++ 6.0; I will put them a test program for you. You can never have too many test programs, right?

1 1

SetWindowHookEx
by steve.lustbader＠philips.com Dec. 1, 2002

Dec. 1, 2002

My app uses SetWindowHookEx to install a WH_KEYBOARD_LL hook. Currently, the wine implementation tells me "fixme:hook:set_windows_hook system hook WH_KEYBOARD_LL won't work right" when I try to use it. I'd like to implement this so I can get my app to run, but I'm not sure where to start, since I don't know why it "won't work right." Any hints/suggestions? -Steve

3 5

SIGSEGV in IDirectDrawImpl_EnumDisplayModes
by Matthew Bloch Nov. 29, 2002

Nov. 29, 2002

Apologies for needing some more hand-holding: from Alexander's advice I now have the game linking and beginning to execute. It now gets stuck while executing this piece of C++: --------------------------------------------------------------------------- void tDirectDrawScreen::destroy() { DDSURFACEDESC ddsd; memset(&ddsd,0,sizeof(DDSURFACEDESC)); ddsd.dwSize = sizeof(DDSURFACEDESC); ddsd.dwFlags = DDSD_CAPS; ddsd.ddsCaps.dwCaps = DDSCAPS_PRIMARYSURFACE; HRESULT hr = mp_directDraw->CreateSurface(&ddsd, &mp_primarySurface, NULL); // crashes here ... } --------------------------------------------------------------------------- This being the segfault that occurs: --------------------------------------------------------------------------- #0 0x40c92c4c in ?? () #1 0x40f56f5f in User_DirectDraw_EnumDisplayModes (iface=0x403acc00, dwFlags=1086925740, pDDSD=0x808c678, context=0x40c92be8, callback=0x40f55dfc <EnumDisplayModesCallbackThunk>) at ddraw/user.c:373 #2 0x40f55e81 in IDirectDrawImpl_EnumDisplayModes (This=0x40c92be8, dwFlags=1086925900, pDDSD=0x808c678, context=0x40c92a94, cb=0x40c92a94) at ddraw/thunks.c:348 #3 0x4080f9b2 in tDirectDrawScreen::setUpWindowedSurfaces (this=0x808c668) at Source/tDirectDrawScreen.cpp:852 #4 0x4080cf1f in tDirectDrawScreen::initialise (this=0x808c668, fullScreen=false, screenWidth=640, screenHeight=480) at Source/tDirectDrawScreen.cpp:88 #5 0x4080caac in tDirectDrawScreen::tDirectDrawScreen (this=0x808c668, fullScreen=false, screenWidth=640, screenHeight=480) at Source/tDirectDrawScreen.cpp:55 #6 0x4082d76f in InitApp (hInst=0x40620000, nCmdShow=1) at Source/Main.cpp:289 #7 0x4082d8fc in WinMain (hInst=0x40620000, hPrevInst=0x0, lpCmdLine=0x403708ad "", nCmdShow=1) at Source/Main.cpp:322 #8 0x4062509c in __wine_exe_main () from /home/mattbee/Work/Nemesis/LSNClient.exe #9 0x400b3799 in start_process () at ../../scheduler/process.c:564 #10 0x400b76c9 in call_on_thread_stack (func=0x400b3558) at ../../scheduler/sysdeps.c:112 --------------------------------------------------------------------------- Any ideas why this might be happening? -- Matthew Bloch Bytemark Computer Consulting Limited http://www.bytemark.co.uk/ tel. +44 (0) 8707 455026

9 22

GetComputerName() question
by Martin Wilck Nov. 5, 2002

Nov. 5, 2002

Why is GetComputerName() an init function, or in other words, why is it important that HKEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Control\\ComputerName\\ComputerName be set at registry initialization time (in _allocate_default_keys())? I am asking because GetComputerName() IMO returns the wrong value (FQDN rather than NETBIOS name). A real implementation of GetComputerName() would look for the above value in the Registry and use gethostname() only as a fallback, but currently it's the other way around - why ? Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

2 8

Re: PATCH: ppc fix 2
by Greg Turner Nov. 4, 2002

Nov. 4, 2002

On Wednesday 30 October 2002 07:22 am, Marcus Meissner wrote: > Hi, > > Just a bad macro. > > ciao, marcus > > Changelog: > Fixed LITTLE_ENDIAN_32_READ macro to at least compile. > > Index: ndr_marshall.c > =================================================================== > RCS file: /home/wine/wine/dlls/rpcrt4/ndr_marshall.c,v > retrieving revision 1.9 > diff -u -r1.9 ndr_marshall.c > --- ndr_marshall.c 29 Oct 2002 23:07:33 -0000 1.9 > +++ ndr_marshall.c 30 Oct 2002 13:21:15 -0000 > @@ -59,8 +59,8 @@ > > #define LITTLE_ENDIAN_32_READ(pchar) \ > (MAKELONG( \ > - MAKEWORD(*(pchar), *((pchar)+1)) \ > - MAKEWORD(*((pchar)+2), *((pchar)+3))) > + MAKEWORD(*(pchar), *((pchar)+1)), \ > + MAKEWORD(*((pchar)+2), *((pchar)+3)))) > #endif > > /* oops! thanks! strange that this compiles for i386 at all. maybe gcc is automagically fixing the macro for some of us? -- gmt "The purpose of government is to rein in the rights of the people" --President Bill Clinton, MTV interview, 1993

2 3

Wine 0.8 TODO v0.1
by Dimitrie O. Paun Nov. 4, 2002

Nov. 4, 2002

This is the initial TODO for Wine 0.8. I know, 0.8 has been released before, but that's ancient history. Whether or not it gets released with this version number is irrelevant. In fact, even if it never becomes a public release, it is an important point to reach toward 0.9, and so if we complete this work, it would have solved its purpose. Now, again, what I mean by 0.8: -- Users can start using Wine -- works well for a fair number of apps -- no MS DLLs required (from real Windows) -- User facing stuff (website, docs, etc.) are in a decent state, to avoid scaring them away What is NOT in 0.8: -- stable server protocol: no binary compatibility -- DLL separation: ditto That being said, this is my initial list. Comments, flames, suggestions, are appreciated. A. WineHQ work 0. Reorganize a bit the navigational menu 1. Add a screenshot link to the homepage 2. Create some really sexy screenshots 3. Rework the FAQ interface (static HTML, a la http://www.dvddemystified.com/dvdfaq.html, all on one page, with a clickable question list at the top) 4. Enlist some 'official' distribution maintainers (at the minimum RedHat, Suse, UnitedLinux, Debian) 5. Create nice page with apps that run virtually flawless They should not require MS dlls, tricks, etc. to run Small explanation, screeshot, optional link to download page, such as Tucows. B. Documentation work Andy, take it away! :) C. Wine configuration 0. Merge configuration into the registry 1. Write control panel applets for editing it 2. Have decent defaults so we can start control panel without prior configuration 3. Have wizard like app to autoconfigure wine (?) 4. Make Wine's DLLs register themselves to avoid manual merging of the winedefault.reg 5. Write .inf script to setup a new Wine installation D. Stabilize utilities 0. Get rid of the init directive from .spec files 1. Make sure the .spec file format is fairly stable 2. Ensure the various utilities' options are stable E. Important fixes Alexandre, what to you see here? -- Dimi.

19 68

Re: So lets say we do it
by Dimitrie O. Paun Nov. 4, 2002

Nov. 4, 2002

On October 31, 2002 04:26 pm, Andreas Mohr wrote: > I wouldn't be 100% against placing a Screenshot link on the main page > - it's a mere 99% only. > But with the current menu infrastructure, I'm about 150% against it. > If we added a separate Screenshots menu item (which, by the way, I don't > think is needed, since we do have that nice About page), > then the whole page would grow overly long. Agreed. I say, let's get some of the content in shape, and worry about the form a wee bit later. BTW, any web-design guys around, that may want to take on this task? -- Dimi.

5 13

Wine securityflaw.
by Peter Andersson Nov. 1, 2002

Nov. 1, 2002

Hello again, (FYI, I took the liberty to change the topic since I started the former thread "How is Win/Dos syscalls implemented in Wine?" which I feel has gone a little bit off-topic) I had some more thoughts on the issue... I believe most wine users trust wine not to touch anything outside of its configured drive space. Malicious Linux/Unix syscalls could be embedded in windows apps and if executed do a great deal of damage. After all checking your app is run whithin Wine is not that hard (reading registry settings for instance). Lets call such an malicious app a wine-virus from now on. At present a wine-virus would even be allowed to fork itself, leaving the wine environment and continue to run even after you shutdown the wineserver, and in some cases even after the user logs out. The virus would now have full access to the system whithin the users permission, doing much greater damage than you expected. The question is...Would you expect that damage from running a windows app in wine, when you know it could be safely run in Windows? In just a few embedded bytes in the code it could remove your home directory in a single syscall. Would you expect that? - I wouldnt. I really love the idea of Wine, and the fact that its working good and rather stable now does mean its gaining popularity and a broader user base, which further IMHO accelerates the wine movement. If wine users were aware of the risks of using wine at present, I believe wine would be used more cautiously. Cant we atleast try implement some protection in wine against these attacks, before something really nasty happens. I do think company policy decissions againt using wine, will do just as much damage to the wine movement as too the free software movement at large. I would, despite my current lack of knowledge, gladly offer my help. But I hope someone more experienced would take the lead. Best Regards, Peter Andersson

18 35

What is a leap second
by György 'Nog' Jeney Nov. 1, 2002

Nov. 1, 2002

While I was looking through dlls/ntdll/time.c I came across the following two comments: "FIXME: Compute the number of leap second corrections here" and "FIXME: get the GMT offset here" What do these mean? nog.

4 9

Versions & mass-appeal
by Dimitrie O. Paun Nov. 1, 2002

Nov. 1, 2002

People, I think everybody here agrees that Wine's biggest problem is the lack of developers. No developers, slow progress, no users, back to no developers. We are in this vicious circle for a while, spinning our wheels like crazy. We've achieved great progress lately, but I hope we all agree that Wine is a vast project that can succeed only with a mass appeal similar to the fueling the development of the Linux Kernel. Why are we in this position? For reasons I will not go into right now, it seems painfully obvious to me that we are suffering from a severe case of Bad Public Image (tm). Whenever I talk to people not intimately familiar with Wine, about our beloved project, I am _always_ treated with the same reaction: a surprised "Really, it works? Hmmm, I thought it was only running Freecell...". Translation: people consider Wine a huge hack that can run (by some strange happenings) some apps, sometimes. It is viewed as unreliable, "freak of nature sideshow"; something (maybe) cool to talk about, but utterly useless. THIS IS OUR PROBLEM. The lack of users follows trivially. We know the above opinion is not true. *I* get constantly amazed by how much progress we've made. Something must be done, and I think there is something to be done. How do we change this state of affairs? Well, people need major events to reevaluate their opinions. Being major, they are by definition few, and so we don't have too many chances. For Wine, these events are the upcoming x.y releases. What I'm trying to say is that we have to prepare properly for them. Here's my concrete proposal for releases: 0.8.x : Wine is usable, we don't guarantee binary compatibility 0.9.x : Wine is usable, and we kinda guarantee binary compatibility 1.0.x : Wine is quite usable, we guarantee binary compatibility I'll define these things more precisely later, but before that, let me explain why we should introduce the 0.8.x series: -- a chance to attract more users into the fold -- Wine is approaching that stage fast -- it's a logical, interim step to 0.9 -- will help us focus Whatever the reason, it's a _logical_ step that we must go through in our journey to 0.9, and from a user's perspective, it makes sense to make it public. There's no point in robbing us of the userbase for a abstract techy goal of binary compatibility. That's the next stage. Criteria for these releases: 0.8.0 -- Wine runs several popular apps well (we're close) -- Web site is updated (e.g. Who's Who, etc) -- Existing docs are up-to-date -- Utilities are close to final form (winebuild, etc.) 0.9.0 -- DLL separation complete -- Server protocol complete 1.0.0 -- Major bugs squashed -- Flawless UI -- Complete docs I'll leave it at that. Comments, flames? -- Dimi.

18 45

Getting actively involved in the Wine project
by Thomas Wickline Nov. 1, 2002

Nov. 1, 2002

From the page: ----- PR manager Currently we almost have no Public Relationship management at all. This should change for the better. Currently almost the only form of PR is "preaching to the choir", since we're having articles on online IT sites (by far most are Linux only !). We should have much more coverage on traditional Windowsish sites and, most importantly, in dead-tree newspapers, to enlighten the general public also known as The Great Unwashed Masses ! ----- Wine users , CodeWeavers & WineX customers could do Previews/Demo's at there local lug meetings as well.. This is what I did a couple months back and it was a huge success there were Windows users at the meeting to see Linux and Win app's being run on Linux ... Also it gives Linux users a look at wine as well. So I suggest that we try to encourage wine users to volinteer to show Wine at there local user groups/Installfest/Computer shows and so on. This is not a PR manager but it is PR...... Tom

3 3

Re: RFC: msvcrt _popen/_wpopen/_pclose
by chrismorgan＠rcn.com Nov. 1, 2002

Nov. 1, 2002

What is wrong with using wcmd and extending it if necessary? Chris > > From: "Jaco Greeff" <jaco(a)puxedo.org> > Date: 2002/10/31 Thu PM 04:27:43 EST > To: wine-devel(a)winehq.com > Subject: RFC: msvcrt _popen/_wpopen/_pclose > > Hi, > > I want some comments on the possibility of a _popen/_wpopen/_pclose > implementation in Wine. Reference available at: > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html… > > The open functions basically operate in the same way as the popen function > in Linux, ie. it spawns a process with the command via the command > interpreter. Now, unfortionately we don't have our won cmd.exe available, > but should people really need this functionality it might not be too much to > ask as to copy it from a working Windows installation. > > In my mind, supporting the Win 95/98 command interpreters might be a > nightmare - my gutt feel is that these two rely too much on DOS internals to > be sucessfully launched via Wine. No, I haven't tried it, so I might be > completely wrong. Either way, something like this might be better > implemented via the Win NT/2000/XP cmd.exe. (I'll test my assumptions > tomorrow, I don't have access to the command interpreters tonight.) > > I've hacked (yes, it was quick) a potential implementation of the _popen > family of functions. (Haven't compiled, haven't tested, this is just and RFC > - if it can work, I'll spend some real time on it.) Anyway, here it is, > comments appreciated: > > --[ inline-ish RFC ]---- > > #include "config.h" > #include "wine/port.h" > > #include <stdio.h> > #include <stdlib.h> > #ifdef HAVE_UNISTD_H > # include <unistd.h> > #endif > > #include "winbase.h" > #include "winnls.h" > #include "wine/unicode.h" > #include "msvcrt/stdio.h" > #include "msvcrt/string.h" > > #include "wine/debug.h" > > #define POPEN_FLAG_READ 0x0001 > #define POPEN_FLAG_WRITE 0x0002 > #define POPEN_FLAG_TEXT 0x0004 > #define POPEN_FLAG_BINARY 0x0008 > > inline CHAR *LPCWSTRToLPSTR(const LPCWSTR lpwstrIn, INT nIn) > { > INT nLen = WideCharToMultiByte(CP_ACP, 0, lpwszIn, nIn, NULL, 0, NULL, > NULL); > CHAR *szOut = (CHAR *)malloc((nLen+1)*sizeof(CHAR)); > if (szOut) > { > WideCharToMultiByte(CP_ACP, 0, lpwszIn, nIn, szOut, nLen+1, NULL, NULL); > szOut[nLen] = '\0'; > } > return szOut; > } > > INT POPEN_parseModeFlags(const CHAR *szMode) > { > INT nFlags = 0; > while (szMode && *szMode) > { > switch (*szMode) > { > case 'r': > { > if (nFlags & POPEN_FLAG_WRITE) > WARN(": _popen: Cannot set both read and write open > flags, ignoring read flag\n"); > else > nFlags = nFlags & POPEN_FLAG_READ; > break; > } > case 'w': > { > if (nFlags & POPEN_FLAG_READ) > WARN(": _popen: Cannot set both read and write open > flags, ignoring write flag\n"); > else > nFlags = nFlags & POPEN_FLAG_WRITE; > break; > } > case 'b': > case 't': > { > FIXME(": _popen: %c mode flag not implemented, ignoring\n", > *szMode); > break; > } > default: > { > WARN(": _popen: unknown mode flag %c, ignoring\n", *szMode); > break; > } > } > } > return nFlags; > } > > MSVCRT_FILE *MSVCRT_popen(const CHAR *szCommand, const CHAR *szMode) > { > MSVCRT_FILE *fProcess = NULL; > > if (!szCommand || !szMode) > return NULL; > > INT nFlags = POPEN_parseModeFlags(szMode); > if (!(nFlags & (POPEN_FLAG_READ|POPEN_FLAG_WRITE))) > { > ERR("No open mode flag r or w specified\n"); > return NULL; > } > > /* _popen/_wpopen executes the required command via the command > * processor, either command.com (Win 95/98) or cmd.exe (Win NT/2000/XP). > * Wine does not currently have it's own "cmd.exe" hence we cannot > * really do anything more at this point. However, we try to lauch it > * and hope for the best... > */ > CHAR *szExec = (CHAR *)malloc(strlen("wine -- C:/cmd.exe -C > ")+strlen(szCommand)+1); > if (szExec) > { > sprintf(szExec, "wine -- C:/cmd.exe -C %s", szCommand); > fProcess = popen(szExec, (nFlags & POPEN_FLAG_READ) ? "r" : "w"); > if (!fProcess) > ERR("Execution of C:/cmd.exe via wine failed\n"); > else > WARN("Launch of %s succeeded, no guarentees of success made\n", > debugstr_a(szExec)); > free(szExec); > } > > return fProcess; > } > > MSVCRT_FILE *MSVCRT_wpopen(const WCHAR *wszCommand, const WCHAR *wszMode) > { > MSVCRT_FILE *fProcess = NULL; > > if (!wszCommand || !wszMode) > return NULL; > > CHAR *szCommand = LPCWSTRToLPSTR(wszCommand, strlenW(wszCommand)); > if (szCommand) > { > CHAR *szMode = LPCWSTRToLPSTR(wszMode, strlenW(wszMode)); > if (szMode) > { > fProcess = _popen(szCommand, szMode); > free(szMode); > free(szCommand); > } > free(szCommand); > } > > return fProcess; > } > > int MSVCRT_pclose(MSVCRT_FILE *fProcess) > { > if (!fProcess) > return -1; > return pclose(fProcess); > } > > > >

2 2

So lets say we do it
by Dimitrie O. Paun Nov. 1, 2002

Nov. 1, 2002

That is, Lets assume for the sake of argument that Alexandre likes my 0.8 idea so much, that he releases Wine 0.8 with much fanfare next Monday (so we have a good audience), and the news reaches Slashdot where a message with a link to http://www.winehq.org is posted, in good CmdrTaco fashion... And so, let's see what's going to happen: 1. 90% of /.ers will click on the link, and WineHQ gets Slashdotted! :) 2. People will look for the typical left-side menu: Home About Status Development Download Screenshots *BZZT* We don't have any. 5% will drop off here. 3. Then they'll visually search for the word "Screenshot" *BZZT* We don't have any on front page. 30% will drop off. *I* drop off here when I visit other projects, for crying out loud! So let's assume that by a miracle they'll discover the screenshots: do they make them drool? No, we loose another 15%. Damn, that's tough! Let's see what happens to the rest: 4. Let's download, and try it out Do we have officially sanctioned binaries (at the very least .rpms for RH, and .deb for Debian)? No. *BZZT* We loose another 30%. Again, *I* don't care about stuff that doesn't come as a binary .rpm for my RH system. I used to, not anymore. Fine, some will install what they download. What next? Hm, this Wine thing just sits there, it's not that simple. We need to read some docs. Back to the site. 5. Look at the docs Oh, we have some. We hate to read docs, but Wine is cool, so we swallow the pill. Only to find out it's out of date!!! What a piece of #@$%! *BZZT* Another 10% drop off. Thats 90% drop-off before they really tried it out! The rest 10%, go on. So, what do we do with it? 6. Look for a list of Win-apps that we can run Is there something on the site? No. Blah, too much hassel... *BZZT* Another 5% go. (Don't even mention app-db, it's *way* too complicated!) So the 5% left, install wine, install a Win-app, and play around. Great, it works! They start learning the utilities, etc., but those are in flux, and we change them, and they get PO-ed. Another percent, or two leave the fold... -- Dimi. P.S. A story-like TODO (with embedded rationale) for 0.8.0 :)

10 27

Warcraft III no go. (probs with 1.03 ?)
by dan carter Oct. 31, 2002

Oct. 31, 2002

OK, it seems everyone but me is able to play War3 under linux. Current status is i have the 1.03 NoCD patch: ³ Warcraft III: Reign Of Chaos 1.03 Virtual Crack ³ ³ Cracked By : gimpsRus ³ Game Type : Strategy ³ ³ Packaged By: gimpsRus ³ Released On: 10 October 2002 ³ I'm using the 'dataparty' RPMs build "wine-cvs-opengl-102802-1" OpenGL is working and i can still load the warez beta version of war3 that i used to play. Now that i have actually bought the damn thing i can't play :( Here is the error i get: [dantheperson(a)danski dantheperson]$ wine .wine/fake_windows/Program\ Files/Warcraft\ III/war3.exe -- -opengl wine: Unhandled exception, starting debugger... err:seh:start_debugger Couldn't start debugger ("debugger/winedbg 134692272 8324") (2) Read the Wine Developers Guide on how to set up winedbg or another debugger [dantheperson(a)danski dantheperson]$ Has anybody had success with the 1.03 patch? Does anyone know where i can get an older NoCD crack that is known to be working under linux? Rgds, dan carter

3 2

RFC: msvcrt _popen/_wpopen/_pclose
by Jaco Greeff Oct. 31, 2002

Oct. 31, 2002

Hi, I want some comments on the possibility of a _popen/_wpopen/_pclose implementation in Wine. Reference available at: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html… The open functions basically operate in the same way as the popen function in Linux, ie. it spawns a process with the command via the command interpreter. Now, unfortionately we don't have our won cmd.exe available, but should people really need this functionality it might not be too much to ask as to copy it from a working Windows installation. In my mind, supporting the Win 95/98 command interpreters might be a nightmare - my gutt feel is that these two rely too much on DOS internals to be sucessfully launched via Wine. No, I haven't tried it, so I might be completely wrong. Either way, something like this might be better implemented via the Win NT/2000/XP cmd.exe. (I'll test my assumptions tomorrow, I don't have access to the command interpreters tonight.) I've hacked (yes, it was quick) a potential implementation of the _popen family of functions. (Haven't compiled, haven't tested, this is just and RFC - if it can work, I'll spend some real time on it.) Anyway, here it is, comments appreciated: --[ inline-ish RFC ]---- #include "config.h" #include "wine/port.h" #include <stdio.h> #include <stdlib.h> #ifdef HAVE_UNISTD_H # include <unistd.h> #endif #include "winbase.h" #include "winnls.h" #include "wine/unicode.h" #include "msvcrt/stdio.h" #include "msvcrt/string.h" #include "wine/debug.h" #define POPEN_FLAG_READ 0x0001 #define POPEN_FLAG_WRITE 0x0002 #define POPEN_FLAG_TEXT 0x0004 #define POPEN_FLAG_BINARY 0x0008 inline CHAR *LPCWSTRToLPSTR(const LPCWSTR lpwstrIn, INT nIn) { INT nLen = WideCharToMultiByte(CP_ACP, 0, lpwszIn, nIn, NULL, 0, NULL, NULL); CHAR *szOut = (CHAR *)malloc((nLen+1)*sizeof(CHAR)); if (szOut) { WideCharToMultiByte(CP_ACP, 0, lpwszIn, nIn, szOut, nLen+1, NULL, NULL); szOut[nLen] = '\0'; } return szOut; } INT POPEN_parseModeFlags(const CHAR *szMode) { INT nFlags = 0; while (szMode && *szMode) { switch (*szMode) { case 'r': { if (nFlags & POPEN_FLAG_WRITE) WARN(": _popen: Cannot set both read and write open flags, ignoring read flag\n"); else nFlags = nFlags & POPEN_FLAG_READ; break; } case 'w': { if (nFlags & POPEN_FLAG_READ) WARN(": _popen: Cannot set both read and write open flags, ignoring write flag\n"); else nFlags = nFlags & POPEN_FLAG_WRITE; break; } case 'b': case 't': { FIXME(": _popen: %c mode flag not implemented, ignoring\n", *szMode); break; } default: { WARN(": _popen: unknown mode flag %c, ignoring\n", *szMode); break; } } } return nFlags; } MSVCRT_FILE *MSVCRT_popen(const CHAR *szCommand, const CHAR *szMode) { MSVCRT_FILE *fProcess = NULL; if (!szCommand || !szMode) return NULL; INT nFlags = POPEN_parseModeFlags(szMode); if (!(nFlags & (POPEN_FLAG_READ|POPEN_FLAG_WRITE))) { ERR("No open mode flag r or w specified\n"); return NULL; } /* _popen/_wpopen executes the required command via the command * processor, either command.com (Win 95/98) or cmd.exe (Win NT/2000/XP). * Wine does not currently have it's own "cmd.exe" hence we cannot * really do anything more at this point. However, we try to lauch it * and hope for the best... */ CHAR *szExec = (CHAR *)malloc(strlen("wine -- C:/cmd.exe -C ")+strlen(szCommand)+1); if (szExec) { sprintf(szExec, "wine -- C:/cmd.exe -C %s", szCommand); fProcess = popen(szExec, (nFlags & POPEN_FLAG_READ) ? "r" : "w"); if (!fProcess) ERR("Execution of C:/cmd.exe via wine failed\n"); else WARN("Launch of %s succeeded, no guarentees of success made\n", debugstr_a(szExec)); free(szExec); } return fProcess; } MSVCRT_FILE *MSVCRT_wpopen(const WCHAR *wszCommand, const WCHAR *wszMode) { MSVCRT_FILE *fProcess = NULL; if (!wszCommand || !wszMode) return NULL; CHAR *szCommand = LPCWSTRToLPSTR(wszCommand, strlenW(wszCommand)); if (szCommand) { CHAR *szMode = LPCWSTRToLPSTR(wszMode, strlenW(wszMode)); if (szMode) { fProcess = _popen(szCommand, szMode); free(szMode); free(szCommand); } free(szCommand); } return fProcess; } int MSVCRT_pclose(MSVCRT_FILE *fProcess) { if (!fProcess) return -1; return pclose(fProcess); }

1 0

Re: So lets say we do it
by Dimitrie O. Paun Oct. 31, 2002

Oct. 31, 2002

On October 31, 2002 04:18 pm, Andreas Mohr wrote: > Bl**dy b*tch ! :-)) Listen man, I don't like that! I mean, what's up with the stars?!? :))) > First you annoy the h*ll out of people, and then you behave as if nothing > had ever happened and the weather was fantastic... ;-) Oh, Andy dude, you are the toughest guy on Wine-devel, crushing poor newbies without remorse. And now, all of a sudden, you become this sensible, in-touch-with-your-feelings guy?!? ;-) (ROTFL) > (BTW: the weather here is awful :) See, and you blame poor me... :P -- Dimi.

1 0

XBox
by Dirk Oct. 31, 2002

Oct. 31, 2002

Could someone do something to make the need for this hardware disappear and save the world of people who love proprietrary video game consoles? There is already a tool that converts xpe files into exe. Only the bios and the improved DirectX must be re-engineered and the rest will be done by a Geforce4 (or 5) and a 2Ghz CPU.

4 3

Debugging advice
by Matthew Bloch Oct. 31, 2002

Oct. 31, 2002

Hi there; I feel like I'm "nearly there" with porting this game to run with winelib, a version checked out from winehq CVS about a week ago. Because I wanted my build system to be cross-platform, and WINE only as a stop-gap, I'm using the Jam build system and so can't directly take advantage of winemaker. Plus I would rather learn and document how the build process works manually, since I can't find this information anywhere else. Anyhow I now have the 400-odd source files compiling happily against my wine header files once I'd excised the need for Direct3D. I have a directory full of object files with external references to Win32 functions and a WinMain function. So to do the final linking step I've used (based on watching the example winemine build process): $WINE/tools/winebuild/winebuild \ -fPIC -DSTRICT -D_REENTRANT \ -exe LSNClient.exe -mgui Builds/native-debug-linux/Source/*.o \ -L$WINE/dlls -luser32 -lgdi32 -ladvapi32 -lkernel32 -lddraw -ldsound \ -lwinmm -ldisplay -ldispdib >Source/LSNClient.exe.c and then compiled & linked LSNClient.exe.c to the rest of the object files with the -shared flag, which leaves me with a shared library. Sideline: am I correct in thinking that winebuild's job is to scan the supplied object files for Win32 dependencies and construct the necessary glue code to load the needed .dll.so files? What's the reason that the linking process can't correspond more closely to "normal" linking, i.e. where I could just supply -lddraw -lwine to my program to produce a final binary? I then run ../wine/wine LSNClient.exe to try to run the game, and get this error: err:module:BUILTIN32_LoadLibraryExA loaded .so but dll display.dll still not found - 16-bit dll or version conflict. err:module:PE_fixup_imports Module (file) display.dll (which is needed by Y:\Work\Nemesis\LSNClient.exe) not found Any idea what might be going wrong, or how I could diagnose it? More generally, the natively compiled .exe runs okay (if grindingly slowly, and with a couple of display glitches) under the binary loader, but I assumed that if I could produce a native version I'd be avoiding a lot of overhead and make my debugging job easier since I could use familiar GNU tools to debug my portability code as I wrote it. What efficiency gains will I make compiling a native "shared library exe" with gcc as opposed to just compiling with Visual C and running it under the normal WINE binary loader? I'm interested in how the latter works efficiently, so any advice in this direction would be appreciated-- I've thought on more than one occasion that maybe I should skip the WINE stop-gap and port it to SDL all at once, but the idea of being able to gradually wean the game off Win32 is appealing. cheers, -- Matthew Bloch Bytemark Computer Consulting Limited http://www.bytemark.co.uk/ tel. +44 (0) 8707 455026

5 6

RE: winapi_check question...
by Patrik Stridvall Oct. 31, 2002

Oct. 31, 2002

> On Thursday 31 October 2002 09:20 am, Patrik Stridvall wrote: > > Greg wrote: > > > winapi_check tells me: > > > > > > ndr_stubless.c:86: rpcrt4: LONG_PTR WINAPIV > > > NdrClientCall2(PMIDL_STUB_DESC,PFORMAT_STRING,...): argument 1 > > > documentation: \ > > > /* CLIENT_CALL_RETURN */ > > > > This is because winapi_check misparser the line: > > LONG_PTR /* CLIENT_CALL_RETURN */ > > RPCRT4_NdrClientCall2(PMIDL_STUB_DESC pStubDesc, PFORMAT_STRING > > pFormat, va_list args) > > > > Ignore it. > > OK. You promise it won't screw up the actual documentation bot? Promise? Hmm. All code have bugs you know and winapi_check is designed to be ad hoc and thus inherently buggy... :-) But seriously, I wouldn't worry about it. Anyway. A real fix to the code you be nice. Presumable the type CLIENT_CALL_RETURN haven't been declared properly. > > > how shall I deal with these? > > > > Fix them as above or do as everybody elses do wait for me to fix it. > > :-) > > heh. Well, maybe I can set an example for those deadbeats :) :-)

2 1

Re: dlls/msvcrt/tests: printf
by Jaco Greeff Oct. 31, 2002

Oct. 31, 2002

On Thu, 31 Oct 2002 17:57:12 +0100, Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote : > Jaco> ... Tests that will fail > Jaco> with current implementation are temporarily commented out > > Don't comment them out, matrk them "todo". Look at the syntax in > documentation/testing. I've marked the code with a "FIXME". I don't want the test sequence to fail for this issue which is solved by my msvcrt patch. The way I've done it allows others to verify the new vfprintf patch with minimal work. > And plain inlined patches are preferred against attachments. I'm doing this via a mail web interface, it has the ugly habit of doing line-wraps. I also prefer inline patches (like to see what is going on without have to save etc.), it is just not entirely possible for me at this point. *sigh* Greetings, Jaco

3 2

Some other problems ...
by Paul Millar Oct. 31, 2002

Oct. 31, 2002

Hi everyone, Just a couple of problems I've noticed. They look like they're due to some broken build dependencies. 1. I have a copy of wine on my laptop which I do "cvs update" every few days. After updating today, I did the usual "./configure --enable-opengl && make depend && make" and left it to compile. But, when I tried the result, I got a client/server mismatch for SERVER_PROTOCOL_VERSION. One was claimed to be v88 whilst the other was v89. Doing a "make distclean" then repeating the build "fixed" the problem. Patch http://cvs.winehq.com/patch.py?id=6064 (committed last Tuesday) bumped the SERVER_PROTOCOL_VERSION up to 89. So it looks like some of the binaries weren't updated during the build. I tried altering the version (manually) and rebuilding, but wine rebuilt correctly. 2. WRT hit a problem last night where "make test" failed. The log included messages like: gcc -c -I. -I. -I../../../include -I../../../include -g -O2 -Wall -mpreferred-stack-boundary=2 -fPIC -DSTRICT -DNONAMELESSUNION -DNONAMELESSSTRUCT -D_REENTRANT -o registry.o registry.c LD_LIBRARY_PATH="../../../library:../../../unicode:$LD_LIBRARY_PATH" ../../../tools/winebuild/winebuild -fPIC -DSTRICT -DNONAMELESSUNION -DNONAMELESSSTRUCT -o advapi32_test.exe.spec.c -exe advapi32_test.exe -mcui registry.o testlist.o -L../../../dlls -ladvapi32 -lkernel32 -lntdll gcc -shared -Wl,-Bsymbolic advapi32_test.exe.spec.o registry.o testlist.o -o advapi32_test.exe.so -L../../../library -lwine -lm advapi32_test.exe.spec.o: In function `__wine_exe_main': /home/paulm/WINE-cvs/wine/dlls/advapi32/tests/advapi32_test.exe.spec.c:116: undefined reference to `main' registry.o: In function `test_enum_value': /home/paulm/WINE-cvs/wine/dlls/advapi32/tests/registry.c:69: undefined reference to `winetest_set_ok_location' /home/paulm/WINE-cvs/wine/dlls/advapi32/tests/registry.c:69: undefined reference to `winetest_ok' /home/paulm/WINE-cvs/wine/dlls/advapi32/tests/registry.c:78: undefined reference to `winetest_set_ok_location' [... etc ...] The later build had six tests that succeded. These were the new scanf tests introduced into that build by patch http://cvs.winehq.com/patch.py?id=6107 I've just done a "make distclean" followed by a normal rebuild and test. Its currently running through the regression tests, but so far it seems to be working. These are vague reports of unrepeatable problems ... never a good thing! I'm quite busy right now (real work and everything), so I don't have time to investigate this myself. Just posting this hoping the cause its obvious to someone else :^) ---- Paul Millar

1 0

Re: dlls/msvcrt/tests: printf
by Jaco Greeff Oct. 31, 2002

Oct. 31, 2002

On Thu Oct 31 20:04:30 2002, "Jaco Greeff" <jaco(a)puxedo.org> wrote : > On Thu, 31 Oct 2002 17:57:12 +0100, Uwe Bonnes > <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote : > > Jaco> ... Tests that will fail > > Jaco> with current implementation are temporarily commented out > > > > Don't comment them out, matrk them "todo". Look at the syntax in > > documentation/testing. > > I've marked the code with a "FIXME". Sorry, I misunderstood the first time around, will something like todo("linux") { do(something() == 1, "whatever"); } do the trick? But unsure about the definition I should use, I can see "cygwin", "freebsd", etc. This one will fail on all non-Windows platforms. Greetings, Jaco

1 0

Re: dlls/msvcrt/tests: printf
by Jaco Greeff Oct. 31, 2002

Oct. 31, 2002

On Thu, 31 Oct 2002 11:04:48 -0600, Greg Turner <gmturner007(a)ameritech.net> wrote : > On Thursday 31 October 2002 10:34 am, Jaco Greeff wrote: > > - Tests that will fail with current implementation are temporarily > > commented out > > Is there a middle ground for tests that are expected to fail? If not, > IMO maybe there should be: It kinda defeats the purpose of a test > framework if we just comment out tests that don't work... Agreed. It will pass shortly though :) At this point the test will help anybody wishing to verify my latest msvcrt patch. Plus, it really should pass. The part that does fail is on Unicode printing, which give me one of a few choices: 1. Don't send in a test; 2. Be stubborn and let the test fail for everybody doing a make test; 3. Send in a really crippled test case; 4. Combination of 3 + 4 so people can easily have the framework to test if progress have been made. That is the reason why I've commented it out, hopefully shortly it will be fully featured. Greetings, Jaco

1 0

Re: dlls/msvcrt/tests: printf
by Greg Turner Oct. 31, 2002

Oct. 31, 2002

On Thursday 31 October 2002 10:34 am, Jaco Greeff wrote: > - Tests that will fail with current implementation are temporarily > commented out Is there a middle ground for tests that are expected to fail? If not, IMO maybe there should be: It kinda defeats the purpose of a test framework if we just comment out tests that don't work... but OTOH, its pretty unfair to the other tests to have the whole "make test" fail because of some known issue. -- gmt "The purpose of government is to rein in the rights of the people" --President Bill Clinton, MTV interview, 1993

1 0

Re: rpc_H_PL9
by Michael Stefaniuc Oct. 31, 2002

Oct. 31, 2002

On Thu, Oct 31, 2002 at 08:49:18AM -0600, Greg Turner wrote: > LICENSE: X11 > > CHANGELOG: > * dlls/rpcrt4: rpc_server.c; > include: rpcdcep.h: > Greg Turner <gmturner007(a)ameritech.net> > - One more fixup for winapi_check > -UINT WINAPI I_RpcWindowProc( HANDLE hWnd, UINT Message, UINT wParam, ULONG lParam) +UINT WINAPI I_RpcWindowProc( void *hWnd, UINT Message, UINT wParam, ULONG lParam ) That's totaly broken. It's a problem in winapi_check and not in your code. Well, their is a problem in your code too, i would change HANDLE to HWND. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

2 2