Re: Header files that conflict with UNIX headers
George Boutwell wrote: --- Francois Gouget [EMAIL PROTECTED] wrote: Yes and no. They need a C library (badly). Frankly I've never used 'crtdll.dll' and don't know it very well. All I know is that it seems very similar to a C library except I'm not sure who is supposed to use it. All the windows programs I've worked on/know of use the standard 'msvcrt.dll'. And all the 'C library' headers in the Windows directory are for 'msvcrt.dll'. This is probably just for your information, but as I understand it. crtdll.dll only came with the very first version of Windows 95, all subsequent version of Win95 (A, B, C, OSR2, OSR2a, etc) either didn't have it at all, or had msvcrt.dll Umm, negative. CRTDLL is still included in Windows 98SE. However I think you may be right that it is not used by anything, but MSVCRT is used instead. According to MSDN, MSVC(++) 6 links against one of 6 C runtime libraries. The first two are release and debug versions of a STATICLY LINKED LIBC(D).LIB which are not MT safe. The next two are release and debug versions of another staticly linked, but MT safe LIBCMT(D).LIB. Finally, there are the MSVCRT(D).LIB import libraries for MSVCRT.DLL. No where does it mention CRTDLL. See http://msdn.microsoft.com/library/periodic/period99/win320799.htm for more details. Not sure what effect that has on how much support/non-support Wine/Winelib should have for crtdll.dll AFAIK, CRTDLL is an older implementation that had bugs relating to MT safeness (i.e. It was supposed to be safe but fell short in some cases). IMHO implementing CRTDLL is not a very high priority, while implementing a reliable C library (MSVCRT) is. However, if it works out that the MSVCRT implementation can be used to implement most or all of CRTDLL, then I think that would be a reasonable thing to do. I am going to go ahead and start implementing MSVCRT so it can be used by winelib. -Dave
Re: Header files that conflict with UNIX headers
George Boutwell wrote: crtdll.dll only came with the very first version of Windows 95, all subsequent version of Win95 (A, B, C, OSR2, OSR2a, etc) either didn't have it at all, or had msvcrt.dll Luckily for this discussion, I had to blow away my C: partition last night and reinstall Win98 (gold retail version). It includes CRTDLL.DLL in WINDOWS\SYSTEM, dated May 11, 1998 (same as the other default system DLLs for Win98 gold retail). MSVCRT is also included of course, since Internet Explorer needs it. -Ian Schmidt [EMAIL PROTECTED]
Re: Focus to deleted windows
On Sun, Oct 29, 2000 at 08:59:53AM -0500, gerard patel wrote: That's they call 'embrace and extend' I guess. This is Marcus's idea but it did not fix the bug with *my* application, so I changed it a bit. I hope it's still fixing his problem - logically it should :-) I just wanted to go and create a revised that does (only for the toplevel destroyed window), that does check the destroyed window tree ONCE for containing the focus: hwnd = GetFocus16(); while (hwnd (GetWindowLongA(hwnd,GWL_STYLE) WS_CHILD)) { if (hwnd == topdestroyedhwnd) { SetFocus(GetWindowLongA(topdestroyedhwnd,GWL_HWNDPARENT); break; } hwnd = GetWindowLongA(hwnd,GWL_HWNDPARENT); } This would be a bit cleaner than my first approach. ;) The 2 points where I have tried to extend his patch are : Not addressed by above approach. How does Windows USER does this? Hmm :/ Ciao, Marcus
Re: PATCH: reduce stackspace usage
Marcus Meissner [EMAIL PROTECTED] writes: No longer use safety buffer of 1 mb for thread stack to save memory. I don't think this is right. The specified stack size is the commit size, but we must still reserve 1Mb (except maybe if a smaller size was specified in the PE header). If the thread doesn't use all of it, it won't cost any memory anyway. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Preferred way to get all 'recent' code
On Sat, Oct 28, 2000 at 10:29:34AM +0100, robert w hall wrote: In message [EMAIL PROTECTED], Andreas Mohr [EMAIL PROTECTED] writes If you're an end-user, you might want to stick with normal releases. Why? But even for end-users CVS is not too bad ;) Andreas Mohr I thought Alexandre's present policy was that there was no real difference between a dated release and a CVS snapshot? Err, wrong. Andreas Mohr
Re: Header files that conflict with UNIX headers
--- David Elliott [EMAIL PROTECTED] wrote: This is probably just for your information, but as I understand it. crtdll.dll only came with the very first version of Windows 95, all subsequent version of Win95 (A, B, C, OSR2, OSR2a, etc) either didn't have it at all, or had msvcrt.dll Umm, negative. CRTDLL is still included in Windows 98SE. However I think you may be right that it is not used by anything, but MSVCRT is used instead. According to MSDN, MSVC(++) 6 links against one of 6 C runtime libraries. The first two are release and debug versions of a STATICLY LINKED LIBC(D).LIB which are not MT safe. The next two are release and debug versions of another staticly linked, but MT safe LIBCMT(D).LIB. Finally, there are the MSVCRT(D).LIB import libraries for MSVCRT.DLL. No where does it mention CRTDLL. Yeah... Sorry got a little mixed-up there. The problem we had was missing the msvcrt (assuming to was installed by Windows, when infact it's not, in the case of a First version of Windows 95). Also, another difference I believe I've heard before is that MSVCRT.DLL bring MS closer to having a POSIX 'compatible' run-time library. AFAIK, CRTDLL is an older implementation that had bugs relating to MT safeness (i.e. It was supposed to be safe but fell short in some cases). IMHO implementing CRTDLL is not a very high priority, while implementing a reliable C library (MSVCRT) is. However, if it works out that the MSVCRT implementation can be used to implement most or all of CRTDLL, then I think that would be a reasonable thing to do. Agreed. I haven't seen many (if any) apps that use/need CRTDLL.DLL, but I have run into some apps that needed MSVCRT.DLL (and in some situations where it wasn't there and the installer didn't put it on the system either.) Sorry for the confusion, guess that'll teach me to shoot my mouth off... :( George __ Do You Yahoo!? Yahoo! Messenger - Talk while you surf! It's FREE. http://im.yahoo.com/
Re: Preferred way to get all 'recent' code
Ok. I thought I remembered something on WineHQ about d/ling some tar.gz of the source tree, then using CVS to 'update' that. Thanks everyone for replying. George __ Do You Yahoo!? Yahoo! Messenger - Talk while you surf! It's FREE. http://im.yahoo.com/
Re: Preferred way to get all 'recent' code
On Sun, 29 Oct 2000, George Boutwell wrote: Ok. I thought I remembered something on WineHQ about d/ling some tar.gz of the source tree, then using CVS to 'update' that. You're right. That is just a shortcut to save time when first downloading the CVS tree: since FTPing a tarball is faster than a virgin CVS checkout, it makes sense to download the latest snapshot, then just use CVS to download the differences between that and the CVS tree. James.
Menu alignement
Hi, The menu patch I sent last week was wrong: it causes Win9x's 'magic items' to be aligned on the left again. This weekend I worked at fixing it and now I believe that all items following the first menu item that has MF_RIGHTJUSTIFY (aka MF_HELP) should be aligned to the right. But not bitmaps! Juergen, according to CVS Web you're the one who added the IS_BITMAP_ITEM check: Revision 1.32 / (download) - [select for diffs] , Mon Apr 26 14:54:38 1999 UTC (18 months ago) by julliard Branch: MAIN CVS Tags: Wine-990426 Changes since 1.31: +23 -19 lines Diff to previous 1.31 Juergen Schmied [EMAIL PROTECTED] - align magic buttons right - shortcuts alignment working again Why did you add it? Was it for a Win 3.1 application? Any chance I might have it? I attached the latest version of my patch for review. Of course it has to first undo my first patch so it's bigger than it should. Hopefully I'll get it right for the next round. See also: http://fgouget.free.fr/wine/PrgWin95/Chap10.shtml#grafmenu -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ La terre est une bĂȘta... Index: controls/menu.c === RCS file: /home/wine/wine/controls/menu.c,v retrieving revision 1.88 diff -u -r1.88 menu.c --- controls/menu.c 2000/10/26 21:47:20 1.88 +++ controls/menu.c 2000/10/30 02:17:59 @@ -1000,7 +1000,7 @@ /* Parse items until line break or end of menu */ for (i = start; i lppop-nItems; i++, lpitem++) { - if ((helpPos == -1) (lpitem-fType MF_HELP)) helpPos = i; + if ((helpPos == -1) (lpitem-fType MF_RIGHTJUSTIFY)) helpPos = i; if ((i != start) (lpitem-fType (MF_MENUBREAK | MF_MENUBARBREAK))) break; @@ -1025,21 +1025,19 @@ lprect-bottom = maxY; lppop-Height = lprect-bottom - lprect-top; -if (TWEAK_WineLook == WIN31_LOOK) { -/* Flush right all magic items and items between the MF_HELP and */ -/* the last item (if several lines, only move the last line) */ -lpitem = lppop-items[lppop-nItems-1]; -orgY = lpitem-rect.top; -orgX = lprect-right; -for (i = lppop-nItems - 1; i = helpPos; i--, lpitem--) { -if ( !IS_BITMAP_ITEM(lpitem-fType) ((helpPos==-1) || (helpPosi) )) -break; /* done */ -if (lpitem-rect.top != orgY) break; /* Other line */ -if (lpitem-rect.right = orgX) break; /* Too far right already */ -lpitem-rect.left += orgX - lpitem-rect.right; -lpitem-rect.right = orgX; -orgX = lpitem-rect.left; -} +/* Flush right all magic items and items between the MF_RIGHTJUSTIFY and */ +/* the last item (if several lines, only move the last line) */ +lpitem = lppop-items[lppop-nItems-1]; +orgY = lpitem-rect.top; +orgX = lprect-right; +for (i = lppop-nItems - 1; i = helpPos; i--, lpitem--) { +if ( (helpPos==-1) || (helpPosi) ) +break; /* done */ +if (lpitem-rect.top != orgY) break; /* Other line */ +if (lpitem-rect.right = orgX) break; /* Too far right already */ +lpitem-rect.left += orgX - lpitem-rect.right; +lpitem-rect.right = orgX; +orgX = lpitem-rect.left; } }
Dots and dashes
Hi, The lines drawn with PS_DASH, PS_DOT, PS_DASHDOT, etc. looked wrong in Wine: the dots and dashes were basically way too short and their proportions were wrong. So I fixed their definitions in graphics/x11drv/pen.c. Here's a patch that fixes them so that they look the same as on Win 9x, let me know if it breaks Win 3.1 applications before I submit it to wine-patches. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ The nice thing about meditation is that it makes doing nothing quite respectable -- Paul Dean Index: graphics/x11drv/pen.c === RCS file: /home/wine/wine/graphics/x11drv/pen.c,v retrieving revision 1.7 diff -u -r1.7 pen.c --- graphics/x11drv/pen.c 2000/04/25 19:55:35 1.7 +++ graphics/x11drv/pen.c 2000/10/29 21:13:12 @@ -11,10 +11,10 @@ #include "x11drv.h" #include "debugtools.h" -static const char PEN_dash[] = { 5,3 }; /* - - - */ -static const char PEN_dot[]= { 1,1 }; /* -- -- -- -- -- -- */ -static const char PEN_dashdot[]= { 4,3,2,3 }; /* -- -- */ -static const char PEN_dashdotdot[] = { 4,2,2,2,2,2 }; /* -- -- */ +static const char PEN_dash[] = { 16,8 }; /* - - - */ +static const char PEN_dot[]= { 4,4 }; /* -- -- -- -- -- -- */ +static const char PEN_dashdot[]= { 12,8,4,8 }; /* -- -- */ +static const char PEN_dashdotdot[] = { 12,4,4,4,4,4 }; /* -- -- */ static const char PEN_alternate[] = { 1,1 }; /* FIXME */ /***
Windows Media Player
Sorry if you already know this, but Windows Media Player works with the following patch^H^H^H^H^Hnasty hack: --cut-- Index: dlls/ddraw/ddraw/dga.c === RCS file: /home/wine/wine/dlls/ddraw/ddraw/dga.c,v retrieving revision 1.16 diff -c -r1.16 dga.c *** dlls/ddraw/ddraw/dga.c 2000/10/23 00:36:45 1.16 --- dlls/ddraw/ddraw/dga.c 2000/10/30 03:30:26 *** *** 421,427 TRACE(" Creating IDirectDraw4 interface (%p)\n", *obj); return S_OK; } ! if ( IsEqualGUID( IID_IDirectDraw7, refiid ) ) { IDirectDraw4Impl*dd = HeapAlloc(GetProcessHeap(),0,sizeof(*dd)); ICOM_VTBL(dd) = dga_dd7vt;dd-ref = 1;dd-d = This-d;This-d++; *obj = dd; --- 421,428 TRACE(" Creating IDirectDraw4 interface (%p)\n", *obj); return S_OK; } ! if ( IsEqualGUID( IID_IDirectDraw7, refiid ) || !(FIXME(" NASTY HACK! IDirectDraw unknown interface, using DDraw4. (%p)\n", *obj) || 1)) { IDirectDraw4Impl*dd = HeapAlloc(GetProcessHeap(),0,sizeof(*dd)); ICOM_VTBL(dd) = dga_dd7vt;dd-ref = 1;dd-d = This-d;This-d++; *obj = dd; --cut-- And by "works" I mean it can play a DivX movie, and both video and sound work right. :) -- Kenneth Arnold [EMAIL PROTECTED] / kcarnold / Linux user #180115 http://arnoldnet.net/~kcarnold/
MS Office 2k doesnt install...
Hi, i have isntalled WINE from the manual instructions, but when i attempt to install office 2k off the cd i get an error that says "Installing this product requires the Windows Installer. An error occurered when installing or upgrading the Windows installer.".. the console messages (for defualt options) are bellow: btw: wine -v Wine release 20001026 -- wine setup Invalid path 'c:\windows\Profiles\Administrator' for profile directory Can't open MIDI device '/dev/sequencer' ! (No such device). If your program needs this (probably not): load MIDI sequencer kernel driver ! fixme:module:CreateProcessA (D:\msi\instmsi.exe,...): NORMAL_PRIORITY_CLASS ignored fixme:module:CreateProcessA (D:\msi\instmsi.exe,...): STARTF_FORCEONFEEDBACK ignored fixme:pthread_kill_other_threads_np Invalid path 'c:\windows\Profiles\Administrator' for profile directory fixme:module:CreateProcessA (E:\IXP000.TMP\msiinst.exe,...): NORMAL_PRIORITY_CLASS ignored fixme:pthread_kill_other_threads_np Invalid path 'c:\windows\Profiles\Administrator' for profile directory fixme:module:CreateProcessA (MsiExec.exe,...): NORMAL_PRIORITY_CLASS ignored fixme:module:CreateProcessA (MsiExec.exe,...): STARTF_FORCEONFEEDBACK ignored fixme:pthread_kill_other_threads_np Invalid path 'c:\windows\Profiles\Administrator' for profile directory fixme:ntdll:NtOpenThreadToken (0xfffe,0x000f,0x0001,0x3f11ec00): stub fixme:ntdll:NtOpenThreadToken (0xfffe,0x0004,0x0001,0x4076577c): stub fixme:advapi:SetThreadToken ((nil), 0): stub fixme:ntdll:NtOpenProcessToken (0x,0x0008,0x40765780): stub fixme:ntdll:NtQueryInformationToken (cafe,1,0x407655c4,80,0x40765618): stub fixme:advapi:SetThreadToken ((nil), cafe): stub fixme:ntdll:NtOpenThreadToken (0xfffe,0x0008,0x0001,0x497f6578): stub fixme:ntdll:NtQueryInformationToken (cafe,8,0x497f656c,4,0x497f6570): stub fixme:advapi:SetThreadToken ((nil), cafe): stub fixme:advapi:SetThreadToken ((nil), 0): stub fixme:advapi:SetThreadToken ((nil), cafe): stub fixme:advapi:SetThreadToken ((nil), 0): stub fixme:advapi:SetThreadToken ((nil), cafe): stub fixme:advapi:SetThreadToken ((nil), 0): stub fixme:advapi:SetThreadToken ((nil), cafe): stub fixme:advapi:SetThreadToken ((nil), 0): stub fixme:advapi:SetThreadToken ((nil), cafe): stub fixme:advapi:SetThreadToken ((nil), 0): stub fixme:advapi:SetThreadToken ((nil), cafe): stub fixme:advapi:SetThreadToken ((nil), 0): stub fixme:advapi:SetThreadToken ((nil), cafe): stub fixme:advapi:SetThreadToken ((nil), 0): stub fixme:advapi:SetThreadToken ((nil), cafe): stub fixme:advapi:SetThreadToken ((nil), 0): stub fixme:advapi:SetThreadToken ((nil), cafe): stub fixme:advapi:SetThreadToken ((nil), 0): stub fixme:advapi:SetThreadToken ((nil), cafe): stub fixme:advapi:SetThreadToken ((nil), 0): stub fixme:advapi:SetThreadToken ((nil), cafe): stub fixme:advapi:SetThreadToken ((nil), 0): stub fixme:advapi:SetThreadToken ((nil), cafe): stub fixme:advapi:SetThreadToken ((nil), 0): stub fixme:advapi:SetThreadToken ((nil), cafe): stub fixme:advapi:SetThreadToken ((nil), 0): stub fixme:advapi:SetThreadToken ((nil), cafe): stub fixme:advapi:SetThreadToken ((nil), 0): stub fixme:advapi:SetThreadToken ((nil), cafe): stub fixme:advapi:SetThreadToken ((nil), 0): stub fixme:advapi:SetThreadToken ((nil), cafe): stub fixme:advapi:SetThreadToken ((nil), 0): stub fixme:advapi:SetThreadToken ((nil), cafe): stub fixme:advapi:SetThreadToken ((nil), 0): stub fixme:advapi:SetThreadToken ((nil), cafe): stub fixme:advapi:SetThreadToken ((nil), 0): stub fixme:advapi:SetThreadToken ((nil), cafe): stub fixme:advapi:SetThreadToken ((nil), 0): stub fixme:advapi:SetThreadToken ((nil), cafe): stub fixme:advapi:SetThreadToken ((nil), 0): stub fixme:advapi:SetThreadToken ((nil), cafe): stub fixme:advapi:SetThreadToken ((nil), 0): stub fixme:advapi:SetThreadToken ((nil), cafe): stub fixme:advapi:SetThreadToken ((nil), 0): stub fixme:advapi:SetThreadToken ((nil), cafe): stub fixme:advapi:SetThreadToken ((nil), 0): stub This installation package could not be opened. Contact the application vendor to verify that this is a valid Windows Installer package. -- Thanx, David -- **note** I'm currently in-between email address, I'll let you know when i get a permanent one!
Re: Windows Media Player
Can it play ASF? Thanx David On Sun, 29 Oct 2000 22:43:38 -0500, Kenneth Arnold said: Sorry if you already know this, but Windows Media Player works with the following patch^H^H^H^H^Hnasty hack: --cut-- Index: dlls/ddraw/ddraw/dga.c === RCS file: /home/wine/wine/dlls/ddraw/ddraw/dga.c,v retrieving revision 1.16 diff -c -r1.16 dga.c *** dlls/ddraw/ddraw/dga.c 2000/10/23 00:36:45 1.16 --- dlls/ddraw/ddraw/dga.c 2000/10/30 03:30:26 *** *** 421,427 TRACE(" Creating IDirectDraw4 interface (%p)\n", *obj); return S_OK; } ! if ( IsEqualGUID( IID_IDirectDraw7, refiid ) ) { IDirectDraw4Impl*dd = HeapAlloc(GetProcessHeap(),0,sizeof(*dd)); ICOM_VTBL(dd) = dga_dd7vt;dd-ref = 1;dd-d = This-d;This-d++; *obj = dd; --- 421,428 TRACE(" Creating IDirectDraw4 interface (%p)\n", *obj); return S_OK; } ! if ( IsEqualGUID( IID_IDirectDraw7, refiid ) || !(FIXME(" NASTY HACK! IDirectDraw unknown interface, using DDraw4. (%p)\n", *obj) || 1)) { IDirectDraw4Impl*dd = HeapAlloc(GetProcessHeap(),0,sizeof(*dd)); ICOM_VTBL(dd) = dga_dd7vt;dd-ref = 1;dd-d = This-d;This-d++; *obj = dd; --cut-- And by "works" I mean it can play a DivX movie, and both video and sound work right. :) -- Kenneth Arnold [EMAIL PROTECTED] / kcarnold / Linux user #180115 http://arnoldnet.net/~kcarnold/ -- **note** I'm currently in-between email address, I'll let you know when i get a permanent one!
Re: GetProcAddress
[EMAIL PROTECTED] writes: I don't see, though, why a winelib implementation of an .exe should be limited to the win32 api. It is after all, simply a *nix X application. Hmmm, unless you compile it with mingw or so. Right. strchr it shall be. That way you can compile an .exe file and run on Vmware/Winxx to see if it really does what it's supposed to do. Bye Uwe Bonnes[EMAIL PROTECTED] Free Software: If you contribute nothing, expect nothing --