- Wine-devel - list.winehq.org

rpcrt / epmapper / scm
by juergen.schmied＠debitel.net 02 Aug '02

02 Aug '02

Hi! Some time ago I did send the rpcrt patches from ove ported to the cvs. It didn't got included. Are there any special reasons? The epmapper was implemented in the wineserver. Should it be a standalone server? 1) If it would be a win32 process we would need 2 context changes for every call. If it would be a server like the wine-server there would only be 1 context change per call. 2) What IPC should we use locally? We could implement LPC like reactos. 3) We need a process for managing services and COM out-of-process servers (the SCM). Any ideas how to do this? To many questions for one mail? ;-) juergen

2 1

problem with destroy window
by Juergen Schmied 02 Aug '02

02 Aug '02

Looks like a window what is in destruction gets the focus from WINPOS_ActivateOtherWindow and don't like it... juergen 08073ff8:Call user32.DestroyWindow(00010022) ret=5d34c141 trace:win:DestroyWindow (10022) 08073ff8:Call x11drv.ResetSelectionOwner(00010022,00000000) ret=4069f640 08073ff8:Ret x11drv.ResetSelectionOwner() retval=02800003 ret=4069f640 08073ff8:Call x11drv.ShowWindow(00010022,00000000) ret=406a4127 08073ff8:Ret x11drv.ShowWindow() retval=00000000 ret=406a4127 trace:win:DestroyWindow (10024) 08073ff8:Call x11drv.ResetSelectionOwner(00010024,00000000) ret=4069f640 08073ff8:Ret x11drv.ResetSelectionOwner() retval=02800007 ret=4069f640 08073ff8:Call x11drv.ShowWindow(00010024,00000000) ret=406a4127 08073ff8:Ret x11drv.ShowWindow() retval=00000000 ret=406a4127 trace:win:WINPOS_SetActiveWindow (10022, 0, 1) trace:win:WINPOS_SetActiveWindow no current active window. 08073ff8:Call window proc 0x5d34c6f6 (hwnd=00010022,msg=WM_QUERYNEWPALETTE,wp=00000000,lp=00000000) 08073ff8:Call user32.GetWindow(00010025,00000005) ret=5d30c073 08073ff8:Ret user32.GetWindow() retval=00000000 ret=5d30c073 08073ff8:Call user32.SendMessageA(00010025,0000030f,00000000,00000000) ret=5d30c0be 08073ff8:Call window proc 0x5d34dfc9 (hwnd=00010025,msg=WM_QUERYNEWPALETTE,wp=00000000,lp=00000000) 08073ff8:Call user32.DefWindowProcW(00010025,0000030f,00000000,00000000) ret=5d34e274 08073ff8:Ret user32.DefWindowProcW() retval=00000000 ret=5d34e274 08073ff8:Ret window proc 0x5d34dfc9 (hwnd=00010025,msg=WM_QUERYNEWPALETTE,wp=00000000,lp=00000000) retval=00000000 08073ff8:Ret user32.SendMessageA() retval=00000000 ret=5d30c0be 08073ff8:Call user32.DefWindowProcA(00010022,0000030f,00000000,00000000) ret=5d34c99a 08073ff8:Ret user32.DefWindowProcA() retval=00000000 ret=5d34c99a 08073ff8:Ret window proc 0x5d34c6f6 (hwnd=00010022,msg=WM_QUERYNEWPALETTE,wp=00000000,lp=00000000) retval=00000000 08073ff8:Call window proc 0x42f35c40 (hwnd=00010024,msg=WM_ACTIVATEAPP,wp=00000001,lp=00000000) 08073ff8:Call user32.GetWindowLongA(00010024,00000000) ret=42f35c91 08073ff8:Ret user32.GetWindowLongA() retval=42ff0408 ret=42f35c91 08073ff8:Call user32.DefWindowProcA(00010024,0000001c,00000001,00000000) ret=42f36426 08073ff8:Ret user32.DefWindowProcA() retval=00000000 ret=42f36426 08073ff8:Ret window proc 0x42f35c40 (hwnd=00010024,msg=WM_ACTIVATEAPP,wp=00000001,lp=00000000) retval=00000000 08073ff8:Call window proc 0x5d34c6f6 (hwnd=00010022,msg=WM_ACTIVATEAPP,wp=00000001,lp=00000000) 08073ff8:Call user32.DefWindowProcA(00010022,0000001c,00000001,00000000) ret=5d34c99a 08073ff8:Ret user32.DefWindowProcA() retval=00000000 ret=5d34c99a 08073ff8:Ret window proc 0x5d34c6f6 (hwnd=00010022,msg=WM_ACTIVATEAPP,wp=00000001,lp=00000000) retval=00000000 08073ff8:Call window proc 0x77a67048 (hwnd=00010021,msg=WM_ACTIVATEAPP,wp=00000001,lp=00000000) 08073ff8:Call user32.DefWindowProcW(00010021,0000001c,00000001,00000000) ret=77a67087 08073ff8:Ret user32.DefWindowProcW() retval=00000000 ret=77a67087 08073ff8:Ret window proc 0x77a67048 (hwnd=00010021,msg=WM_ACTIVATEAPP,wp=00000001,lp=00000000) retval=00000000 08073ff8:Call window proc 0x5d34c6f6 (hwnd=00010022,msg=WM_NCACTIVATE,wp=00000001,lp=00000000) 08073ff8:Call user32.DefWindowProcA(00010022,00000086,00000001,00000000) ret=5d34c99a 08073ff8:Ret user32.DefWindowProcA() retval=00000001 ret=5d34c99a 08073ff8:Ret window proc 0x5d34c6f6 (hwnd=00010022,msg=WM_NCACTIVATE,wp=00000001,lp=00000000) retval=00000001 08073ff8:Call window proc 0x5d34c6f6 (hwnd=00010022,msg=WM_ACTIVATE,wp=00000001,lp=00000000) 08073ff8:Call kernel32.GetLastError() ret=00402238 08073ff8:Ret kernel32.GetLastError() retval=00000578 ret=00402238 08073ff8:Call kernel32.TlsGetValue(00000000) ret=00402246 08073ff8:Ret kernel32.TlsGetValue() retval=429e0100 ret=00402246 08073ff8:Call kernel32.SetLastError(00000578) ret=0040229a 08073ff8:Ret kernel32.SetLastError() retval=00000578 ret=0040229a 08073ff8:Call kernel32.UnhandledExceptionFilter(40464900) ret=0040172a =>0 0x5d30bf01 (HHCTRL.OCX..text+0xaf01 in C:\WINNT\SYSTEM32\HHCTRL.OCX) (ebp=40575064) 1 0x5d34c7b2 (HHCTRL.OCX.DllGetClassObject+0x22159 in C:\WINNT\SYSTEM32\HHCTRL.OCX) (ebp=405760fc) 2 0x406a54db (WINPROC_wrapper+0x17 in user32.dll.so) (ebp=40576120) 3 0x406a557e (WINPROC_CallWndProc+0x8e(proc=0x5d34c6f6, hwnd=0x10022, msg=0x6, wParam=0x1, lParam=0x0) [winproc.c:183] in user32.dll.so) (ebp=40576150) 4 0x406ab84b (CallWindowProcA+0x3b(func=0x5d34c6f6, hwnd=0x10022, msg=0x6, wParam=0x1, lParam=0x0) [winproc.c:2779] in user32.dll.so) (ebp=40576178) 5 0x406bb830 (call_window_proc+0x100(hwnd=0x10022, msg=0x6, wparam=0x1, lparam=0x0, unicode=0x0) [message.c:1372] in user32.dll.so) (ebp=405761c8) 6 0x406bc4f8 (SendMessageTimeoutA+0xe8(hwnd=0x10022, msg=0x6, wparam=0x1, lparam=0x0, flags=0x0, timeout=0xffffffff, res_ptr=0x40576250, hwnd=0x10022) [message.c:1784] in user32.dll.so) (ebp=40576220) 7 0x406bc679 (SendMessageA+0x39(hwnd=0x10022, msg=0x6, wparam=0x1, lparam=0x0) [message.c:1829] in user32.dll.so) (ebp=40576254) 8 0x406a4a96 (WINPOS_SetActiveWindow+0x476(hWnd=0x10022, fMouse=0x0, fChangeFocus=0x1) [winpos.c:1359] in user32.dll.so) (ebp=405762a0) 9 0x406a39c1 (SetActiveWindow+0xd1(hwnd=0x10022) [winpos.c:723] in user32.dll.so) (ebp=405762d0) 10 0x406a4cfd (WINPOS_ActivateOtherWindow+0x13d(hwnd=0x10024) [winpos.c:1463] in user32.dll.so) (ebp=405762f0) 11 0x4069f6f6 (DestroyWindow+0x1f6(hwnd=0x10024) [win.c:1504] in user32.dll.so) (ebp=4057630c) 12 0x4069f6b6 (DestroyWindow+0x1b6(hwnd=0x10022) [win.c:1492] in user32.dll.so) (ebp=40576328) 13 0x5d34c141 (HHCTRL.OCX.DllGetClassObject+0x21ae8 in C:\WINNT\SYSTEM32\HHCTRL.OCX) (ebp=4057690c)

1 0

DTR/DSR vs RTS/CTS - followup
by lists＠vmn.com.br 02 Aug '02

02 Aug '02

Hello All, Last week I sent an email about a problem with a serial printer that used DTS/DTR hardware flow control. I later understood that DTS/DTR was not supported in linux , and therefore not in wine. Linux [and wine] support RTS/CTS hardware flow control. Since the protocols are similar, an ideia that I received was to construct a cable that made the computer think it was using RTS/CTS and the printer think it was using DTR/DTS. Today, I received the cable from the printer manufacturer and the initial tests with wine/linux worked. **************************** RTS - Ready To Send CTS - Clear To Send DTR - Data Terminal Ready DSR - Data Set Ready **************************** Here is a snippet of mytestapp --debugmsg +comm trace:comm:COMM_Init COM1 = /dev/ttyS0 trace:comm:COMM_Init LPT1 = /dev/lp0 trace:comm:COMM_Init COM2 = /dev/ttyS1 trace:comm:COMM_Init COM3 = /dev/ttyS2 trace:comm:COMM_Init COM4 = /dev/modem trace:comm:BuildCommDCBAndTimeoutsA (COM2:9600,N,8,1,0x4002af48,(nil)) trace:comm:COMM_BuildOldCommDCB (COM2:9600,N,8,1), ptr 0x4002af48 trace:comm:COMM_BuildOldCommDCB baudrate (9600) trace:comm:COMM_BuildOldCommDCB parity (N) trace:comm:COMM_BuildOldCommDCB charsize (8) trace:comm:COMM_BuildOldCommDCB stopbits (1) trace:comm:SetCommState handle 52, ptr 0x4002af48 trace:comm:SetCommState bytesize 8 baudrate 9600 fParity 0 Parity 0 stopbits 1 trace:comm:SetCommState ~IXON ~IXOFF trace:comm:SetCommState CRTSCTS trace:comm:SetCommMask handle 52, mask 10 Thanks every one from wine-devel for all the prompt answers I received. Miguel Feitosa ------------------------------------------------- This mail sent through IMP: webmail.vmn.com.br

2 1

Compilation error with newer CVS on glibc -2.0
by Martin Cracauer 02 Aug '02

02 Aug '02

Hi, guys, since Jul 20 or so I get this compilation error on glibc-2.1.3/linux-2.4.18: gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -fno-strength-reduce -mpreferred-stack-boundary=2 -D__WINE__ -D_REENTRANT -I/usr/X11R6/include -o wrc.o wrc.c In file included from wrc.h:25, from wrc.c:61: wrctypes.h:447: redefinition of `struct user' make[2]: *** [wrc.o] Error 1 make[2]: Leaving directory `/disks/part9/home/cracauer/work/cvs-packages-work/stupids/wine/wine/tools/wrc' Wine's definition of struct user is clashing with the one from /usr/include/sys/user.h Now, it appears that /usr/include/sys/user.h (a glibc-2.1.3 file) is in error having this struct in first place, since newer kernels have this struct in asm/user.h. I fixed the problem in my /usr/include, but I guess it is better to use a different name for the struct in Wine to be compatible with this configuration (it's Debian-2.1 with an upgraded kernel). Unless somebody disagrees with that analysis, I'll submit a patch to rename the struct. Suggestions about a suitable name welcome. Martin

2 4

Translation wine documentation to other languages
by Andriy Palamarchuk 01 Aug '02

01 Aug '02

Sorry for crossposting initial message to both lists. I think the topic may be interesting for both - users and developers. Any volunteers to help to translate the documentation to languages other than English? This is very big job, so there can be more than one person, working on the same language. Among responses to my call for volunteers I got response from Pedro Restrepo suggesting his help in Wine localization. See his message below. Damian Wojslaw requested information on the same topic on wine-users. --- Pedro Restrepo <pedrores(a)tutopia.com> wrote: > Hi Andiry, > > First, thank you and thanks to all people working on > Wine. I am using > Wine to run Lotus Notes Client on Linux. At the > moment, we are testing > it. > > I want to help on Wine project. I propose you one > new work: Wine > translation to spanish (documentation, installer, > web site info, etc). I > think in this work because I think this project is > necessary for all > people who need transition tools from Windows to > Linux and there are > many people in this situation in SouthAmerica (I am > from Colombia and I > am tired of the big payments for software in our > poor nations). Currently Wine does not have official documentation in other languages. Some winelib applications are localized to other languages. Documents with highest priority for translation: * README file * Wine User Guide * user-oriented pages on Winehq Plus, we'll need to keep translations in sync with original documentation. Comments, ideas, suggestions? Andriy __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

2 1

Re: PATCH: Convert HMIDI to void*
by Eric Pouech 01 Aug '02

01 Aug '02

Michael Stefaniuc a écrit : > > Hello, > > am I right that HMIDI and HMIDIIN, HMIDIOUT shouldn't be > interchangeable? Would save some conversions. > > License: LGPL, X11 > Changelog: > Michael Stefaniuc <mstefani(a)redhat.com> > Convert HMIDI to a void* I just modified a bit Michael's patch: - better fix for midimap file - changed all HMIDI???? Alexandre, use this version instead. A+ Name: mm_midih ChangeLog: HMIDI??? handles are no long OLD_HANDLE License: X11 GenDate: 2002/08/01 07:11:07 UTC ModifiedFiles: dlls/winmm/lolvldrv.c dlls/winmm/mmsystem.c dlls/winmm/mciseq/mcimidi.c dlls/winmm/midimap/midimap.c include/mmsystem.h AddedFiles: =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/dlls/winmm/lolvldrv.c,v retrieving revision 1.29 diff -u -u -r1.29 lolvldrv.c --- dlls/winmm/lolvldrv.c 3 Jul 2002 21:10:44 -0000 1.29 +++ dlls/winmm/lolvldrv.c 1 Aug 2002 06:51:25 -0000 @@ -693,7 +693,7 @@ *(LPDWORD)((char*)ptr + sizeof(LPMIDIOPENDESC)) = *lpdwUser; mod16 = (LPMIDIOPENDESC16)((LPSTR)ptr + sizeof(LPMIDIOPENDESC) + 2*sizeof(DWORD)); - mod16->hMidi = mod32->hMidi; + mod16->hMidi = LOWORD(mod32->hMidi); mod16->dwCallback = mod32->dwCallback; mod16->dwInstance = mod32->dwInstance; mod16->dnDevNode = mod32->dnDevNode; Index: dlls/winmm/mmsystem.c =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/dlls/winmm/mmsystem.c,v retrieving revision 1.63 diff -u -u -r1.63 mmsystem.c --- dlls/winmm/mmsystem.c 29 Jul 2002 23:29:23 -0000 1.63 +++ dlls/winmm/mmsystem.c 1 Aug 2002 06:51:25 -0000 @@ -2188,7 +2188,7 @@ *lphMidiOut = hMidiOut; if (lpwm) { - lpwm->mod.hMidi = hMidiOut; + lpwm->mod.hMidi = (HMIDI) hMidiOut; lpwm->mod.dwCallback = *lpdwCallback; lpwm->mod.dwInstance = *lpdwInstance; lpwm->mod.dnDevNode = 0; @@ -2739,7 +2739,7 @@ if (lpwm == NULL) return MMSYSERR_NOMEM; - lpwm->mod.hMidi = hMidiIn; + lpwm->mod.hMidi = (HMIDI) hMidiIn; lpwm->mod.dwCallback = dwCallback; lpwm->mod.dwInstance = dwInstance; Index: dlls/winmm/mciseq/mcimidi.c =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/dlls/winmm/mciseq/mcimidi.c,v retrieving revision 1.16 diff -u -u -r1.16 mcimidi.c --- dlls/winmm/mciseq/mcimidi.c 31 May 2002 23:40:57 -0000 1.16 +++ dlls/winmm/mciseq/mcimidi.c 1 Aug 2002 06:51:25 -0000 @@ -817,7 +817,7 @@ wmm->dwStatus = MCI_MODE_NOT_READY; if (oldstat == MCI_MODE_PAUSE) - dwRet = midiOutReset(wmm->hMidi); + dwRet = midiOutReset((HMIDIOUT)wmm->hMidi); while (wmm->dwStatus != MCI_MODE_STOP) Sleep(10); @@ -962,7 +962,7 @@ MIDI_mciReadNextEvent(wmm, mmt); /* FIXME == 0 */ } - dwRet = midiOutOpen(&wmm->hMidi, MIDIMAPPER, 0L, 0L, CALLBACK_NULL); + dwRet = midiOutOpen((LPHMIDIOUT)&wmm->hMidi, MIDIMAPPER, 0L, 0L, CALLBACK_NULL); /* dwRet = midiInOpen(&wmm->hMidi, MIDIMAPPER, 0L, 0L, CALLBACK_NULL);*/ if (dwRet != MMSYSERR_NOERROR) { return dwRet; @@ -1142,7 +1142,7 @@ break; default: if (doPlay) { - dwRet = midiOutShortMsg(wmm->hMidi, mmt->dwEventData); + dwRet = midiOutShortMsg((HMIDIOUT)wmm->hMidi, mmt->dwEventData); } else { switch (LOBYTE(LOWORD(mmt->dwEventData)) & 0xF0) { case MIDI_NOTEON: @@ -1150,7 +1150,7 @@ dwRet = 0; break; default: - dwRet = midiOutShortMsg(wmm->hMidi, mmt->dwEventData); + dwRet = midiOutShortMsg((HMIDIOUT)wmm->hMidi, mmt->dwEventData); } } } @@ -1163,9 +1163,9 @@ } } - midiOutReset(wmm->hMidi); + midiOutReset((HMIDIOUT)wmm->hMidi); - dwRet = midiOutClose(wmm->hMidi); + dwRet = midiOutClose((HMIDIOUT)wmm->hMidi); /* to restart playing at beginning when it's over */ wmm->dwPositionMS = 0; @@ -1212,7 +1212,7 @@ midiHdr.dwBufferLength = 1024; midiHdr.dwUser = 0L; midiHdr.dwFlags = 0L; - dwRet = midiInPrepareHeader(wmm->hMidi, &midiHdr, sizeof(MIDIHDR)); + dwRet = midiInPrepareHeader((HMIDIIN)wmm->hMidi, &midiHdr, sizeof(MIDIHDR)); TRACE("After MIDM_PREPARE \n"); wmm->dwStatus = MCI_MODE_RECORD; /* FIXME: there is no buffer added */ @@ -1220,12 +1220,12 @@ TRACE("wmm->dwStatus=%p %d\n", &wmm->dwStatus, wmm->dwStatus); midiHdr.dwBytesRecorded = 0; - dwRet = midiInStart(wmm->hMidi); + dwRet = midiInStart((HMIDIIN)wmm->hMidi); TRACE("midiInStart => dwBytesRecorded=%lu\n", midiHdr.dwBytesRecorded); if (midiHdr.dwBytesRecorded == 0) break; } TRACE("Before MIDM_UNPREPARE \n"); - dwRet = midiInUnprepareHeader(wmm->hMidi, &midiHdr, sizeof(MIDIHDR)); + dwRet = midiInUnprepareHeader((HMIDIIN)wmm->hMidi, &midiHdr, sizeof(MIDIHDR)); TRACE("After MIDM_UNPREPARE \n"); if (midiHdr.lpData != NULL) { HeapFree(GetProcessHeap(), 0, midiHdr.lpData); @@ -1255,7 +1255,7 @@ /* stop all notes */ unsigned chn; for (chn = 0; chn < 16; chn++) - midiOutShortMsg(wmm->hMidi, 0x78B0 | chn); + midiOutShortMsg((HMIDIOUT)(wmm->hMidi), 0x78B0 | chn); wmm->dwStatus = MCI_MODE_PAUSE; } if (lpParms && (dwFlags & MCI_NOTIFY)) { Index: dlls/winmm/midimap/midimap.c =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/dlls/winmm/midimap/midimap.c,v retrieving revision 1.13 diff -u -u -r1.13 midimap.c --- dlls/winmm/midimap/midimap.c 31 May 2002 23:40:57 -0000 1.13 +++ dlls/winmm/midimap/midimap.c 1 Aug 2002 06:46:12 -0000 @@ -81,7 +81,7 @@ { char name[MAXPNAMELEN]; int loaded; - HMIDI hMidi; + HMIDIOUT hMidi; unsigned short uDevID; LPBYTE lpbPatch; unsigned int aChn[16]; Index: include/mmsystem.h =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/include/mmsystem.h,v retrieving revision 1.51 diff -u -u -r1.51 mmsystem.h --- include/mmsystem.h 31 May 2002 23:06:48 -0000 1.51 +++ include/mmsystem.h 1 Aug 2002 06:52:49 -0000 @@ -34,10 +34,10 @@ DECLARE_OLD_HANDLE(HWAVE); DECLARE_OLD_HANDLE(HWAVEIN); DECLARE_OLD_HANDLE(HWAVEOUT); -DECLARE_OLD_HANDLE(HMIDI); -DECLARE_OLD_HANDLE(HMIDIIN); -DECLARE_OLD_HANDLE(HMIDIOUT); -DECLARE_OLD_HANDLE(HMIDISTRM); +DECLARE_HANDLE(HMIDI); +DECLARE_HANDLE(HMIDIIN); +DECLARE_HANDLE(HMIDIOUT); +DECLARE_HANDLE(HMIDISTRM); DECLARE_OLD_HANDLE(HMIXER); DECLARE_OLD_HANDLE(HMIXEROBJ); DECLARE_OLD_HANDLE(HMMIO);

3 2

Netbios and Wins support
by Claudiu Costin 01 Aug '02

01 Aug '02

Dear friends, Is there anybody working on Netbios/MS Windows Network support? I want to run Outlook with Exchange. I can help testing and hacking, but not writing real code. kind regards, -- Claudiu Costin, claudiuc(a)kde.org Linux-KDE Romania http://www.ro.kde.org

2 1

Re: PATCH: Convert HMIDI to void*
by Eric Pouech 31 Jul '02

31 Jul '02

Michael Stefaniuc a écrit : > > Hello, > > am I right that HMIDI and HMIDIIN, HMIDIOUT shouldn't be > interchangeable? Would save some conversions. yes & no HMIDIIN cannot be used for a HMIDIOUT (anyway, this will be checked internally by our mmsys implementation: all HMIDI???? handles are stored in the same table, and we never rely on the HMIDI??? handle type but on the actual object type) however, HMIDI can be used for a HMIDIIN (or HMIDIOUT or HMIDISTRM) handle (see midiConnect for example) it's true that midimap dll should use HMIDIOUT instead of HMIDI in its internal data structure A+

3 4

Toolbar redraw problem
by dusanv 31 Jul '02

31 Jul '02

Hi, I am seeing a bunch of apps have redrawing problems when a toolbar is dragged accross the window. Here's a screen shot: http://dusanv.net/files/wine-ss.png Does anyone have any info on this? I'd like to fix it but can't find anyhting relevant. TIA, Dusan

2 2

Re: PATCH: a bit further with a cygwin build (fixed patch)
by Francois Gouget 31 Jul '02

31 Jul '02

On Tue, 30 Jul 2002, Rafael Kitover wrote: > Sorry, due to brain-deadness on my part the previous version of this > patch didn't build properly. This version is much cleaner and builds > properly on linux. > +#ifndef HAVE__FSTAT > int _fstat(int fd, struct _stat* buf) > +#else > +int MSVCRT(_fstat)(int fd, struct _stat* buf) > +#endif /* HAVE__FSTAT */ ... > +#ifndef HAVE__STAT > int _stat(const char* path, struct _stat * buf) > +#else > +int MSVCRT(_stat)(const char* path, struct _stat * buf) > +#endif /* HAVE__STAT */ You should systematically use MSVCRT(_fstat) and MSVCRT(_stat). Your previous patch was better :-) Basically, we use MSVCRT(xxx) for all symbols for which we may get a conflict with the native C library headers. On Unix systyems, the _xxx functions are never defined (though there may be a couple of exceptions) so we don't use MSVCRT() for readability's sake. But if you find a system where there is a conflict, then it's best to just systematically use MSVCRT() than to use ifdefs that make it even harder to read. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Any sufficiently advanced Operating System is indistinguishable from Linux

1 0