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

Re: Warcraft III no go. (probs with 1.03 ?)

by Bobby Bingham

hmm ... i had 1.00 and 1.01 working fine, but then i updraded to 1.03 ... but it dies differently for me (AFAICS) ... it seems the cracked executable is missing some exported funtions that warcraft 3 1.03's game.dll requires .... i've tried this under windoze too, and it crashes for me immediately (with a dialog saying game.dll is linked to missing exports from war3.exe) under wine, it prints out: err:win32:PE_fixup_imports No implementation for War3.exe.697 imported from C:\Program Files\Warcraft III\game.dll, setting to 0xdeadbeef err:win32:PE_fixup_imports No implementation for War3.exe.696 imported from C:\Program Files\Warcraft III\game.dll, setting to 0xdeadbeef err:win32:PE_fixup_imports No implementation for War3.exe.702 imported from C:\Program Files\Warcraft III\game.dll, setting to 0xdeadbeef err:win32:PE_fixup_imports No implementation for War3.exe.699 imported from C:\Program Files\Warcraft III\game.dll, setting to 0xdeadbeef err:win32:PE_fixup_imports No implementation for War3.exe.700 imported from C:\Program Files\Warcraft III\game.dll, setting to 0xdeadbeef err:win32:PE_fixup_imports No implementation for War3.exe.701 imported from C:\Program Files\Warcraft III\game.dll, setting to 0xdeadbeef but it starts running. too bad it tries calling those exports when you want to start playing, and crashes with an access violation ... -- Bobby Bingham

Oct. 31, 2002

Re: Versions & mass-appeal

by Dimitrie O. Paun

On October 31, 2002 03:35 am, Johan Gill wrote: > Even with perfectly working builtin dlls, one needs overrides for the > native dlls that are proprietary, or the loading will fail. Or is this a > bug? This doesn't sound right. Can you give some examples of that happening? -- Dimi.

Oct. 31, 2002

Re: So lets say we do it

by Dimitrie O. Paun

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.

Oct. 31, 2002

RFC: msvcrt _popen/_wpopen/_pclose

by Jaco Greeff

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); }

Oct. 31, 2002

Re: So lets say we do it

by Dimitrie O. Paun

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.

Oct. 31, 2002

Re: XBox

by Francois Gouget

On 30 Oct 2002, Chris Thielen wrote: [...] > I'm sure an Xbox emulator will eventually come along, assuming there > aren't a few already in the works; they, however, under Linux at least, > would have to implement DirectX calls; it would be interesting to > frequently contact those developers as they would face many of the same > issues of implementing DirectX as the newly formed Wine DX group will. I > don't know of any emulators that support Xbox architecture, but I don't > think wine should be the project to do so, not unless an Xbox game runs > under (normal) Windows. I thought that the XBox was basically a stripped down version of the Win32 API + DirectX + some hardware and software modifications to make XBox games incompatible with regular Windows. I also thought one of Microsoft's goals was to lure PC game programmers to the XBox by making it very similar to writing games for a PC. So it seems like Wine would contain 90% of what's needed to make an XBox emulator (for Unix), thus making it a good starting place. Same as Wine would be a good starting place to write a WinCE emulator. Of course I don't have (and probably will never have) and XBox and have never programmed a game for the XBox so maybe others know better? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ War doesn't determine who's right. War determines who's left.

Oct. 31, 2002

Re: So lets say we do it

by Andreas Mohr

On Thu, Oct 31, 2002 at 03:20:34PM -0500, Dimitrie O. Paun wrote: > On October 31, 2002 03:11 pm, Andreas Mohr wrote: > > Why, the current rate is avalanche-like ;) > > > > I'm growing ever more astonished about the increase in wine-patches per > > day... > > Same here. It's quite amazing! But can we sustain the rate for a year? I might be willing to bet that it might actually increase even more, now that more and more companies go The Linux Way... > > But of course you're sorta right, we're still quite far off the mark. > > Yes, but it's been my experience that there's nothing like a good, > focused TODO list to get people working on what's needed. And this > is were I'm aiming with these emails... Very true. We should make sure that the Contribute page links more or less directly to one page listing the requirements for a specific version (that'd be the Bugzilla 0.9 and 1.0 pages, I guess). But AFAIK the Contribute page already does this. BTW, I just updated the Contribute page quite a lot. -- Microsoft Licensing 6.0: "Pay us now in advance, so that we can own you later."

Oct. 31, 2002

Re: So lets say we do it

by Dimitrie O. Paun

On October 31, 2002 03:33 pm, Andreas Mohr wrote: > (OK, if you're overly pessimistic, then you'll probably tell me now that > nobody will ever work on updating foreign languages, despite of such > a marvellous infrastructure) No, all I am saying is that's a lot of effort, for not that huge gain. IMO there is a lot to gain on the docs front by just working on the English docs, that's all. And it's not nearly as complicated, requires no infrastructure, etc. Once we tackle that, we can start thinking about localizing the docs (even though I would suggest waiting for things to stabilize, since it's a lot of work, and there's no point in tracking a rapidly changing Wine in a gazillion languages). > Hmm, WAIT... didn't I say somewhere that I wouldn't work on docu > any more ? > I guess I didn't :) Oh, come on man! Pretty please? :))) -- Dimi.

Oct. 31, 2002

Re: So lets say we do it

by Andreas Mohr

On Thu, Oct 31, 2002 at 03:17:26PM -0500, Dimitrie O. Paun wrote: > On October 31, 2002 03:09 pm, Andreas Mohr wrote: > > Well, that maintenance would e.g. include the localization work I > > suggested, having a *separate* CVS containing all localized Wine Guides, > > and having automatically updated docu maintenance web pages > > for every language involved. > > But this is probably a bit too much. I mean, yeah, would be great to > have the guides localized, and what not, but that's a _lot_ of work, > and we don't seem to be able to maintain the English ones, let alone > other languages. Localizing the guides right now would just compound > the problem by just ending up with more unmaintained documentation. And here AGAIN I have to disagree with you :) Given a *correct* and *working* framework, the docu simply would not be rendered unmaintained. Every change in the English docu would keep sitting (or rotting) on the various foreign language translation pages until this change has been applied to the respective language and the item has been closed. (OK, if you're overly pessimistic, then you'll probably tell me now that nobody will ever work on updating foreign languages, despite of such a marvellous infrastructure) > What would be more productive, at this point, is a clear, and focused > TODO list for the current documentation, broken down into two sections: > 1. What is out of date (and needs fixing) > 2. What is missing (and needs writing) > Now, you being the guy that know the docs best, ..., eh, ..., maybe > you can help create such a list ;) Once it's done, maybe people will > start picking an item at a time, etc. What do ya say? Hmm, WAIT... didn't I say somewhere that I wouldn't work on docu any more ? I guess I didn't :) I could do that, but don't count on it, since my time is limited. (heck, I can't even keep up with the Wine mails that keep flooding my inbox !) (not to mention that it's me today who's to blame quite a lot for this mail situation today :) -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://mohr.de.tt

Oct. 31, 2002

Re: So lets say we do it

by Dimitrie O. Paun

On October 31, 2002 03:11 pm, Andreas Mohr wrote: > Why, the current rate is avalanche-like ;) > > I'm growing ever more astonished about the increase in wine-patches per > day... Same here. It's quite amazing! But can we sustain the rate for a year? > But of course you're sorta right, we're still quite far off the mark. Yes, but it's been my experience that there's nothing like a good, focused TODO list to get people working on what's needed. And this is were I'm aiming with these emails... -- Dimi.

Oct. 31, 2002