November 2003 - Wine-Devel - list.winehq.org

Re: winehq name
by Alexandre Julliard Nov. 26, 2003

Nov. 26, 2003

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > I know we've discussed this before, but I feel things > have changed and it's worth another try :) Namely, > have the winehq.org name be the default one. It seems > virtually everybody (except you) prefer the .org name > over the .com name, it's way more community friendly, > and it seems to be the default one on WineHQ for a > while, without any negative side effects. It's not that I prefer the .com name, frankly I couldn't care less, it's just that I think it's silly to change a perfectly good name that everybody was used to, simply to achieve some questionable ideal of "purity" of the domain name; and even more silly to have to change all references to try to reduce the confusion that would never have happened if we hadn't changed it in the first place. But I don't really care enough to keep fighting about it, so I put your patch in... -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: wine/programs/winedbg debug.l
by Dimitrie O. Paun Nov. 26, 2003

Nov. 26, 2003

On November 25, 2003 11:10 pm, Alexandre Julliard wrote: > Modified files: > programs/winedbg: debug.l > > Log message: > Fixed one more HeapReAlloc call. Good catch! I didn't lie when I said all calls were reviewed, it's just that I didn't search .l files... -- Dimi.

1 0

RE: wine/ windows/win.c windows/message.c programs ...
by Robert Shearman Nov. 26, 2003

Nov. 26, 2003

> -----Original Message----- > From: wine-cvs-admin(a)winehq.com [mailto:wine-cvs-admin(a)winehq.com]On > Behalf Of Alexandre Julliard > Sent: 26 November 2003 04:09 > To: wine-cvs(a)winehq.com > Subject: wine/ windows/win.c windows/message.c programs ... > > Log message: > Fixed declarations of BroadcastSystemMessage and > TranslateAccelerator > in winuser.h. Added GetWindowModuleFileName. > +LONG WINAPI BroadcastSystemMessageA(DWORD,LPDWORD,UINT,WPARAM,LPARAM); > +LONG WINAPI BroadcastSystemMessageW(DWORD,LPDWORD,UINT,WPARAM,LPARAM); > +#define BroadcastSystemMessage WINELIB_NAME_A(BroadcastSystemMessage) Should this not be WINELIB_NAME_AW? Rob

1 0

Strange problem with wine
by Gerhard W. Gruber Nov. 25, 2003

Nov. 25, 2003

I'm using a build that is about one month old, but I don't think that this is the problem. I will update in the next few days and then I will see if this goes away. OK. I have written this small tool which you can download at http://sourceforge.net/projects/launchmen. The Linux port uses a normal fork() and then executes the specifed application when the entry is selected from the menu. It works for every application but only with wine/Agent I have to select the entry twice to make it run. When I select the entry wich should run wine with Agent nothing happens. When I look into the process list the first time I can see this: 1506 ? S 0:00 /usr/local/bin/wine /home/user/wine/D/home/agent/agent.exe 1507 ? S 0:00 \_ wineserver 1508 ? S 0:00 \_ wineserver Which is strange because I have two wineservers running. When I launch exactly the same commandline from the shell everything is normal. I see one Agent, one wineserver and Agent comes up fine. In the case of my application I can see the above list and Agent doesn't start. Only when I launch Agent a second time from my app then it starts fine. When I exit Agent then and look again I can still see the old Agent hanging, but as long as this one is there my app can launch Agent normally. When I kill this Agent and wineserver the same happens again and I have to start it twice. Any ideas what this could be? Since I only have this problem with wine I thought I ask if somebody could say something about this. -- Gerhard Gruber Maintainer of SoftICE for Linux - http://sourceforge.net/projects/pice Fast application launcher - http://sourceforge.net/projects/launchmenu

1 0

Re: unicows update and PE memory format
by Rolf Kalbermatter Nov. 25, 2003

Nov. 25, 2003

Message: 4 Subject: Re: PE stack trick not working on lowmem machines From: Mike Hearn <mike(a)theoretic.com> To: Alexandre Julliard <julliard(a)winehq.org> Cc: Marcus Meissner <meissner(a)suse.de>, wine-devel(a)winehq.com Date: Mon, 24 Nov 2003 21:00:33 +0000 On Mon, 2003-11-24 at 20:38, Alexandre Julliard wrote: > > Btw, why don't we use -Wa,--noexecstack ? > > It doesn't help with prelink AFAICT. Is it really too late to get some kind of hook into prelink to stop it interfering with Wine? It seems daft that we need such a big hack when surely a flag in the elf headers would work just as well with co-operation from the rtld. --__--__-- >Shachar Shemesh <wine-devel(a)shemesh.biz> writes: >Now here's the puzzle - GetProcAddress is never called. Neither are >these functions imported from the DLL in the PE header. In fact, >unicows.dll does not even appear in the PE header (which makes sense - >on NT you don't even want to install it). This means that unicows.lib >manages to call GetProcAddress, without actually calling GetProcAddress. > >Some tracing leads me to suspect (I have not done enough research to >determine yet) that it accesses the PE header of kernel32 directly. It >appears that unicows.dll enountered the exact same problem we have vis a >vis GetProcAddress, and have happily hacked their way around it using >direct memory access. What I see them do is call "GetModuleHandle" on >"kernel32.dll", and then use the resulting handle as a struct/array >pointer, and access offsets into it. This is not exactly very nice but it is also not to surprising. The PE header is actually documented on MSDN including the import and export tables. GetModuleHandle actually also just returns the HMODULE which at least for Win32 is the same as the HINSTANCE returned by LoadLibrary. The difference is if I'm not mistaken, that GetModuleHandle will usually not try to load the module if it isn't already loaded, but for kernel32 you can safely assume that a process has it already loaded implicitedly or even explicitedly. An HMODULE on Win32 is nothing else than the base address of a loaded module image, and with some offset calculations using Macros from winnt.h you can get at anything in that image including the export table and from there you can then search GetProcAddress. One possible problem is that the unicows GetProcAddress implementation might not search the function in the export table by name but rather by ordinal and our ordinal or ordinal base is different from what Unicows expects. Rolf Kalbermatter

2 1

Re: Small fontdlg fix.
by Shachar Shemesh Nov. 25, 2003

Nov. 25, 2003

Rein Klazes wrote: > HPEN hOrigPen; > HFONT hOrigFont; > COLORREF rgbPrev; >- WCHAR sample[SAMPLE_EXTLEN+5]={'A','a','B','b'}; >+ WCHAR sample[SAMPLE_EXTLEN+9]={'A','a','B','b','Y','y','Z','z'}; > > This is wrong. "YyZz" are only added if it's a western encoding. This already happens (a patch I submitted earlier this year, and forgot to add my copyright to the file). With this patch, if you view a font in it's Western encoding, you get a sample that says "AaBbYyZzYyZz". If you view a font in another encoding (say, Hebrew, because that's the only one that was fed in), you get "AaBbYyZz��", instead of "AaBb��", like it is on Windows 2000, and like it makes sense (we want to spare some space). Shachar -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/

2 3

Re: [PATCH] wininet.dll compile time defines
by Vincent Béron Nov. 25, 2003

Nov. 25, 2003

Le mar 25/11/2003 à 00:37, Alex Tribble a écrit : > Hi, > When upgrading to Fedora Core 1 (the new RedHat release, sort of), > wine stopped compiling for me. I was getting errors while parsing > <openssl/ssl.h>, et al. -DOPENSSL_NO_KRB5 makes these go away. > > Any thoughts? Please CC me, as I'm not subscribed to the devel list. The patch http://cvs.winehq.com/patch.py?id=10182 (applied yesterday in CVS) fixes the issue. Vincent

1 0

Re: Mach-O Support for imageSize in NtHeader
by Alexandre Julliard Nov. 25, 2003

Nov. 25, 2003

"Pierre d'Herbemont" <stegefin(a)free.fr> writes: > Here is my second try for a replacement of the _end symbol. I think > that since there is no support of it we need a kind of emulation > function, which I thought should be located in the wine_port lib. So I > add a mach-o.c port file, with the needed function. But should it be > done this way? No, the static char _end[] thing should be enough, you don't have to store anything in there (which won't do what you want anyway). The only thing that matters is the address of the _end symbol. -- Alexandre Julliard julliard(a)winehq.com

2 1

unicows update and PE memory format
by Shachar Shemesh Nov. 25, 2003

Nov. 25, 2003

Hi list, Here is a quick update. It seems that I won't be able to use the forwarding inside the spec file. I'm not sure exactly why that is, but I think the unicows.lib link time library tries to load stuff by doing "GetModuleHandle", and then fetching relative values from that place. Is there a plausable assumption about PE memory layout? Is this something that Win32 properly defines? Do we have such a format for winelib dlls? Shachar -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/

3 5

RFH: *ReAlloc* mess
by Dimitrie O. Paun Nov. 25, 2003

Nov. 25, 2003

Hi folks, I need some help to figure out how the following realloc functions behave: GlobalReAlloc LocalReAlloc Local32ReAlloc16 NetApiBufferReallocate SysReAllocStringLen So, I need to know: -- do they allocate memory when a NULL is passed in? -- do they free memory when the size is passed in as 0? Help with this matter is much appreciated! -- Dimi.

1 0