wine-devel

wine-devel@winehq.org

84471 discussions

PRIVATE flag sends dllwrap for a loop.
by Steven Edwards 26 Nov '03

26 Nov '03

Hello, This is a problem I have had for a while building WINE dlls for use on Windows and ReactOS. When linking the dlls dllwrap always complains that it cant find the symbol private that is added to the .def file. When I remove this symbol and rebuild my import libs and dlls I dont have any problems so lets disable it for now. Changelog: Disable PRIVATE name on for exports in def files. Index: spec32.c =================================================================== RCS file: /home/wine/wine/tools/winebuild/spec32.c,v retrieving revision 1.72 diff -u -r1.72 spec32.c --- spec32.c 3 Nov 2003 22:19:44 -0000 1.72 +++ spec32.c 20 Nov 2003 18:21:56 -0000 @@ -900,7 +900,9 @@ fprintf( outfile, " @%d", odp->ordinal ); if (!odp->name) fprintf( outfile, " NONAME" ); if (is_data) fprintf( outfile, " DATA" ); +#if 0 if (odp->flags & FLAG_PRIVATE) fprintf( outfile, " PRIVATE" ); +#endif fprintf( outfile, "\n" ); } } __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/

2 3

Re: netapi32: implement Netbios()
by Juan Lang 26 Nov '03

26 Nov '03

Hi Uwe et al.. Uwe said: > Saying a little more may help. > > What's needed to test you patch? What programs show > improvement? Good questions. I have little test programs that I've been using, but NetBIOS is hard to test without knowing something about your network configuration, so they're not much use for netapi32/tests. I don't know of any programs that work now that didn't, except what I'm working on: I'm trying to implement the Network Neighborhood. I've been tweaking WINE's SMB code to use Netbios() rather than implementing the netbios-over-tcpip stuff directly. That work isn't done yet, watch this space for more :) There was an article a while back linked here about some HP management program (for their NAS appliance) that didn't discover their box under WINE because of lack of NetBIOS support. I suspect this may now work, but I don't know. > Any configuration items needed in a .ini file or the > registry? Needed? No, should work as-is. You may configure some things in the registry if you need to. Many are configured in the same way as Win98's reg, but not all. I didn't know a good place to document these; comments in winedefault.reg??? > And thanks for your work :-) You're very welcome :) --Juan __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/

1 0

Re: netapi32: implement Netbios()
by Uwe Bonnes 26 Nov '03

26 Nov '03

>>>>> "Juan" == Juan Lang <juan_lang(a)yahoo.com> writes: Juan> Apologies for the size of the patch, I didn't see any useful way Juan> to shrink it. Juan> ChangeLog: implement rather a lot of Netbios() Juan> I could say a bit more than that, but it wouldn't mean much to Juan> most people. Where there was nearly none, now there is some. Saying a little more may help. What's needed to test you patch? What programs show improvement? Any configuration items needed in a .ini file or the registry? Just some thoughts. And thanks for your work :-) 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

debugger problems
by Chris Morgan 26 Nov '03

26 Nov '03

I'm trying to debug a crash in some changes to the jack audio driver and can't seem to have the wine debugger show me the actual source code of the crash. I start up the debugger and get this: oaded debug information from ELF 'wine' ((nil)) No debug information in 32bit DLL 'C:\Program Files\winamp\Winamp.exe' (0x400000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\NTDLL.DLL' (0x401d0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\KERNEL32.DLL' (0x404b0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\ADVAPI32.DLL' (0x408c0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\GDI32.DLL' (0x40840000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\USER32.DLL' (0x406f0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\RPCRT4.DLL' (0x40a00000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\OLE32.DLL' (0x40980000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\SHLWAPI.DLL' (0x40a50000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\COMCTL32.DLL' (0x40aa0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\SHELL32.DLL' (0x40900000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WINMM.DLL' (0x40b50000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WINSPOOL.DRV' (0x40c40000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\COMDLG32.DLL' (0x40bd0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\OLEAUT32.DLL' (0x40c80000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\X11DRV.DLL' (0x40e10000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WINEJACK.DRV' (0x410e0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MSACM32.DLL' (0x41130000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MSACM.DRV' (0x41120000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MIDIMAP.DRV' (0x41270000) In 32-bit mode. Wine-dbg> I run and get a crash: Backtrace: =>0 0x41101541 (WINEJACK.DRV..data+0x14541) (ebp=42b87748) 1 0x410e6cbf (WINEJACK.DRV..text+0x5cbf in WINEJACK.DRV) (ebp=42b877cc) 2 0x410e7e10 (WINEJACK.DRV..text+0x6e10 in WINEJACK.DRV) (ebp=42b87804) 3 0x410e9111 (WINEJACK.DRV.wodMessage+0x131 in WINEJACK.DRV) (ebp=42b8783c) 4 0x40b70999 (WINMM.DLL.joySetThreshold+0xd89 in WINMM.DLL) (ebp=42b878ac) 5 0x40b711a4 (WINMM.DLL.joySetThreshold+0x1594 in WINMM.DLL) (ebp=42b878dc) 6 0x40b813e6 (WINMM.DLL.midiStreamStop+0x266 in WINMM.DLL) (ebp=42b87948) 7 0x40b818f4 (WINMM.DLL.waveOutOpen+0x54 in WINMM.DLL) (ebp=42b87974) 8 0x41121362 (MSACM.DRV..text+0x362 in MSACM.DRV) (ebp=42b879a8) 9 0x4112158b (MSACM.DRV..text+0x58b in MSACM.DRV) (ebp=42b87a14) 10 0x411225e7 (MSACM.DRV.wodMessage+0xe7 in MSACM.DRV) (ebp=42b87a4c) 11 0x40b70999 (WINMM.DLL.joySetThreshold+0xd89 in WINMM.DLL) (ebp=42b87abc) 12 0x40b711a4 (WINMM.DLL.joySetThreshold+0x1594 in WINMM.DLL) (ebp=42b87aec) 13 0x40b813e6 (WINMM.DLL.midiStreamStop+0x266 in WINMM.DLL) (ebp=42b87b58) 14 0x40b818f4 (WINMM.DLL.waveOutOpen+0x54 in WINMM.DLL) (ebp=42b87b84) 15 0x42a69ca6 (DSOUND.DLL.DirectSoundCreate8+0x5d6 in DSOUND.DLL) (ebp=42b87c44) 16 0x425f90eb (OUT_DS.DLL..text+0x10eb in OUT_DS.DLL) (ebp=00000000) 0x41101541 (WINEJACK.DRV..data+0x14541): movb %al,0x0(%edx) Wine-dbg>list Enter path to file '': What am I doing wrong here? Chris

3 3

Re: Intresting page
by Ivan Leo Murray-Smith 26 Nov '03

26 Nov '03

> Hmm. I'd be wary of trusting a page with such obviously manipulated > screenshots (check out the different background colours/fonts of some of > the labels), and "Write in HERE or die LMAO!" as the link to the > guestbook :-) I think they manipulated the screenshots to avoid someone hosting them and saying "I took this screenshot on my pc". Also, if you look on google you can find links to pages that talk about neptune, nashville and so on.

1 0

Intresting page
by Ivan Leo Murray-Smith 26 Nov '03

26 Nov '03

Lists (And screenshots) of lots of stuff m$ never released, like windows neptune, Whistler Advanced Server, Cairo, Nashville (Windows 96), windows titanium, windows 99, and more. http://ad-iso.mine.nu/~air101/

2 1

PE stack trick not working on lowmem machines
by Marcus Meissner 26 Nov '03

26 Nov '03

Hi, On SuSE 8.2, i586 glibc, loader/wine-* crash due to the 256 MB static array in main(). The test machine has just 64MB RAM and 200MB swap. If I start decreasing the array it works, up to 201MB. $ /lib/ld-linux.so.2 ./wine-kthread ./wine-kthread: error while loading shared libraries: ./wine-kthread: cannot map zero-fill pages: Cannot allocate memory $ So ld.so really wants to get 20xMB memory but fails. -> Not good on low memory machines. (Not sure if we should fix it.) Btw, why don't we use -Wa,--noexecstack ? Ciao, Marcus

3 3

Re: Reject wildcards in directory names
by Rolf Kalbermatter 26 Nov '03

26 Nov '03

Alexandre Julliard <julliard(a)winehq.org> wrote: > > As for the invalid characters, [Create|Remove]File[A|W] only check > > for '?', '*', which I just copied for [Create|Remove]Directory[A|W]. > > I take it you will accept a patch that also extends the checks in > > [Create|Remove]File*? > > Yes, and of course it should use a common routine to do the checks, so > that it's consistent everywhere. Also the Create and Remove cases > should be handled differently IMO, a Remove should succeed if the > specified file exists, even if it contains illegal characters. I would actually agree with Alexandre here, but W2K at least behaves differently. My tests show that RemoveDirectory just as CreateDirectory rejects all paths which contain one of the wildcards ": * ? \" < > |" with error 123 completely independent where that character occurs (not just in the path element which is created). And as far as I can say DeleteFile just as much behaves also this way. So should we attempt to be smarter than Windows in this case? Rolf Kalbermatter

5 12

Re: winehq name
by Alexandre Julliard 26 Nov '03

26 Nov '03

"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 26 Nov '03

26 Nov '03

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 26 Nov '03

26 Nov '03

> -----Original Message----- > From: wine-cvs-admin(a)winehq.com [mailto:wine-cvs-admin@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 25 Nov '03

25 Nov '03

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 25 Nov '03

25 Nov '03

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 25 Nov '03

25 Nov '03

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 25 Nov '03

25 Nov '03

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 25 Nov '03

25 Nov '03

"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 25 Nov '03

25 Nov '03

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 25 Nov '03

25 Nov '03

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

Re: Update comctl spec
by Alexandre Julliard 24 Nov '03

24 Nov '03

Hans Leidekker <hans(a)it.vu.nl> writes: > Changelog: > - Export more functions by name. This will break the import libraries. Why do you want to do that? -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Compile Bug: dlls/wininet/cookie.c .. and its cause
by Alexandre Julliard 24 Nov '03

24 Nov '03

Ivan Gyurdiev <ivg2(a)cornell.edu> writes: > I have no clue what the FAR macro does, but wouldn't it be better to > just rename the wine FAR macro to something different if you dont want > it to conflict w/ the other FAR macro? It's a Windows thing, we can't change it. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: heap: fix RtlHeapReAllocate()
by Dimitrie O. Paun 24 Nov '03

24 Nov '03

On November 21, 2003 03:21 pm, Eric Pouech wrote: > this will not compile on Win9x. You have to take care of: Good point, sorry about that, I was being lazy. To force people to do the dyn load, we shouldn't import ntdll, no? ChangeLog RtlHeapReAllocate() should not allocate memory. Add small test to make sure it doesn't return. Don't import ntdll for tests, we need to load it dynamically. Index: dlls/ntdll/heap.c =================================================================== RCS file: /var/cvs/wine/dlls/ntdll/heap.c,v retrieving revision 1.25 diff -u -r1.25 heap.c --- dlls/ntdll/heap.c 10 Oct 2003 00:12:17 -0000 1.25 +++ dlls/ntdll/heap.c 20 Nov 2003 21:00:39 -0000 @@ -1231,11 +1231,11 @@ HEAP *heapPtr; SUBHEAP *subheap; - if (!ptr) return RtlAllocateHeap( heap, flags, size ); /* FIXME: correct? */ + if (!ptr) return NULL; if (!(heapPtr = HEAP_GetPtr( heap ))) { set_status( STATUS_INVALID_HANDLE ); - return FALSE; + return NULL; } /* Validate the parameters */ Index: dlls/ntdll/tests/Makefile.in =================================================================== RCS file: /var/cvs/wine/dlls/ntdll/tests/Makefile.in,v retrieving revision 1.9 diff -u -r1.9 Makefile.in --- dlls/ntdll/tests/Makefile.in 8 May 2003 03:47:24 -0000 1.9 +++ dlls/ntdll/tests/Makefile.in 24 Nov 2003 07:19:04 -0000 @@ -3,12 +3,12 @@ SRCDIR = @srcdir@ VPATH = @srcdir@ TESTDLL = ntdll.dll -IMPORTS = ntdll CTESTS = \ env.c \ error.c \ generated.c \ + heap.c \ large_int.c \ path.c \ rtl.c \ --- /dev/null 2003-01-30 05:24:37.000000000 -0500 +++ dlls/ntdll/tests/heap.c 2003-11-24 02:17:07.000000000 -0500 @@ -0,0 +1,49 @@ +/* + * Unit test suite for heap functions + * + * Copyright 2003 Dimitrie O. Paun + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#include <stdarg.h> +#include <stdlib.h> + +#include "ntstatus.h" +#include "windef.h" +#include "winbase.h" +#include "wine/test.h" +#include "winnt.h" +#include "winnls.h" +#include "winreg.h" +#include "winternl.h" + +PVOID (WINAPI *pRtlReAllocateHeap)(HANDLE,ULONG,PVOID,ULONG); + +static void test_realloc( void ) +{ + void *mem = NULL; + + mem = pRtlReAllocateHeap(GetProcessHeap(), 0, mem, 10); + ok(mem == NULL, "memory allocated"); +} + +START_TEST(heap) +{ + HMODULE mod = GetModuleHandle("ntdll.dll"); + if (!mod) return; + pRtlReAllocateHeap = (void *)GetProcAddress(mod, "RtlReAllocateHeap"); + if (pRtlReAllocateHeap) test_realloc(); +} -- Dimi.

3 3

Compile Bug: dlls/wininet/cookie.c .. and its cause
by Ivan Gyurdiev 24 Nov '03

24 Nov '03

Macro __WINESRC__ is defined for dlls/wininet/cookie.c in the Makefile. The file cookie.c includes wine/debug.h. wine/debug.h includes windef.h. windef.h defines the macro FAR to __ONLY_IN_WINELIB() __ONLY_IN_WINELIB() defines to do_not_use_this_in_wine if __WINESRC__ The file dlls/wininet/cookie.c also includes dlls/wininet/internet.h dlls/wininet/internet.h includes openssl/ssl.h for my machine openssl/ssl.h includes openssl/kssl.h openssl/kssl.h has the following code using the FAR macro: #ifdef KRB5_HEIMDAL typedef unsigned char krb5_octet; #endif #ifndef FAR #define FAR #endif ... Line 136: krb5_octet FAR *key; This is on a Fedora core system, which applies a patch to openssl that changes the original openssl-devel regarding this, but I think the issue's with wine, and is still there. The original openssl-devel looks like this: #ifdef KRB5_HEIMDAL typedef unsigned char krb5_octet; define FAR #endif Either way, the point is the FAR macro is being used in kssl.h, and it's defined in windef.h, as do_not_use_this_in_wine, resulting in this: gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_WINX32_ -D_REENTRANT -fPIC -Wall -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o cookie.o cookie.c In file included from /usr/include/openssl/ssl.h:179, from internet.h:36, from cookie.c:39: /usr/include/openssl/kssl.h:136: error: syntax error before '*' token /usr/include/openssl/kssl.h:149: error: syntax error before '*' token /usr/include/openssl/kssl.h:150: error: syntax error before '*' token /usr/include/openssl/kssl.h:151: error: syntax error before '*' token /usr/include/openssl/kssl.h:151: error: syntax error before '*' token /usr/include/openssl/kssl.h:152: error: syntax error before '*' token /usr/include/openssl/kssl.h:153: error: syntax error before '*' token /usr/include/openssl/kssl.h:155: error: syntax error before '*' token /usr/include/openssl/kssl.h:157: error: syntax error before '*' token /usr/include/openssl/kssl.h:159: error: syntax error before '*' token /usr/include/openssl/kssl.h:167: error: syntax error before '*' token In file included from internet.h:36, from cookie.c:39: /usr/include/openssl/ssl.h:909: error: syntax error before "KSSL_CTX" /usr/include/openssl/ssl.h:931: error: syntax error before '}' token make[2]: *** [cookie.o] Error 1 make[2]: Leaving directory `/home/phantom/tmp/firebird-downloads/wine-20031118/dlls/wininet' make[1]: *** [wininet] Error 2 make[1]: Leaving directory `/home/phantom/tmp/firebird-downloads/wine-20031118/dlls' make: *** [dlls] Error 2 ===================================================================== I am not subscribed to this list. If you'd like to email back write to ivg2(a)cornell.edu. Also, some unrelated questions: does anyone know what causes this: err:module:NE_LoadBuiltinModule loaded .so but dll winealsa.drv still not found (the file is there... oss is there too, and works great) ....or why keyboard focus is always lost (characters appear in the console, kb doesn't work in application) when playing most games under a window manager like gnome or kde, but not under twm? This bug has been there forever and is really annoying.

3 2

Re: winmm: move MCI settings from system.ini to the registry
by Andreas Mohr 24 Nov '03

24 Nov '03

Hi, On Mon, Nov 24, 2003 at 12:10:20PM -0500, Dimitrie O. Paun wrote: > On November 22, 2003 03:02 am, Eric Pouech wrote: > > I won't have too much time to look at this in details right now, so if > > someone wants to jump in, I'll be happy to give him (her ?) a hand. > > To be honest, > My interest in doing this work is to get rid of system.ini from the > Wine tree. While I agree that there's more to do, it's just not up > my alley :) So, this version of the patch still maintains support > for system.ini, just like the old code does, but it also adds support > for registry, which should allow us to move stuff there. To be honest, I'm not sure why one would want that. After all the system.ini settings are an essential part of a Windows environment, and removing the whole file will break many (admittedly older) programs, if I'm not mistaken... (nevermind the duplication of the parameters, which does exist) Andreas Mohr

1 0

Re: documentation/samples/generic.ppd
by Marcus Meissner 24 Nov '03

24 Nov '03

On Mon, Nov 24, 2003 at 02:32:49AM -0500, Dimitrie O. Paun wrote: > > I can't help but feel that this file does not belong in the > Wine tree, but in the print system packages (cups, etc.). > > cvs rm -f documentation/samples/generic.ppd > > ChangeLog > Remove generic.ppd, it does not belong in the Wine tree. This is the generic fallback PPD file which can be used LPR style printing, where we do not get access to a PPD easily. Ciao, Marcus

2 1

IS_STRING_ITEM( lpitem->fType ) but no lpitem->text
by Uwe Bonnes 24 Nov '03

24 Nov '03

Hallo, Peter Heckert <ph_newsalias(a)arcor.de> posted on c.e.m.w a problem with Sigma Photo Pro 2. Sigma Photo Pro 2 can be downloaded at http://www.sigma-photo.co.jp/english/downloads/downloads.html It seems that IS_STRING_ITEM( lpitem->fType ) is set while there is no lpitem->text. Appended hack lets Sigma Photo Pro 2 run until exit, where it crashes again. Can anybody look at that problem? -- 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/controls/menu.c =================================================================== RCS file: /home/wine/wine/controls/menu.c,v retrieving revision 1.169 diff -u -r1.169 menu.c --- wine/controls/menu.c 18 Nov 2003 19:42:31 -0000 1.169 +++ wine/controls/menu.c 23 Nov 2003 21:52:38 -0000 @@ -936,7 +936,7 @@ /* it must be a text item - unless it's the system menu */ - if (!(lpitem->fType & MF_SYSMENU) && IS_STRING_ITEM( lpitem->fType )) + if (!(lpitem->fType & MF_SYSMENU) && IS_STRING_ITEM( lpitem->fType )&& lpitem->text) { SIZE size; GetTextExtentPoint32W(hdc, lpitem->text, strlenW(lpitem->text), &size); @@ -1361,7 +1361,7 @@ } /* No bitmap - process text if present */ - else if (IS_STRING_ITEM(lpitem->fType)) + else if (IS_STRING_ITEM(lpitem->fType) && lpitem->text) { register int i; HFONT hfontOld = 0;

2 2

Jump to page:

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