- wine-devel - winehq.org

RE: Wine 0.8 TODO v0.1
by Patrik Stridvall 01 Nov '02

01 Nov '02

> Oh, one other thing that would be nice, while I think of > it... is there > any reason (now we are GPL'ed) that we cannot incorperate cabextract > (http://www.kyz.uklinux.net/cabextract.php3) into Wine? Because we are not GPL:ed. We are LGPL:ed. Application that go under programs/ might as an exception go under GPL. However in the case of cabextract we need substantial parts of it to implement functions like SetupIterateCabinet in SETUPAPI.DLL so only the LGPL or less restrictive is acceptable. However the author(s) of cabextract might agree to release the parts we need under the LGPL. Perhaps it better if he release it all under the GPL since we might want to implement the CAB SDK tools like cabarc.exe that is supposed to do almost exactly what cabextract does (and possibly more) AFAICS. What don't you ask him? > Currently we shell out to it as an external program, Do we? Hmm. OK, it seems we do in dlls/urlmon/umon.c. Ugly. That code should probably call SetupIterateCabinet instead. Of course that function is not implemented yet. See above. > in order to run > Microsoft's setup APIs ecetra. This is really annoying for > new users, as > unless they look closely at pages of logs... theres no real indication > that's why installation of a Microsoft program failed. True.

1 0

Tucows top-100 applications :)
by Carlos Lozano 01 Nov '02

01 Nov '02

Hello, It is today top 100 tucows list. I think that it shouldn't be the better wine top 100 list, some entries should be removed, and some new added. (For example some cdrecord program). Regards, Carlos. -- ___ _ \ | / Infraestructuras | . |._ _ _| | ___ ___ ___ http://www.andago.com | || ' |/ . |<_> |/ . |/ . \__ GNU/Linux |_|_||_|_|\___|<___|\_. |\___/ _ \ __|\ \ / Carlos A. Lozano <___'/ | \ -_) __/\__ \ > < -_) [ carlos.lozano(a)andago.com ]\___|_| ____/ _/\_\___| [ calb(a)epsxe.com ] http://www.epsxe.com

2 1

What is a leap second
by György 'Nog' Jeney 01 Nov '02

01 Nov '02

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

Status of libwine MFC and msvcrt compilation
by Uwe Bonnes 01 Nov '02

01 Nov '02

Hallo, what is the status of winelib compilation of MFC and msvcrt? Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

Versions & mass-appeal
by Dimitrie O. Paun 01 Nov '02

01 Nov '02

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 01 Nov '02

01 Nov '02

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 01 Nov '02

01 Nov '02

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 01 Nov '02

01 Nov '02

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

Re: Treeview notifications
by Dustin Navea 01 Nov '02

01 Nov '02

--- "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. > Another sidenote... in TREEVIEW_NotifyFormat shouldnt (lParam == NF_REQUERY) be (lParam == NF_QUERY) and change the corresponding line in TREEVIEW_Create since that is the original query? I have already searched throughout the sources and the only place that TREEVIEW_NotifyFormat is called is in treeview.c in TREEVIEW_Create ... -Dustin __________________________________________________ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/

2 1

Re: I suck...
by Dimitrie O. Paun 01 Nov '02

01 Nov '02

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 01 Nov '02

01 Nov '02

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 01 Nov '02

01 Nov '02

> 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 01 Nov '02

01 Nov '02

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 01 Nov '02

01 Nov '02

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 31 Oct '02

31 Oct '02

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@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@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 31 Oct '02

31 Oct '02

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 31 Oct '02

31 Oct '02

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 31 Oct '02

31 Oct '02

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 31 Oct '02

31 Oct '02

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 31 Oct '02

31 Oct '02

> 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 31 Oct '02

31 Oct '02

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 31 Oct '02

31 Oct '02

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 31 Oct '02

31 Oct '02

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 31 Oct '02

31 Oct '02

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 31 Oct '02

31 Oct '02

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 31 Oct '02

31 Oct '02

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

RE: winapi_check question...
by Patrik Stridvall 31 Oct '02

31 Oct '02

> 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. > rpc_epmap.c:56: rpcrt4: RPC_STATUS WINAPI > RpcEpRegisterA(RPC_IF_HANDLE,PRPC_BINDING_VECTOR,PUUID_VECTOR,LPSTR): > no translation defined: PRPC_BINDING_VECTOR This is because winapi_check doesn't know the type of PRPC_BINDING_VECTOR. One day I will teach it to parse the header files properly. Until then tell it what type it is in the the file tools/winapi/win32.api: %%rpcrt4 ... %ptr ... PRPC_BINDING_VECTOR ... Since PRPC_BINDING_VECTOR is presumable a pointer it goes under the ptr section. > rpc_epmap.c:56: rpcrt4: RPC_STATUS WINAPI > RpcEpRegisterA(RPC_IF_HANDLE,PRPC_BINDING_VECTOR,PUUID_VECTOR,LPSTR): > no translation defined: PUUID_VECTOR Same as above. > rpc_epmap.c:102: rpcrt4: RPC_STATUS WINAPI > RpcEpUnregister(RPC_IF_HANDLE,PRPC_BINDING_VECTOR,PUUID_VECTOR): > argument 2 type is forbidden: PRPC_BINDING_VECTOR (unknown) Same as above. > how shall I deal with these? Fix them as above or do as everybody elses do wait for me to fix it. :-)

2 1

Re: dlls/msvcrt/tests: printf
by Uwe Bonnes 31 Oct '02

31 Oct '02

>>>>> "Jaco" == Jaco Greeff <jaco(a)puxedo.org> writes: 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. And plain inlined patches are preferred against attachments. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Re: Re: So lets say we do it
by chrismorgan＠rcn.com 31 Oct '02

31 Oct '02

> > From: Alexandre Julliard <julliard(a)winehq.com> > Date: 2002/10/31 Thu AM 11:24:28 EST > To: dpaun(a)rogers.com > CC: Wine Devel <wine-devel(a)winehq.com> > Subject: Re: So lets say we do it > > "Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > > > So the 5% left, install wine, install a Win-app, and play around. > > Great, it works! > > You forgot a few things here: > > First it doesn't even start because they don't have a config file. OK, > they copy one from somewhere, it doesn't work because the drives are > wrong. Then they don't have the proper registry (winedefault.reg? > what's that?) I was going to reply yesterday on this issue. I help a fair amount of people on irc that have config problems and there are a few things we should probably do to fix this. 1. Check the wine config on startup. If the config is missing or incorrect then launch a gui config app to fix things. It would be best if this tool had two user options, one for an Automatic setup and another for an Expert setup. We do a good job with wineinstall so I don't have much doubt that we could automate the config and satisfy 80%+ of users. 2. Make it easier for users to modify their configs via a gui tool. 3. Straighten out how packages(RPM, deb, etc) setup wine's config. I'm not even sure how this is done right now and LOTS of people come asking for help saying they have installed an RPM version of wine but don't know how to configure it. This might be completely solved by #1. Chris

1 0

Re: Re: So lets say we do it
by chrismorgan＠rcn.com 31 Oct '02

31 Oct '02

> > 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. > > Sorry to say that, but in this mail, *you* were talking *some* crap IMHO > ;-) > > We *do* have screenshots. The About page has some pretty nice screenshot. > OK, it's a minimalist approach, granted, but it does show IE etc. > I'd also like to second the opinion that we should have a dedicated "Screenshot" entry right off of the main page. I do the same stuff that Dimitrie does, go to a project, look at some text briefly and then immediately want to see what the app looks like when it is working. So maybe leave the screenshot link off of the "About" page but also put a link on the main page. Chris

1 0

RPC test code?
by Greg Turner 31 Oct '02

31 Oct '02

OK, wine made it's first successful RPC's on my box today (yay!) Now, it's time to do a smidgen of housekeeping, and whip up a test. This is a bit tricky, I have a few open questions, which I will enumerate: 1) It feels like cheating to use the same process as client /and/ server. OTOH, it will be a bit cleaner to do it as such... any thoughts on this? specifically, 1a) Will wedging what is basically a winelib app into my test directory create a problem in the configure/make system? Is there a clean way to make sure I invoke the right winelib .exe.so file (the one in my test directory)? 1b) Are all the process-control API's I will need for this in place? (in particular I should kill off the server in case of a failure... will this be a problem? I guess probably not, or else I'd see a lot more wine's hanging around in my process table.) 1c) If the test fails in the winelib thingy, I have to propagate this back to the test; but relying on RPC for this (aside from being unimplemented ATM) is a catch-22, since error propagation might be broken (hence the need for a test)... I guess I can think of creative solutions to this like putting stupid temp files somewhere. Any better ideas? 1d) Anyone know of a problem with this I haven't thought of yet? 2) Whether I use threads or processes, I need some coordination to happen; I am very concerned about race conditions. I want my tests to run under the most absurd and grueling conditions, with NO race conditions. But I can't wrap my mind around how to avoid them ATM. For example: 2a) Should the rpc.c "real" test be the client or the server? I can imagine races either way. Let's say rpc.c is the client. This isn't so bad at a glance; I invoke the server thread/process, and poll RPC from time to time until it goes active (how I do this is another issue, but I'll think of something). Now I do my magic, and request a shutdown via RPC to the server... but, in two cases there is technically a race: first, while I'm invoking the server, I have to wait for it to start as discussed; second, after I send the Shutdown RPC to the server, I have to actually wait for the process/thread to terminate. In both cases, how long is long enough? What if the tests are running on some absurdly bogged down machine that's simultaneously compiling a matrix of 10,000 different wine's, for example? On the other hand, if I use some really liberal timeout like 30 minutes, then in a failure condition, my test would appear to hang, this isn't so great either. If rpc.c is the server, similar problems exist. 2b-?) uh, I guess I squeezed all of these questions into 2a. 3) MIDL? I still haven't figured out the legal ramifications of using midl-generated code. I'd rather not spend a month working on widl before generating a test... so do I need to code my stubs by hand? Even if I do, they're gonna come out looking more-or-less just like MIDL code... maybe I need to figure out the licensing restrictions on MIDL-generated code myself, but does anyone know offhand, I didn't see any obvious discussion of this on microsoft.com or in the platform sdk. ugh. thanks for taking the time to read this long-winded post. Any responses, assistance, flames, etc. are appreciated. -- gmt "The purpose of government is to rein in the rights of the people" --President Bill Clinton, MTV interview, 1993

4 6

Re: SetWindowHookEx
by steve.lustbader＠philips.com 31 Oct '02

31 Oct '02

This patch fixed it. Could you change the fixme message in user/hook.c to something more explicit than "won't work right," or at least include a comment in the code explaining why it won't work right? -Steve steve.lustbader(a)philips.com writes: > It's returning NULL for me, which implies it isn't working. Is there some > sort of trace that I can send you to help you out? Oops you are right, this should fix it: Index: server/hook.c =================================================================== RCS file: /opt/cvs-commit/wine/server/hook.c,v retrieving revision 1.1 diff -u -r1.1 hook.c --- server/hook.c 29 Oct 2002 00:41:42 -0000 1.1 +++ server/hook.c 30 Oct 2002 19:51:20 -0000 @@ -227,7 +227,8 @@ set_error( STATUS_INVALID_PARAMETER ); return; } - if (!(thread = get_thread_from_id( req->tid ))) return; + if (!req->tid) thread = (struct thread *)grab_object( current ); + else if (!(thread = get_thread_from_id( req->tid ))) return; if ((hook = add_hook( thread, req->id - WH_MINHOOK ))) { -- Alexandre Julliard julliard(a)winehq.com

1 0

Adobe SVG viewer mouse tracing
by Mike Hearn 31 Oct '02

31 Oct '02

Hi, I have CrossOver beta 1.3 and have got IE6 installed and version 3 of the Adobe SVG viewer. The installer doesn't work, but I got around that problem, the issue I'm interested in solving now is that mouse interaction is messed up, namely that when the plugin receives a mousemove event, it appears to immediately receive another for 0,0 - this is just a theory I've got however. I'm wondering if there's a way to restrict debug logging to code in a particular file? I'm not interested in any mouse messages except those to the COM object in NPSVG3.dll thanks -mike

1 0

winapi_check question...
by Greg Turner 31 Oct '02

31 Oct '02

winapi_check tells me: ndr_stubless.c:86: rpcrt4: LONG_PTR WINAPIV NdrClientCall2(PMIDL_STUB_DESC,PFORMAT_STRING,...): argument 1 documentation: \ /* CLIENT_CALL_RETURN */ rpc_epmap.c:56: rpcrt4: RPC_STATUS WINAPI RpcEpRegisterA(RPC_IF_HANDLE,PRPC_BINDING_VECTOR,PUUID_VECTOR,LPSTR): no translation defined: PRPC_BINDING_VECTOR rpc_epmap.c:56: rpcrt4: RPC_STATUS WINAPI RpcEpRegisterA(RPC_IF_HANDLE,PRPC_BINDING_VECTOR,PUUID_VECTOR,LPSTR): no translation defined: PUUID_VECTOR rpc_epmap.c:102: rpcrt4: RPC_STATUS WINAPI RpcEpUnregister(RPC_IF_HANDLE,PRPC_BINDING_VECTOR,PUUID_VECTOR): argument 2 type is forbidden: PRPC_BINDING_VECTOR (unknown) how shall I deal with these? -- gmt "The purpose of government is to rein in the rights of the people" --President Bill Clinton, MTV interview, 1993

1 0

Re: miscemu/wine gets into the way in map_image
by Uwe Bonnes 31 Oct '02

31 Oct '02

>>>>> "Alexandre" == Alexandre Julliard <julliard(a)winehq.com> writes: Alexandre> Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: >> However when unzip has unpacked the 160 MByte file and the Setup >> should start, a crash happens, and the debugger startup stops with >> "Memory exhausted". The same happens when I run in winedbg: Loaded >> debug information from ELF >> '/home/bon/tmp/wine/compile/wine/miscemu/wine' (0x00000000) >> Breakpoint 2 at 0x4000c714 (_end+0xf7fec) Memory exhausted. Alexandre> You probably need reduce the base address a bit to leave more Alexandre> space for malloc(). Try changing the 0x3ff to 0x3f0. Now of Alexandre> course we shouldn't be using malloc, so that hack would be a Alexandre> good way to enforce that <g> Alexandre, could we get this into the wine tree? At least one person stumled across that with the same application I had. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

EMF bug
by doome 31 Oct '02

31 Oct '02

Hi! I am not sure if this is a bug, or I did something wrong. My collegaues made a little program what shows the bug. It shows an EMF file, but the text boxes appears bad. Two screenshots and the source are included in the tar.gz. Please somebody examine it, and help me if you can. The source, binaries, and screenshots can be downloaded from ftp://ftp.uhulinux.hu/misc/testprg.tar.gz. It needs to be exctracted to the wine c:\ directory Thanks for your help in advance! If needed I can send you wine debug msgs. -- doome

4 3

richedit
by Michael Stefaniuc 31 Oct '02

31 Oct '02

Hello, is somebody working on the richedit dll? I encountered 3 unknown RTF control words and wanted to add them but I got scared by the overzealous use of #define's in rtf.h . My first impuls was exchange that with some enum's, but i thought i better ask here before i do the work in vain. 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

3 3

Is it me or is "winedbg --debugmsg -all" not honored
by Uwe Bonnes 30 Oct '02

30 Oct '02

Hallo, did I miss something or is it me or is the registry entry ( as advertised in winedefaults.reg) [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AeDebug] "Debugger"="winedbg --debugmsg -all %ld %ld" not honored any more ( since some time). The relay log is cluttered with about 150k lines of debugger start relay output :-( Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

Re: rpc_H_PL1
by Alexandre Julliard 30 Oct '02

30 Oct '02

Greg Turner <gmturner007(a)ameritech.net> writes: > diff -ur -x CVS -x 'bigdif*' ../wine.test/dlls/rpcrt4/rpc_binding.c ./dlls/rpcrt4/rpc_binding.c > --- ../wine.test/dlls/rpcrt4/rpc_binding.c 2002-10-29 12:59:02.000000000 -0600 > +++ ./dlls/rpcrt4/rpc_binding.c 2002-10-29 13:28:39.000000000 -0600 > @@ -865,14 +865,21 @@ > * Exists in win9x and winNT, but with different number of arguments > * (9x version has 3 arguments, NT has 2). > */ > +#ifdef WINNT > +RPC_STATUS WINAPI I_RpcBindingSetAsync( RPC_BINDING_HANDLE Binding, RPC_BLOCKING_FN BlockingFn) > +#else > RPC_STATUS WINAPI I_RpcBindingSetAsync( RPC_BINDING_HANDLE Binding, RPC_BLOCKING_FN BlockingFn, unsigned long ServerTid ) > +#endif > { This can't work, we are not going to build two versions of Wine with different #ifdefs. We should simply decide which version we support (NT would probably be preferable) and get rid of the #ifdefs in the header. -- Alexandre Julliard julliard(a)winehq.com

2 1

No more Office 11 for Win98/ME
by Uwe Bonnes 30 Oct '02

30 Oct '02

Hallo, e.g. on www.heise.de there is the news that MS announces to drop support for Win98/ME for the next office version. That's probably a point in time when many people will look for alternatives. Hopefully Wine and Linux are in good shape then. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Re: Versions & mass-appeal
by Francois Gouget 30 Oct '02

30 Oct '02

On Wed, 30 Oct 2002, Keith Matthews wrote: [...] > Stressing the number of calls in the MS API is another important point > to make, thanks to Andreas for providing an updated figure. For more API stats you can check out the following page (and disclaimer): http://fgouget.free.fr/wine/winapi_stats-en.shtml While I'm writing I will just mention some other links relevant to the 'Wine perception' aspect: * Contributing to Wine Trying to present ways to get started helping Wine. More work is needed on this section and it needs to be made much more visible. http://www.winehq.com/about/index.php?contrib * Why Wine is so important Many people have a primitive 'say no to Windows software' attitude because they do not understand why Wine is important. http://www.winehq.com/about/index.php?why * Debunking Wine Myths These myths are quite common and detract to Wine's image http://www.winehq.com/about/index.php?myths Here's my thoughts on getting more developpers: * I think step one is fixing Wine's perception issues by improving the Web site to make the above more visible, add screenshots and make it easier to navigate. * Step two is to add more resources geared towards new developpers to make it easier for them to get started (e.g. taslets bug list, finish the conformance testing guide, update the developer's guide, etc.). * Step three is to be more outgoing. Do a better job at describing the tasks that need to be done for instance. Let people know that we need help, that with done much with less than one tenth the number of developpers that the Linux kernel has. Someone suggested making Wine presentations at local LUGs. I think that's a goog idea too. I have done some work on the above items (all committed) but I'm not a technical writer so it takes me a lot of time to write documentation and I'm rarely happy with the result. And free time is in very short supply currently. Plus I'm not familiar with PHP which would be required for some of the Web site changes (again a time issue). So please, if anyone feels like updating the web site or writing documentation, go ahead. Wine needs you! -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ $live{free} || die "";

1 0

Re: splitting msvideo/msvfw32
by Alexandre Julliard 30 Oct '02

30 Oct '02

Eric Pouech <eric.pouech(a)wanadoo.fr> writes: > + case DLL_PROCESS_ATTACH: > + if (!GetModuleHandleA("MSVFW32.DLL") && !LoadLibraryA("MSVFW32.DLL")) > + { > + ERR("Could not load sibling MSVfW32.dll\n"); > + return FALSE; > + } Note that this is not necessary. The 32-bit dll is always loaded before the 16-bit one (otherwise we couldn't reference symbols in it). -- Alexandre Julliard julliard(a)winehq.com

1 0

Treeview Notifications Fix (found cause), now I need some help...
by Dustin Navea 30 Oct '02

30 Oct '02

Hey everyone, after about 3 hours of adding traces to treeview.c, I have found the line that is causing all of my headaches! in /wine/dlls/comctl32/treeview.c: in function TREEVIEW_NOTIFYFORMAT i = SendMessageA(GetParent (infoPtr->hwnd), WM_NOTIFYFORMAT, (WPARAM)infoPtr->hwnd, NF_QUERY); SendMessageA is returning 2 (NFR_UNICODE) on the StarCraft installer window. This is incorrect, the return should be 1 (NFR_ANSI). I don't know of any way to get it to return 1 myself as I dont know windows API, so I am asking for some help. can anyone that has some free time and knows the WM subsystem help me out? Please add yourself to CC on bug 1073. TIA -Dustin __________________________________________________ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/

2 2

Re: SetWindowHookEx
by steve.lustbader＠philips.com 30 Oct '02

30 Oct '02

>steve.lustbader(a)philips.com writes: > >> 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? > >I'm working on it. Basically it won't work right across processes at >this point; if you have a single process it should be OK. > It's returning NULL for me, which implies it isn't working. Is there some sort of trace that I can send you to help you out? -Steve

2 1

Re: What is a leap second
by Peter Ekberg 30 Oct '02

30 Oct '02

Hello! I compiled the following using msvc: ----------8<--------------------------- #include <stdio.h> #include <windows.h> typedef short CSHORT; typedef struct { CSHORT Year; CSHORT Month; CSHORT Day; CSHORT Hour; CSHORT Minute; CSHORT Second; CSHORT Milliseconds; CSHORT Weekday; } TIME_FIELDS, *PTIME_FIELDS; typedef VOID (*RtlTimeToTimeFieldsT) (PLARGE_INTEGER Time, PTIME_FIELDS TimeFields); int main() { LARGE_INTEGER RtlTime; TIME_FIELDS tf; HINSTANCE hLib; RtlTimeToTimeFieldsT RtlTimeToTimeFields; RtlTime.LowPart = 0x20de5700; RtlTime.HighPart = 0x1c27d90; hLib = LoadLibrary("ntdll"); RtlTimeToTimeFields = (RtlTimeToTimeFieldsT)GetProcAddress (hLib, "RtlTimeToTimeFields"); RtlTimeToTimeFields(&RtlTime, &tf); FreeLibrary(hLib); printf("%d %d %d %d %d %d\n", tf.Year, tf.Month, tf.Day, tf.Hour, tf.Minute, tf.Second); return 0; } ----------8<--------------------------- with the following output on win2k. 9 0 10 0 9 10

2 2

listview: last column problem
by Rein Klazes 30 Oct '02

30 Oct '02

Dimitri, The missing last column in newsbin seems to be caused by this line: | if (!lpColumn || nColumn < 0 || nColumn > infoPtr->hdpaColumns->nItemCount) return -1; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ removing the marked part of the test result in a couple of error messages: | err:listview:LISTVIEW_InsertColumnT nColumn=4, nNewColumn=3 | err:listview:LISTVIEW_InsertColumnT nColumn=4, nNewColumn=3 | err:listview:LISTVIEW_InsertColumnT nColumn=4, nNewColumn=3 but otherwise runs fine. Do you see any objections removing the test and error message? Rein. -- Rein Klazes rklazes(a)xs4all.nl

2 2

Re: PATCH: ppc fix 2
by Greg Turner 30 Oct '02

30 Oct '02

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 > > /* oh, it's non-i386 only, and I guess I never tested this one... makes sense now, ignore my previous comment. -- gmt "The purpose of government is to rein in the rights of the people" --President Bill Clinton, MTV interview, 1993

1 0

EMF bug?
by Domsodi Gergely 30 Oct '02

30 Oct '02

Hi! I am not sure if this is a bug, or I did something wrong. My collegaues made a little program what shows the bug. It shows an EMF file, but the text boxes appears bad. Two screenshots and the source are included in the tar.gz. Please somebody examine it, and help me if you can. The source, binaries, and screenshots can be downloaded from ftp://ftp.uhulinux.hu/misc/testprg.tar.gz. It needs to be exctracted to the wine c:\ directory Thanks for your help in advance! If needed I can send you wine debug msgs. -- doome _______________________________________________ wine-users mailing list wine-users(a)winehq.com http://www.winehq.com/mailman/listinfo/wine-users -- Dömsödi Gergely UHU-Linux Csapat

1 0

RE: winapi update
by Patrik Stridvall 30 Oct '02

30 Oct '02

> On October 29, 2002 11:27 am, Patrik Stridvall wrote: > > Anyway, I can't inline my patches the because Microsoft > Outlook wraps > > the lines and I sure a lot of other people that use attachments have > > similar problems. > > And can't be turned off?!? Hmmm, anyway, just attach them as > text/plain. I have no idea how or if it is possible to do either.

4 3

What is a leap second
by György 'Nog' Jeney 30 Oct '02

30 Oct '02

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 this mean? nog.

4 6

DSTRICT: some more fixes for the user dll
by Michael Stefaniuc 29 Oct '02

29 Oct '02

Hello, this fixes 117 warning in the user dll when compiled with -DSTRICT License: LGPL, X11 Changelog: Michael Stefaniuc <mstefani(a)redhat.com> - some more fixes for compiling the user dll with -DSTRICT 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

1 1

RE: What is a leap second
by Medland, Bill 29 Oct '02

29 Oct '02

> -----Original Message----- > From: wine-devel-admin(a)winehq.com > [mailto:wine-devel-admin@winehq.com]On > Behalf Of György 'Nog' Jeney > Sent: Tuesday, October 29, 2002 10:46 AM > To: wine-devel(a)winehq.com > Subject: What is a leap second > > > > 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 this mean? > > nog. > > > > (Trying to avoid repeating everyone else) The best source I know for information on leap seconds is http://tycho.usno.navy.mil/leapsec.html That includes a link to the list of when the leap seconds have been. I was also looking at "time" over the past couple of days, from the "GetDateFormat" side of things (files/dos_fs.c). I note that (Win98) SystemTimeToFileTime etc do not include any leap seconds (i.e. file time assumes no leap seconds). Bill

1 0

rpc_H_PL3 (do not apply)
by Greg Turner 29 Oct '02

29 Oct '02

This fixes wineserver crashes exposed by recent tests, in the unmerged parts of the RPC code. Parts of this may never see the light of day. Relative to H_PL0, of course. LICENSE: X11 CHANGELOG: * dlls/rpcrt4: rpc_epmap.c; server: rpc_epmap.c: Greg Turner <gmturner007(a)ameritech.net> - don't crash the wineserver. - don't printf("%s", NULL). -- gmt "The purpose of government is to rein in the rights of the people" --President Bill Clinton, MTV interview, 1993

1 0

Re: Bug #321: dlls/msvct/vf[w]printf functions (Patch 2)
by Shachar Shemesh 29 Oct '02

29 Oct '02

Jaco Greeff wrote: >On Tue, 29 Oct 2002 21:10:52 +0100, Andreas Mohr ><andi(a)rhlx01.fht-esslingen.de> wrote : > > >>[insert some rant about certain highly non-rewarding functions here...] >> >>Still, you're doing some pretty essential work, so let me just say thanks >>for your (annoying ?) work ! >> >> > >Annoying? Sometimes. Boring? Never. I'm enjoying every minute of it, as long >as I don't get to frustrate myself with idiotic mistakes. (Of which I've had >a couple in the last week, the last one just took the prize :)) > I don't know. My personal best is to spend two weeks chasing a one wrong character bug. What's more, it was introduced after adding ~20 lines of code, and I knew it. Beat that! To my credit I will say that this was assembly (68000), and that the problem manifested itself in such an unrelated area of the program, that I overruled my own judgment and searched the problem in the vicinity of where it happened. As life would have it, the real problem was a missing "#" (which means "use immediate value X", so instead it read "Take value from address X"). > O, well, >maybe I just need some extra sleep. > >Thanks a lot, encouragement is always appreciated. > > > >

1 0

Bug in SYSDEPS_CallOnStack()?
by Juraj Hercek 29 Oct '02

29 Oct '02

Hi, When I was trying to get wine working on sparc solaris, I experienced troubles with exception handling. I always got error (after Ctrl + C): err:seh:EXC_DefaultHandling Exception frame is not in stack limits => unable to dispatch exception. After deeper insight into wine's guts I've figured out that problem lies in SYSDEPS_CallOnStack function (scheduler/sysdeps.c:236), which doesn't switch thread stack on sparcs -> I'll try to implement this soon. I also looked at implementation of this function for __i386__ (since it was just a couple of lines above... :o) ) and I think there is a mistake in implementation for _MSC_VER compiler. Original: ... __asm mov edx, 8[esp]; __asm mov fs:[0x04], esp; <--- __asm push edx; ... I think it should look like this: ... __asm mov edx, 8[esp]; __asm mov esp, fs:[0x04]; <--- __asm push edx; ... Just some questions: Is anyone compiling wine with microsoft compiler? If so, what are the reasons? Next, current snapshot from cvs doesn't compile on solaris, is anyone compiling wine on solaris? Regards, Juraj

4 3

Re: dlls/advapi32/RegFlushKey (Patch 2)
by Jaco Greeff 29 Oct '02

29 Oct '02

On 29 Oct 2002 12:38:10 -0800, Alexandre Julliard <julliard(a)winehq.com> wrote : > I'm afraid this can't possibly work. Registry keys don't have an > associated file descriptor. Bingo. That was my understanding as well, until I looked at the RegCloseKey and was thrown totally off-track: /* RegCloseKey */ ... return RtlNtStatusToDosError( NtClose( hkey ) ); which translates more or less to: /* NtClose */ ... SERVER_START_REQ( close_handle ) { req->handle = Handle; ret = wine_server_call( req ); if (!ret && reply->fd != -1) close( reply->fd ); } SERVER_END_REQ; ... Basically leading to the belief that there is actually an fd. (Ignoring the fact that we need to keep things general) Which, looking at the arch doesn't make much sense... lots of little files would do nobody good. Next time I'll ask before I'm lead to believe what I shouldn't. Greetings, Jaco

1 0

Re: dlls/advapi32/RegFlushKey (Patch 2)
by Alexandre Julliard 29 Oct '02

29 Oct '02

"Jaco Greeff" <jaco(a)puxedo.org> writes: > * dlls/advapi32/registry.c: Jaco Greeff <jaco(a)puxedo.org> > - Implemented the RegFlushKey function I'm afraid this can't possibly work. Registry keys don't have an associated file descriptor. -- Alexandre Julliard julliard(a)winehq.com

1 0

RE: winapi update
by Patrik Stridvall 29 Oct '02

29 Oct '02

I run the swedish version... > You can change the number of the line wrapping. Tools -> > Options -> Mail > Formating -> ... but I'm with you here. > Internet Format -> Plain Text Options. No, I have no such option. I run Microsoft Outlook 2000...

3 2

RE: winapi update
by Rolf Kalbermatter 29 Oct '02

29 Oct '02

From: Patrik Stridvall <ps(a)leissner.se> >> You can change the number of the line wrapping. Tools -> >> Options -> Mail >> Formating -> > >... but I'm with you here. > >> Internet Format -> Plain Text Options. > >No, I have no such option. > >I run Microsoft Outlook 2000... Try "Tools -> Options -> Mail Format. Select "Plain Text" in the "Message Format" and click the "Settings" button. Rolf Kalbermatter CIT Engineering Nederland BV tel: +31 (070) 415 9190 Treubstraat 7H fax: +31 (070) 415 9191 2288 EG Rijswijk http://www.citengineering.com Netherlands mailto:rolf.kalbermatter@citeng.com

1 0

Re: Bug #321: dlls/msvct/vf[w]printf functions (Patch 2)
by Jaco Greeff 29 Oct '02

29 Oct '02

On 29 Oct 2002 10:53:32 -0800, Alexandre Julliard <julliard(a)winehq.com> wrote : > Still, this only works for vfprintf, vfwprintf > has to output in Unicode so you cannot convert to ASCII or use the > system printf for that. It would probably be easier to grab a printf > implementation from somewhere and convert it to Unicode. Can I swear on this mailing list? Please, I need to. And one would think I've never used the vfwprintf function before the way I'm making all these wrong assumptions. Damnit, I know the Win32 API. *sigh* Luckily my wife got most of the frustrations at my stupidity... On your suggestion: I've looked at the glibc one. No comments. I'll refrain and look a bit more... I do feel that we are making progress however, albeit slowly ;) Do you think it a good idea just doing the ASCII version now and get it into CVS without the W version. (Ripping out the vfwprintf for now.) I can then proceed to make this ASCII implementation into a full "real-prntf" implementation and subsequently, when we are all happy do the Unicode conversion. Basically I'm suggesting breaking it up into small(er) steps. Comments? Greetings, Jaco

2 1

Wineconsole feature request
by György 'Nog' Jeney 29 Oct '02

29 Oct '02

Would it be possible for someone to add a feature to wineconsole so that when the child process exits the console isnt torn down immediatly? This would be very nice because some dos apps dont work when not run through the console and so it is impossible to see their command line syntax. nog.

2 1

Re: Bug #321: dlls/msvct/vf[w]printf functions (Patch 2)
by Alexandre Julliard 29 Oct '02

29 Oct '02

"Jaco Greeff" <jaco(a)puxedo.org> writes: > I'm not sure if I should send the whole patch or just do increments for the > new stuff. At this point it is everything, including cleanups of the test > case and use of correct WideCharToMultiByte as suggested by Dimitri. In > additions the configure.ac patch for the dlls/msvcrt/tests/Makefile.in is added. > > As always, comments are very welcome to get this thing bedded down finally. - you can't use the libc printf to print unicode chars, the format is not the same - WideCharToMultiByte can output several characters for a single unicode char, you need to take that into account for buffer sizes - you cannot cast a WCHAR* into a CHAR* to convert the format to ASCII - there's no point in using strncat if you don't pass it the real size of the buffer - please don't copy code from MSDN, it is copyrighted by Microsoft. -- Alexandre Julliard julliard(a)winehq.com

3 4

RE: winapi update
by Patrik Stridvall 29 Oct '02

29 Oct '02

> > Why not, instead of complaining to people who doesn't > > (or only partly) listens, write some sort of mail "filter" > > the reformats the mail to one or more mail of a more > > appropriate format. Inline attachments and that sort of things... > > Oh, come on man, this _is_ silly. You are the only one sending > multiple patches per email, for crying out loud! :) Perhaps. Haven't checked. Anyway, I can't inline my patches the because Microsoft Outlook wraps the lines and I sure a lot of other people that use attachments have similar problems. So an attachment inliner might be useful nether the less...

2 1

Known listview bugs (take 2)
by Dimitrie O. Paun 29 Oct '02

29 Oct '02

Folks, After my latest X-series patches (currently at X6), I am aware of the following listview bugs: Yes, you read correctly: NONE. :) So I ask you for one of two things: -- bug reports or -- success stories Otherwise, I'm gonna declare listview the coolest, nicest, most huggable piece of code out there <g>. -- Dimi.

8 34

recent ListView problems
by post＠maikschulz.de 29 Oct '02

29 Oct '02

Hi, I'm using WinMX (www.winmx.com) rather frequently, currently version 3.30. Some two weeks ago, Wine HEAD displayed the ListView components from the search and transfer tabs perfectly, now the refresh/redrawing is messed up. The application documented the changes ListView has undergone in the recent months quite well, though (I'm updating Wine from CVS almost every day). Congratulations for implementing that rather complex control (almost) perfectly! Take care, -Maik

2 1

more desperate cries for help...
by Greg Turner 29 Oct '02

29 Oct '02

o I don't yet know how to properly raise and catch exceptions in wine. I see some examples, but I don't see any of try/finally, of which I am a big fan and would probably like to use. Is there a guide somewhere on how to do these things? o If we want MIDL generated code to compile in winelib, we are going to have to implement the RpcTryExcept and RpcTryFinally macros. I think I heard somewhere that, these are somewhat mysterious macros, i.e., their implementation is based on compiler magic instead of normal header files... how on earth shall we deal with that? I tried grepping the psdk header files and they map to __try, __except, __finally, and so on.... does wine have those? Thanks again for any assistance, -- gmt "The purpose of government is to rein in the rights of the people" --President Bill Clinton, MTV interview, 1993

3 5

RE: winapi update
by Patrik Stridvall 29 Oct '02

29 Oct '02

> On October 29, 2002 09:32 am, Patrik Stridvall wrote: > > *** winapi_check > > > > * tools/winapi/win16.api, > > tools/winapi/win32.api: > > API file update. > > > > *** winapi_checked > > Patrik, please send different patches in different emails. I try to do that more and more. However in this case there are some logical relation between the patches. Every issue winapi_check reports results in either a patch to winapi_check (winapi_check.diff) or a patch to some source file (winapi_checked.diff). So if you wish to find any possible misstake I might have done your really should read both. OK, this time they might be not so useful to read both since they are almost 100% percent independant but that is not always when I do the winapi_check update. > See past discussions for rationale. I remember. :-) Speaking of which: Why not, instead of complaining to people who doesn't (or only partly) listens, write some sort of mail "filter" the reformats the mail to one or more mail of a more appropriate format. Inline attachments and that sort of things... Then we could have a wine-patches-filtered mailing list for people that like the patches in a specific format.

2 1

Re: 16-bit shell seperation
by Alexandre Julliard 29 Oct '02

29 Oct '02

"György 'Nog' Jeney" <nog(a)sdf.lonestar.org> writes: > ChangeLog: > * dlls/shell32/shell32_main.h > * dlls/shell32/shell.c > * dlls/shell32/shellreg.c > * dlls/shell32/Makefile.in > * dlls/shell32/shlexec.c > Seperate out 16-bit functions into seperate file. I have applied the registry stuff, but not ShellExecute16; this one will be need to be split properly so that the 32-bit version doesn't contain 16-bit stuff. -- Alexandre Julliard julliard(a)winehq.com

3 2

Re: winapi update
by Dimitrie O. Paun 29 Oct '02

29 Oct '02

On October 29, 2002 09:32 am, Patrik Stridvall wrote: > *** winapi_check > > * tools/winapi/win16.api, > tools/winapi/win32.api: > API file update. > > *** winapi_checked Patrik, please send different patches in different emails. See past discussions for rationale. -- Dimi.

1 0

RE: winsock + DSTRICT
by Patrik Stridvall 29 Oct '02

29 Oct '02

> Perhaps someone could check if SOCKET is really a 32bit type on 64bit > Windows. No it isn't. >From the latest SDK: typedef UINT_PTR SOCKET; A SOCKET is a pointer disguised as an integer and thus 64-bit on 64-bit platforms.

1 0

Re: more desperate cries for help...
by Dustin Navea 29 Oct '02

29 Oct '02

> --- Greg Turner <gmturner007(a)ameritech.net> wrote: > Beware of this one, It's long, and I've spliced > together at least two > (three?) posts, and probably quoted things > out-of-order... First off, everything seems in order to me... but thats just me... [-snip-] > to work, and may not get right? Why make getting > > it right harder by > > adding a lot of complexity, instead of adding > > infrastructure? > > good point, that seems like the logical way to > proceed. I totally agree here, we should always implement things and get them working properly before we get them working fast, or else we become like the evil empire ;) > Also: we could, indeed, implement wine-rpcss as you > mention. Since it's > not properly a "subsystem" in the MS sense of the > term, maybe it's > called "wine-epmap" but that's just semantics... > what you describe is > totally doable, and we could convert from some > low-level kludgy > implementation to an RPC-based implementation once > the necessary > marshalling was in place... I'll give this serious > thought. ok well if it is doable, i believe we should do it, why focus on the stuff that is _truely_ hard and that we may possibly not know jack shit about when we can get the _easier_ (not necessarily easy) stuff out of the way first, that will lead to a more solid codebase with which to work with. > Back to Ove: [snip] > heh, I know how that goes. Your insights, alone, > are helpful and > appreciated; get well, and we will collaborate on > this when you have > the time to devote to it. yes please, do get better soon, i may be coming down with something myself, my friend/roommate's ex may be the one that gave it to me too :( she is in the hospital now with an abcess on her tonsils, and i may have (somehow) gotten something from it, as I now have a sore throat... -Dustin P.S. nice quote Greg ;) __________________________________________________ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/

2 1

winsock + DSTRICT
by Martin Wilck 29 Oct '02

29 Oct '02

Hi Michael, all, here is a patch to make winsock compile without warnings without -DWINE_NO_STRICT. Comments are welcome. Martin PS Michael, will you send this stuff to wine-patches? Index: Makefile.in =================================================================== RCS file: /home/wine/wine/dlls/winsock/Makefile.in,v retrieving revision 1.18 diff -u -r1.18 Makefile.in --- Makefile.in 18 Oct 2002 23:46:28 -0000 1.18 +++ Makefile.in 28 Oct 2002 15:02:23 -0000 @@ -1,4 +1,4 @@ -EXTRADEFS = -DUSE_WS_PREFIX -DWINE_NO_STRICT +EXTRADEFS = -DUSE_WS_PREFIX TOPSRCDIR = @top_srcdir@ TOPOBJDIR = ../.. SRCDIR = @srcdir@ Index: async.c =================================================================== RCS file: /home/wine/wine/dlls/winsock/async.c,v retrieving revision 1.27 diff -u -r1.27 async.c --- async.c 17 Oct 2002 16:43:43 -0000 1.27 +++ async.c 28 Oct 2002 15:02:24 -0000 @@ -136,6 +136,10 @@ #define AQ_GETSERV 2 #define AQ_GETMASK 3 +/* The handles used are pseudo-handles that can be simply casted. */ +/* 16-bit values are used internally (to be sure handle comparison works right in 16-bit apps). */ +#define WSA_H32(h16) ((HANDLE)(ULONG_PTR)(h16)) + /* ----------------------------------- helper functions - */ static int list_size(char** l, int item_size) @@ -335,7 +339,7 @@ return size; } -static HANDLE __ws_async_handle = 0xdead; +static HANDLE16 __ws_async_handle = 0xdead; /* Generic async query struct. we use symbolic names for the different queries * for readability. @@ -486,7 +490,7 @@ } break; } - PostMessageA(HWND_32(aq->hWnd),aq->uMsg,aq->async_handle,size|(fail<<16)); + PostMessageA(HWND_32(aq->hWnd),aq->uMsg,(WPARAM) aq->async_handle,size|(fail<<16)); HeapFree(GetProcessHeap(),0,arg); return 0; } @@ -547,7 +551,8 @@ aq->ptr1 = ptr1; aq->int2 = int2; aq->ptr2 = ptr2; - aq->async_handle = ++__ws_async_handle; + /* avoid async_handle = 0 */ + aq->async_handle = (++__ws_async_handle ? __ws_async_handle : ++__ws_async_handle); aq->flags = flags; aq->sbuf = (SEGPTR)sbuf; aq->sbuflen = sbuflen; @@ -579,10 +584,10 @@ HANDLE WINAPI WSAAsyncGetHostByAddr(HWND hWnd, UINT uMsg, LPCSTR addr, INT len, INT type, LPSTR sbuf, INT buflen) { - TRACE("hwnd %04x, msg %04x, addr %08x[%i]\n", + TRACE("hwnd %p, msg %04x, addr %08x[%i]\n", hWnd, uMsg, (unsigned)addr , len ); - return __WSAsyncDBQuery(hWnd,uMsg,len,addr,type,NULL,sbuf,buflen, - AQ_NUMBER|AQ_COPYPTR1|AQ_WIN32|AQ_GETHOST); + return WSA_H32( __WSAsyncDBQuery(hWnd,uMsg,len,addr,type,NULL,sbuf,buflen, + AQ_NUMBER|AQ_COPYPTR1|AQ_WIN32|AQ_GETHOST)); } /*********************************************************************** @@ -604,10 +609,10 @@ HANDLE WINAPI WSAAsyncGetHostByName(HWND hWnd, UINT uMsg, LPCSTR name, LPSTR sbuf, INT buflen) { - TRACE("hwnd %04x, msg %08x, host %s, buffer %i\n", + TRACE("hwnd %p, msg %08x, host %s, buffer %i\n", hWnd, uMsg, (name)?name:"<null>", (int)buflen ); - return __WSAsyncDBQuery(hWnd,uMsg,0,name,0,NULL,sbuf,buflen, - AQ_NAME|AQ_DUPLOWPTR1|AQ_WIN32|AQ_GETHOST); + return WSA_H32( __WSAsyncDBQuery(hWnd,uMsg,0,name,0,NULL,sbuf,buflen, + AQ_NAME|AQ_DUPLOWPTR1|AQ_WIN32|AQ_GETHOST)); } /*********************************************************************** @@ -629,10 +634,10 @@ HANDLE WINAPI WSAAsyncGetProtoByName(HWND hWnd, UINT uMsg, LPCSTR name, LPSTR sbuf, INT buflen) { - TRACE("hwnd %04x, msg %08x, protocol %s\n", + TRACE("hwnd %p, msg %08x, protocol %s\n", hWnd, uMsg, (name)?name:"<null>" ); - return __WSAsyncDBQuery(hWnd,uMsg,0,name,0,NULL,sbuf,buflen, - AQ_NAME|AQ_DUPLOWPTR1|AQ_WIN32|AQ_GETPROTO); + return WSA_H32( __WSAsyncDBQuery(hWnd,uMsg,0,name,0,NULL,sbuf,buflen, + AQ_NAME|AQ_DUPLOWPTR1|AQ_WIN32|AQ_GETPROTO)); } @@ -654,9 +659,9 @@ HANDLE WINAPI WSAAsyncGetProtoByNumber(HWND hWnd, UINT uMsg, INT number, LPSTR sbuf, INT buflen) { - TRACE("hwnd %04x, msg %04x, num %i\n", hWnd, uMsg, number ); - return __WSAsyncDBQuery(hWnd,uMsg,number,NULL,0,NULL,sbuf,buflen, - AQ_GETPROTO|AQ_NUMBER|AQ_WIN32); + TRACE("hwnd %p, msg %04x, num %i\n", hWnd, uMsg, number ); + return WSA_H32( __WSAsyncDBQuery(hWnd,uMsg,number,NULL,0,NULL,sbuf,buflen, + AQ_GETPROTO|AQ_NUMBER|AQ_WIN32)); } /*********************************************************************** @@ -678,10 +683,10 @@ HANDLE WINAPI WSAAsyncGetServByName(HWND hWnd, UINT uMsg, LPCSTR name, LPCSTR proto, LPSTR sbuf, INT buflen) { - TRACE("hwnd %04x, msg %04x, name %s, proto %s\n", + TRACE("hwnd %p, msg %04x, name %s, proto %s\n", hWnd, uMsg, (name)?name:"<null>", (proto)?proto:"<null>"); - return __WSAsyncDBQuery(hWnd,uMsg,0,name,0,proto,sbuf,buflen, - AQ_GETSERV|AQ_NAME|AQ_DUPLOWPTR1|AQ_DUPLOWPTR2|AQ_WIN32); + return WSA_H32( __WSAsyncDBQuery(hWnd,uMsg,0,name,0,proto,sbuf,buflen, + AQ_GETSERV|AQ_NAME|AQ_DUPLOWPTR1|AQ_DUPLOWPTR2|AQ_WIN32)); } /*********************************************************************** @@ -703,10 +708,10 @@ HANDLE WINAPI WSAAsyncGetServByPort(HWND hWnd, UINT uMsg, INT port, LPCSTR proto, LPSTR sbuf, INT buflen) { - TRACE("hwnd %04x, msg %04x, port %i, proto %s\n", + TRACE("hwnd %p, msg %04x, port %i, proto %s\n", hWnd, uMsg, port, (proto)?proto:"<null>" ); - return __WSAsyncDBQuery(hWnd,uMsg,port,NULL,0,proto,sbuf,buflen, - AQ_GETSERV|AQ_NUMBER|AQ_DUPLOWPTR2|AQ_WIN32); + return WSA_H32( __WSAsyncDBQuery(hWnd,uMsg,port,NULL,0,proto,sbuf,buflen, + AQ_GETSERV|AQ_NUMBER|AQ_DUPLOWPTR2|AQ_WIN32)); } /*********************************************************************** @@ -714,7 +719,7 @@ */ INT WINAPI WSACancelAsyncRequest(HANDLE hAsyncTaskHandle) { - FIXME("(%08x),stub\n", hAsyncTaskHandle); + FIXME("(%p),stub\n", hAsyncTaskHandle); return 0; } @@ -723,7 +728,7 @@ */ INT16 WINAPI WSACancelAsyncRequest16(HANDLE16 hAsyncTaskHandle) { - return (HANDLE16)WSACancelAsyncRequest((HANDLE)hAsyncTaskHandle); + return (INT16)WSACancelAsyncRequest(WSA_H32 (hAsyncTaskHandle)); } /*********************************************************************** Index: socket.c =================================================================== RCS file: /home/wine/wine/dlls/winsock/socket.c,v retrieving revision 1.109 diff -u -r1.109 socket.c --- socket.c 17 Oct 2002 16:43:43 -0000 1.109 +++ socket.c 28 Oct 2002 15:02:24 -0000 @@ -26,6 +26,7 @@ #include "config.h" #include "wine/port.h" +#include <assert.h> #include <stdio.h> #include <string.h> #include <sys/types.h> @@ -131,6 +132,18 @@ inet_ntoa(((struct sockaddr_in *)a)->sin_addr), \ ntohs(((struct sockaddr_in *)a)->sin_port)) +/* HANDLE<->SOCKET conversion (SOCKET is u_int). */ +#define SOCKET2HANDLE(s) ((HANDLE)(ULONG_PTR)(s)) +#define HANDLE2SOCKET(h) ((SOCKET)(ULONG_PTR)(h)) +#define HANDLE2SOCKET_S(h) __handle2socket(h) + +inline static SOCKET __handle2socket (HANDLE h) +/* Sanity check (necessary if sizeof (HANDLE) > sizeof (SOCKET)) */ +{ + assert ( SOCKET2HANDLE ( HANDLE2SOCKET (h) ) == h ); + return HANDLE2SOCKET(h); +} + /**************************************************************** * Async IO declarations ****************************************************************/ @@ -314,14 +327,15 @@ { int fd; - if (set_error( wine_server_handle_to_fd( s, GENERIC_READ, &fd, NULL, NULL ) )) return -1; + if (set_error( wine_server_handle_to_fd( SOCKET2HANDLE(s), GENERIC_READ, &fd, NULL, NULL ) )) + return -1; return fd; } inline static int _get_sock_fd_type( SOCKET s, DWORD access, enum fd_type *type, int *flags ) { int fd; - if (set_error( wine_server_handle_to_fd( s, access, &fd, type, flags ) )) return -1; + if (set_error( wine_server_handle_to_fd( SOCKET2HANDLE(s), access, &fd, type, flags ) )) return -1; if ( ( (access & GENERIC_READ) && (*flags & FD_FLAG_RECV_SHUTDOWN ) ) || ( (access & GENERIC_WRITE) && (*flags & FD_FLAG_SEND_SHUTDOWN ) ) ) { @@ -332,8 +346,8 @@ return fd; } -static void _enable_event(SOCKET s, unsigned int event, - unsigned int sstate, unsigned int cstate) +static void _enable_event( HANDLE s, unsigned int event, + unsigned int sstate, unsigned int cstate ) { SERVER_START_REQ( enable_socket_event ) { @@ -351,7 +365,7 @@ int ret; SERVER_START_REQ( get_socket_event ) { - req->handle = s; + req->handle = SOCKET2HANDLE(s); req->service = FALSE; req->c_event = 0; wine_server_call( req ); @@ -366,7 +380,7 @@ unsigned int ret; SERVER_START_REQ( get_socket_event ) { - req->handle = s; + req->handle = SOCKET2HANDLE(s); req->service = FALSE; req->c_event = 0; wine_server_call( req ); @@ -389,7 +403,7 @@ SERVER_START_REQ( get_socket_event ) { - req->handle = s; + req->handle = SOCKET2HANDLE(s); req->service = FALSE; req->c_event = 0; wine_server_set_reply( req, events, sizeof(events) ); @@ -427,7 +441,7 @@ */ BOOL WINAPI WS_LibMain(HINSTANCE hInstDLL, DWORD fdwReason, LPVOID fImpLoad) { - TRACE("0x%x 0x%lx %p\n", hInstDLL, fdwReason, fImpLoad); + TRACE("%p 0x%lx %p\n", hInstDLL, fdwReason, fImpLoad); switch (fdwReason) { case DLL_PROCESS_ATTACH: opentype_tls_index = TlsAlloc(); @@ -1089,7 +1103,7 @@ } wsa->overlapped->InternalHigh = 0; - TRACE ( "wsa %p, ops %p, h %d, ev %d, fd %d, func %p, ov %p, uov %p, cfunc %p\n", + TRACE ( "wsa %p, ops %p, h %p, ev %p, fd %d, func %p, ov %p, uov %p, cfunc %p\n", wsa, wsa->async.ops, wsa->async.handle, wsa->async.event, wsa->async.fd, wsa->async.func, wsa->overlapped, wsa->user_overlapped, wsa->completion_func ); @@ -1196,7 +1210,7 @@ wsa->overlapped->Internal = STATUS_SUCCESS; wsa->overlapped->InternalHigh = result; TRACE ( "received %d bytes\n", result ); - _enable_event ( (SOCKET) wsa->async.handle, FD_READ, 0, 0 ); + _enable_event ( wsa->async.handle, FD_READ, 0, 0 ); return; } @@ -1204,7 +1218,7 @@ if ( err == WSAEINTR || err == WSAEWOULDBLOCK ) /* errno: EINTR / EAGAIN */ { wsa->overlapped->Internal = STATUS_PENDING; - _enable_event ( (SOCKET) wsa->async.handle, FD_READ, 0, 0 ); + _enable_event ( wsa->async.handle, FD_READ, 0, 0 ); TRACE ( "still pending\n" ); } else @@ -1288,7 +1302,7 @@ wsa->overlapped->Internal = STATUS_SUCCESS; wsa->overlapped->InternalHigh = result; TRACE ( "sent %d bytes\n", result ); - _enable_event ( (SOCKET) wsa->async.handle, FD_WRITE, 0, 0 ); + _enable_event ( wsa->async.handle, FD_WRITE, 0, 0 ); return; } @@ -1296,7 +1310,7 @@ if ( err == WSAEINTR ) { wsa->overlapped->Internal = STATUS_PENDING; - _enable_event ( (SOCKET) wsa->async.handle, FD_WRITE, 0, 0 ); + _enable_event ( wsa->async.handle, FD_WRITE, 0, 0 ); TRACE ( "still pending\n" ); } else @@ -1373,7 +1387,7 @@ goto out; } /* Try immediate completion */ - if ( WSAGetOverlappedResult ( (HANDLE) s, ovl, NULL, FALSE, NULL ) ) + if ( WSAGetOverlappedResult ( s, ovl, NULL, FALSE, NULL ) ) return 0; if ( (err = WSAGetLastError ()) == WSA_IO_INCOMPLETE ) return 0; @@ -1411,11 +1425,11 @@ close(fd); SERVER_START_REQ( accept_socket ) { - req->lhandle = s; + req->lhandle = SOCKET2HANDLE(s); req->access = GENERIC_READ|GENERIC_WRITE|SYNCHRONIZE; req->inherit = TRUE; set_error( wine_server_call( req ) ); - as = (SOCKET)reply->handle; + as = HANDLE2SOCKET_S( reply->handle ); } SERVER_END_REQ; if (as) @@ -1524,7 +1538,7 @@ int WINAPI WS_closesocket(SOCKET s) { TRACE("socket %08x\n", s); - if (CloseHandle(s)) return 0; + if (CloseHandle(SOCKET2HANDLE(s))) return 0; return SOCKET_ERROR; } @@ -1571,7 +1585,7 @@ if (errno == EINPROGRESS) { /* tell wineserver that a connection is in progress */ - _enable_event(s, FD_CONNECT|FD_READ|FD_WRITE, + _enable_event(SOCKET2HANDLE(s), FD_CONNECT|FD_READ|FD_WRITE, FD_CONNECT|FD_READ|FD_WRITE, FD_WINE_CONNECTED|FD_WINE_LISTENING); if (_is_blocking(s)) @@ -1608,7 +1622,7 @@ connect_success: close(fd); - _enable_event(s, FD_CONNECT|FD_READ|FD_WRITE, + _enable_event(SOCKET2HANDLE(s), FD_CONNECT|FD_READ|FD_WRITE, FD_WINE_CONNECTED|FD_READ|FD_WRITE, FD_CONNECT|FD_WINE_LISTENING); return 0; @@ -2236,9 +2250,9 @@ } close(fd); if (*argp) - _enable_event(s, 0, FD_WINE_NONBLOCKING, 0); + _enable_event(SOCKET2HANDLE(s), 0, FD_WINE_NONBLOCKING, 0); else - _enable_event(s, 0, 0, FD_WINE_NONBLOCKING); + _enable_event(SOCKET2HANDLE(s), 0, 0, FD_WINE_NONBLOCKING); return 0; case WS_SIOCATMARK: @@ -2295,7 +2309,7 @@ if (listen(fd, backlog) == 0) { close(fd); - _enable_event(s, FD_ACCEPT, + _enable_event(SOCKET2HANDLE(s), FD_ACCEPT, FD_WINE_LISTENING, FD_CONNECT|FD_WINE_CONNECTED); return 0; @@ -2562,7 +2576,7 @@ /* Try immediate completion */ if ( lpOverlapped && !NtResetEvent( lpOverlapped->hEvent, NULL ) ) { - if ( WSAGetOverlappedResult ( (HANDLE) s, lpOverlapped, + if ( WSAGetOverlappedResult ( s, lpOverlapped, lpNumberOfBytesSent, FALSE, &dwFlags) ) return 0; @@ -2585,7 +2599,7 @@ { err = wsaErrno(); if ( err == WSAEWOULDBLOCK ) - _enable_event (s, FD_WRITE, 0, 0); + _enable_event (SOCKET2HANDLE(s), FD_WRITE, 0, 0); goto err_free; } @@ -2849,12 +2863,12 @@ close(fd); } - _enable_event( s, 0, 0, clear_flags ); + _enable_event( SOCKET2HANDLE(s), 0, 0, clear_flags ); if ( how > 1) WSAAsyncSelect( s, 0, 0, 0 ); return 0; error: - _enable_event( s, 0, 0, clear_flags ); + _enable_event( SOCKET2HANDLE(s), 0, 0, clear_flags ); WSASetLastError ( err ); return SOCKET_ERROR; } @@ -3247,11 +3261,11 @@ { int ret; - TRACE("%08x, hEvent %08x, lpEvent %08x\n", s, hEvent, (unsigned)lpEvent ); + TRACE("%08x, hEvent %p, lpEvent %08x\n", s, hEvent, (unsigned)lpEvent ); SERVER_START_REQ( get_socket_event ) { - req->handle = s; + req->handle = SOCKET2HANDLE(s); req->service = TRUE; req->c_event = hEvent; wine_server_set_reply( req, lpEvent->iErrorCode, sizeof(lpEvent->iErrorCode) ); @@ -3270,11 +3284,11 @@ { int ret; - TRACE("%08x, hEvent %08x, event %08x\n", s, hEvent, (unsigned)lEvent ); + TRACE("%08x, hEvent %p, event %08x\n", s, hEvent, (unsigned)lEvent ); SERVER_START_REQ( set_socket_event ) { - req->handle = s; + req->handle = SOCKET2HANDLE(s); req->mask = lEvent; req->event = hEvent; req->window = 0; @@ -3319,7 +3333,7 @@ if ( r == WAIT_OBJECT_0 ) NtSetEvent ( lpOverlapped->hEvent, NULL ); } - + if ( lpcbTransfer ) *lpcbTransfer = lpOverlapped->InternalHigh; @@ -3348,11 +3362,11 @@ { int ret; - TRACE("%x, hWnd %x, uMsg %08x, event %08lx\n", s, hWnd, uMsg, lEvent ); + TRACE("%x, hWnd %p, uMsg %08x, event %08lx\n", s, hWnd, uMsg, lEvent ); SERVER_START_REQ( set_socket_event ) { - req->handle = s; + req->handle = SOCKET2HANDLE(s); req->mask = lEvent; req->event = 0; req->window = hWnd; @@ -3404,7 +3418,7 @@ */ BOOL WINAPI WSACloseEvent(WSAEVENT event) { - TRACE ("event=0x%x\n", event); + TRACE ("event=%p\n", event); return CloseHandle(event); } @@ -3491,7 +3505,7 @@ req->flags = dwFlags; req->inherit = TRUE; set_error( wine_server_call( req ) ); - ret = (SOCKET)reply->handle; + ret = HANDLE2SOCKET_S( reply->handle ); } SERVER_END_REQ; if (ret) @@ -4005,7 +4019,7 @@ /* Try immediate completion */ if ( lpOverlapped && !NtResetEvent( lpOverlapped->hEvent, NULL ) ) { - if ( WSAGetOverlappedResult ( (HANDLE) s, lpOverlapped, + if ( WSAGetOverlappedResult ( s, lpOverlapped, lpNumberOfBytesRecvd, FALSE, lpFlags) ) return 0; @@ -4036,7 +4050,7 @@ HeapFree (GetProcessHeap(), 0, iovec); close(fd); - _enable_event(s, FD_READ, 0, 0); + _enable_event(SOCKET2HANDLE(s), FD_READ, 0, 0); return 0; @@ -4127,12 +4141,12 @@ case CF_DEFER: SERVER_START_REQ ( set_socket_deferred ) { - req->handle = s; - req->deferred = cs; + req->handle = SOCKET2HANDLE (s); + req->deferred = SOCKET2HANDLE (cs); if ( !wine_server_call_err ( req ) ) { SetLastError ( WSATRY_AGAIN ); - CloseHandle ( cs ); + WS_closesocket ( cs ); } } SERVER_END_REQ; @@ -4184,7 +4198,7 @@ * the target use the global duplicate, or we could copy a reference to us to the structure * and let the target duplicate it from us, but let's do it as simple as possible */ hProcess = OpenProcess(PROCESS_DUP_HANDLE, FALSE, dwProcessId); - DuplicateHandle(GetCurrentProcess(), s, + DuplicateHandle(GetCurrentProcess(), SOCKET2HANDLE(s), hProcess, (LPHANDLE)&lpProtocolInfo->dwCatalogEntryId, 0, FALSE, DUPLICATE_SAME_ACCESS); CloseHandle(hProcess);

3 3

Re: Bug #321: msvcrt-vfprintf-3.diff
by Dmitry Timoshkov 29 Oct '02

29 Oct '02

"Jaco Greeff" <jaco(a)puxedo.org> wrote: > Ok, try number 3. I've made the changes as requested > > * Get result length before allocating and copying with WideCharToMultiByte; > * Make intentions clear on strncat, replaced with strcat > * Removed CHAR castings to get the WCHAR formatting character. > * Fixes as requested by Dimitri and included in previous version; You are still using L prefix and redundant (WCHAR) casts. Instead of if (*szFmt == (WCHAR)L'-') and case (WCHAR)L'd': ADD_FORMAT_TYPE(VFMT_INTEGER, "d"); simple if (*szFmt == '-') and case 'd': ADD_FORMAT_TYPE(VFMT_INTEGER, "d"); will do the job. -- Dmitry.

2 1

problem building rpcrt4 on Mingw
by Steven Edwards 29 Oct '02

29 Oct '02

when building the current sources under mingw- gcc-3.2 I am getting this: rpc_binding.c:869: conflicting types for `I_RpcBindingSetAsync' ../../include/rpcdcep.h:135: previous declaration of `I_RpcBindingSetAsync' I dont really have much time to look at it now but if its a mingw only problem I can look at it tonight. Thanks Steven

2 1

Re: dlls/advapi32/registry.c: RegFlushKey implementation
by Eric Pouech 29 Oct '02

29 Oct '02

> Changelog: > * dlls/advapi32/registry.c: Jaco Greeff <jaco(a)puxedo.org> > - Implementation of the RegFlushKey function it seems however that RegFlushKey shouldn't close the handle see for example (at the bottom of list... it seems this API confuses a lots of people) http://groups.google.com/groups?hl=fr&lr=&ie=UTF-8&threadm=39067129.96B55F7…

2 1

Listview: what next?
by Dimitrie O. Paun 29 Oct '02

29 Oct '02

Folks, I now consider the listview rewrite complete. What this means: -- current revision (1.325) may become a reference rev for a while -- bugs for the listview should be submitted through Bugzilla NOw, I know there are outstanding bugs. Most likely, there would always be. But i have to draw the line somewhere. I would like everybody that submitted bugs/feature requests/etc. to retest with the latest code in CVS, and submit a bug at http://bugs.winehq.org: 1. assign it to me (dpaun(a)rogers.com) 2. try to find the revision that caused it 3. screenshots of visual problems help alot Due to my hand problems, I will not be as active these days. But I will be glad to review problems, and think about solving them, so please fill out those bug reports! :) Again, having the bugs in Bugzilla will help me greatly in managing them. -- Dimi.

1 0

wwn141
by Jürgen Schmied 28 Oct '02

28 Oct '02

Just a comment to the mentioned use of LPC to ememinate the server part of rpc: Since wine uses a server every lpc-call causes a lot of context switching. LPC with the wine server will never be as fast as on winnt. -The client would have to wait on the client side what means a client call needs 2 roundtrips to the server. - There are 3 processes playing a role: client, wine-server and the server. Where winnt needs only a context switch between the client and the server and one back, we need at least 6: client -> wineserver (copies request-message to wineserver) wineserver -> client (gives wait handle back) wineserver->server (server wakes up on it's wait handle and gets request-message) ... server is working now ... server->wineserver (server copies replay-message to wineserver) client->wineserver (client is waken up and calls wineserver for data) wineserver->client (client gets replay-message from wineserver) So I would consider a different IPC mechanism for this. Or could we implement LPC in a better way? juergen --- juergen.schmied(a)debitel.net

4 3

Re: Interrupts / Improve winedos infrastructure
by Alexandre Julliard 28 Oct '02

28 Oct '02

Jukka Heinonen <jhei(a)iki.fi> writes: > Changelog: > Add routines for manipulating protected mode interrupt handlers to > winedos dll. Add routine for checking if process is Windows process. > Fix DOSVM_IsDos32 interface. Move real mode interrupt handler > manipulation routines to interrupts.c. I have applied it, but I think you should change DOSVM_GetBuiltinHandler to use a static function table; there's no need to use GetProcAddress on winedos.dll itself, this is only necessary for 16-bit entry points. -- Alexandre Julliard julliard(a)winehq.com

1 0

open-source friendly network card vendor
by David Christensen 28 Oct '02

28 Oct '02

wine-devel(a)winehq.com: I've looked for a forum, mailing list, or newsgroup specifically oriented for network card device driver development, but haven't found one. Any suggestions? I'm looking for an open-source friendly network card vendor -- e.g. the vendor publicly discloses the technical information required to write device drivers. Does anybody have any recommendations? If so, can you please provide URL's to their technical information? TIA, David Christensen dpchrist(a)holgerdanske.com

1 0

RE: MSVCRT: added support for re-throwing exceptions
by Patrik Stridvall 28 Oct '02

28 Oct '02

> "Patrik Stridvall" <ps(a)leissner.se> wrote: > > > [1] All tests currenly doesn't compile quite yet, but the > > infrastructure is in place. I haven't had much time to look at > > it yet. Help would be nice... > > Patrik, what kind of help do you need regarding this issue? > I'll gladly help when I have time. [I assume any reader is knows how to use MS VC++, Especially how to use workspaces with multi projects] First of all you need two computers. One with Windows and Microsoft Visual C++ 6.0 One with some Unix supported by Wine and Samba installed. Unpack (or better download with CVS) Wine on the Unix computer. cd wine ./tools/winapi/msvcmaker Export the wine directory on the Unix computer using Samba and mount it on the Windows computer. Open the file winetest.dsw in the wine directory (generated by msvcmaker) using Microsoft Visual C++. Now you can compile and run the tests. Or rather you should be able to. All the tests doesn't compile. That what I want help with. The second step would be actually getting all the tests to not fail as well... PS. Note that you can try to compile all of Wine as well by opening wine.dsw instead. Of course that doesn't compile either but that have less priority than the tests...

1 0

Tab Control
by Fabian Cenedese 28 Oct '02

28 Oct '02

Hi When I try to use the tab control in a VB6 program it exits with an error dialog: "Can't load 'SSTab' from TabCtl32.ocx. TabCtl32.ocx is probably too old." This is with builtin dlls. It works when I set ole.dll and oleaut32.dll to native. Winedbg doesn't give more information, it just looks like: --- (snip) --- No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\VB6DE.DLL' (0x66630000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\TABCTL32.OCX' (0x212f0000) (here comes the error dialog, OK) Invalid address for breakpoint 1, disabling it Invalid address for breakpoint 2, disabling it Process of pid=08112ba8 has terminated I also made some traces with +ole but I couldn't see any reasons why it fails. Also a bt at the moment of the popup doesn't show much, it's all inside MSVBVM60.DLL. If somebody wants to try, here's a small test project and exe (VB6). The TabCtl32.ocx in my case is from SP4. I don't know if this matters. http://www.indel.ch/ftp/TabError.zip Thanks bye Fabi

1 0

RE: MSVCRT: added support for re-throwing exceptions
by Patrik Stridvall 28 Oct '02

28 Oct '02

> LICENSE: LGPL > > If you compile the following code with Visual C++ using the > /MD option (so > that it uses msvcrt.dll) > > class CExceptionClass > { > public: > CExceptionClass() {number=0;} > long number; > }; > > void doSomething() > { > try { > throw CExceptionClass(); > } catch(...) { > throw; > } > } > > int main(int argc, char* argv[]) > { > try { > doSomething(); > } catch(CExceptionClass& e) { > printf("%d\n",e.number); > } > return 0; > } > > and run it under WINE, it will crash. It would probably be a good idea to submit this as a test in order to check that this will work in the future. However this is not a normal test because of two reasons 1. It is a C++ only test 2. It is only meaningful if a binary compiled by MS VC++ is run under Wine. Anyway, since very recently thanks to ./tools/winapi/msvcmaker it is possible to compile[1] the Wine tests using MS VC/C++ and run them under Windows. Obviously the binaries generated should be able to run under Wine as well... [1] All tests currenly doesn't compile quite yet, but the infrastructure is in place. I haven't had much time to look at it yet. Help would be nice...

2 1

Re: Listview Z8
by Jeff Smith 28 Oct '02

28 Oct '02

(note that I am presently at a computer *not* set up for i18n) I think Hebrew was made to go RTL just to give programmers headaches. Actually, I'm trying to learn Hebrew, and I keep catching myself trying to write it LTR. Now if Dimi went to the Hebrew alephbet, would he have to change from Z1, Z2,... to 1{aleph}, 2{aleph},... -- Jeff S. >From: Shachar Shemesh <wine-devel(a)sun.consumer.org.il> > >That's why I included them here, so you can copy and paste.... > >Just remeber to set your locale to either Iso-8859-8 or UTF-8, or you'll >lose the special chars. Even more tricky, if your email client supports >BiDi (Your'e using kmail, but only the one that came with KDE-3 did, and I >don't know what version that was), then the first character, "×", is on >the *right* `-) > > Shachar > > >Dimitrie O. Paun wrote: > >>On October 27, 2002 12:14 pm, Shachar Shemesh wrote: >> >> >>>"×××××××××××××× ×¡×¢×€×Š×§×š×©×ª". Very useful `-) >>> >>> >> >>Very cool man, but, ..., hmm, ..., I don't have a Hebrew keyboard. ;) _________________________________________________________________ Get a speedy connection with MSN Broadband. Join now! http://resourcecenter.msn.com/access/plans/freeactivation.asp

2 1

[OT] Announcing Aztech AZF3328/PCI168 sound driver
by Andreas Mohr 28 Oct '02

28 Oct '02

Hi all, the reason I've been rather quiet on the wine-patches side is that I've been busy writing an ALSA driver for the entirely UNDOCUMENTED and UNSUPPORTED PCI soundcard Aztech PCI168. This has been consuming vast amounts of weeks (all in all I'd say in compressed form 4 weeks of 2 hours per evening). This driver (azt3328.c) is more or less working now (some minor quirks remain) and has just been committed to ALSA CVS today. I don't expect anyone here to have access to such a card, but if you have, then you might want to give it a whirl ;-) Greetings, Andi

1 0

Re: Segmentation Fault: A possibility???
by Kye Lewis 28 Oct '02

28 Oct '02

Hi, Sorry for posting all of this to the wine-devel group continuously, but I may have found the problem (or I may not have) but either way I need some help. I have run wine --debugmsg +relay acrord32.exe and read the resulting file. The last thing that comes up is: wineoss.drv I had a quick look through the specific function's code (The actual log entry is: Call wineoss.drv.DriverProc(00000000,403e2858,00000001,00000000,00000000) ret=40c9d2b5 ) Recently in the KDE Control Panel's Sound options, I ticked the 'Use Full Duplex' option - and ever since that it hasn't worked. Could this have been the reason? I can't look and see if it was now, i'll have to restart linux, and right now i'm the internet server on the network - so no restarts for me :( -- Thanks, Kye Lewis kyethespy(a)liquid2k.com

2 1

Bad hand
by Dimitrie O. Paun 28 Oct '02

28 Oct '02

Sorry everybody, My right hand hurts badly, I'll be off for a few days... -- Dimi.

2 1

Re: Bug #321: dlls/msvct/vf[w]printf functions
by Dmitry Timoshkov 28 Oct '02

28 Oct '02

"Jaco Greeff" <jaco(a)puxedo.org> wrote: > Changelog: > * dlls/msvcrt/vfprintf.c, dlls/msvcrt/Makefile.in, > dlls/msvcrt/tests/printf.c, dlls/msvcrt/tests/Makefile.in: Jaco Greeff > <jaco(a)puxedo.org> > - Full implementation to allow for %C & %S in all printf related functions > - Test case for the printf functions to test all known cases of formatting > (test case based on example found on MSDN site) I'm sorry for returning to that topic again and again, but it's really does matter. > +static void test_printf(void) > +{ > + FILE* f; > + char ch = 'a', *string = "computer"; > + int count = -9234; > + double fp = 251.7366; > + wchar_t wch = L'w', *wstring = L"Unicode"; > + void *p = 0x1234ABCD; Please, 1. use explicit WCHAR type instead of wchar_t. 2. explicitly encode unicode strings. > wctomb(ch, wch); 3. directly use Win32 conversion APIs (WideCharToMultiByte in this case). Take a look at other places in the Wine source how to do it properly. Thanks. -- Dmitry.

3 6

Re: Listview Z8
by Dimitrie O. Paun 28 Oct '02

28 Oct '02

On October 27, 2002 11:28 am, Dimitrie O. Paun wrote: > ChangeLog > Mark immutable objects as const. Fix inconsisten *-style. This one, of course, is Z7, not Z8. Hmm, now I have problems with digits, on top of the alphabet... And NO, we used to do a _lot_ of math in Romania! :P -- Dimi.

3 4

Re: Segmentation Fault
by Kye Lewis 28 Oct '02

28 Oct '02

Oh, and one other thing. If I run the setup for who wants to beat up a millionaire (it's a WISE installer), the blue 'Initializing Wise Installation Wizard' screen comes up BEFORE wine faults. > On Sun, 2002-10-27 at 21:14, Kye Lewis wrote: > > I don't know if this will help my Segmentation Fault at all, but when > > runing winedbg c:\\windows\\pbrush.exe, the Debugger actually waits for > > a command from me. > > > > If i take a step, it says: > > > > Single Stepping until exit from function, > > which has no line number information > > Stopped on breakpoint 1 at 0x0040100c (pbrush.exe.Entrypoint in > > c:\windows\pbrush.exe > > > > If i then step again > > > > Invalid address for breakpoint 0, disabling it > > ..... breakpoint 1 ..... > > ..... breakpoint 2 ..... > > Process of pid=0a24dbf0 has terminated > > > > a very odd thing happens if i run, and then step: > > > > another window pops up (gdb) and I get wine_dbg_cmd: Exception c00000005 > > in the Wine Debugger > > the gdb window says 0x402e2b41 in nanosleep () from /lib/i686/libc.so.6 > > > > and stepping in that window steps me through function nanosleep (?!?!?!) > > > > it would seem that it starts to debug wine itself! > > > > unfortunately, this window doesn't allow copy and paste, so i'll have to > > type it out for you (it may be a little incorrect): > > > > __errno_location () at errno.c:48 > > 48 return wine_errno_location(); > > > > (gdb) step > > > > thread_errno_location () at ../../include/winnt.h:1717 > > 1717 __asm__(".byte 0x64\n\tmov1 (0x18),%0" : "=r" (teb)); > > > > (gdb) step > > > > Program recieved signal SIGSEGV, Segmentation fault > > thread_errno_location () at ../../include/winnt.h:1717 > > 1717 __asm__(".byte 0x64\n\tmov1 (0x18),%0" : "=r" (teb)); > > > > (gdb) step > > > > Program recieved signal SIGCONT, Continued > > 0x40305134 in read () from /lib/i686/lib.so.6 > > > > etc... etc... etc... > > > > and it goes through a whole heck of code... > > > > The only thing that comes up in the console is > > > > Can't attach process 8072d90: error 5 > > > > Thanks, > > Kye Lewis > > kyethespy(a)liquid2k.com > > > > > > > > >

1 0

Re: Listview Z8
by Jeff Smith 28 Oct '02

28 Oct '02

Actually, I believe Klingon got rejected. Some junk about it not being a 'real' language or something. Try telling that to all the people that speak it though. Probably more than some of the other languages represented in Unicode. Maybe we should continue through the ASCII character set: 'X' 'Y' 'Z' '[' '\' ']' '^' '_' ... -- Jeff S. >From: "David D. Hagood" <wowbagger(a)sktc.net> >To: wine-devel(a)winehq.com > >Andreas Mohr wrote: > >> >>What a weak and useless suggestion, this will run out of characters in >>no time at all ;-) >>Better use Chinese characters ! > >Bah! You are still weak! Better to use Klingon - I do beleive they've >reserve some Unicode space for them! _________________________________________________________________ Surf the Web without missing calls! Get MSN Broadband. http://resourcecenter.msn.com/access/plans/freeactivation.asp

1 0

[wine application] wineinput
by yumj 28 Oct '02

28 Oct '02

http://opencjk.org/projects/wineinput/index-e.html

1 0

Treeview bug - question
by Dustin Navea 28 Oct '02

28 Oct '02

Anyone wanna take a stab at the treeview email I sent earlier, since Guy isnt actively developing anymore? I may take a look at it, but I'm not sure if I will be able to do anything with it. __________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/

1 0

Re: Listview Z8
by David D. Hagood 28 Oct '02

28 Oct '02

Andreas Mohr wrote: > > What a weak and useless suggestion, this will run out of characters in > no time at all ;-) > Better use Chinese characters ! Bah! You are still weak! Better to use Klingon - I do beleive they've reserve some Unicode space for them!

1 0

search for Slava Monich
by Doug Brown 27 Oct '02

27 Oct '02

Hello I used to work with Slava Monich in the period 1992-1997 thereabouts. I am interested to find him now. I found his name on some Wine web pages from Google search on his name and after not finding anything furthermore specific I ask you for help. If you have any latest and greatest contact information for this gentleman, please let me know. I tried him at monich(a)ftp.com but got denied. Thank you very much DHB

2 1

Re: Bug #321: dlls/msvct/vf[w]printf functions
by Jaco Greeff 27 Oct '02

27 Oct '02

On 27 Oct 2002 22:28:33 -0000, "Jaco Greeff" <jaco(a)puxedo.org> wrote : > Changelog: > - Test case for the printf functions to test all known cases of formatting > (test case based on example found on MSDN site) The test case is mostly the same as this example with "\t" replaced with spaces and some extra "\n" characters: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html… Output from a test run attached to this mail. Greetings, Jaco

1 0

Found problem-causing patch for treeview
by Dustin Navea 27 Oct '02

27 Oct '02

Ok, I finally found the patch that is causing treeview to not work on StarCraft (see bug #1073 for more info and the debug output) The hypermail link to the patch is: http://www.winehq.com/hypermail/wine-cvs/2002/03/0070.html I'm not sure which part of the patch caused it but that is the one causing it because cvs 1 second before that patch works fine, cvs the second of the patch does not. If someone could take a look at it and the debug output I would greatly appreciate it. I believe that this bug may also be whats causing native regedit to not show anything, but I'm not sure, that one could be listview related. -Dustin __________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/

2 1

Re: Listview Z8
by Shachar Shemesh 27 Oct '02

27 Oct '02

Oh my god!!! he is running out of alphabet letters!!! ;-) Shachar Dimitrie O. Paun wrote: >ChangeLog > Mark immutable objects as const. Fix inconsisten *-style. > >--- dlls/comctl32/listview.c.Z6 2002-10-27 10:29:52.000000000 -0500 >+++ dlls/comctl32/listview.c 2002-10-27 11:24:45.000000000 -0500 >@@ -370,7 +370,7 @@ > static void LISTVIEW_GetOrigin(LISTVIEW_INFO *, LPPOINT); > static BOOL LISTVIEW_GetViewRect(LISTVIEW_INFO *, LPRECT); > static void LISTVIEW_SetGroupSelection(LISTVIEW_INFO *, INT); >-static BOOL LISTVIEW_SetItemT(LISTVIEW_INFO *, LPLVITEMW, BOOL); >+static BOOL LISTVIEW_SetItemT(LISTVIEW_INFO *, const LVITEMW *, BOOL); > static void LISTVIEW_UpdateScroll(LISTVIEW_INFO *); > static void LISTVIEW_SetSelection(LISTVIEW_INFO *, INT); > static void LISTVIEW_UpdateSize(LISTVIEW_INFO *); >@@ -380,7 +380,7 @@ > static INT LISTVIEW_GetStringWidthT(LISTVIEW_INFO *, LPCWSTR, BOOL); > static BOOL LISTVIEW_KeySelection(LISTVIEW_INFO *, INT); > static UINT LISTVIEW_GetItemState(LISTVIEW_INFO *, INT, UINT); >-static BOOL LISTVIEW_SetItemState(LISTVIEW_INFO *, INT, LPLVITEMW); >+static BOOL LISTVIEW_SetItemState(LISTVIEW_INFO *, INT, const LVITEMW *); > static LRESULT LISTVIEW_VScroll(LISTVIEW_INFO *, INT, INT, HWND); > static LRESULT LISTVIEW_HScroll(LISTVIEW_INFO *, INT, INT, HWND); > static INT LISTVIEW_GetTopIndex(LISTVIEW_INFO *); >@@ -469,7 +469,7 @@ > /* > * compares a Unicode to a Unicode/ANSI text string > */ >-static inline int textcmpWT(LPWSTR aw, LPWSTR bt, BOOL isW) >+static inline int textcmpWT(LPCWSTR aw, LPCWSTR bt, BOOL isW) > { > if (!aw) return bt ? -1 : 0; > if (!bt) return aw ? 1 : 0; >@@ -517,7 +517,7 @@ > return buffers[index++ % DEBUG_BUFFERS]; > } > >-static inline char* debugrange(const RANGE* lprng) >+static inline char* debugrange(const RANGE *lprng) > { > if (lprng) > { >@@ -527,7 +527,7 @@ > } else return "(null)"; > } > >-static inline char* debugpoint(const POINT* lppt) >+static inline char* debugpoint(const POINT *lppt) > { > if (lppt) > { >@@ -537,7 +537,7 @@ > } else return "(null)"; > } > >-static inline char* debugrect(const RECT* rect) >+static inline char* debugrect(const RECT *rect) > { > if (rect) > { >@@ -580,7 +580,7 @@ > return text; > } > >-static char* debugnmlistview(LPNMLISTVIEW plvnm) >+static char* debugnmlistview(const NMLISTVIEW *plvnm) > { > if (plvnm) > { >@@ -593,7 +593,7 @@ > } else return "(null)"; > } > >-static char* debuglvitem_t(LPLVITEMW lpLVItem, BOOL isW) >+static char* debuglvitem_t(const LVITEMW *lpLVItem, BOOL isW) > { > char* buf = debug_getbuf(), *text = buf; > int len, size = DEBUG_BUFFER_SIZE; >@@ -629,7 +629,7 @@ > return text; > } > >-static char* debuglvcolumn_t(LPLVCOLUMNW lpColumn, BOOL isW) >+static char* debuglvcolumn_t(const LVCOLUMNW *lpColumn, BOOL isW) > { > char* buf = debug_getbuf(), *text = buf; > int len, size = DEBUG_BUFFER_SIZE; >@@ -670,7 +670,7 @@ > } > > >-static char* debuglvhittestinfo(LPLVHITTESTINFO lpht) >+static char* debuglvhittestinfo(const LVHITTESTINFO *lpht) > { > if (lpht) > { >@@ -817,7 +817,7 @@ > return bResult; > } > >-static void customdraw_fill(NMLVCUSTOMDRAW *lpnmlvcd, LISTVIEW_INFO *infoPtr, HDC hdc, LPRECT rcBounds) >+static void customdraw_fill(NMLVCUSTOMDRAW *lpnmlvcd, LISTVIEW_INFO *infoPtr, HDC hdc, const RECT *rcBounds) > { > ZeroMemory(lpnmlvcd, sizeof(NMLVCUSTOMDRAW)); > lpnmlvcd->nmcd.hdc = hdc; >@@ -1045,7 +1045,7 @@ > /*** > * Creates an iterator over the items which intersect lprc. > */ >-static BOOL iterator_frameditems(ITERATOR* i, LISTVIEW_INFO* infoPtr, const RECT* lprc) >+static BOOL iterator_frameditems(ITERATOR* i, LISTVIEW_INFO* infoPtr, const RECT *lprc) > { > UINT uView = infoPtr->dwStyle & LVS_TYPEMASK; > RECT frame = *lprc, rcItem, rcTemp; >@@ -1130,7 +1130,7 @@ > /*** > * Creates an iterator over the items which intersect the visible region of hdc. > */ >-static BOOL iterator_visibleitems(ITERATOR* i, LISTVIEW_INFO *infoPtr, HDC hdc) >+static BOOL iterator_visibleitems(ITERATOR *i, LISTVIEW_INFO *infoPtr, HDC hdc) > { > POINT Origin, Position; > RECT rcItem, rcClip; >@@ -1705,7 +1705,7 @@ > * RETURN: > * None. > */ >-static void LISTVIEW_GetItemMetrics(LISTVIEW_INFO *infoPtr, LVITEMW *lpLVItem, >+static void LISTVIEW_GetItemMetrics(LISTVIEW_INFO *infoPtr, const LVITEMW *lpLVItem, > LPRECT lprcBox, LPRECT lprcState, > LPRECT lprcIcon, LPRECT lprcLabel) > { >@@ -2018,7 +2018,7 @@ > * Success: TRUE > * Failure: FALSE > */ >-static BOOL LISTVIEW_MoveIconTo(LISTVIEW_INFO *infoPtr, INT nItem, LPPOINT lppt, BOOL isNew) >+static BOOL LISTVIEW_MoveIconTo(LISTVIEW_INFO *infoPtr, INT nItem, const POINT *lppt, BOOL isNew) > { > POINT old; > >@@ -3039,7 +3039,7 @@ > /*** > * Tests wheather the item is assignable to a list with style lStyle > */ >-static inline BOOL is_assignable_item(LPLVITEMW lpLVItem, LONG lStyle) >+static inline BOOL is_assignable_item(const LVITEMW *lpLVItem, LONG lStyle) > { > if ( (lpLVItem->mask & LVIF_TEXT) && > (lpLVItem->pszText == LPSTR_TEXTCALLBACKW) && >@@ -3064,7 +3064,7 @@ > * SUCCESS : TRUE > * FAILURE : FALSE > */ >-static BOOL set_main_item(LISTVIEW_INFO *infoPtr, LPLVITEMW lpLVItem, BOOL isNew, BOOL isW, BOOL *bChanged) >+static BOOL set_main_item(LISTVIEW_INFO *infoPtr, const LVITEMW *lpLVItem, BOOL isNew, BOOL isW, BOOL *bChanged) > { > ITEM_INFO *lpItem; > NMLISTVIEW nmlv; >@@ -3199,7 +3199,7 @@ > * SUCCESS : TRUE > * FAILURE : FALSE > */ >-static BOOL set_sub_item(LISTVIEW_INFO *infoPtr, LPLVITEMW lpLVItem, BOOL isW, BOOL *bChanged) >+static BOOL set_sub_item(LISTVIEW_INFO *infoPtr, const LVITEMW *lpLVItem, BOOL isW, BOOL *bChanged) > { > HDPA hdpaSubItems; > SUBITEM_INFO *lpSubItem; >@@ -3271,7 +3271,7 @@ > * SUCCESS : TRUE > * FAILURE : FALSE > */ >-static BOOL LISTVIEW_SetItemT(LISTVIEW_INFO *infoPtr, LPLVITEMW lpLVItem, BOOL isW) >+static BOOL LISTVIEW_SetItemT(LISTVIEW_INFO *infoPtr, const LVITEMW *lpLVItem, BOOL isW) > { > UINT uView = infoPtr->dwStyle & LVS_TYPEMASK; > LPWSTR pszText = NULL; >@@ -3286,7 +3286,7 @@ > if ((lpLVItem->mask & LVIF_TEXT) && is_textW(lpLVItem->pszText)) > { > pszText = lpLVItem->pszText; >- lpLVItem->pszText = textdupTtoW(lpLVItem->pszText, isW); >+ ((LVITEMW *)lpLVItem)->pszText = textdupTtoW(lpLVItem->pszText, isW); > } > > /* actually set the fields */ >@@ -3311,7 +3311,7 @@ > if (pszText) > { > textfreeT(lpLVItem->pszText, isW); >- lpLVItem->pszText = pszText; >+ ((LVITEMW *)lpLVItem)->pszText = pszText; > } > > return bResult; >@@ -3372,7 +3372,7 @@ > * Success: TRUE > * Failure: FALSE > */ >-static inline BOOL LISTVIEW_FillBkgnd(LISTVIEW_INFO *infoPtr, HDC hdc, const RECT* lprcBox) >+static inline BOOL LISTVIEW_FillBkgnd(LISTVIEW_INFO *infoPtr, HDC hdc, const RECT *lprcBox) > { > if (!infoPtr->hBkBrush) return FALSE; > >@@ -4410,7 +4410,7 @@ > * FAILURE : -1 > */ > static INT LISTVIEW_FindItemW(LISTVIEW_INFO *infoPtr, INT nStart, >- LPLVFINDINFOW lpFindInfo) >+ const LVFINDINFOW *lpFindInfo) > { > UINT uView = infoPtr->dwStyle & LVS_TYPEMASK; > WCHAR szDispText[DISP_TEXT_SIZE] = { '\0' }; >@@ -4540,7 +4540,7 @@ > * FAILURE : -1 > */ > static INT LISTVIEW_FindItemA(LISTVIEW_INFO *infoPtr, INT nStart, >- LPLVFINDINFOA lpFindInfo) >+ const LVFINDINFOA *lpFindInfo) > { > BOOL hasText = lpFindInfo->flags & (LVFI_STRING | LVFI_PARTIAL); > LVFINDINFOW fiw; >@@ -5722,7 +5722,7 @@ > * SUCCESS : new item index > * FAILURE : -1 > */ >-static INT LISTVIEW_InsertItemT(LISTVIEW_INFO *infoPtr, LPLVITEMW lpLVItem, BOOL isW) >+static INT LISTVIEW_InsertItemT(LISTVIEW_INFO *infoPtr, const LVITEMW *lpLVItem, BOOL isW) > { > UINT uView = infoPtr->dwStyle & LVS_TYPEMASK; > INT nItem; >@@ -5934,7 +5934,7 @@ > /* LISTVIEW_SetBkImage */ > > /*** Helper for {Insert,Set}ColumnT *only* */ >-static void column_fill_hditem(LISTVIEW_INFO *infoPtr, HDITEMW *lphdi, INT nColumn, LPLVCOLUMNW lpColumn, BOOL isW) >+static void column_fill_hditem(LISTVIEW_INFO *infoPtr, HDITEMW *lphdi, INT nColumn, const LVCOLUMNW *lpColumn, BOOL isW) > { > if (lpColumn->mask & LVCF_FMT) > { >@@ -6021,7 +6021,7 @@ > * FAILURE : -1 > */ > static INT LISTVIEW_InsertColumnT(LISTVIEW_INFO *infoPtr, INT nColumn, >- LPLVCOLUMNW lpColumn, BOOL isW) >+ const LVCOLUMNW *lpColumn, BOOL isW) > { > COLUMN_INFO *lpColumnInfo; > INT nNewColumn; >@@ -6126,7 +6126,7 @@ > * FAILURE : FALSE > */ > static BOOL LISTVIEW_SetColumnT(LISTVIEW_INFO *infoPtr, INT nColumn, >- LPLVCOLUMNW lpColumn, BOOL isW) >+ const LVCOLUMNW *lpColumn, BOOL isW) > { > HDITEMW hdi, hdiget; > BOOL bResult; >@@ -6178,7 +6178,7 @@ > * SUCCESS : TRUE > * FAILURE : FALSE > */ >-static BOOL LISTVIEW_SetColumnOrderArray(LISTVIEW_INFO *infoPtr, INT iCount, LPINT lpiArray) >+static BOOL LISTVIEW_SetColumnOrderArray(LISTVIEW_INFO *infoPtr, INT iCount, const INT *lpiArray) > { > FIXME("iCount %d lpiArray %p\n", iCount, lpiArray); > >@@ -6672,7 +6672,7 @@ > * SUCCESS : TRUE > * FAILURE : FALSE > */ >-static BOOL LISTVIEW_SetItemState(LISTVIEW_INFO *infoPtr, INT nItem, LPLVITEMW lpLVItem) >+static BOOL LISTVIEW_SetItemState(LISTVIEW_INFO *infoPtr, INT nItem, const LVITEMW *lpLVItem) > { > BOOL bResult = TRUE; > LVITEMW lvItem; >@@ -6710,7 +6710,7 @@ > * SUCCESS : TRUE > * FAILURE : FALSE > */ >-static BOOL LISTVIEW_SetItemTextT(LISTVIEW_INFO *infoPtr, INT nItem, LPLVITEMW lpLVItem, BOOL isW) >+static BOOL LISTVIEW_SetItemTextT(LISTVIEW_INFO *infoPtr, INT nItem, const LVITEMW *lpLVItem, BOOL isW) > { > LVITEMW lvItem; > >@@ -6946,7 +6946,7 @@ > * Success: 0 > * Failure: -1 > */ >-static LRESULT LISTVIEW_Create(HWND hwnd, LPCREATESTRUCTW lpcs) >+static LRESULT LISTVIEW_Create(HWND hwnd, const CREATESTRUCTW *lpcs) > { > LISTVIEW_INFO *infoPtr; > UINT uView = lpcs->style & LVS_TYPEMASK; >@@ -7680,7 +7680,7 @@ > * RETURN: > * Zero > */ >-static LRESULT LISTVIEW_HeaderNotification(LISTVIEW_INFO *infoPtr, LPNMHEADERW lpnmh) >+static LRESULT LISTVIEW_HeaderNotification(LISTVIEW_INFO *infoPtr, const NMHEADERW *lpnmh) > { > UINT uView = infoPtr->dwStyle & LVS_TYPEMASK; > >@@ -8160,7 +8160,7 @@ > * Zero > */ > static INT LISTVIEW_StyleChanged(LISTVIEW_INFO *infoPtr, WPARAM wStyleType, >- LPSTYLESTRUCT lpss) >+ const STYLESTRUCT *lpss) > { > UINT uNewView = lpss->styleNew & LVS_TYPEMASK; > UINT uOldView = lpss->styleOld & LVS_TYPEMASK; > > > > >

3 2

How is Win/Dos syscalls implemented in Wine?
by Peter Andersson 27 Oct '02

27 Oct '02

Hello! Perhaps someone can give me a good answer to this question. Please give me a direct answer, I have allready been trouh the wine FAQ:s , docs, code, etc. I know DOS syscalls is made using interupts (int instruction) but, is Windows/NT syscalls made the same way. How does wine stop these instructions from reaching the unix kernel?

5 22

License query
by Matthew Bloch 27 Oct '02

27 Oct '02

I'm porting a closed-source game to Linux, and as a stop-gap I'd like to get a version out using WINE until I can rewrite the Direct(Sound|Draw|3D) backends with SDL. After reading this post: http://lists.debian.org/debian-devel/2002/debian-devel-200205/msg02823.html and then downloading the source from the winehq.com cvs, I'm confused as to my options. The LICENSE file implies that the ddraw DLL is transgaming's IP but the files themselves have LGPL declarations at the top. In short, am I within my rights to release a statically linked binary which uses the core WINE source code, providing I comply with the other terms of the LGPL? I notice some files have Transgaming's name on them, but appear to be LGPL. I think I'm within my rights, but not sure: the post above gives me most of the information that explains this state of affairs, but not everything. Any further pointers on WINE licensing history would be appreciated. cheers, -- Matthew Bloch Bytemark Computer Consulting Limited http://www.bytemark.co.uk/ tel. +44 (0) 8707 455026

2 2

Re: Segmentation Fault
by Kye Lewis 27 Oct '02

27 Oct '02

I don't know if this will help my Segmentation Fault at all, but when runing winedbg c:\\windows\\pbrush.exe, the Debugger actually waits for a command from me. If i take a step, it says: Single Stepping until exit from function, which has no line number information Stopped on breakpoint 1 at 0x0040100c (pbrush.exe.Entrypoint in c:\windows\pbrush.exe If i then step again Invalid address for breakpoint 0, disabling it ..... breakpoint 1 ..... ..... breakpoint 2 ..... Process of pid=0a24dbf0 has terminated a very odd thing happens if i run, and then step: another window pops up (gdb) and I get wine_dbg_cmd: Exception c00000005 in the Wine Debugger the gdb window says 0x402e2b41 in nanosleep () from /lib/i686/libc.so.6 and stepping in that window steps me through function nanosleep (?!?!?!) it would seem that it starts to debug wine itself! unfortunately, this window doesn't allow copy and paste, so i'll have to type it out for you (it may be a little incorrect): __errno_location () at errno.c:48 48 return wine_errno_location(); (gdb) step thread_errno_location () at ../../include/winnt.h:1717 1717 __asm__(".byte 0x64\n\tmov1 (0x18),%0" : "=r" (teb)); (gdb) step Program recieved signal SIGSEGV, Segmentation fault thread_errno_location () at ../../include/winnt.h:1717 1717 __asm__(".byte 0x64\n\tmov1 (0x18),%0" : "=r" (teb)); (gdb) step Program recieved signal SIGCONT, Continued 0x40305134 in read () from /lib/i686/lib.so.6 etc... etc... etc... and it goes through a whole heck of code... The only thing that comes up in the console is Can't attach process 8072d90: error 5 Thanks, Kye Lewis kyethespy(a)liquid2k.com

1 0

Re: dlls/user: w[v]snprintf[A|W] fixes
by David Laight 27 Oct '02

27 Oct '02

> > > Changelog: > > * dlls/user/wsprintf.c Jaco Greeff <jaco(a)puxedo.org> > > - Changed the wsprintf[A|W] and wvsprintf[A|W] functions to > > determine the size of the destination buffer before writing > > to it. Previously the size was hardcoded to 1024 bytes. > > The size is supposed to be hardcoded to 1024, that's how wsprintf > works. You can't make it dynamic since the buffer is allocated by the > application. Seems to me (from info in a later post) that M$ wsprintf uses an internal temporary buffer that has a size of 1024 - thus resticting the user to a buffer size of 1024, The actual size of the user buffer cannot be determined - hence the common 'buffer overflow' issues with sprintf. The C standard now includes snprintf() where the application passes in the length of the target buffer. I guess M$ might follow :-) Some systems also have an asprintf() routine which will malloc() a buffer that the caller must free(). David -- David Laight: david(a)l8s.co.uk

1 0

Segmentation Fault
by Kye Lewis 27 Oct '02

27 Oct '02

Hi, Not really sure if this is the right place to post this, but as i'm signed up to it; My version of wine has suddenly started Seg Faulting on startup. The last thing I tried with wine was netmeeting. This is with cvs version from 26th October at about 2:00 Australian Eastern Standard Time ( not sure what that is GMT - it was about 5 hours before posting this message ) Any help would be appreciated. Thanks, Kye Lewis kyethespy(a)liquid2k.com

3 5

Re: dlls/user: w[v]snprintf[A|W] fixes
by Jaco Greeff 27 Oct '02

27 Oct '02

On 26 Oct 2002 14:57:53 -0700, Alexandre Julliard <julliard(a)winehq.com> wrote : > The size is supposed to be hardcoded to 1024, that's how wsprintf > works. You can't make it dynamic since the buffer is allocated by the > application. >From MSDN: "Pointer to a buffer to receive the formatted output. The maximum size of the buffer is 1024 bytes." The question I need to ask myself now is what function reference did I compare this one to when I searched there?

1 0

[RFC] creating Wine's own 'assert' variant
by Lionel Ulmer 26 Oct '02

26 Oct '02

Hi all, Currently, Wine's code is full of 'asserts'. The problem I have with that if that when such an assert is reached, only the thread being asserted is aborted, but Wine is not 'shut down' properly. Moreover, if I want the debugger to be launched on assert, I would need first to start the application with the debugger and add a breakpoint on some libc internal function. So, don't you think it would be better to have our own 'wine_assert' macro / function that could be configurable (ie abort or start the debugger) and that would also shut-down Wine properly ? Lionel -- Lionel Ulmer - http://www.bbrox.org/

4 5

Re: interrupts in when in NT version
by John K. Hohm 26 Oct '02

26 Oct '02

> Tough all safedisc programs depend on this, I have decided not to make an > official patch. The reason is that additional info is needed for a proper > fix. Safedisc depends on that EXCEPTION_ACCESS_VIOLATION is returned on an > int 0x01 call. But it should be checked what exceptions are raised on > different windows versions when int 0x01 is called. And maybe the same should > be done with other interrupts. > It would be good if somebody could make that test program. Else I will keep > the non proper fix. You may think me a rube, but I just made a test program that calls an arbitrary interrupt and prints the exception information. I don't set up any registers, so perhaps it generates an exception when it ought not in some cases, but anyone else is free to improve it. Source and a VC6-compiled MSVCRT-using version, along with results for all 255 interrupts on Windows XP Professional, is here: http://petra.trnty.edu/~jhohm/intexcep.zip

2 1

Re: dlls/user: w[v]snprintf[A|W] fixes
by Alexandre Julliard 26 Oct '02

26 Oct '02

"Jaco Greeff" <jaco(a)puxedo.org> writes: > Changelog: > * dlls/user/wsprintf.c Jaco Greeff <jaco(a)puxedo.org> > - Changed the wsprintf[A|W] and wvsprintf[A|W] functions to > determine the size of the destination buffer before writing > to it. Previously the size was hardcoded to 1024 bytes. The size is supposed to be hardcoded to 1024, that's how wsprintf works. You can't make it dynamic since the buffer is allocated by the application. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: msvcrt: printf family (Bug #321)
by Alexandre Julliard 26 Oct '02

26 Oct '02

"Jaco Greeff" <jaco(a)puxedo.org> writes: > * dlls/msvcrt/file.c Jaco Greeff <jaco(a)puxedo.org> > - Allow for the processing of %S and %C format specifiers as per > bug #321 > - Code duplicated/shared between dlls/user/wsprintf.c, > dlls/shlwapi/wsprintf.c and now dlls/msvcrt/file.c That's not correct. wsprintf is not a normal printf, it lacks a lot of features so it's not good enough for msvcrt. We either need a full printf implementation in msvcrt, or we need to patch the %S/%C in the format string and call the libc printf. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: DSTRICT: commdlg
by Dimitrie O. Paun 26 Oct '02

26 Oct '02

On October 26, 2002 11:14 am, Matthew Davison wrote: > - hInst = GetWindowLongA( lpofn->hwndOwner, GWL_HINSTANCE ); > + hInst = (HINSTANCE)(ULONG_PTR)GetWindowLongA( lpofn->hwndOwner, GWL_HINSTANCE ); Why can't you cast here directly to HINSTANCE? -- Dimi.

2 1

Control Panel Application does not start
by Stefan Leichter 26 Oct '02

26 Oct '02

Hello, i am currently tracking down a problem with a program (Nokia PC Suite 4; NclConf.exe) that is unable to start its control panel application. The control panel application should be started by the rundll32.exe. It does not get started because of the path in the filename. The applet is searched in the correct directory but it does not get found because the path was not stripped from the filename. So a filename with path is compared to the filename without path read from the directoy. This will never match. I have attached a logfile with the relevant line (i hope). Will please someone be so kind and look at it and tell me what ithe reason for the problem is. Thanks Stefan -------------------------------------------------------------------------------------------------------------------------- 0831f930:Call shell32.Control_RunDLL(00020025,00400000,40370bb5,0000000a) ret=00401380 0831f930:Call kernel32.LoadLibraryA(403d0028 "\"C:\\Programme\\Gemeinsame Dateien\\Nokia\\NCLTools\\NclConf.cpl\"") ret=409bb0f4 trace:dosfs:DOSFS_GetFullName L"\"C:\\Programme\\Gemeinsame Dateien\\Nokia\\NCLTools\\NclConf.cpl\"" (last=1) trace:string:lstrcpynA (0x406d1c50, "/wine_app/wine_app", 1024) trace:string:lstrcpynA (0x406d1c63, "Programme/Gemeinsame Dateien/Nokia/NCLTools", 1005) trace:string:lstrcpynW (0x406d2056, L"PROG~1F2\\GEME~SR3\\NOKIA\\NCLTOOLS", 1021) trace:dosfs:DOSFS_FindUnixName /wine_app/wine_app/Programme/Gemeinsame Dateien/Nokia/NCLTools,L"\"C:\\Programme\\Gemeinsame Dateien\\Nokia\\NCLTools\\NclConf.cpl\"" trace:dosfs:DOSFS_ToDosFCBFormat (L"\"C:\\Programme\\Gemeinsame Dateien\\Nokia\\NCLTools\\NclConf.cpl\"", 0x406d1b78) trace:dosfs:DOSFS_OpenDir "/wine_app/wine_app/Programme/Gemeinsame Dateien/Nokia/NCLTools" trace:dosfs:DOSFS_ReadDir Read: long_name: L".", short_name: (null) trace:dosfs:DOSFS_FindUnixName L"\"C:\\Programme\\Gemeinsame Dateien\\Nokia\\NCLTools\\NclConf.cpl\"" -- L"." trace:dosfs:DOSFS_ReadDir Read: long_name: L"..", short_name: (null) trace:dosfs:DOSFS_FindUnixName L"\"C:\\Programme\\Gemeinsame Dateien\\Nokia\\NCLTools\\NclConf.cpl\"" -- L".." trace:dosfs:DOSFS_ReadDir Read: long_name: L"NCLCONF_I.HLP", short_name: (null) trace:dosfs:DOSFS_FindUnixName L"\"C:\\Programme\\Gemeinsame Dateien\\Nokia\\NCLTools\\NclConf.cpl\"" -- L"NCLCONF_I.HLP" trace:dosfs:DOSFS_ReadDir Read: long_name: L"NCLCONF_D.HLP", short_name: (null) trace:dosfs:DOSFS_FindUnixName L"\"C:\\Programme\\Gemeinsame Dateien\\Nokia\\NCLTools\\NclConf.cpl\"" -- L"NCLCONF_D.HLP" trace:dosfs:DOSFS_ReadDir Read: long_name: L"NCLCONF_E.HLP", short_name: (null) trace:dosfs:DOSFS_FindUnixName L"\"C:\\Programme\\Gemeinsame Dateien\\Nokia\\NCLTools\\NclConf.cpl\"" -- L"NCLCONF_E.HLP" trace:dosfs:DOSFS_ReadDir Read: long_name: L"NCLCONF_F.HLP", short_name: (null) trace:dosfs:DOSFS_FindUnixName L"\"C:\\Programme\\Gemeinsame Dateien\\Nokia\\NCLTools\\NclConf.cpl\"" -- L"NCLCONF_F.HLP" trace:dosfs:DOSFS_ReadDir Read: long_name: L"NCLCONF_G.HLP", short_name: (null) trace:dosfs:DOSFS_FindUnixName L"\"C:\\Programme\\Gemeinsame Dateien\\Nokia\\NCLTools\\NclConf.cpl\"" -- L"NCLCONF_G.HLP" trace:dosfs:DOSFS_ReadDir Read: long_name: L"NCLCONF.HLP", short_name: (null) trace:dosfs:DOSFS_FindUnixName L"\"C:\\Programme\\Gemeinsame Dateien\\Nokia\\NCLTools\\NclConf.cpl\"" -- L"NCLCONF.HLP" trace:dosfs:DOSFS_ReadDir Read: long_name: L"NCLCONF_N.HLP", short_name: (null) trace:dosfs:DOSFS_FindUnixName L"\"C:\\Programme\\Gemeinsame Dateien\\Nokia\\NCLTools\\NclConf.cpl\"" -- L"NCLCONF_N.HLP" trace:dosfs:DOSFS_ReadDir Read: long_name: L"NCLCONF_S.HLP", short_name: (null) trace:dosfs:DOSFS_FindUnixName L"\"C:\\Programme\\Gemeinsame Dateien\\Nokia\\NCLTools\\NclConf.cpl\"" -- L"NCLCONF_S.HLP" trace:dosfs:DOSFS_ReadDir Read: long_name: L"NCLCONF_SV.HLP", short_name: (null) trace:dosfs:DOSFS_FindUnixName L"\"C:\\Programme\\Gemeinsame Dateien\\Nokia\\NCLTools\\NclConf.cpl\"" -- L"NCLCONF_SV.HLP" trace:dosfs:DOSFS_ReadDir Read: long_name: L"NclConf.exe", short_name: (null) trace:dosfs:DOSFS_FindUnixName L"\"C:\\Programme\\Gemeinsame Dateien\\Nokia\\NCLTools\\NclConf.cpl\"" -- L"NclConf.exe" trace:dosfs:DOSFS_ReadDir Read: long_name: L"NclConf.cpl", short_name: (null) trace:dosfs:DOSFS_FindUnixName L"\"C:\\Programme\\Gemeinsame Dateien\\Nokia\\NCLTools\\NclConf.cpl\"" -- L"NclConf.cpl" warn:dosfs:DOSFS_FindUnixName L"\"C:\\Programme\\Gemeinsame Dateien\\Nokia\\NCLTools\\NclConf.cpl\"" not found in '/wine_app/wine_app/Programme/Gemeinsame Dateien/Nokia/NCLTools' warn:module:MODULE_LoadLibraryExA Failed to load module 'C:\WINDOWS\SYSTEM32'; error=2 0831f930:Ret kernel32.LoadLibraryA() retval=00000000 ret=409bb0f4 0831f930:Call kernel32.FreeLibrary(00000000) ret=409bb088 0831f930:Ret kernel32.FreeLibrary() retval=00000000 ret=409bb088 0831f930:Ret shell32.Control_RunDLL() retval=00000001 ret=00401380

4 7

Re: DSTRICT: commdlg
by Dimitrie O. Paun 26 Oct '02

26 Oct '02

On October 26, 2002 11:14 am, Matthew Davison wrote: > - chf32a->hInstance=chf16->hInstance; > + chf32a->hInstance=(HINSTANCE)(ULONG_PTR)chf16->hInstance; Shouldn't we have a HINSTANCE_32 macro, for uniformity? -- Dimi.

2 1

Re: DSTRICT: commdlg
by Dimitrie O. Paun 26 Oct '02

26 Oct '02

On October 26, 2002 11:14 am, Matthew Davison wrote: > - bRet = DialogBoxIndirectParam16( hInst, lfs->hDlgTmpl16, lpofn->hwndOwner, > + bRet = DialogBoxIndirectParam16( (HINSTANCE16)LOWORD(hInst), lfs->hDlgTmpl16, lpofn->hwndOwner, And here we should have a HINSTANCE_16 macro... -- Dimi.

1 0

Re: DSTRICT: commdlg
by Dimitrie O. Paun 26 Oct '02

26 Oct '02

On October 26, 2002 11:14 am, Matthew Davison wrote: > - FillRect(hDC, &lpp->old3angle, GetClassLongA( hwnd, GCL_HBRBACKGROUND)); > + FillRect((HDC)hDC, &lpp->old3angle, (HBRUSH)GetClassLongA( hwnd, GCL_HBRBACKGROUND)); This is not right. At that point, hDC should be a HDC, if it's not, you have to modify the code around it. Such casting should happen in the WindowProc, all functions should work with the proper type. Alexandre, please do not apply the patch in this form: it silence warnings, and it makes it very difficult to properly correct the code in the future. -- Dimi.

1 0

Re: interrupts in when in NT version
by Zsolt Rizsanyi 26 Oct '02

26 Oct '02

I have forgotten to cc this discussion to wine-devel. But who is interested can catch up from this mail. On Saturday 26 October 2002 14:07, Eric Pouech wrote: > > > > Could somebody answer/test if calling interrupt int 0x01 is allowed > > > > from a win32 program in WinNT environment? I would pretty like to > > > > know that! > > > > > > I don't think it is > > > > Should I write then a patch, which would deny calling of int 0x01 from > > win32 code when winver is NT? > > Would that be applied? > > the rule of thumb is: if there's a program which depends on this to be > implemented, then yes patch will be applied > otherwise, leave it as it is Tough all safedisc programs depend on this, I have decided not to make an official patch. The reason is that additional info is needed for a proper fix. Safedisc depends on that EXCEPTION_ACCESS_VIOLATION is returned on an int 0x01 call. But it should be checked what exceptions are raised on different windows versions when int 0x01 is called. And maybe the same should be done with other interrupts. It would be good if somebody could make that test program. Else I will keep the non proper fix. > > > it was allowed on Win9x, and is used in this context IIRC as a ring 3 > > > to ring 0 transition code (how to create a cheap call gate) > > > > How good it would be if I could understand what you are speaking about :( > > But could you explain what a call gate is? > > If it is too long, then dont bother tough... > > I'll try to make it short > context: > - i386 have 4 levels of privilege => ring 3 (less privilege) up to ring > 0 > - certain operations are only allowed at ring 0 (or 1) > - user code runs in ring 3 > - kernel code runs in ring 0 (to be exact, NT had been designed to have > kernel in ring 0, and device drivers in ring 1, but this has been > altered - some drivers run in ring 0 too) > - you can always call into a less priviledged level (ring 0 => ring 3 > for example) > - the other way around requires what is known as call gates (ring 0 for > example defines the "entry points" in some way) > - most of the interrupt handlers run in ring 0 > > what the safedisc code was doing was: > 0/ code is running in ring 3 > 1/ install an interrupt handler for division by zero (IIRC) > 2/ trigger the division > 3/ have the interrupt handler called, but this is done in ring 0, even > if the code has been loaded from a user space program. here, in the > interrupt handler, you can do any ring 0 operation you want > > that's why I called it a cheap call gate (no real call gate has been > installed, and the code run in ring 0 isn't decided by the kernel but > the app) > > NT doesn't allow this to run. step 1 is not allowed (only the kernel can > decide to change an interrupt handler, which makes lots of sense) Thanks for the detailed explanation. And for completeness I will include here the explanation of Laurent Pinchart why a safedisc program calls int 0x01 : > - the last attempt to detect a debugger uses int 0x01 (enter SMM/ICE mode), > which checks if an external hardware emulator is connected to the > processor. I haven't been able to understand what the code is supposed to > do. Regards Zsolt

1 0

Re: shlfileoperation
by Uwe Bonnes 26 Oct '02

26 Oct '02

>>>>> "Dietrich" == Dietrich Teickner <Dietrich_Teickner(a)t-online.de> writes: Dietrich> Hi, I am a Odin programmer (wine for os/2). I have in Dietrich> shlfileop 3 FO_ operations full imlemented. It's tested in Dietrich> Odin. Can anyone implement and test this patch in wine ? I Dietrich> have also one test programm, if nessesary. Please send the test program. And please state how to handle your patch with regard to wine-gpl and wine-x11 license. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Loading program icon
by Peter Andersson 26 Oct '02

26 Oct '02

Hi, How do you read the icon of a windows application? Please tell me how to do it inside wine/windows-environment, and possibly independent of wine/win (the raw way). Can someone give me a hint? //Peter

1 0

Re: Listview Z0 (roll-up patch)
by David D. Hagood 26 Oct '02

26 Oct '02

Well, a cvs up -C and rebuild, and things are find here at home. I'll have to see what is up with my machine at work Monday...

1 0

Re: Listview Z0 (roll-up patch)
by David D. Hagood 25 Oct '02

25 Oct '02

Dimitrie O. Paun wrote: > > The algorithm has been: start a new series when Alexandre has committed > the previous one. So, for example, because I've started the Z-series > last night, that means that Alexandre already committed the X-series. > So the only outstanding patch not committed to CVS is Z0. I don't see a > need for a roll-up patch ;) > > That helps, but also leaves me with a conundrum - when I do a CVS update on my machine at work, and rebuild wine (make clean, make depend, make, su, wipe wine directories in /usr/local, make install, exit, run Mng4) I get the listview crash on "Along the way". I haven't been updating my machine at home, which had the patches applied, so I thought the patches were not in CVS. I will do a cvs up -C and rebuild here at home, and see what I get.

1 0

Status Report: -DSTRICT
by Michael Stefaniuc 25 Oct '02

25 Oct '02

Hello, status reports seems to be pretty popular this day so here is mine regarding compiling wine with -DSTRICT. Below is the amount of warnings we get when removing -DWINE_NO_STRICT: dll real total ------------------------------ commdlg 21 63 gdi 128 273 ntdll 148 178 ole32 16 38 shell32 120 155 user 450 839 winmm/wavemap 7 40 winmm 104 145 winsock 14 42 x11drv 60 79 ------------------------------ total 1068 1852 "real" is the number of warning for which real work is need to be done, the rest up to "total" are warnings of the type "int format, HANDLE arg". And to fix this beasts just grab http://people.redhat.com/mstefani/wine/fixpointerarg.pl and do: cd wine/dlls/$dll_in_work make clean make 2>&1 | fixpointerarg.pl and you should be done. Happy hacking bye michael P.S.: a request from Eric: please let him finish the 32bit - 16bit separation of winmm. After that is yours. -- 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

1 0

Re: DSTRICT: LZexpand
by Michael Stefaniuc 25 Oct '02

25 Oct '02

It seems to look good and i'm very happy about it: i almost can't see that stuff anymore. bye michael On Sat, Oct 26, 2002 at 12:05:16AM +0100, Matthew Davison wrote: > This is my first patch to wine so if it is wrong please dont chew me up > anyway, here goes. > > ChangeLog: > Made LZexpand compile with DSTRICT defined. > -- 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

1 0

Re: Listview Z0 (roll-up patch)
by David D. Hagood 25 Oct '02

25 Oct '02

For those of us who are a little behind on the patches, would it be possible to get a roll-up patch of all diffs from the CVS MAIN branch? Also, what is the status of CVS vs. the patches - what patches have been applied?

4 5

Re: Known listview bugs (take 2)
by Jeff Smith 25 Oct '02

25 Oct '02

Just a couple of days ago, the problem with native (W95-OSR2.1) regedit was that changing keys in the tree kept piling up new items in the listview. It was quite interesting seeing multiple (Default) values for a key :-). Now (12 hours ago anyways) it is always blank. When I click on where the values should be (highlight them), sometimes they will show up then. It seems something is not being refreshed that should be. Maybe I'll get a chance to dig in later today if nothing has been uncovered by then. -- Jeff S. >From: Greg Turner <gmturner007(a)ameritech.net> > >On Friday 25 October 2002 07:35 am, Dimitrie O. Paun wrote: > > On October 25, 2002 02:36 am, Greg Turner wrote: > > > So, I know this has been discussed before... but I can't recall: is > > > native (W98) regedit expected to work right now? For me, it doesn't. > > > > Well, I don't have that application, so you'll need to help debug > > it if you want it working :). First step is a --debugmsg +listview. > > If you think that's relevant, a screenshot too. > >ok, I'll do this tonight, and maybe even try to drill in a little deeper >if I can figure anything interesting out. FYI, I think this problem >existed before your listvew work started, so its probably not your >doing. > >BTW, thanks for your ongoing work, listviews feel much better lately! > >-- >gmt _________________________________________________________________ Unlimited Internet access -- and 2 months free! Try MSN. http://resourcecenter.msn.com/access/plans/2monthsfree.asp

2 1

interrupts in when in NT version
by Zsolt Rizsanyi 25 Oct '02

25 Oct '02

Hi! I have Laurent Pinchart's safedisc patch applied and working for a while now. (and it works perfectly). But the recent interrupt changes tend to cause cvs conflicts and to break it. This patch is supposed to work only if winver is nt40 so very probably this applies only to NT. What the patch relies on is that the interrupt handling code (which was INSTR_EmulateInstruction before the changes), return EXCEPTION_ACCESS_VIOLATION if interrupt 0x01 is called (if I understand it correctly). This was done with the next patches: Index: dlls/ntdll/signal_i386.c =================================================================== RCS file: /home/wine/wine/dlls/ntdll/signal_i386.c,v retrieving revision 1.46 diff -u -p -r1.46 signal_i386.c --- dlls/ntdll/signal_i386.c 12 Sep 2002 22:07:03 -0000 1.46 +++ dlls/ntdll/signal_i386.c 24 Oct 2002 10:13:36 -0000 @@ -729,6 +729,7 @@ static void do_segv( CONTEXT *context, i { EXCEPTION_RECORD rec; DWORD page_fault_code = EXCEPTION_ACCESS_VIOLATION; + DWORD priv_instr_code = EXCEPTION_PRIV_INSTRUCTION; #ifdef CR2_sig /* we want the page-fault case to be fast */ @@ -758,8 +759,8 @@ static void do_segv( CONTEXT *context, i case T_SEGNPFLT: /* Segment not present exception */ case T_PROTFLT: /* General protection fault */ case T_UNKNOWN: /* Unknown fault code */ - if (INSTR_EmulateInstruction( context )) return; - rec.ExceptionCode = EXCEPTION_PRIV_INSTRUCTION; + if (INSTR_EmulateInstruction( context, &priv_instr_code )) return; + rec.ExceptionCode = priv_instr_code; break; case T_PAGEFLT: /* Page fault */ #ifdef CR2_sig Index: memory/instr.c =================================================================== RCS file: /home/wine/wine/memory/instr.c,v retrieving revision 1.19 diff -u -p -r1.19 instr.c --- memory/instr.c 23 Oct 2002 22:24:10 -0000 1.19 +++ memory/instr.c 24 Oct 2002 10:14:08 -0000 @@ -397,7 +397,7 @@ static void INSTR_outport( WORD port, in * * Emulate a privileged instruction. Returns TRUE if emulation successful. */ -BOOL INSTR_EmulateInstruction( CONTEXT86 *context ) +BOOL INSTR_EmulateInstruction( CONTEXT86 *context, DWORD *exception_code ) { int prefix, segprefix, prefixlen, len, repX, long_op, long_addr; SEGPTR gpHandler; @@ -685,6 +685,29 @@ BOOL INSTR_EmulateInstruction( CONTEXT86 break; /* Unable to emulate it */ case 0xcd: /* int <XX> */ +<<<<<<< instr.c + if (long_op) + { + ERR("int 0x%02x from 32-bit code is not supported.\n", instr[1]); + if (instr[1] == 0x01) + *exception_code = EXCEPTION_ACCESS_VIOLATION; + break; /* Unable to emulate it */ + } + else + { + FARPROC16 addr = INT_GetPMHandler( instr[1] ); + WORD *stack = get_stack( context ); + /* Push the flags and return address on the stack */ + *(--stack) = LOWORD(context->EFlags); + *(--stack) = context->SegCs; + *(--stack) = LOWORD(context->Eip) + prefixlen + 2; + add_stack(context, -3 * sizeof(WORD)); + /* Jump to the interrupt handler */ + context->SegCs = HIWORD(addr); + context->Eip = LOWORD(addr); + } + return TRUE; +======= if(!Dosvm.EmulateInterruptPM && !DPMI_LoadDosSystem()) ERR("could not initialize interrupt handling\n"); else { @@ -693,6 +716,7 @@ BOOL INSTR_EmulateInstruction( CONTEXT86 return TRUE; } break; /* Unable to emulate it */ +>>>>>>> 1.19 case 0xcf: /* iret */ if (long_op) The second one is pretty ugly since I have not resolved the cvs conflict (I'm waiting for your input :), but the important part is this: + if (long_op) + { + ERR("int 0x%02x from 32-bit code is not supported.\n", instr[1]); + if (instr[1] == 0x01) + *exception_code = EXCEPTION_ACCESS_VIOLATION; + break; /* Unable to emulate it */ + } Here is the EXCEPTION_ACCESS_VIOLATION is returned if interrupt 0x01 is called. This was good when interrupts from 32-bit code were not supported. But now we need a special case for this. I think that on NT calling 0x01 is forbidden. But I have not tested this (and will not, because I dont have windows devel tools - I just want to run my Longman Dictionary :) I would like if this could be fixed properly and that would work with the safedisk patch, if thats possible. Thanks Zsolt

5 4

Re: [linux-audio-dev] Fwd: Opinions on running VST or DirectX plugins on Linux in real time
by Kjetil S. Matheussen 25 Oct '02

25 Oct '02

On 23 Oct 2002, Benno Senoner wrote: > I contacted the author of the VQF plugin about opinions of running > windows plugins under Linux. He is not subscribed to LAD so he told me > to forward this mail to the list. > cheers, > Benno > Interesting. But one idea I just got... Could it be possible to overcome all problems mentioned just by simply adding jack-support to the wine-server? Then someone could make a simple windows-program for chaining directx and vst plug-ins. I dont know how the wine-server works though, so please shout out if its not possible. > On Tue, 22 Oct 2002, Benno Senoner wrote: > > > We are currently discussing about the possibility to run VST or > DirectX audio > > plugins on Linux in real time. > > I remember you wrote an xmms plugin that allowed to run the windows > VQF plugin > > under Linux using wine & co. > > <snip> > > It would be cool if you could write on the linux-audio-dev list about > > experiences in that field. > > I am afraid I will have to keep this short as I'm really busy at the > moment. I also am a long way from being an audio expert or wine so I > doubt > my experiences will be of much use to you hence I didn't subscribe to > the > list . Feel free to forward this to the audio-dev list and cc me on it > if > you wish > > First, the solution I used for the VQF plugin was extremly clunky. There > was no way of letting the plugin run inside XMMS without causing > segfaults. They simply did not merge well no matter what I tried. > > I suspect but never proved that it was how WINE has to lay out it's > memory > to be able to mimic how Windows sees things like segments. The layout is > drastically different to how a Linux app normally sees things. By the > time > a VQF plugin could be loaded, the two very differnet approaches to > managing memory simply did not work well together > > In the end, the solution used was this; > > 1. At XMMS start, fork and exec an application that uses libwine to load > the windows DLL. Communicate with the parent through pipes, sockets > or > shared memory > > 2. Start up XMMS as normal > > 3. The plugin just implements stub functions for every routine a plugin > is > meant to implement and communicates the information to the child > > This had a number of issues. First, it was difficult to get information > from the plugin. It opened the sound device directly itself which meant > that visualisation data was not available. > > At one point, this was resolved by hacking wine itself to write the PCM > data to a named pipe rather than playing to a device but needless to > say, > it was too ugly to live and couldn't really be distributed easily. (I > considered it unreasonable to get users to patch and compile WINE just > to > play a piece of music, visualisations weren't that important). > > If I had a nice plugin, what I would try to do is set up two unamed > pipes > at application start to a child application using libwine. One pipe for > writing would send commands and one pipe for reading would take PCM > data. > I don't know how viable this is for you. > > > I'm not a windows / wine expert but commonsense says me it should be > > possibile to run these windows plugins under Linux in real time with > small > > buffer sizes in order to get low response times (low latency). > > I would be inclined to go the other way. With the above solution, I > would > try and buffer as much data as humanly possible to try and avoid the > overhead of calling wine constantly. For example, I would try and get 10 > seconds worth of data from the windows plugin before starting to play > anything. Once I had the PCM data, it would not matter if the plugin > could > not make real time contraints. > > > It should be possible to let wine handle the GUI stuff . (if word and > excel > > runs then it should be able to run plugin GUIs too). > > It can, but remember that if you are trying to use this plugin with a > normal application, you are likely to run into a lot of trouble. At > least > I did, but this was a few years back. Things might be different now > > I imagine you already have checked out how avifile loads it's plugins. > When I last looked at it (a few years back), it was using a stripped > down > version of WINE to just load the plugins and get the function pointers. > It > might be worth checking into. > > -- > Mel Gorman > MSc Student, University of Limerick > http://www.csn.ul.ie/~mel > > > > >

4 5

Re: Resubmitted - Prefereable GetDateFormatW fix
by Dimitrie O. Paun 25 Oct '02

25 Oct '02

On October 25, 2002 12:39 pm, Medland, Bill wrote: > (Sorry Dimi; it has to be an attachment to stop the mailer wrapping it) No, it doesn't, as long as you set up your mail to not wrap. Or, alternatively, just add it as text/plain, so it is displayed inline. But actually inlining it is better, because people can reply to it, and easily quote the portion of interest. -- Dimi.

1 0

How can an app detect it's running under WINE?
by Alberto Massari 25 Oct '02

25 Oct '02

Hi everybody, I am working on making our software (Stylus Studio, http://www.stylusstudio.com) run under WINE, if this is feasible. To achieve this, I have already implemented a bunch of APIs (the application is built against the UNICODE version of the Win32 APIs) and fixed some bugs I hit (I already mailed the first patch to wine-patches(a)winehq.com). However, I would feel better if I could detect I am running under WINE and gracefully disable some functionalities that are not yet fully supported; is there any way to achieve this? Is there a WIN32 API (like, say, GetVersionEx) that can return a string like "Windows 2000 (WINE)" or is WINE trying to be as stealth as possible? Thanks in advance, Alberto ------------------------------- Alberto Massari eXcelon Corp. http://www.StylusStudio.com

4 3

RE: How can an app detect it's running under WINE?
by Patrik Stridvall 25 Oct '02

25 Oct '02

> --- Patrik Stridvall <ps(a)leissner.se> wrote: > > > So that is why there is no OFFICAL way to detect > > Wine, simple because > > if where was an offical way people could quite > > reasonable complain if > > some change to Wine broke their detection. However > > since there are no > > offical way, they can't complain can they? :-) > > Probably it's time to make an "official" way? No and IMHO there is no reason to have an offical way at all. > This problem appears with each application, ported > with Wine and isn't going to go away even when Wine > will correctly implement all Windows api ;-) If Wine implement every Windows API, why do you care whether you are running under Wine at all? Your application works as good as it does under Windows. Period. Of course you might better intergration with X Windows, printing or whatever to make your application work EVEN BETTER under Wine. :-) Then you have two choice: 1. Recompile your application using Winelib and use Unix API's 2. Under Windows, link with and use some "Wine extension" DLL that are just in many cases "return FALSE; SetLastError(ERROR_NOT_IMPLEMENTED)" on Windows but are implemented on Unix (or some Unixes). Sure (2) currently doesn't exist yet. However it wouldn't be very difficult to do it, if there is need. But no these functions are not for detecting Wine they are for tighter intergration with the underlying "OS" like X Windows, printing or whatever. However this is IMHO far beyond 1.0, so don't hold your breath. But sure if you can name some "Wine extension" API we REALLY need we might do it sooner... PS. Theoretically, the "Wine extensions" DLLs might be implementated on some future version Windows as well and it would be quite ironical if Microsoft did in the future. :-)

1 0

Re: How can an app detect it's running under WINE?
by Alberto Massari 25 Oct '02

25 Oct '02

Hi Andreas, At 03.12 25/10/2002 -0500, you wrote: >Message: 13 >Date: Fri, 25 Oct 2002 10:10:32 +0200 >From: Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> >To: Alberto Massari <alby(a)exln.com> >Cc: wine-devel(a)winehq.com >Subject: Re: How can an app detect it's running under WINE? >Reply-To: andi(a)rhlx01.fht-esslingen.de > >On Fri, Oct 25, 2002 at 09:25:23AM +0200, Alberto Massari wrote: > > Hi everybody, > > I am working on making our software (Stylus Studio, > > http://www.stylusstudio.com) run under WINE, if this is feasible. To > > achieve this, I have already implemented a bunch of APIs (the application > > is built against the UNICODE version of the Win32 APIs) and fixed some > bugs > > I hit (I already mailed the first patch to wine-patches(a)winehq.com). > > > > However, I would feel better if I could detect I am running under WINE and > > gracefully disable some functionalities that are not yet fully supported; > > is there any way to achieve this? Is there a WIN32 API (like, say, > > GetVersionEx) that can return a string like "Windows 2000 (WINE)" or is > > WINE trying to be as stealth as possible? >http://www.winehq.org/FAQ/ would have been answering this in countless >cases already. I'm sorry I asked this here, but the only help I got from the FAQ was: ------ Q: How can I detect Wine? A: You really shouldn't want to do this. If there's a quirk in Wine you need to work around, it's *much* better to fix it in Wine (after all you're a developer, so you should be able to gather enough help and knowledge to fix it for real). If you think you really want to know how to detect it anyway (maybe in order to just have a cool "running on Wine" status text or so), then please mail me. (address-suppressed) ------ So I though I could ask it here.... Alberto ------------------------------- Alberto Massari eXcelon Corp. http://www.StylusStudio.com

4 4

RE: How can an app detect it's running under WINE?
by Patrik Stridvall 25 Oct '02

25 Oct '02

> At 13.22 25/10/2002 +0200, Andreas Mohr wrote: > >On Fri, Oct 25, 2002 at 10:30:15AM +0200, Alberto Massari wrote: > > >[...] > > > >Like someone else said (IIRC), you could check for the existence > >of the Wine configuration registry key branch. That'd be a > 150% reliable > >method of detecting Wine presence. > > > >But again, trying to fix issues would be preferrable. > >(unless there are just too many problems to be fixed) > > Thanks for your answers: we all agree that the best thing to > do is to have > WINE support all the WIN32 API, and mimic all the Windows flavors. > But just like an application calls GetVersionEx to decide how > to behave on > a specific platform, it is perfectly valid for it to try to > detect WINE as > a variant of Windows, and react accordingly. That registry > information is > the right piece of information, as it could also be used to > instruct the > user on the changes needed to make the application work better. Oh sure, you CAN detect Wine if you want, the point is that the Wine project reserves the right to change any behavior at any time for any reason, but most often in order to try to make some application more compatible with Windows. If this breaks your Wine detection, tough. We will not change back because of you. So that is why there is no OFFICAL way to detect Wine, simple because if where was an offical way people could quite reasonable complain if some change to Wine broke their detection. However since there are no offical way, they can't complain can they? :-)

2 1

Whats done? not?
by Christensen Tom 25 Oct '02

25 Oct '02

Obviously wine is still being actively developed, and I know its not close to "done" however, I want to get involved, I know C/C++ and have a pretty good grasp of windows apis, I'm just wondering is there a place (kinda like in the Mono project they have a tree laid out with all of the classes/functions that are in the .NET runtime, and they have them marked done, being worked on, not started...) So I'm wondering if wine has anything similar? or should i just pick a function, and see if its done already by searching through the source? At any rate, wine should have a nice concise place to look and see if wine has certain functions implimented.. Tom _________________________________________________________________ Broadband? Dial-up? Get reliable MSN Internet Access. http://resourcecenter.msn.com/access/plans/default.asp

4 3

Re: How can an app detect it's running under WINE?
by Greg Turner 25 Oct '02

25 Oct '02

On Friday 25 October 2002 03:55 am, Uwe Bonnes wrote: > >>>>> "Greg" == Greg Turner <gmturner007(a)ameritech.net> writes: > Greg> I don't like this solution. Those entries are likely to be > Greg> present in certain shared wine / native windows configurations. > > The "Software\\Wine\\Wine\\Config" tree is read from ~/.wine/config on each > startup and is not written to a .reg file. So if it ret mixed, things are > broken. > > Bye I didn't think of those. you are right, that seems pretty safe. -- gmt "Oh, and of course, the fastest way to dig a tunnel is to dig at both sides." -- The Linux Advanced Routing HOWTO

1 0

Re: How can an app detect it's running under WINE?
by Greg Turner 25 Oct '02

25 Oct '02

On Friday 25 October 2002 02:51 am, Uwe Bonnes wrote: > >>>>> "Alberto" == Alberto Massari <alby(a)exln.com> writes: > > Alberto> Hi everybody, I am working on making our software (Stylus > Alberto> Studio, http://www.stylusstudio.com) run under WINE, if this > is Alberto> feasible. To achieve this, I have already implemented a bunch > Alberto> of APIs (the application is built against the UNICODE version > Alberto> of the Win32 APIs) and fixed some bugs I hit (I already mailed > Alberto> the first patch to wine-patches(a)winehq.com). > > Alberto> However, I would feel better if I could detect I am running > Alberto> under WINE and gracefully disable some functionalities that > are Alberto> not yet fully supported; is there any way to achieve this? Is > Alberto> there a WIN32 API (like, say, GetVersionEx) that can return a > Alberto> string like "Windows 2000 (WINE)" or is WINE trying to be as > Alberto> stealth as possible? > > You can query for example the wine registry entries. > > Bye I don't like this solution. Those entries are likely to be present in certain shared wine / native windows configurations. -- gmt "Oh, and of course, the fastest way to dig a tunnel is to dig at both sides." -- The Linux Advanced Routing HOWTO

1 0

hack to make GrandPrixLegens and N2002 work
by Christoph Frick 25 Oct '02

25 Oct '02

Hi! This is an more or less a straight forward hack to make the game grand prix legends work. It will also effect other games from Papyrus. The game has two problems: 1) It binds more than one time to the same port without doing an SO_REUSEADDR. Acording to UNP it is no big deal to do so - so i just force it. 2) The game sets SO_DONTROUTE on the socket. This works in linux and prevent the user of connecting to games in other networks. Either windows ignores the SO_DONTROUTE or it is not set in native windows or it is ignored. I dont have any opportunity to find out. Another thing is a registry key the game expexcts: [System\\CurrentControlSet\\Services\\Class\\NetTrans\\0000] 1027876728 "IPAddress"="192.168.66.6" It runs with this setting (also N2002); maybe the dontroute problem could also be solved, if the remaining keys to properly define the TCP/IP config for a NIC in windows are set?! So my plea: Could some windows network/socket guru point me in a direction to do further investigations? BTW: i can not imagine this "patch" makes it to the tree - but just to have it said: The patch is under BSD License. CU!

1 0

Re: avoid XF86DGANoDirectVideoMode while detecting no dga
by Lionel Ulmer 25 Oct '02

25 Oct '02

On Thu, Oct 24, 2002 at 04:21:22PM -0500, Greg Turner wrote: > I did not investigate root causes, so someone may know > a better fix. > LICENSE: X11 > CHANGELOG: > * dlls/x11drv/dga2.c: Greg Turner <gmturner(a)ameritech.net> > - avoid X11 error during DGA detection. Grmbl, I must have missed that case when I submitted my fix last time (I only did it in the actual DGA2 usage, not in the 'probing' code). The actual root cause is (for me), a 'feature' in the X server that, instead of reporting the extension as missing on remote clients, report it as being present but then send error messages when trying to use it. Lionel -- Lionel Ulmer - http://www.bbrox.org/

2 1

Services
by Martin Wilck 25 Oct '02

25 Oct '02

I have had a look at dlls/advapi/services.c and found that it is pretty incomplete. Can anybody tell what the current implementation is used for (are there any known programs starting services?) In particular I'd like to know what people generally think about the usefulness of Services in Wine. The fact that wine cannot change user personalities and is lacking most of the NT security concepts makes services pretty useless. However it may be desirable to translate services into something useful on Unix, especially for winelib (it would be useful for the app I am trying to port). Has there been a discussion yet how to set this up without compromising system security? Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

8 22

eTax status report
by Ben Stanley 24 Oct '02

24 Oct '02

Hi, I have now completed using the eTax program from the Australian Taxation Office (http://etax.ato.gov.au) under wine, and have some concluding remarks. * Yellow Note Popups over buttons: these notes pop up almost immediately you put your mouse over a button, and if you click on them, the button does not respond. This causes great user frustration, as you point the mouse at a button, click the mouse, and nothing happens because the popup note appeared and stole the mouse click. Perhaps this could be solved by moving the popup note position so that it's not directly under the mouse pointer? I don't know if this is an etax problem or a wine problem. Workaround: move mouse over button and click again, or be very quick with your mouse click the first time. * ListView (tree): when hovering over items with long names, the same popup note appears, and also greedily steals mouse clicks, preventing you from selecting the item underneath. The note must pass the mouse click through for proper handling by the list item. Workaround: Wait for popup to disappear and then click on list item. * I had some refresh issues with the print preview section of the program. When it draws a page for the first time, all form fields appear to be filled in correctly, but when scrolling the form fields are often left blank when they should be filled in. This may be verified by going forward and then back a page, to force a complete re-draw of the original page, and verifying that fields which were previously blank are now drawn properly. * I didn't try to submit the tax return under wine, as I did not know about the wine integration of the web browser which would be used to perform the submission. (I failed to download the security codes under Mozilla, so I resorted to a Windows box for downloanding security codes and submission.) * Help problems, partly to do with launching winhelp from within etax, and also partly because WINE help can't yet read the etax help file properly. I used etax in the desktop windowing mode, as I had problems with both the managed and unmanaged modes. I set all dlls to builtin (except for "*"). This is the first year that I have been able to use eTax to do the tax return. I want to thank all of the wine contributors for making it possible! Last year I gave up and used a Windows box for the whole thing. Ben Stanley

2 1

Re: Services
by Dustin Navea 24 Oct '02

24 Oct '02

--- Steve Langasek <vorlon(a)dodds.net> wrote: > On Thu, Oct 24, 2002 at 11:19:21AM -0700, Dustin > Navea wrote: > > > --- Steve Langasek <vorlon(a)dodds.net> wrote: > > > On Thu, Oct 24, 2002 at 08:08:49AM -0700, Dustin > > > Navea wrote: > > > > Just as wine should not be run as root, file i/o > in > > > wine should NEVER be > > > done in a security context other than that of > the > > > user running the Windows > > > app. Anything that would cause user data files > to > > > be written out under a > > > different uid is broken. > > > Thats not what I'm saying, what I'm saying is > this: > > Yes, that *is* what you're saying. Having the file > get saved to the Unix > fs with owner and group wine is most definitely a > user data file "[being] > written out under a different uid." That is > absolutely out of the > question. I will never knowingly permit software > that works this way > to be installed on my systems. > Not exactly, because as the fact that wine is the program saving it, and wine is running under user/group wine (in the future), it will save it as user/group wine. > > So he goes and changes the owner/group to > > speeddy/speeddy, oepns the file in kword, adds a > few > > more lines, and saves it. > > Um, and how exactly is this supposed to happen on a > multiuser system? You > *cannot* change the ownership of a file without root > privileges. that is what im saying, he does: sudo chown speeddy.speeddy /path/to/filename At best, > if you have write perms on the directory the file's > in and you have read > access to the file, you can copy the file and delete > the original, giving > you a single copy that's owned by you. But this is > only the least of the > reasons why Windows apps should not be writing to > files as user "wine" to > begin with. I knew that much already ;) But if wine is to run as a "service" (i.e. load at bootup via an initscript) and acutally be functional as well as user-friendly, it will have to run in it's own account, just like apache and pgsql do and like i believe named does... -Dustin __________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/

1 0

Why would Installshield want WINSPOOL.DRV
by David.Goodenough＠DGA.co.uk 24 Oct '02

24 Oct '02

I was asked by my son to install a couple of games for him on his Linux laptop. Wine is installed (at the current Debian unstable level) but when I try to run the installer, which says it is InstallShield, it gets to 99% and stops, and the console says that it can not load WINSPOOL.DRV. Firstly I can think of no good reason for InstallShield to want this (can anyone else, as far as I know this game - Star Trek Elite Force - does not have a print facility), and secondly what do you think is my best route fix the problem. There are some Windows machines (98/ME/NT4) in the house, I am using Win 98 mode in Wine, which machine should I copy WINSPOOL.DRV from if it will help? Thanks in advance David

3 2

Third listview status update
by Dimitrie O. Paun 24 Oct '02

24 Oct '02

Folks, With my latest W-series patches, the listview should now be a pleasure to work with: fast, *no* flicker, etc. It should be a lot better than before I started working on it. If this is not the case (there are regressions, there is nasty flicker *anywhere*, it's slow, or in general it's not a pleasure to interact with it, i.e. you don't get a warm and fuzzy feeling) let me know now. Internally, the code is a lot cleaner. I have started on Sep. 9, 2002, at revision 1.138. A month and a half, and almost 150 revisions later, most of the code has changed multiple times. Large number of visible, and mostly invisible bugs have been fixed, a lot of corner cases covered, features implemented, listview has been made scalable, flicker has been eliminated by redrawing the absolute minimum, etc. We are now on solid ground to implement more stuff. This has been an extenuating exercise. I am tired, and on top of it all, real life has knocked on my door. This does not mean I'll stop working on it, but it probably means that I will not be able to put as much time into it. For the above mentioned reasons, I think it's best for everybody if we stabilize the code as much as possible, before we start working on the large number of missing features. For this I need your help -- the few apps that I test with work just fine now. I would like to thank everybody that helped me with testing, patches, or reporting bugs. I couldn't have done the half of it without that support. This sounds like this is a done deal. It's not. There's a lot of stuff that remains to be done, but I needed some closure. :) -- Dimi.

2 10

Impressive success
by John K. Hohm 23 Oct '02

23 Oct '02

I just got an ATAPI Plextor PlexWriter 40/12/40A (which rocks), and Plextor's Win32-only firmware updater worked flawlessly in wine, a few months old CVS. Kudos to all involved in supporting that sort of access!

2 1

Re: wine not detecting CUPS printers
by Dan Fer 23 Oct '02

23 Oct '02

>From: "Dan Fer" <ezra_daniel(a)hotmail.com> >To: wine-devel(a)winehq.com >Subject: wine not detecting wine printers >Date: Wed, 23 Oct 2002 16:32:09 +0200 > > > > >Has anyone tried using cups under Wine in any of the latest builds? > >I tried to builds from this month and none detect any printer. > >Is there a patch? Anything I could use to fix it? > > > > > > >_________________________________________________________________ >MSN. Más Útil Cada Día http://www.msn.es/intmap/ _________________________________________________________________ Charla con tus amigos en línea mediante MSN Messenger: http://messenger.microsoft.com/es

1 0

Re: French resources
by Vincent Béron 23 Oct '02

23 Oct '02

Le mer 23/10/2002 à 16:09, Vincent Béron a écrit : > This brings some French resources up-to-date with the English ones. > There are 3 resources not yet done: dlls/avifil32/avifil32_Fr.rc, > dlls/comctl32/comctl_Fr.rc and programs/winefile/Fr.rc. > > Plus it corrects a small typo in Shell32_En.rc. > > License: X11 and LGPL, as usual > > Changelog > Bring some French resources in sync with English ones. > > Vincent > ---- > Alexandre, Forget the programs/progman/Fr.rc from this patch. The one you just commited is better. But the rest of the patch is meant to be applied. Do you want me to resend a new one without that file? Vincent

1 0

Re: Re: [linux-audio-dev] Fwd: Opinions on running VST or DirectX plugins
by chrismorgan＠rcn.com 23 Oct '02

23 Oct '02

Just so people don't think the code has fallen off of the face of the planet ;-) Currently I'm working on two things with the wine jack driver , one of which needs to be complete before I submit the patch, the other can wait until some ongoing jack support is complete. 1. The driver currently closes and opens jack connections synchronously with wodOpen and wodClose. The problem is that jack doesn't actually close the clients right away, sometimes it can take many seconds for this to occur. Apparently this is a known jack bug but I'm also wondering if this is a problem in wines pthread implementation of conditions(there is no support for them right now). Either way I've implemented a workaround that basically consists of opening jack connections and marking them as in-use or available as apps open or close audio devices. This behavior can be enabled/disabled via a define in the driver. This isn't complete yet but it should be soon and would prevent the lockups and delays that currently make things a pain. 2. I don't know of an easy way to do resampling so the input audio matches the sample rate that jack expects. What I want is to be able to do something along the lines of: set_sample_rates(input_rate, jack_output_rate); set_resample_algorithm(x); /* pick a reasonable algorithm based on the current cpu and latency requirements */ And then in the callback routine something like: resample(audio_data_in, *audio_data_out); I haven't found anything even close to this simple as of yet, if anyone has any suggestions feel free to mail me about them. There is someone on the jack mailing list working on a resampling library that is supposed to be easy to use and flexable. Either way, this isn't critical although your music sounds funny if your sample rates don't line up very well ;-) Otherwise I'm also looking into a crash with using the jack driver and directsound that might be due to the client process and memory allocation. After working on the arts driver I realized that the future of audio servers really is callback based. It is quite frustrating to see so little use of jack and so much use of poor solutions like direct hardware drivers(alsa/oss) or high latency servers like artsd. No offense intended to people that work on or use either of those audio solutions, it just doesn't make sense when you want to have multiple apps outputting audio at the same time or if you need low latency(high end audio, games?, etc). I'll see what I can do to get things cleaned up and a patch submitted in the next week, conditional of course upon Alexandre accepting jack support into wine. At least now I have someone other than myself with an interest in using jack and wine together ;-) Thanks, Chris > > From: "Kjetil S. Matheussen" <k.s.matheussen(a)notam02.no> > Date: 2002/10/23 Wed PM 12:18:13 EDT > To: linux-audio-dev(a)music.columbia.edu > CC: wine-devel(a)winehq.com > Subject: Re: [linux-audio-dev] Fwd: Opinions on running VST or DirectX plugins > on Linux in real time > > > > On Wed, 23 Oct 2002, Taybin Rutkin wrote: > > > On Wed, 23 Oct 2002, Kjetil S. Matheussen wrote: > > > > > Could it be possible to overcome all problems mentioned just by simply > > > adding jack-support to the wine-server? Then someone could make a simple > > > windows-program for chaining directx and vst plug-ins. > > > > Someone has done this, I believe: > > http://kt.zork.net/wine/wn20021011_139.html#2 > > > Wow, it allready exist. Hey, wine-people, this driver is really needed for > real-time audio-work, and for programs as sound-editors, multitrackers > and interactive dsp programs as pd, jmax, and a lot of others. Artsd > (f.ex) is not an alternative in its current form, and probably never will > be either. Its something else. I guess Paul or some other competant person > can explain a bit more why jack is so important. > > > -- > > > > >

2 1

Re: using native regedit
by Jeff Smith 23 Oct '02

23 Oct '02

I did some testing and found that *\\whatever.exe does not work, while *whatever.exe does. In case anyone thinks to themselves, "but that could cause problems for xwhatever.exe!", I tested further and found that it only affects programs with the name whatever.exe and not those such as xwhatever.exe. -- Jeff S. >We could add this to show different behaviours : > >; you can specify applications too >; This one will apply for all notepad.exe >;"*\\notepad.exe" = "native, builtin" >; This one will apply only for a particular file >;"C:\\regedit.exe" = "native, builtin" > >Is everyone ok ? _________________________________________________________________ Get faster connections -- switch to MSN Internet Access! http://resourcecenter.msn.com/access/plans/default.asp

3 2

Fixing OLE_GetFormatW
by Medland, Bill 23 Oct '02

23 Oct '02

I am just about to fix OLE_GetFormatW. (As far as I can see it can't have worked since rev 1.1). Before correcting the minor error I want to check something. Can anyone with access to NT answer this for me? If you pass a format string to GetDateFormatW that contains time-formatting characters I presume it just throws them away. Similarly if you pass a format string to GetTimeFormatW that contains date-formatting characters I presume it throws them away. Bill

1 0

fairly old wine regression: no$gmb no longer works
by Jonathan Gevaryahu 23 Oct '02

23 Oct '02

In wine builds from early? last year until January 29th, 2002, no$gmb (Nocash gameboy emulator) worked reasonably in wine (yes it would crash if you did 'animate trace' for too long, but that's a seperate issue). the commit which broke it was to wine/dlls/comctl32/status.c, on January 29th at 11:54 am. However, the fix that was done to status.c seems to be valid (later fixes to status.c do the same as what the fix did, I believe), so I suspect that the bug stems from some other issue which causes it to need the incorrect behavior in status.c in order to work. (personally I think it was something done during January that makes it need the incorrect status.c behavior, but I'm probably wrong) The nocash website is http://www.work.de/nocash/ or http://nocash.work.de/ Jonathan Gevaryahu

2 2

Bug tracked down in mci.c
by Erland Lewin 23 Oct '02

23 Oct '02

Hello, I just got the latest wine from cvs, and it crashed when I tried to run Half Life. The problem turned out to be in mci.c, in the mciSendStringA function. The variable lpCmd is set to point into the (in my case mciavi) driver's command table, at the word "open". However, towards the end of the mciSendStringA function, there is the following code: if (strcmp(verb, "open") == 0) { if ((dwRet = MCI_FinishOpen(wmd, (LPMCI_OPEN_PARMSA)data, dwFlags))) MCI_UnLoadMciDriver(iData, wmd); /* FIXME: notification is not properly shared across two opens */ } else { dwRet = MCI_SendCommand(wmd->wDeviceID, MCI_GetMessage(lpCmd), dwFlags, (DWORD)data, TRUE); } TRACE("=> 1/ %lx (%s)\n", dwRet, lpstrRet); dwRet = MCI_HandleReturnValues(iData, dwRet, wmd, lpCmd, data, lpstrRet, uRetLen); The problem is that MCI_UnLoadMciDriver is called, which causes the driver to be removed from memory, which means that lpCmd points to invalid memory. When MCI_HandleReturnValues then tries to use its lpCmd parameter, a segmentation fault will occur, becuase it tries to read from unmapped memory. I did a quick hack to work around the problem (lpCmd = strdup( lpCmd )) before the MCI_FinishOpen. I'd appreciate it if someone else could add a better permanent fix... Thanks for the good work on Wine!

2 1

RE: [RFC] Adding an include/wine/wine directory?
by Patrik Stridvall 23 Oct '02

23 Oct '02

> Actually there is a portable solution. Here's what i did when > I compiled > the Wine tests on Windows: > > Run 'vcvars32.bat' first. When you install Microsoft Visual C++ you > can either tell it to add environment variables with the useful stuff > (either in autoexec.bat or the registry for NT), or just rely on > 'vcvars32.bat'. This script is usually in the include directory: > c:\Program Files\Microsoft Visual Studio\VC98\include\vcvars32.bat > > Well, so I run it on the command line and then in the > makefile (a realy > .mak file) I put: > > INCLUDE=$(TOTOP)\include;$(INCLUDE) > > Then I don't use -I at all and the compiler will automatically use the > environment variable. If using the .mak file directly from the IDE you > don't even need to run vcvars32.bat, First of all I use .dsw/.dsp files not Makefile. OK, they are sort of Makefile but not quite. Secondly the idea is that have different targets so you can easily switch between them. So that does quite cut it. > However I still had include order problems: part of the headers were > coming from MS and part from Wine but did not have time to > look into it > in detail. So I ended up extracting the tests from the Wine > tree. But if > you are able to avoid the header mixup then the above could work. As Alexandre suggested I copied the needed header files. It work eventhough it is a little kludgy. Oh well, it will do for now. Now I just have to properly fix all compile error instead of just kludging them...

1 0

RE: [RFC] Adding an include/wine/wine directory?
by Patrik Stridvall 23 Oct '02

23 Oct '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > Of course compiling every DLL with the Microsoft headers requires > > fixing all of include/wine/ but then as long as we have a solution > > when we get where eventually is good enough IMHO, doing that is no > > particular rush. Having the Wine tests work properly sooner > > rather than later is much more important though. > > I agree getting the Wine tests to work soon is important, but you > don't really need the final header organization for that; you can > easily work around the current problem by copying files around or > specifying an absolute -I option. True. I have already done so. It works. Patch posted to wine-patches. > I don't think we have found a fully satisfying solution yet, and IMO > the situation will be clearer when the dll separation is finished and > the loose ends are cleaned up, so I'd prefer to wait until then to > decide on the final structure. OK. As you wish. > (And my secret hope is that by then we > will be able to switch to Subversion which should make renaming files > a lot easier; but that's another topic...) Ah, nice. :-)

1 0

message box fix.
by Rein Klazes 23 Oct '02

23 Oct '02

Hi, Fix for recent Messagebox breakage. windows/ : msgbox.c In MessageBoxIndirectW call FindResourceEx with arguments in the right order. Rein. -- Rein Klazes rklazes(a)xs4all.nl

2 1

Docu fix for builtin/native apps
by Sylvain Petreolle 23 Oct '02

23 Oct '02

Changelog : Added valid entries into samples/config to specify if an app should be loaded builtin or native. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

wine not detecting wine printers
by Dan Fer 23 Oct '02

23 Oct '02

Has anyone tried using cups under Wine in any of the latest builds? I tried to builds from this month and none detect any printer. Is there a patch? Anything I could use to fix it? _________________________________________________________________ MSN. Más Útil Cada Día http://www.msn.es/intmap/

1 0

Re: Treeview fix
by Jeff Smith 23 Oct '02

23 Oct '02

This patch did the trick. Well I cannot test it at the moment, but as the value INT_MAX (0x7fffffff) was the issue, I know this will fix it. The limit works a lot better (is a lot safer) than the 'special' value. ... - if (i == 0x7fff) + if (i >= 0x7fff) i = hdpa->nItemCount; ... >From: "Dimitrie O. Paun" <dpaun(a)rogers.com> > >On October 23, 2002 01:29 am, Jeff Smith wrote: > > Oops, your previous message got lost in the shuffle... > > I'm sure anything is better than the little patch I wrote. > > I was just taking a minimalist approach to get treeview working. > >No, your patch was quite good. Would have certainly fixed the treeview, >but I think apps depend on the extended behavior. Does my patch fix >the problems you were experiencing? > >-- >Dimi. _________________________________________________________________ Broadband? Dial-up? Get reliable MSN Internet Access. http://resourcecenter.msn.com/access/plans/default.asp

1 0

Re: Treeview fix
by Jeff Smith 23 Oct '02

23 Oct '02

Oops, your previous message got lost in the shuffle... I'm sure anything is better than the little patch I wrote. I was just taking a minimalist approach to get treeview working. -- Jeff S Dimi wrote: >On October 23, 2002 12:44 am, Jeff Smith wrote: > > I discovered treeview uses DSA's and Dimi recently > > changed the max element number in DSA's to 0x7fff (SHRT_MAX). > > Note this value has the special meaning in DSA_InsertPtr > > functions of 'add new element to end of array'. > >This was my initial reaction to this thing, as well. But I >think my fix (sent earlier with Subject DPA_InsertPtr) is >better. Please try it out -- it should fix your problem. > >BTW, I've also audited all other uses of DPA_InsertPtr, >and they are fine. We should be back to normal now (well, >after my patch is applied, of course). > >-- >Dimi. _________________________________________________________________ Surf the Web without missing calls! Get MSN Broadband. http://resourcecenter.msn.com/access/plans/freeactivation.asp

2 1

LogonUser(), netapi work
by Martin Wilck 23 Oct '02

23 Oct '02

Hi, after having been busy with other stuff for a while, I'd like to inquire the status of my LogonUser() patch (http://www.winehq.com/hypermail/wine-devel/2002/09/0448.html) I have had almost no feedback, positive or negative, on this, and it wasn't applied either. I still think it could be useful, although it is clear that wine won't (shouldn't) be able to change personality in the foreseeable future. Andriy, what is the status of your netapi work? Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

2 1

Re: Using winbind with Wine
by Martin Wilck 23 Oct '02

23 Oct '02

Am Mit, 2002-09-25 um 00.55 schrieb Andrew Bartlett: > Firstly, it's good to see that winbind is starting to get some interest > :-) I have been ignoring it so far, but in the context of the current inquiries I tried it out and was impressed :-) > Secondly, don't fall into the trap squid (with my encouragement I might > add...) fell into - don't use the winbind pipe directly. The winbind > API is an internal Samba API, and can change without warning. Hmm - what other APIs are there? The only libraries that are accessible are nss_winbind and pam_winbind. Those two already carry us a long way, BUT ... I started thinking about other options when I found the "wbinfo -n" call. AFAIK there is no way to obtain equivalent info through PAM/NSS, simply because these APIs have no concept of a SID. Obviously apart from the SID there is a lot more information to gather from a PDC. I have not digged deeply enough into this to be able to enumerate everything, but think of the different GetUserInfo() calls on NT. libsmbclient can't be used by wine because it's GPL. And even if we could use it, it's headers only define calls related to shares and printing, which is not what I'm currently aiming at. > As to unicode, I > have designated one call as being in utf8, to cope with external > interaction, so it's possible things can happen here. What matters to wine is that if a call goes like this: Windows app <-> wine <-> PAM or other API <-> winbind <-> RPC <-> Windows server, we must ensure that the Unicode string wine receives from the app reaches the server ungarbled. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

8 12

Marshalling code for me to use?
by Greg Turner 23 Oct '02

23 Oct '02

Before I go off and duplicate a bunch of work somebody already did, I wanted to verify that wine has no existing implementation of NDR data marshalling? I don't know of such a thing, but I don't necessarily have the big picture. rpcrt4 needs this for somewhat obvious reasons, and the format is well documented by OpenGroup if we need to start an implementation from scratch. -- gmt

4 8

another snapshot (F_PL1_pre1)
by Greg Turner 23 Oct '02

23 Oct '02

relative to yesterday's RPC_E_PL15_unmerged.diff. LICENSE: X11 CHANGELOG: * dlls/rpcrt4: ndr_marshall.c, ndr_midl.c, ndr_misc.h, rpcrt4_main.c, ndr_stubless.c; include: rpcndr.h, wine/rpcfc.h: Greg Turner <gmturner007(a)ameritech.net> - make explicit some hidden include dependencies - Implement NdrGetBuffer, NdrFreeBuffer, NdrConformantStringBufferSize and NdrConformantStringMarshall - define the RPC_FC_C_CSTRING constant - perhaps I don't want those MIDL_*_FORMAT_STRING structs, after all. removed. - add todo list - MIDL_STUB_MESSAGE.uFlags aren't. - comment out the NdrClientCall2 mock-up since some of that stuff is in the process of being implemented. -- gmt "Oh, and of course, the fastest way to dig a tunnel is to dig at both sides." -- The Linux Advanced Routing HOWTO

1 0

Treeview fix
by Jeff Smith 23 Oct '02

23 Oct '02

Intro: Once I got wine to finally execute the native regedit, treeview was bringing it down. Background: I discovered treeview uses DSA's and Dimi recently changed the max element number in DSA's to 0x7fff (SHRT_MAX). Note this value has the special meaning in DSA_InsertPtr functions of 'add new element to end of array'. Problem: INT_MAX (0x7fffffff) was being passed from treeview to DSA_InsertPtr. This caused failure returns and eventually a seg fault. Conclusion: This patch fixes the problem (according to the style of other calls to DSA_InsertPtr), and native regedit now works. Questions for further thought: I wonder, should 0x7fff be used explicitly, or should SHRT_MAX be used in places like this instead? Changelog: Treeview fix due to change in maximum DSA size. -- Jeff S. Index: dlls/comctl32/treeview.c =================================================================== RCS file: /home/wine/wine/dlls/comctl32/treeview.c,v retrieving revision 1.103 diff -u -r1.103 treeview.c --- dlls/comctl32/treeview.c 6 Sep 2002 19:41:18 -0000 1.103 +++ dlls/comctl32/treeview.c 23 Oct 2002 04:12:53 -0000 @@ -949,7 +949,7 @@ if (!newItem) return NULL; - if (DPA_InsertPtr(infoPtr->items, INT_MAX, newItem) == -1) + if (DPA_InsertPtr(infoPtr->items, 0x7fff, newItem) == -1) { COMCTL32_Free(newItem); return NULL; @@ -2885,7 +2885,7 @@ for (child = item->firstChild; child != NULL; child = child->nextSibling) { - if (DPA_InsertPtr(list, INT_MAX, child) == -1) + if (DPA_InsertPtr(list, 0x7fff, child) == -1) { DPA_Destroy(list); return NULL; _________________________________________________________________ Get faster connections -- switch to MSN Internet Access! http://resourcecenter.msn.com/access/plans/default.asp

2 1

Re: using native regedit
by Jeff Smith 23 Oct '02

23 Oct '02

I agree that the example should be changed to indicate a 'valid' entry if this is the way it is supposed to be. This would have saved me a lot of trouble and confusion. Now I can work on getting native regedit working again. -- Jeff S. >Shouldn't we update the sample entry in documentation/sample/config ? > > ; you can specify applications too >-"*\\notepad.exe" = "native, builtin" >+"notepad.exe" = "native, builtin" > ; default for all other dlls > "*" = "builtin, native" > > > It's the way it's supposed to work, because it mimics the way > > loadorder works for dlls: a simple "regedit.exe" matches only if > > regedit is in the system directory. Otherwise you need to specify the > > full path, or use a wildcard entry like "*regedit.exe". > > > > -- > > Alexandre Julliard > > julliard(a)winehq.com _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

2 1

Re: using native regedit
by Jeff Smith 23 Oct '02

23 Oct '02

Found something: it works if I fully qualify the command name. I was trying this in the DllOverrides / command-line respectively: "regedit.exe" = "native, builtin" --dll regedit.exe=n,b What I have to do for it to work is this: "C:\\Windows\\regedit.exe" = "native, builtin" --dll C:\\Windows\\regedit.exe=n,b I still do not think this is *exactly* as it should be, but I'm finally on the track to figuring it out. -- Jeff S. _________________________________________________________________ Broadband? Dial-up? Get reliable MSN Internet Access. http://resourcecenter.msn.com/access/plans/default.asp

3 2

[RFC] Adding an include/wine/wine directory?
by Patrik Stridvall 23 Oct '02

23 Oct '02

As some of you probably know I have been working on compiling Wine on Windows using Microsoft Visual C/C++ (MSVC). Even though it doesn't really work that well yet there have been at least some success. Anyway recently I have began trying to get the Wine tests to compile and work using MSVC. More specifically I have been trying to get the my generated tests for data structure packing (tests/generated.c) to work. This currently works quite well. A few patches regarding errors found coming soon. However there are at least two intresting ways to compile and run the tests on Windows. 1. Compile using the Wine headers. 2. Compile using the Microsoft headers. Currently only (1) works in a portable way. To get (2) to work I had to add the directory of the Microsoft includes to the begining of the include path. This is not very portable since it differs from installation to installation. I have currently hardcoding my specific directory. The above have to be done because the Wine tests includes include/wine/test.h as thus ..\..\..\include (or similar depending on directory depth have to be added the the include). This overides the Microsoft headers!!! Microsoft C unlike GNU C have no option to avoid this other than adding the path the Microsoft include directory which as I previously mention varies depend on installation. :-) However I finally think I have found a portable solution, that will work not only with the Wine test but also with Wine itself (eventhough that is perhaps less instresting right now). We currently have the directory structure like include: Wine's version of Windows headers include/wine: Wine's internal and "extension" headers I would like to have a directory structure like include: Wine's version of Windows headers include/wine: Wine's internal headers include/wine/wine: Wine's "extension" headers With "extension" headers I mean that headers that are exported and usuable by Winelib applications. This would allow me to, using MSVC, just do /I ..\..\..\include\wine instead of the current very ugly and unportable /I d:\program files\microsoft visual studio\vc98\include /I ..\..\..\include So concretely what I think needs to be done (not tested) is the following. cd include/wine mkdir wine mv exception.h test.h unicode.h wine # Then include/Makefile.in needs to be changed accordingly as well. # In principle all the include/wine/ files named in include/Makefile.in # should be moved as well. However the files named above is enough for # the Wine tests AFAICS. --- Make.rules.in 19 Oct 2002 17:15:00 -0000 1.131 +++ Make.rules.in 21 Oct 2002 12:58:35 -0000 @@ -45,7 +45,7 @@ LN = @LN@ LN_S = @LN_S@ TOOLSDIR = @TOOLSDIR@ -DIVINCL = -I$(SRCDIR) -I. -I$(TOPSRCDIR)/include -I$(TOPOBJDIR)/include $(EXTRAINCL) +DIVINCL = -I$(SRCDIR) -I. -I$(TOPSRCDIR)/include -I$(TOPOBJDIR)/include -I$(TOPSRCDIR)/include/wine $(EXTRAINCL) ALLCFLAGS = $(DIVINCL) $(CFLAGS) $(DEFS) $(OPTIONS) LD = @LD@ LDFLAGS = @LDFLAGS@ So what do you think? Note that compiling Winelib applications under Linux might benefit from this as well since it makes it easier to use the real Microsoft headers together the Wine extensions (wine/*.h). Sure currently GNU C chokes on this but one day some compiler (GNU C or some other) might not...

3 2

RE: [RFC] Adding an include/wine/wine directory?
by Patrik Stridvall 22 Oct '02

22 Oct '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > We could do that following instead: > > (1) /usr/include/wine => /usr/include/wine/windows > > (2) /usr/include/wine/wine => /usr/include/wine/windows/wine > > (3) /usr/include/wine/wine/wine => /usr/include/wine > > > > Also note (2) will disappear eventually. > > Well, it's somewhat better, but it's still too complex IMO. Where is the complexity? If you want to port a Window application, you add -I/usr/include/wine/windows and everything as much as like under Windows as possible. If you in addition wish to call some Wine "extension" no problem just do #include "wine/foo.h" or similar. If you just want to use the Windows API in an Unix application you need anything at all. Just do #include "wine/windows/wincrypt.h" and you're done. [Linking is a separate problem, of course. But then, this changes nothing as far as this is concerned] > Maybe what > we should do is put the (3) headers directly in /usr/include, like > /usr/include/wine_unicode.h. But this would work only if we don't have > many of them, so we probably want to work on simplifying this first. I can't see any principal difference between /usr/include/wine_foo.h or /usr/include/wine/foo.h None of them requires any -I. It is more a convention that if you have many .h you have a directory, if not, well then you can have a directory anyway, it is up to you. > Also note that this is not going to solve your problem, because > wine/test.h is more a category (2) header Well wine/test.h is really kind of a special case anyway it could be moved to programs/winetest/include/wine or something under whatever name it is not really a concern. Perhaps we should move programs/winetest/wtmain.c to test/ and make it a library similar to library/ and unicode/. This is what I did with MSVC, eventhough I did it in programs/winetest instead. > (or maybe you need a new > category for Wine internal headers that don't get installed). You mean for files like windef16.h? Well, in the long run such files really belongs in the dlls/* directories. In the extent that that can't they really are Wine "extension" that might as well be used by any Winelib application not just internally should IMHO be installed. But yes, we certainly need some place to put them in the meantime, since this isn't happing over night. However I think that they can remain in include/wine/ until we move them one by one. See below. > > PS. Of course we could move include/*.h to include/wine/windows or > > something like that but then it is no real use and beside it ruins > > the cvs patch log. Better stick to the ugly include/wine/wine > > solution interally IMHO. > > Not an option. If we have to move the files we'll move them; it's > better to avoid moving things around too much. but we shouldn't let > CVS limitations impose a broken structure. OK. > Now if we can find a non > broken structure that also doesn't involve moving files that's better. Perhaps this would work: mkdir library/wine mv include/wine/{library,port}.h library/wine mkdir unicode/wine mv include/wine/unicode.h unicode/wine mkdir dlls/ntdll/wine mv include/wine/exception.h dlls/ntdll/wine Sure it would mean a few more -I internally but it would not be that bad. Then during install all these files as well as some files from include/wine/ ends up in /usr/include/wine and the include/ files end up in /usr/include/wine/windows or /usr/include/wine/win32 not sure what is best. That would require moving a minimum of files. As before eventually far in the future include/wine/ would be empty. Transition done. We needn't move everything right now either. As mentioned before running the Wine test with the Microsoft headers currently AFAICS only requires that we fix wine/{exception,test,unicode}.h. Of course compiling every DLL with the Microsoft headers requires fixing all of include/wine/ but then as long as we have a solution when we get where eventually is good enough IMHO, doing that is no particular rush. Having the Wine tests work properly sooner rather than later is much more important though.

3 2

using native regedit
by Jeff Smith 22 Oct '02

22 Oct '02

3 2

Re: updated dlls/comctl32/commctrl.c comments
by Dimitrie O. Paun 22 Oct '02

22 Oct '02

On October 22, 2002 03:02 pm, Christian Neumair wrote: > Dimitrie started posting a header doc patch for listview.c, so I got > motivated and wrote the same thing for commctrl.c. > I hope it's complete. Thanks, Chris. In many respects, this is more important than code. For many reasons I will not go into here, I think it is vital that we have a header giving a _clear_ pictures of what remains to be done. I just hope others will do the same. -- Dimi.

1 0

Re: Don't return FILE_ATTRIBUTE_SYMLINK
by Dimitrie O. Paun 22 Oct '02

22 Oct '02

On October 22, 2002 04:25 pm, Medland, Bill wrote: > diff105.diff Can you please insert such files in the body of the message? It gets combersome to review patches in attachments... -- Dimi.

1 0

RE: [RFC] Adding an include/wine/wine directory?
by Patrik Stridvall 22 Oct '02

22 Oct '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > I suggest that we gradually move the files in include/wine > > to include/wine/wine or in some cases other places like the DLL > > directories. Eventually, far in the future, the > include/wine directory > > will be empty (save for a wine directory). > > > > This provides a slow and steady migration path from the old > > to the new that doesn't have any of the problems you described. > > What more can you ask for? > > A clean solution? Seriously this is ugly as hell; It would have been nice if had been cleaner yes, but then you can't have everything can you? :-) Seriously, I think we can do a little better. See below. > especially when you > consider that after you install you will get Wine headers in > /usr/include/wine, /usr/include/wine/wine and > /usr/include/wine/wine/wine. Correct. [I think we understand each other at least this time] > Tell me this isn't confusing... First of all you have /usr/include/wine and /usr/include/wine/wine even today. Which already is a little confusing. But hey it works for most thing so I'm not complaining that much. But yes, it is a little confusing. Hmm. Thinking.... We could do that following instead: (1) /usr/include/wine => /usr/include/wine/windows (2) /usr/include/wine/wine => /usr/include/wine/windows/wine (3) /usr/include/wine/wine/wine => /usr/include/wine Also note (2) will disappear eventually. This would be very nice since now normal Winelib applications ie ports from Windows can do -I/usr/include/wine/windows regardless of whether they use the Wine "extensions" or not since #include "wine/test.h" for example will work without a -I. "Special" Winelib application could do #include "wine/windows/wincrypt.h" without any -I if somebody for example wanted to use the Windows encryption API in a normal Unix application. Hmm. Perhaps /usr/include/wine/windows should be /usr/include/wine/win32 instead, with perhaps /usr/include/wine/windows as symbolic link to /usr/include/wine/win32. But that is just details, what do you think in principle. > If you really want to make it possible to mix and match headers from > different sources, you need a more serious redesign of the whole > include layout, and you need to ensure that the normal case is at > least as easy and clean as it is today. I think the suggestion above would do nicely. Internally in the wine tree I think we might have to choose the ugly include/wine/wine solution, but we could install to the solution above which is what's really important. PS. Of course we could move include/*.h to include/wine/windows or something like that but then it is no real use and beside it ruins the cvs patch log. Better stick to the ugly include/wine/wine solution interally IMHO.

2 1

An RPC progress report
by Greg Turner 22 Oct '02

22 Oct '02

On Tuesday 22 October 2002 12:47 pm, you wrote: > Greg - > > I've been following the RPC merges lately, > looks like a lot of stuff added. I browsed > the code, but I couldn't really get a grasp > on some of it. That's OK, I'm not sure /I've/ got a grasp on some of it !! ;) > I was just wondering if > you'd like to write an update (short, long, > whatever) about what you've done, what's left > to do, major stumbling blocks, etc. I'll > include it in the next issue of Wine Weekly > News. Above what Ove already implemented, I really haven't done all that much. Frankly, in its current state, it is quite possible that the RPC work I am doing will /detract/ from the stability of wine, until the implementation is more complete. RPC is painfully complicated, and a victim of serious creeping featurism. Microsoft makes it worse by providing poorly documented extentions to the protocol, and a largely undocumented marshalling API (much of which developers typically don't have to learn because the API calls are generated by the MIDL compiler). My target right now is to get a "hello world" API invocation to work across processes using wine RPC. Once that is achieved, I plan to create a unit test for this. Then, we'll have a framework that we can begin to extend and implement "properly." I am not there yet, but I think I'm getting close. I just have to implement marshalling for strings, which, in theory, looks pretty easy. There are probably many bugs that need squashing before it works, and maybe some additional gaps in functionality that I don't even realize exist yet... but I do think I'm pretty near. Now, what remains to be done? Well, as Ove mentions in the TODO for his units, "a whole lot." Here are several things in no particular order: - widl is like MIDL for wine. For wine to be a useful RPC platform, quite a bit of work needs to be done here. widl currently doesn't generate stubs for RPC invocation -- it will need to; this is tricky because the MIDL compiler does some really wierd stuff. Then again, we don't neccesarily have to make widl work like MIDL, so it could be worse. - RPC has a quite featureful error handling mechanism; none of it is implemented right now. - The server portions of the patch don't seem to be getting accepted by Alexandre. My guess is that once I have a working test he'll conceed to let this in. To implement this properly is tricky and possibly beyond my abilities; Ove seems to think the right way to do this is to use LPC (Local Procedure Call, another undocumented monster). LPC has no implementation in wine and is not going to be trivial to create. - there are several different memory allocation schemes for MSRPC. I don't even understand what they all are yet, much less have them properly implemented. - MSRPC provides impersonation capabilities which currently are not possible to implement in wine. - Some transports are not yet implemented. The existing transport implementations are incomplete. (By transports I mean, tcp/ip, named-pipes, local procedure call, etc --- the various types of low-level plumbing that can be used to connect the client and the server). - Data marshalling is the means by which RPC represents data across process and machine boundaries. MSRPC extends NDR format for this. The wire protocol is mostly documented, but the MS API's to convert data-types in memory into NDR are not. This, alone, is a sizable chunk of work. - ORPC is RPC for OLE; once we have a working RPC framework, we can use it to implement out-of-process OLE client/server communications. This will be a huge win for wine. But again, it's a lot of work, and I'm no OLE expert (hell, I'm no RPC expert :) - Surely there is much more stuff I am forgetting. Like Ove said, it's "a whole lot" of stuff, approximately as big a project as, say, DirectX. Basically, RPC for wine is a huge beast of a project. IMO it is probably the biggest and most difficult-to-fill hole in wine's feature-completeness ATM. In the short term, don't expect any miracles --- I really doubt that I'm going to "solve" this (in my spare time!) anytime soon. But, once I start getting some results, I imagine others will be enticed to help out, as contributors like Ove already have. (To be clear: Ove enticed me, not the other way around: He did all the "real" work, and deserves way more credit than me for any success I may achieve in the near future). wish me luck, -- gmt "Oh, and of course, the fastest way to dig a tunnel is to dig at both sides." -- The Linux Advanced Routing HOWTO

2 2

Re: using native regedit
by Jeff Smith 22 Oct '02

22 Oct '02

Thanks for the advice, this should get me by for now. Of course I would still like DllOverrides section to work as advertised, but maybe I can hack on it some more when I am more in the mood. P.S. Sorry about the HTML message, the Hotmail admins seem to be playing around with default settings. -- Jeff S. >From: Greg Turner To: "Jeff Smith" , wine-devel(a)winehq.com On Tuesday 22 >October 2002 01:01 pm, Jeff Smith wrote: > I know I must be missing > >something very simple, but I cannot seem to > > get native regedit to run. The builtin version always > runs instead. >The only thing I could think of was an entry > in DllOverrides: > > "regedit.exe" = "native, builtin". That did not work. > > > I have debugged a little and know MODULE_GetLoadOrder > is returning >{LOADORDER_BI, LOADORDER_DLL, LOADORDER_INVALID, > LOADORDER_INVALID} even >when I add that DllOverride line. > But I am just not in the mood at the >moment for deep digging if > I can help it. > -- Jeff S. >Well, if my wetware HTML parser is working today, I think I understand your >problem. Just rename regedit.exe to "winregedit.exe" (or whatever you >like), or create a symlink or copy of the native version. (some configs >don't respect symlinks). > >-- >gmt _________________________________________________________________ Surf the Web without missing calls! Get MSN Broadband. http://resourcecenter.msn.com/access/plans/freeactivation.asp

1 0

RE: [RFC] Adding an include/wine/wine directory?
by Patrik Stridvall 22 Oct '02

22 Oct '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > Perhaps (2) and (3) are not much different (se below), > > but (1) and (2/3) are clearly different. > > Well yes, that why they are in different directories. (1) is in > include and (2/3) is in include/wine. Yes, but because of how they are positioned in the filesystemet and used by C they are effectively "packaged together" in a bad way. It seems that I'm not the only one having this problem as well. Steven Edwards also wants a way to use the Mingw/W32api package together with Wine in a sane way. But I have a plan how to smoothly migrated from the current layout to a new layout. See below. > > That is why I think "-I../../include" shouldn't automatically give > > you (2) and (3) as it does now. Having to add -I../../include/wine > > or whatever to get it would make it possible in addition to > > solving my MSVC Microsoft header problem to make it possible to > > uses the Microsoft headers or whomevers headers even on Linux. > > The problem is that then you require everybody who wants to use > Winelib to add stuff to their include path, even if they don't use any > Wine header directly (since our Windows headers reference the Wine > ones). They currently do, yes. That is why I initially suggested creating a include/wine/wine and only moving the "extension" headers like over to include/wine/wine. The "extension" headers are files in include/wine like debug.h, exception.h, library.h, port.h, server.h, test.h, unicode.h that isn't or shouldn't be included by our Windows headers. In the extent that they are it is a bug IMHO and AFAICS one that is quite easily fixed in most cases as well. However, in the first phase to get the all the tests running I AFAICS only need exception.h, test.h and unicode.h. Of them only unicode.h is currently used by the Wine headers (file.h and heap.h). However fixing that shouldn't really be a problem. I will look into it. I suggest that we gradually move the files in include/wine to include/wine/wine or in some cases other places like the DLL directories. Eventually, far in the future, the include/wine directory will be empty (save for a wine directory). This provides a slow and steady migration path from the old to the new that doesn't have any of the problems you described. What more can you ask for? > So you are making the normal case more complex to simplify the > very unusual case of mixing headers. I prefer to ask people who want > to mix headers to do some extra steps and make the common case as easy > as possible. As stated above the problem can be solved. Wine itself is AFAIU (not tested) fixed by this patch. Nothing more should be needed. Index: Make.rules.in =================================================================== RCS file: /home/wine/wine/Make.rules.in,v retrieving revision 1.131 diff -u -r1.131 Make.rules.in --- Make.rules.in 19 Oct 2002 17:15:00 -0000 1.131 +++ Make.rules.in 22 Oct 2002 09:02:33 -0000 @@ -45,7 +45,7 @@ LN = @LN@ LN_S = @LN_S@ TOOLSDIR = @TOOLSDIR@ -DIVINCL = -I$(SRCDIR) -I. -I$(TOPSRCDIR)/include -I$(TOPOBJDIR)/include $(EXTRAINCL) +DIVINCL = -I$(SRCDIR) -I. -I$(TOPSRCDIR)/include -I$(TOPOBJDIR)/include -I$(TOPSRCDIR)/include/wine $(EXTRAINCL) ALLCFLAGS = $(DIVINCL) $(CFLAGS) $(DEFS) $(OPTIONS) LD = @LD@ LDFLAGS = @LDFLAGS@ Normal Winelib application have shouldn't (and needn't) use the Wine "extension" header so they don't need the in the include path them. The few application that does, can be very easily fixed simply by adding an additional -I, which isn't to much to ask IMHO.

3 2

Problem with X11 driver
by Till Mossakowski 22 Oct '02

22 Oct '02

Hi, I have a problem with the X11 driver (it seems), related to bug 1027. When I run my program (Fitch.exe), wine gets stuck. All threads do a WaitForMultipleObjects, the main thread a WaitMessage. And I get an error err:ntdll:RtlpWaitForCriticalSection section 0x40af4b04 "x11drv_main.c: X11DRV_CritSection" wait timed out, retrying (60 sec) tid=080b8780 I read the FAQ about critical section errors, and it helped my to get the following calling stack: KERNEL32.DLL.WaitForMultipleObjectsEx+0x16a X11DRV.DLL.MsgWaitForMultipleObjectsEx+0xf3 USER32.DLL.MsgWaitForMultipleObjectsEx+0x14f USER32.DLL.WaitMessage+0x22 WINAWT.DLL.PrintEmbeddedFrame+0x7ca JAVAI.DLL.mmiFrameMethod+0x3625 JAVAI.DLL.mmiFrameMethod+0xb60 COMDLG32.DLL.PrintDlgExW+0x2a2dc0 JPEG.DLL..reloc+0x12e2cb9b *** Invalid address 0xc308c483 (IBMJITC.DLL..reloc+0x1df5f482) (Indeed, Fitch is written in Java - however, unfortunately it is not possible to run it directly under Linux. I also tried to get diagnostic messages from the Java runtime systems, but it seems that all classes are loaded correctly, and then the error occurs.) When I set "Synchronous" = "Y" in the x11drv section of config, everything works, but *very* slowly. Sometimes it takes 15 seconds until a mouse click leads to the desired action. I also played with the other x11drv settings in the config file, but without effect. The documentation says that one should set "Synchronous" = "Y" for debugging purposes. But how proceed then? Greetings, Till -- Till Mossakowski Phone +49-421-218-4683 Dept. of Computer Science Fax +49-421-218-3054 University of Bremen till(a)tzi.de P.O.Box 330440, D-28334 Bremen http://www.tzi.de/~till

2 7

OleAut32.dll.DispCallFunc
by Fabian Cenedese 22 Oct '02

22 Oct '02

Hi all My app stumbled over a not implemented function from oleaut32.dll called DispCallFunc. It's only available as stub. I tried to find some info about this but it's an undocumented "feature". MSDN doesn't mention it at all (obviously) and on the net I could only find this short description: *** ITypeInfo::Invoke (or DispInvoke) needs v-table to call-in a method. But when we are talking about pure disp-interfaces - they don't have any info about v-table, but just a mapping between DISPID and method signature. Therefore these functions would fail miserably to convey the call to pure dispinterface, but as all we know - the majority of sources(/events) interfaces are these pesky dispinterfaces. DispCallFunc is a low-level routine (that btw is used by DispInvoke and ITypeInfo::Invoke internally). It pushes arguments from DISPPARAMS argument to the stack accordingly to supplied description of the method, calls specified function pointer and on the return adjusts stack back and return retval (both variant and HRESULT) to the caller. *** And I also found this example: *** //Helper for invoking the event HRESULT InvokeFromFuncInfo(void (__stdcall T::*pEvent)(), _ATL_FUNC_INFO& info, DISPPARAMS* pdispparams, VARIANT* pvarResult) { T* pT = static_cast<T*>(this); VARIANTARG** pVarArgs = info.nParams ? (VARIANTARG**)alloca(sizeof(VARIANTARG*)*info.nParams) : 0; for (int i=0; i<info.nParams; i++) pVarArgs[i] = &pdispparams->rgvarg[info.nParams - i - 1]; CComStdCallThunk<T> thunk; thunk.Init(pEvent, pT); CComVariant tmpResult; if (pvarResult == NULL) pvarResult = &tmpResult; HRESULT hr = DispCallFunc( &thunk, 0, info.cc, info.vtReturn, info.nParams, info.pVarTypes, pVarArgs, pvarResult); ATLASSERT(SUCCEEDED(hr)); return hr; } *** Does anyone know more about this function? Where would this have to be implemented? Thanks bye Fabi

2 1

Re: MZ_Exec() patch, try 3
by Jukka Heinonen 22 Oct '02

22 Oct '02

The patch starts to look good, only one tiny thing left: you most likely want to return FALSE from MZ_Exec if CreateProcessA fails. If you want to read all comments to posts on wine-devel you have to take into account different time zones and different mail reading habits - waiting 24 hours should be enough to get replies from all active readers during weekdays. But, anyway, good to see I didn't scare you by being critical :) -- Jukka Heinonen <http://www.iki.fi/jhei/>

1 0

VS6 Package & Deployment Wizard regression
by Ender 22 Oct '02

22 Oct '02

Oddly, some recent change has broken some of the command buttons in VS6's Package/Deployment wizard's dialogs.. Does anyone have any suggestions on what'd be some good traces to turn on? Or want to fix it themselves? <grin> - Ender

1 0

RE: [RFC] Adding an include/wine/wine directory?
by Patrik Stridvall 22 Oct '02

22 Oct '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > I would like to have a directory structure like > > > > include: Wine's version of Windows headers > > include/wine: Wine's internal headers > > include/wine/wine: Wine's "extension" headers > > > > With "extension" headers I mean that headers that > > are exported and usuable by Winelib applications. > > That's ugly IMO. The specific solution above, perhaps. However I think it would be very useful to make a proper distinction between 1. The Wine version of Microsoft headers 2. Anything that Wine uses to communicate internal 3. Extensions that Winelib applications can use. Perhaps (2) and (3) are not much different (se below), but (1) and (2/3) are clearly different. That is why I think "-I../../include" shouldn't automatically give you (2) and (3) as it does now. Having to add -I../../include/wine or whatever to get it would make it possible in addition to solving my MSVC Microsoft header problem to make it possible to uses the Microsoft headers or whomevers headers even on Linux. > Besides there is no such distinction between internal > and "extension" headers, all the headers in include/wine are supposed > to be usable by Winelib app. Sure there are. Not all header from include/wine are copied to /usr/local/include/wine/wine during. The ones that are not copied are "internal" and the ones there are are "extensions" in some meaning. Only the "exension" headers (ie header that are copied during install) can be used by Winelib applications. However that might perhaps only be a temporary distiction. Anyway cd include/wine mkdir wine mv *.h wine work for me as well if you prefer that. > I'd suggest you simply copy the ones you > need with MSVC somewhere else to avoid conflicts. Hmm. Yes, that is another possibillity (read: kludge). Don't really like copying source files around, but it would work (with the possible exception of dependecies, but then "Rebuild all" is your friend :-). In short: I still think that we should require another -I to access the Wine specific (internal and extension) headers. However I don't really care if we do (1) -I$(TOPSRCDIR)/include -I$(TOPSRCDIR)/include/wine (2) -I$(TOPSRCDIR)/include -I$(TOPSRCDIR)/$(WHATEVER) I just don't think just doing -I$(TOPSRCDIR)/include like now is good for the reasons given above and below. Sometime you only want the Wine specific header sometimes you only want Wine's version of the Windows header. "Forcing" everybody to take them as a package only gives rise to unnessary problem like the one I'm trying to solve. Sure I could kludge it, but why not try to solve it properly?

3 2

MZ_Exec() patch, try 3
by chrismorgan＠rcn.com 22 Oct '02

22 Oct '02

Alright, yet another revision of this patch. This one uses dynamic memory allocation via HeapAlloc/Free(), doesn't modify the input command line and doesn't try to close process handles if CreateProcess failed. Third time a charm? ;-) * dlls/winedos/module.c: Chris Morgan <cmorgan(a)alum.wpi.edu> Call CreateProcessA() when executing non-dos applications from a dos application. Index: dlls/winedos/module.c =================================================================== RCS file: /home/wine/wine/dlls/winedos/module.c,v retrieving revision 1.23 diff -u -r1.23 module.c --- dlls/winedos/module.c 18 Oct 2002 23:48:58 -0000 1.23 +++ dlls/winedos/module.c 21 Oct 2002 22:00:16 -0000 @@ -339,17 +339,78 @@ /*********************************************************************** * MZ_Exec + * + * this may only be called from existing DOS processes */ BOOL WINAPI MZ_Exec( CONTEXT86 *context, LPCSTR filename, BYTE func, LPVOID paramblk ) { - /* this may only be called from existing DOS processes - * (i.e. one DOS app spawning another) */ - /* FIXME: do we want to check binary type first, to check - * whether it's a NE/PE executable? */ + DWORD binType; + STARTUPINFOA st; + PROCESS_INFORMATION pe; + BOOL status; + HANDLE hFile = CreateFileA( filename, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, 0); BOOL ret = FALSE; + + if(!GetBinaryTypeA(filename, &binType)) /* determine what kind of binary this is */ + { + return FALSE; /* binary is not an executable */ + } + if (hFile == INVALID_HANDLE_VALUE) return FALSE; + + /* handle non-dos executables */ + if(binType != SCS_DOS_BINARY) + { + if(func == 0) /* load and execute */ + { + LPBYTE fullCmdLine; + WORD fullCmdLength; + LPBYTE psp_start = (LPBYTE)((DWORD)DOSVM_psp << 4); + PDB16 *psp = (PDB16 *)psp_start; + ExecBlock *blk = (ExecBlock *)paramblk; + LPBYTE cmdline = PTR_REAL_TO_LIN(SELECTOROF(blk->cmdline),OFFSETOF(blk->cmdline)); + LPBYTE envblock = PTR_REAL_TO_LIN(psp->environment, 0); + BYTE cmdLength = cmdline[0]; + + fullCmdLength = (strlen(filename) + 1) + cmdLength + 1; /* filename + space + cmdline + terminating null character */ + + fullCmdLine = HeapAlloc(GetProcessHeap(), 0, fullCmdLength); + + /* build the full command line from the executable file and the command line being passed in */ + snprintf(fullCmdLine, fullCmdLength, "%s ", filename); /* start off with the executable filename and a space */ + memcpy(fullCmdLine + strlen(fullCmdLine), cmdline + 1, cmdLength); /* append cmdline onto the end */ + fullCmdLine[fullCmdLength - 1] = 0; /* null terminate string */ + + ZeroMemory (&st, sizeof(STARTUPINFOA)); + st.cb = sizeof(STARTUPINFOA); + status = CreateProcessA (NULL, fullCmdLine, NULL, NULL, TRUE, + 0, envblock, NULL, &st, &pe); + + WaitForSingleObject(pe.hProcess, INFINITE); /* wait here until the child process is complete */ + + HeapFree(GetProcessHeap(), 0, fullCmdLine); /* free the memory we allocated */ + + /* clean up PROCESS_INFORMATION handles if necessary */ + if(status) + { + CloseHandle(pe.hProcess); + CloseHandle(pe.hThread); + } + + ret = TRUE; + } else + { + FIXME("EXEC type of %d not implemented for non-dos executables\n", func); + ret = FALSE; + } + + CloseHandle(hFile); + return ret; + } /* if(binType != SCS_DOS_BINARY) */ + + /* handle dos executables */ switch (func) { case 0: /* load and execute */ case 1: /* load but don't execute */

3 4

Re: Listview V15
by Bobby Bingham 21 Oct '02

21 Oct '02

On Mon, Oct 21, 2002 at 10:51:35AM -0400, Dimitrie O. Paun wrote: > > ChangeLog > Updated header documentation to the latest, and greatest. > <snip> > + * -- LVIS_ACTIVATING (not currently supported my comctl32.dll version 6.0) you mean "by" comctl32.dll version 6.0 ? <snip> > + * -- LVN_BEGINDRAG, LVN_BEGINRDRAG hmmm ... how about "LVN_BEGINFRAG, LVN_ENDDRAG" -- Bobby Bingham

2 2

compile with -DSTRICT
by Michael Stefaniuc 21 Oct '02

21 Oct '02

Hello, i'm not 100% sure what -DWINE_NO_STRICT should do, but i suspect it should negate the effect of -DSTRICT. The attached patch enables that and lets wine compile with -DSTRICT where WINE_NO_STRICT isn't defined. Comments? bye michael P.S.: is this -DSTRICT a m$ windows thing or a wine only thing? -- 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

Small DDraw problem...
by Lionel Ulmer 21 Oct '02

21 Oct '02

Hi all, I looked at this problem a long time and did not find what the problem is... So I ask for the help of people here :-) Some TRACE extracts : trace:ddraw:DirectDrawCreate ((null),0x406a2b80,(nil)) trace:ddraw:DDRAW_Create Returning interface 0x403b48bc | the DirectDraw interface trace:ddraw:Main_DirectDraw_QueryInterface (0x403b48b0)->({9c59509a-39bd-11d1-8c4a-00c04fd930c5},0x406a2b84) trace:ddraw:Main_DirectDraw_QueryInterface Returning interface 0x403b48b4 | the DirectDraw4 interface trace:ddraw:IDirectDraw4Impl_CreateSurface thunking interface 0x403b48b4 trace:ddraw:Main_DirectDraw_CreateSurface (0x403b48b0)->(0x406a2ae0,0x415712dc,(nil)) So the surface is created using the DirectDraw4 interface and not the DirectDraw one returned by DirectDrawCreate. trace:ddraw:User_DirectDrawSurface_Construct (0x403b4c68,0x403b48b0,0x406a29d8) | the DirectDrawSurface4 interface trace:ddraw:Main_DirectDrawSurface_GetAttachedSurface (0x403b4c68)->Looking for caps: 4,400c97f1,40380000,403b4bc0 output: 0x415712e0 So we clearly see that the application is giving us a DDSCAPS structure and NOT a DDSCAPS2 as it should be for a DirectDrawSurface4 interface (because by 'hacking' the code by checking only dwCaps, the game goes further). So : 1) it is a bug in the game (and it works fine in Windows because, miraculously, the three others words of the 'fake' DDSCAPS2 structure are set to '0' or because Windows only checks with 'dwCaps' and not with all 'dwCaps' fields). 2) somehow the docs are wrong and it should be a DirectDrawSurface that is returned by a CreateSurface even if the CreateSurface is called on a DirectDraw4 interface... I would be glad for any help... Trying to go further with my hack in place :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

2 2

Second Listview status update
by Dimitrie O. Paun 21 Oct '02

21 Oct '02

Folks, The listview should now be better than before I started working on it. If there are regressions, I would like to know about them. During my work, the REPORT mode got a lot faster rendering. The Q-series patches undoes partly those speed enhancements. However, the situation is temporary, and when I'm done with it, we'll have pretty much as fast a rendering as possible. For this to happen, I need to do a bit more infrastructure work. Namely, we have to keep track of column information, such as rect, alignment, etc. This will no only speed up report rendering, it will allow us to have icons for subitems as well (most of the work for this is actually done, I just need a place to put the on/off flag). Once this is done, we can start working on actually adding features. And there are a _lot_ of features that we're missing. But this is another story! :) My aim here is to bring the listview to a solid foundation that can take all these new features without turning it into something (1) buggy, (2) unmanageable, and (3) slow. There is one more infrastructure bit that may need to be done. That is, we may need to keep an ordered array of item positions in LVS_{,SMALL}ICON modes. Currently, we don't have something like this, and as a result we need to iterate over the entire item set in the above mentioned modes. This works for a small number of items, but when we have 10s of thousands, or millions, or what have you of items, it will blow chunks. The good thing is that all the iterator work that I've done lately nicely separates all these details away from the code. So it can wait for now. So once again, I am interested to hear about regressions. I think the code reached a state where we can concentrate on cleaning up our act, before adding new features. -- Dimi.

3 19

WM_COPYDATA linear/SEGPTR crash
by Andreas Mohr 21 Oct '02

21 Oct '02

Hi all, Dr. Hardware crashes like that: Backtrace: 0 0x0297:0x01c0 1 0x00f7:0x0000 2 WINPROC_CallWndProc16+0x211(proc=0x2970186, hwnd=0xa4, msg=WM_COPYDATA, wParam=0xab, lParam=0x403cbc48) 3 WINPROC_CallProc32WTo16+0x99(...., , wParam=0x200ab, ...) 4 CallWindowProcW+0x6f(func=0x4ce0458, hwnd=0x400a4, msg=WM_COPYDATA,wParam=0x200ab, lParam=0x403cbc48) 5 call_window_proc(...) 6 MSG_peek_message+0x409(msg=0x410b2a74, hwnd=0x0, first=0x0, last=0xffffffff, flags=1) 7 PeekMessageW+0x7c(msg_out=0x410b2b78, hwnd=0x0, first=0x0, last=0x0) 8 GetMessageW(msg=0x410b2b78, hwnd=0x0, first=0x0, last=0x0) 9 GetMessage32_16(msg16=0x403c9698, hwnd16=0, first=0, last=0, wHaveParamHigh=0) 10 GetMessage16(msg=0x403c9698, hwnd=0, first=0, last=0) 11 __wine_user_exe_CallFrom16_p_word_pwww.... 0x0297:0x01c0: lesw 0x104a,%bx Wine-dbg>x/2w 0x2af:0x104a 0x02a:0x104a: bc48 403c (sound familiar ?) To me it's obvious what's happening. Now the obvious question is: how to fix this problem ? (i.e.: where is some kind of translation missing ?) -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://mohr.de.tt

1 0

RE: LVM_* defs
by Patrik Stridvall 21 Oct '02

21 Oct '02

> Can anyone help me with the definition of these > listview messages? TIA. [snip] grep LVM_ commctrl.h | grep define #define LVM_FIRST 0x1000 // ListView messages #define LVM_SETUNICODEFORMAT CCM_SETUNICODEFORMAT #define LVM_GETUNICODEFORMAT CCM_GETUNICODEFORMAT #define LVM_GETBKCOLOR (LVM_FIRST + 0) #define LVM_SETBKCOLOR (LVM_FIRST + 1) #define LVM_GETIMAGELIST (LVM_FIRST + 2) #define LVM_SETIMAGELIST (LVM_FIRST + 3) #define LVM_GETITEMCOUNT (LVM_FIRST + 4) #define LVM_GETITEMA (LVM_FIRST + 5) #define LVM_GETITEMW (LVM_FIRST + 75) #define LVM_GETITEM LVM_GETITEMW #define LVM_GETITEM LVM_GETITEMA #define LVM_SETITEMA (LVM_FIRST + 6) #define LVM_SETITEMW (LVM_FIRST + 76) #define LVM_SETITEM LVM_SETITEMW #define LVM_SETITEM LVM_SETITEMA #define LVM_INSERTITEMA (LVM_FIRST + 7) #define LVM_INSERTITEMW (LVM_FIRST + 77) #define LVM_INSERTITEM LVM_INSERTITEMW #define LVM_INSERTITEM LVM_INSERTITEMA #define LVM_DELETEITEM (LVM_FIRST + 8) #define LVM_DELETEALLITEMS (LVM_FIRST + 9) #define LVM_GETCALLBACKMASK (LVM_FIRST + 10) #define LVM_SETCALLBACKMASK (LVM_FIRST + 11) #define LVM_GETNEXTITEM (LVM_FIRST + 12) #define LVM_FINDITEMA (LVM_FIRST + 13) #define LVM_FINDITEMW (LVM_FIRST + 83) #define LVM_FINDITEM LVM_FINDITEMW #define LVM_FINDITEM LVM_FINDITEMA #define LVM_GETITEMRECT (LVM_FIRST + 14) #define LVM_SETITEMPOSITION (LVM_FIRST + 15) #define LVM_GETITEMPOSITION (LVM_FIRST + 16) #define LVM_GETSTRINGWIDTHA (LVM_FIRST + 17) #define LVM_GETSTRINGWIDTHW (LVM_FIRST + 87) #define LVM_GETSTRINGWIDTH LVM_GETSTRINGWIDTHW #define LVM_GETSTRINGWIDTH LVM_GETSTRINGWIDTHA #define LVM_HITTEST (LVM_FIRST + 18) #define LVM_ENSUREVISIBLE (LVM_FIRST + 19) #define LVM_SCROLL (LVM_FIRST + 20) #define LVM_REDRAWITEMS (LVM_FIRST + 21) #define LVM_ARRANGE (LVM_FIRST + 22) #define LVM_EDITLABELA (LVM_FIRST + 23) #define LVM_EDITLABELW (LVM_FIRST + 118) #define LVM_EDITLABEL LVM_EDITLABELW #define LVM_EDITLABEL LVM_EDITLABELA #define LVM_GETEDITCONTROL (LVM_FIRST + 24) #define LVM_GETCOLUMNA (LVM_FIRST + 25) #define LVM_GETCOLUMNW (LVM_FIRST + 95) #define LVM_GETCOLUMN LVM_GETCOLUMNW #define LVM_GETCOLUMN LVM_GETCOLUMNA #define LVM_SETCOLUMNA (LVM_FIRST + 26) #define LVM_SETCOLUMNW (LVM_FIRST + 96) #define LVM_SETCOLUMN LVM_SETCOLUMNW #define LVM_SETCOLUMN LVM_SETCOLUMNA #define LVM_INSERTCOLUMNA (LVM_FIRST + 27) #define LVM_INSERTCOLUMNW (LVM_FIRST + 97) # define LVM_INSERTCOLUMN LVM_INSERTCOLUMNW # define LVM_INSERTCOLUMN LVM_INSERTCOLUMNA #define LVM_DELETECOLUMN (LVM_FIRST + 28) #define LVM_GETCOLUMNWIDTH (LVM_FIRST + 29) #define LVM_SETCOLUMNWIDTH (LVM_FIRST + 30) #define LVM_GETHEADER (LVM_FIRST + 31) #define LVM_CREATEDRAGIMAGE (LVM_FIRST + 33) #define LVM_GETVIEWRECT (LVM_FIRST + 34) #define LVM_GETTEXTCOLOR (LVM_FIRST + 35) #define LVM_SETTEXTCOLOR (LVM_FIRST + 36) #define LVM_GETTEXTBKCOLOR (LVM_FIRST + 37) #define LVM_SETTEXTBKCOLOR (LVM_FIRST + 38) #define LVM_GETTOPINDEX (LVM_FIRST + 39) #define LVM_GETCOUNTPERPAGE (LVM_FIRST + 40) #define LVM_GETORIGIN (LVM_FIRST + 41) #define LVM_UPDATE (LVM_FIRST + 42) #define LVM_SETITEMSTATE (LVM_FIRST + 43) #define LVM_GETITEMSTATE (LVM_FIRST + 44) #define LVM_GETITEMTEXTA (LVM_FIRST + 45) #define LVM_GETITEMTEXTW (LVM_FIRST + 115) #define LVM_GETITEMTEXT LVM_GETITEMTEXTW #define LVM_GETITEMTEXT LVM_GETITEMTEXTA #define LVM_SETITEMTEXTA (LVM_FIRST + 46) #define LVM_SETITEMTEXTW (LVM_FIRST + 116) #define LVM_SETITEMTEXT LVM_SETITEMTEXTW #define LVM_SETITEMTEXT LVM_SETITEMTEXTA #define LVM_SETITEMCOUNT (LVM_FIRST + 47) #define LVM_SORTITEMS (LVM_FIRST + 48) #define LVM_SETITEMPOSITION32 (LVM_FIRST + 49) #define LVM_GETSELECTEDCOUNT (LVM_FIRST + 50) #define LVM_GETITEMSPACING (LVM_FIRST + 51) #define LVM_GETISEARCHSTRINGA (LVM_FIRST + 52) #define LVM_GETISEARCHSTRINGW (LVM_FIRST + 117) #define LVM_GETISEARCHSTRING LVM_GETISEARCHSTRINGW #define LVM_GETISEARCHSTRING LVM_GETISEARCHSTRINGA #define LVM_SETICONSPACING (LVM_FIRST + 53) #define LVM_SETEXTENDEDLISTVIEWSTYLE (LVM_FIRST + 54) // optional wParam == mask #define LVM_GETEXTENDEDLISTVIEWSTYLE (LVM_FIRST + 55) #define LVM_GETSUBITEMRECT (LVM_FIRST + 56) #define LVM_SUBITEMHITTEST (LVM_FIRST + 57) #define LVM_SETCOLUMNORDERARRAY (LVM_FIRST + 58) #define LVM_GETCOLUMNORDERARRAY (LVM_FIRST + 59) #define LVM_SETHOTITEM (LVM_FIRST + 60) #define LVM_GETHOTITEM (LVM_FIRST + 61) #define LVM_SETHOTCURSOR (LVM_FIRST + 62) #define LVM_GETHOTCURSOR (LVM_FIRST + 63) #define LVM_APPROXIMATEVIEWRECT (LVM_FIRST + 64) #define LVM_SETWORKAREAS (LVM_FIRST + 65) #define LVM_GETWORKAREAS (LVM_FIRST + 70) #define LVM_GETNUMBEROFWORKAREAS (LVM_FIRST + 73) #define LVM_GETSELECTIONMARK (LVM_FIRST + 66) #define LVM_SETSELECTIONMARK (LVM_FIRST + 67) #define LVM_SETHOVERTIME (LVM_FIRST + 71) #define LVM_GETHOVERTIME (LVM_FIRST + 72) #define LVM_SETTOOLTIPS (LVM_FIRST + 74) #define LVM_GETTOOLTIPS (LVM_FIRST + 78) #define LVM_SORTITEMSEX (LVM_FIRST + 81) #define LVM_SETBKIMAGEA (LVM_FIRST + 68) #define LVM_SETBKIMAGEW (LVM_FIRST + 138) #define LVM_GETBKIMAGEA (LVM_FIRST + 69) #define LVM_GETBKIMAGEW (LVM_FIRST + 139) #define LVM_SETSELECTEDCOLUMN (LVM_FIRST + 140) #define LVM_SETTILEWIDTH (LVM_FIRST + 141) #define LVM_SETVIEW (LVM_FIRST + 142) #define LVM_GETVIEW (LVM_FIRST + 143) #define LVM_INSERTGROUP (LVM_FIRST + 145) #define LVM_SETGROUPINFO (LVM_FIRST + 147) #define LVM_GETGROUPINFO (LVM_FIRST + 149) #define LVM_REMOVEGROUP (LVM_FIRST + 150) #define LVM_MOVEGROUP (LVM_FIRST + 151) #define LVM_MOVEITEMTOGROUP (LVM_FIRST + 154) #define LVM_SETGROUPMETRICS (LVM_FIRST + 155) #define LVM_GETGROUPMETRICS (LVM_FIRST + 156) #define LVM_ENABLEGROUPVIEW (LVM_FIRST + 157) #define LVM_SORTGROUPS (LVM_FIRST + 158) #define LVM_INSERTGROUPSORTED (LVM_FIRST + 159) #define LVM_REMOVEALLGROUPS (LVM_FIRST + 160) #define LVM_HASGROUP (LVM_FIRST + 161) #define LVM_SETTILEVIEWINFO (LVM_FIRST + 162) #define LVM_GETTILEVIEWINFO (LVM_FIRST + 163) #define LVM_SETTILEINFO (LVM_FIRST + 164) #define LVM_GETTILEINFO (LVM_FIRST + 165) #define LVM_SETINSERTMARK (LVM_FIRST + 166) #define LVM_GETINSERTMARK (LVM_FIRST + 167) #define LVM_INSERTMARKHITTEST (LVM_FIRST + 168) #define LVM_GETINSERTMARKRECT (LVM_FIRST + 169) #define LVM_SETINSERTMARKCOLOR (LVM_FIRST + 170) #define LVM_GETINSERTMARKCOLOR (LVM_FIRST + 171) #define LVM_SETINFOTIP (LVM_FIRST + 173) #define LVM_GETSELECTEDCOLUMN (LVM_FIRST + 174) #define LVM_ISGROUPVIEWENABLED (LVM_FIRST + 175) #define LVM_GETOUTLINECOLOR (LVM_FIRST + 176) #define LVM_SETOUTLINECOLOR (LVM_FIRST + 177) #define LVM_CANCELEDITLABEL (LVM_FIRST + 179) #define LVM_MAPINDEXTOID (LVM_FIRST + 180) #define LVM_MAPIDTOINDEX (LVM_FIRST + 181) #define LVM_SETBKIMAGE LVM_SETBKIMAGEW #define LVM_GETBKIMAGE LVM_GETBKIMAGEW #define LVM_SETBKIMAGE LVM_SETBKIMAGEA #define LVM_GETBKIMAGE LVM_GETBKIMAGEA

1 0

LVM_* defs
by Dimitrie O. Paun 21 Oct '02

21 Oct '02

Can anyone help me with the definition of these listview messages? TIA. LVM_CANCELEDITLABEL LVM_CREATEDRAGIMAGE LVM_ENABLEGROUPVIEW LVM_GETBKIMAGE LVM_GETGROUPINFO LVM_GETGROUPMETRICS LVM_GETINSERTMARK LVM_GETINSERTMARKCOLOR LVM_GETINSERTMARKRECT LVM_GETOUTLINECOLOR LVM_GETSELECTEDCOLUMN LVM_GETTILEINFO LVM_GETTILEVIEWINFO LVM_GETUNICODEFORMAT LVM_GETVIEW LVM_HASGROUP LVM_INSERTGROUP LVM_INSERTGROUPSORTED LVM_INSERTMARKHITTEST LVM_ISGROUPVIEWENABLED LVM_MAPIDTOINDEX LVM_MAPINDEXTOID LVM_MOVEGROUP LVM_MOVEITEMTOGROUP LVM_REMOVEALLGROUPS LVM_REMOVEGROUP LVM_SETBKIMAGE LVM_SETGROUPINFO LVM_SETGROUPMETRICS LVM_SETINFOTIP LVM_SETINSERTMARK LVM_SETINSERTMARKCOLOR LVM_SETOUTLINECOLOR LVM_SETSELECTEDCOLUMN LVM_SETTILEINFO LVM_SETTILEVIEWINFO LVM_SETTILEWIDTH LVM_SETTOOLTIPS LVM_SETUNICODEFORMAT LVM_SETVIEW LVM_SETWORKAREAS LVM_SORTGROUPS LVM_SORTITEMSEX -- Dimi.

1 0

Msg help
by Dimitrie O. Paun 21 Oct '02

21 Oct '02

Anyone know the message name for the codes: 2486 2793 The progress bar receives them, and complains because it doesn't know what they are... -- Dimi.

1 0

RtlAllocateHeap crash
by Dimitrie O. Paun 21 Oct '02

21 Oct '02

While I was playing around with Newsbin Pro, I stumbled over this: Unhandled exception: page fault on write access to 0x0000000c in 32-bit code (0x400c2eaa). In 32-bit mode. 0x400c2eaa (RtlAllocateHeap+0xda [heap.c:1039] in libntdll.dll.so): movl %eax,0xc(%edx) 1040 pArena->prev->next = pArena->next; Is it worth investigating? -- Dimi.

1 0

Re: WebBrowser
by Dimitrie O. Paun 21 Oct '02

21 Oct '02

On October 19, 2002 03:27 am, Malte Starostik wrote: > ChangeLog > * Fixed IWebBrowser::Navigate() parameter type > * Added IWebBrowserApp and related typedefs BTW, any taker on implementing IWebBrowser & Co. in terms of the Gecko API, so we can get Mozilla working through Wine? -- Dimi.

3 4

Re: glibc 2.3 pthread patch
by Alexandre Julliard 20 Oct '02

20 Oct '02

Ove Kaaven <ovehk(a)ping.uio.no> writes: > Now that glibc 2.3 is available for those bleeding-edge folks on debian > unstable, it seems that Wines compiled on 2.2 won't run on 2.3 systems. > The glibc folks did warn us about this a while ago though, so here's a > patch that implements their suggestion for making wine compatible with as > many glibc versions as possible. Perhaps Alexandre wants to use his > WINE_GET_SONAME stuff to detect the name of the libc at configure time > instead of at runtime like I do, though. Funny, I was working on the same thing right now... But do you really need to fetch the real libc handle? It seems to me RTLD_NEXT should be enough. Here's how I did it: Index: scheduler/pthread.c =================================================================== RCS file: /opt/cvs-commit/wine/scheduler/pthread.c,v retrieving revision 1.26 diff -u -r1.26 pthread.c --- scheduler/pthread.c 12 Sep 2002 22:07:06 -0000 1.26 +++ scheduler/pthread.c 20 Oct 2002 21:45:13 -0000 @@ -38,13 +38,6 @@ #include "thread.h" #include "winternl.h" -static int init_done; - -void PTHREAD_init_done(void) -{ - init_done = 1; -} - /* Currently this probably works only for glibc2, * which checks for the presence of double-underscore-prepended * pthread primitives, and use them if available. @@ -62,28 +55,18 @@ asm(".globl " PSTR(alias) "\n" \ "\t.set " PSTR(alias) "," PSTR(orig)) -/* strong_alias does not work on external symbols (.o format limitation?), - * so for those, we need to use the pogo stick */ -#if defined(__i386__) && !defined(__PIC__) -/* FIXME: PIC */ -#define jump_alias(orig, alias) __ASM_GLOBAL_FUNC( alias, "jmp " PSTR(orig)) -#endif +static int init_done; -/* get necessary libc symbols */ -#if (__GLIBC__ == 2) && (__GLIBC_MINOR__ >= 1) && defined(HAVE___LIBC_FORK) -#define LIBC_FORK __libc_fork -#define PTHREAD_FORK __fork -#define ALIAS_FORK -#else -#define LIBC_FORK __fork -#define PTHREAD_FORK fork -#endif -extern pid_t LIBC_FORK(void); +static pid_t (*libc_fork)(void); +static int (*libc_sigaction)(int signum, const struct sigaction *act, struct sigaction *oldact); + +void PTHREAD_init_done(void) +{ + init_done = 1; + if (!libc_fork) libc_fork = dlsym( RTLD_NEXT, "fork" ); + if (!libc_sigaction) libc_sigaction = dlsym( RTLD_NEXT, "sigaction" ); +} -#define LIBC_SIGACTION __sigaction -extern int LIBC_SIGACTION(int signum, - const struct sigaction *act, - struct sigaction *oldact); /* NOTE: This is a truly extremely incredibly ugly hack! * But it does seem to work... */ @@ -255,15 +238,20 @@ } strong_alias(__pthread_atfork, pthread_atfork); -pid_t PTHREAD_FORK(void) +pid_t __fork(void) { pid_t pid; int i; + if (!libc_fork) + { + libc_fork = dlsym( RTLD_NEXT, "fork" ); + assert( libc_fork ); + } EnterCriticalSection( &atfork_section ); /* prepare handlers are called in reverse insertion order */ for (i = atfork_count - 1; i >= 0; i--) if (atfork_prepare[i]) atfork_prepare[i](); - if (!(pid = LIBC_FORK())) + if (!(pid = libc_fork())) { InitializeCriticalSection( &atfork_section ); for (i = 0; i < atfork_count; i++) if (atfork_child[i]) atfork_child[i](); @@ -275,9 +263,7 @@ } return pid; } -#ifdef ALIAS_FORK -strong_alias(PTHREAD_FORK, fork); -#endif +strong_alias(__fork, fork); /***** MUTEXES *****/ @@ -658,13 +644,20 @@ /***** ANTI-OVERRIDES *****/ /* pthreads tries to override these, point them back to libc */ -#ifdef jump_alias -jump_alias(LIBC_SIGACTION, sigaction); -#else int sigaction(int signum, const struct sigaction *act, struct sigaction *oldact) { - return LIBC_SIGACTION(signum, act, oldact); + if (!libc_sigaction) + { + libc_sigaction = dlsym( RTLD_NEXT, "sigaction" ); + assert( libc_sigaction ); + } + return libc_sigaction(signum, act, oldact); +} + +#else /* __GLIBC__ */ + +void PTHREAD_init_done(void) +{ } -#endif #endif /* __GLIBC__ */ -- Alexandre Julliard julliard(a)winehq.com

2 2

Known listview problems
by Dimitrie O. Paun 20 Oct '02

20 Oct '02

Folks, Things look pretty good on the listview front. In fact, I am kindda happy the way things are, as the S-series patches were rather tricky at points... Currently, I know of the following problems: -- Newsbin dies swiftly (reported my Rein Klazes) -- FTPCommander seems to experience some listview-related faults (reported by Carlos Lozano) -- Xnews has some minor focus rectangle problems (discovered by myself :)) -- IDAdemo _may_ have some minor drawing glitches (ditto) At this point, I would like to ask everybody that is aware of a listview problem to report it. I might not be able to put as much time, and effort into listview, as I did lately, so the more of a complete picture I have now, the better the chances that I'm gonna fix it. Next on my TODO: -- Fix Newsbin's crash (BTW, Rein I need a new trace with the latest CVS, if possible) -- Store per-column info into the listview (see the second status update for details) If you feel that there is a particular are of the listview that needs attention, let me know so I can work it into my TODO, time permitting. -- Dimi.

3 6

configuration
by Eric Pouech 20 Oct '02

20 Oct '02

I dunno if Alexandre will like this patch, but - when compiling with --disable-win16 turned on - the glue generation is based on the C_SRCS16 files as well as the C_SRCS - this, of course, brings in lots of unneed imports (triggered by the non needed glue code) the attached patch, when wine compilation is configured with --disable-win16, removes all 16 bit .c files from the inspection for glue generation this might not be sufficient: - the .glue.c file is generated in any case - however, it should compile as an empty compilation unit A+ Index: configure.ac =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/configure.ac,v retrieving revision 1.84 diff -u -r1.84 configure.ac --- configure.ac 10 Oct 2002 17:54:28 -0000 1.84 +++ configure.ac 20 Oct 2002 17:43:53 -0000 @@ -25,10 +25,12 @@ AC_SUBST(OPTIONS) AC_SUBST(WIN16_FILES,"\$(WIN16_FILES)") AC_SUBST(WIN16_INSTALL,"\$(WIN16_INSTALL)") +AC_SUBST(C_SRCS16,"\$(C_SRCS16)") if test "x$enable_win16" = "xno" then WIN16_FILES="" WIN16_INSTALL="" + C_SRCS16="" fi if test "x$enable_debug" = "xno" then Index: dlls/Makedll.rules.in =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/dlls/Makedll.rules.in,v retrieving revision 1.36 diff -u -r1.36 Makedll.rules.in --- dlls/Makedll.rules.in 2 Oct 2002 02:34:10 -0000 1.36 +++ dlls/Makedll.rules.in 20 Oct 2002 17:42:51 -0000 @@ -37,7 +37,7 @@ # Rule for 16-bit glue $(MODULE).glue.c: $(C_SRCS) $(C_SRCS16) $(WINEBUILD) - $(LDPATH) $(WINEBUILD) $(DEFS) -o $@ -glue -C$(SRCDIR) $(C_SRCS) $(C_SRCS16) + $(LDPATH) $(WINEBUILD) $(DEFS) -o $@ -glue -C$(SRCDIR) $(C_SRCS) @C_SRCS16@ # Rules for .dll files

2 1

Listview regression
by David D. Hagood 20 Oct '02

20 Oct '02

I've just applied/built/installed/tested the U series patches, and I have 2 regressions in the AAA MapNGo program: First, the first column of the directions window (which shows the type of road) is missing. Second, when I do the "Along the way", the program cores out. The log, and a screen cap showing (or rather, NOT showing) the missing field in the directions window, are in a tarball: http://sktc.net/~wowbagger/listview3.tar.gz

2 10

Fw: Wine problem
by Leonardo Bocalon 20 Oct '02

20 Oct '02

Hello it´s me again , i tried the procedure that you told me to do, I downloaded the last version of the wine, i installed it and still not working the keyboard display. Trying to explain to you more specifically the problem I´m going to send you the log which was the problem!!(I compacted whit .lha). I also want to know how to register (use) the files virtual drivers ( VXD)! Thanks again for you atention. Leonardo Bocalon Sysmo Informática / Brasil ----- Original Message ----- From: "Andreas Mohr" <andi(a)rhlx01.fht-esslingen.de> To: "Leonardo Bocalon" <leonardo(a)sysmo.com.br> Cc: <wine-devel(a)winehq.com> Sent: Wednesday, October 16, 2002 4:16 AM Subject: Re: Wine problem > On Tue, Oct 15, 2002 at 01:50:19PM -0300, Leonardo Bocalon wrote: > > Ac wine programers !! > > I am from a software company and we have a problem, our software communicate with a keyboard which has a display this software is make using Delphi (by borland) and for cominicate with the keyboard we use assembler code , wile we run the software in windows it work perfectly but when we try to use it in Linux using the wine it dosen´t work (the keyboard display). > > > > Please a need a sulution for it !!!! > Please retry with latest Wine CVS if you haven't yet, then add a BugZilla report > describing the problem if it still persists. > Attach screenshots if useful and maybe already add some log file like: > wine --debugmsg +relay,+event,+key,+keyboard MyPrg.exe &>/tmp/winekey.log > > -- > Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany > Tel. +49 7159 800604 http://mohr.de.tt

5 4

Re: DPA_InsertPtr (A1)
by Dimitrie O. Paun 20 Oct '02

20 Oct '02

On October 20, 2002 12:33 pm, Paul Rupe wrote: > I was just looking at this same problem. Should we not also remove the > line hdpa->nItemCount++? DPA_SetPtr already does this (which is why we > needed the -1 you added), so I think we end up incrementing it twice. You are correct. I've actually sent the patch in about 5minutes ago ... :) > For comparison, here's the patch I was about to send (relative to the first > comctl32undoc.c patch): Yup, that's what we need to end up with. -- Dimi.

1 0

Re: InstallShield
by Jeff Smith 20 Oct '02

20 Oct '02

Already running builtin ole32/oleaut32/rpcrt4. I have stdole2.tlb and stdole32.tlb, but no tbl files. Am I missing something? Any further thoughts? BTW, the only command-line message I get is: "fixme:seh:check_resource_write Broken app is writing to the resource data, enabling work-around" - Thanks - Jeff S. > >>>>> "Jeff" == Jeff Smith <whydoubt(a)hotmail.com> writes: > > Jeff> Trying to install the Music Ace Demo (harmonicvision.com), I get > Jeff> stopped by a messagethat "The InstallShield Engine (iKernel.exe) > Jeff> could not be installed. (0x20)" > > Jeff> I think someone said DCOM98 needs to be installed for > Jeff> InstallShield to work properly, so I did, and nothing changed. > >Have native stdole*.tbl available in the system directory and run with >builtin ole32/oleaut32/rpcrt4. Has been told uqite often... > >Bye >-- >Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de _________________________________________________________________ Get a speedy connection with MSN Broadband. Join now! http://resourcecenter.msn.com/access/plans/freeactivation.asp

2 1

DOS/Win16 interrupt handling architecture
by Jukka Heinonen 20 Oct '02

20 Oct '02

I have been thinking about interrupt handling in Wine because it needs some reworking in order to get DPMI32 programs to work. I have formed a proposal for refactoring current interrupt handling code and I would like to get some comments about this scheme before I decide whether I want to work on it or not. So, my proposal is to move all interrupt handlers to winedos dll and have only single interrupt handler routine per interrupt, instead of having separate real and protected mode handlers. If an interrupt occurs in protected mode ntdll would just load winedos and call single function from winedos that simulates the interrupt. A list of some things pro and con the proposal: + Win32 programs don't care about interrupt handlers. It would seem reasonable to think that many Win16 programs don't need them either. Also, architectures not supporting DOS/Win16 probably don't want to have any interrupt code. + Real and protected mode interrupt handlers are heavily interconnected. For example, protected mode handlers already serve both real mode and protected mode interrupts. MSDN documentation also says that nearly all interrupts under Win16 work just like they do under DOS real mode. + Differences in handling interrupts depend more on whether we are running DOS or Windows process than on whether the interrupt was called from real or protected mode. + We would only have one place that handles interrupts. This should make it easier to maintain interrupt code. + DLL separation would be easier because we would require far fewer calls between winedos and ntdll. - Win16 programs using interrupts take a bit longer to start and they get all kinds of unnecessary stuff into their address space from winedos. - Restructuring stuff means lots of work and possibility for regression bugs in Win16 support. P.S. I have a good idea on what needs to be done to make Wine support DPMI32. I have actually got some 32-bit DOS extenders to almost work. However, this requires lots of interrupt related work and I would like to wait until I get enough feedback about this interrupt refactoring proposal in order to see whether to continue working using the current interrupt code. -- Jukka Heinonen <http://www.iki.fi/jhei/>

3 4

WANTED (dead or alive): additional AppDB maintainer
by Andreas Mohr 20 Oct '02

20 Oct '02

Hi all, as I'm currently in my studies duties again and the AppDB submissions are piling up enormously (> 20 new entries in less than two weeks), I'm looking for one or two additional AppDB maintainers to do the Beowulf thingy ;-) (I'm talking about http://appdb.winehq.org, here) The job description can be found at http://www.winehq.org/about/index.php?contrib#active Sadly enough, this description page has been online for several months now, with (almost ?) nobody applying for any jobs listed. Thanks, Andi

4 3

InstallShield
by Jeff Smith 20 Oct '02

20 Oct '02

Trying to install the Music Ace Demo (harmonicvision.com), I get stopped by a messagethat "The InstallShield Engine (iKernel.exe) could not be installed. (0x20)" I think someone said DCOM98 needs to be installed for InstallShield to work properly, so I did, and nothing changed. Anybody got a take on what I need to try next? -- Jeff S. _________________________________________________________________ Choose an Internet access plan right for you -- try MSN! http://resourcecenter.msn.com/access/plans/default.asp

2 1

Appplied U[1-5], still faults
by David D. Hagood 19 Oct '02

19 Oct '02

Applied and tested listview patches through U5 - The road type column in the directions window is back (good), but the system still dies on the Along the way (bad), with the same assertion failure as the previous report.

2 1

OpenGL problems - textures hosed
by David D. Hagood 19 Oct '02

19 Oct '02

I'm getting some strange textures on HalfLife, Opposing Force, and Blue Shift: Sample screen shots are here: http://sktc.net/~wowbagger/ba_hazard10000.png http://sktc.net/~wowbagger/ba_hazard10001.png Specifically, any static texture is screwed up. Dynamic textures, like water or "people" are OK. Native GL apps, like Q3A, RTCW and UT are fine, which would tend to exonerate the local GL. This is running the CVS of Wine, updated a few hours ago (call it noon US Central Daylight time 19 Oct 2002 (UTC-5)), and the main branch of the DRI CVS, on a dual P3-1GHz machine. I have tried coming up in single processor mode with no change in rendering. Any pointers?

1 0

Re: Don't link winedump to libwine
by Alexandre Julliard 19 Oct '02

19 Oct '02

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > tools/winedump/Makefile.in: > Don't link winedump to libwine, we don't need that Actually we do, it's used for the various portability functions. -- Alexandre Julliard julliard(a)winehq.com

2 2

_tempnam
by Uwe Bonnes 19 Oct '02

19 Oct '02

Changelog: dlls/msvcrt/file.c: _tempnam Follow documented searchpath for directory. Return with no file created. LT Switchercad installation passes NULL as dir-argument. Xilinc _pn.exe relies on a _mkdir call succeeding immediatly after the _tempnam call. -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- Index: wine/dlls/msvcrt/file.c =================================================================== RCS file: /home/wine/wine/dlls/msvcrt/file.c,v retrieving revision 1.39 diff -u -r1.39 file.c --- wine/dlls/msvcrt/file.c 17 Sep 2002 18:32:53 -0000 1.39 +++ wine/dlls/msvcrt/file.c 19 Oct 2002 13:37:18 -0000 @@ -1274,15 +1274,32 @@ char *_tempnam(const char *dir, const char *prefix) { char tmpbuf[MAX_PATH]; + char dirname[MAX_PATH]; - TRACE("dir (%s) prefix (%s)\n",dir,prefix); - if (GetTempFileNameA(dir,prefix,0,tmpbuf)) - { - TRACE("got name (%s)\n",tmpbuf); - return _strdup(tmpbuf); - } + if ( (GetEnvironmentVariableA("TMP",dirname,MAX_PATH) ) + && (GetTempFileNameA(dirname,prefix,0,tmpbuf))) + goto done; + if ( (dir) && lstrcpynA(dirname, dir,MAX_PATH) + && (GetTempFileNameA(dirname,prefix,0,tmpbuf))) + goto done; +#ifdef P_tmpdir + if ( (dir) && lstrcpynA(dirname, P_tmpdir,MAX_PATH) + && (GetTempFileNameA(dirname,prefix,0,tmpbuf))) + goto done; +#else + if ( (GetEnvironmentVariableA("PWD",dirname,MAX_PATH) ) + && (GetTempFileNameA(dirname,prefix,0,tmpbuf))) + goto done; +#endif + TRACE("failed (%ld)\n",GetLastError()); return NULL; + + done: + TRACE("got name (%s)\n",tmpbuf); + DeleteFileA(tmpbuf); + return _strdup(tmpbuf); + } /********************************************************************* @@ -1291,16 +1308,36 @@ WCHAR *_wtempnam(const WCHAR *dir, const WCHAR *prefix) { WCHAR tmpbuf[MAX_PATH]; + WCHAR dirname[MAX_PATH]; + WCHAR tmp_env[] = {'T','M','P',0}; + WCHAR pwd_env[] = {'P','W','D',0}; - TRACE("dir (%s) prefix (%s)\n",debugstr_w(dir),debugstr_w(prefix)); - if (GetTempFileNameW(dir,prefix,0,tmpbuf)) - { - TRACE("got name (%s)\n",debugstr_w(tmpbuf)); - return _wcsdup(tmpbuf); - } TRACE("failed (%ld)\n",GetLastError()); return NULL; -} + if ( (GetEnvironmentVariableW(tmp_env,dirname,MAX_PATH) ) + && (GetTempFileNameW(dirname,prefix,0,tmpbuf))) + goto done; + if ( (dir) && lstrcpynW(dirname, dir,MAX_PATH) + && (GetTempFileNameW(dirname,prefix,0,tmpbuf))) + goto done; +#ifdef _wP_tmpdir + if ( (dir) && lstrcpynW(dirname, _wP_tmpdir,MAX_PATH) + && (GetTempFileNameW(dirname,prefix,0,tmpbuf))) + goto done; +#else + if ( (GetEnvironmentVariableW(pwd_env,dirname,MAX_PATH) ) + && (GetTempFileNameW(dirname,prefix,0,tmpbuf))) + goto done; +#endif + + TRACE("failed (%ld)\n",GetLastError()); + DeleteFileW(tmpbuf); + return NULL; + +done: + TRACE("got name (%s)\n",debugstr_w(tmpbuf)); + return _wcsdup(tmpbuf); + } /********************************************************************* * _umask (MSVCRT.@)

1 0

Problem with lz32.dll
by Sylvain Petreolle 19 Oct '02

19 Oct '02

Hi, trying to start programs that use lz32 give me problems with the loadorder thing. I specified lz32 to be loaded native in the global [DllOverrides] section and the program I want to use report this : Warning: loading builtin lz32.dll, but native version already present. Expect trouble. I don't have an entry in my config file that want lz32 to be builtin for a wanted application. This happens with builtin expand. I attached expandlog and my .wine/config ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel