- Wine-Devel - list.winehq.org

Re: I suck...
by Dimitrie O. Paun Nov. 1, 2002

Nov. 1, 2002

On October 31, 2002 08:17 pm, Greg Turner wrote: > Inlined for your viewing pleasure. Cool, thanks! :) -- Dimi.

1 0

Re: Treeview notifications
by Dustin Navea Nov. 1, 2002

Nov. 1, 2002

Unfortunately, no it didnt fix the problem. :( -Dustin --- "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > Dustin, Adrian, can you please try this one, and let me > know if it fixes your problems? > > ChangeLog > Fix some treeview notification codes between ANSI/Unicode mode. > __________________________________________________ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/

1 0

Re: So lets say we do it
by John K. Hohm Nov. 1, 2002

Nov. 1, 2002

> Once we have that we need to make sure we have suitable defaults to > allow running at least the drives/paths control panel without registry > files at all. We also need the Wine dlls to register themselves > instead of having to merge winedefault.reg by hand. Then it should be > possible to write a .inf script to setup a new Wine install > automatically from scratch. Once upon a time (well okay, in July) I said I would make the Wine dlls self-registerable, and now I've gone and created bug #1117 to remind me to do it. I plan to use the (mostly-)static-array-driven, dumb but generic, regsvr_register and regsvr_unregister functions that are currently situated in dlls/comcat. I don't like the idea of copying around exact duplicates of regsvr.[hc], but they seem too small to put in their own libwine_regsvr.so; what do you recommend?

1 0

Re: wine/dlls/rpcrt4 ndr_marshall.c
by Greg Turner Nov. 1, 2002

Nov. 1, 2002

On Thursday 31 October 2002 07:47 pm, Alexandre Julliard wrote: > Fix stupid clone of broken macro, found by Marcus. On Thursday 31 October 2002 07:17 pm, I wrote: > - fix stupid clone of broken macro, found by Alexandre. sheesh! I can't even get the fixer's fixed. oh well :( Like I said in the patch subject, I suck... -- gmt "The purpose of government is to rein in the rights of the people" --President Bill Clinton, MTV interview, 1993

1 0

Re: I suck...
by Alexandre Julliard Nov. 1, 2002

Nov. 1, 2002

Greg Turner <gmturner007(a)ameritech.net> writes: > Thanks for catching the first, Alexandre, or > I wouldn't have caught this second... Actually I didn't catch anything, the first one was fixed by Marcus. -- Alexandre Julliard julliard(a)winehq.com

1 0

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