Re: MSVC4, next two buttons on installer
Dan Kegel wrote: Q1. What do I have to do to get Wine's builtin rich text DLL to work there? I tried wine --dll riched32=b, but that didn't help. there are several version of the richedit DLLs. riched32 should be version 1.0. what your app requires seems to be version 2.0 of this DLL. as of today, version 1.0 is very poorly implemented in wine, and far from 2.0... so you're stuck with either using native riched20.dll, or doing lots of hard work to implement version 1.0 and 2.0 (IIRC, there's also a 3.0 version ;-) Q2. Any idea what I'd need to do to get a Windows Explorer going without actually installing the real Windows Explorer?-) Does Wine have a builtin Windows Explorer clone yet? there's a winfile compatible (winefile) in the programs directory, but this isn't really an explorer clone. however making it explorer.exe compatible (from the command line point of view) shouldn't be too difficult. but there are lots of other stuff in there (DDE server for example) which will require quite some work too. A+ -- Eric Pouech
[RFH] _FORCENAMELESSUNION
Folks,
Why do we need to define _FORCENAMELESSUNION to get nameless unions
in oleauto.h? Is this a standard feature, or is it just another Wine
extension? Can someone please check the Windows headers to see how
struct tagVARIANT is defined? Our is as follows:
struct tagVARIANT
{
union
{
struct __tagVARIANT
{
VARTYPE vt;
WORD wReserved1;
WORD wReserved2;
WORD wReserved3;
union /* DUMMYUNIONNAME */
{
/* By value. */
CHAR cVal;
USHORT uiVal;
ULONG ulVal;
INT intVal;
UINT uintVal;
BYTE bVal;
short iVal;
long lVal;
float fltVal;
double dblVal;
VARIANT_BOOL boolVal;
SCODE scode;
DATE date;
BSTR bstrVal;
CY cyVal;
IUnknown* punkVal;
IDispatch* pdispVal;
SAFEARRAY* parray;
/* By reference */
CHAR* pcVal;
USHORT* puiVal;
ULONG* pulVal;
INT* pintVal;
UINT* puintVal;
BYTE* pbVal;
short* piVal;
long* plVal;
float* pfltVal;
double* pdblVal;
VARIANT_BOOL* pboolVal;
SCODE* pscode;
DATE* pdate;
BSTR* pbstrVal;
VARIANT* pvarVal;
PVOID byref;
CY* pcyVal;
DECIMAL* pdecVal;
IUnknown** ppunkVal;
IDispatch** ppdispVal;
SAFEARRAY** pparray;
} __VARIANT_NAME_3;
} __VARIANT_NAME_2;
DECIMAL decVal;
} __VARIANT_NAME_1;
};
--
Dimi.
Re: wineboot - Andy's version
Ok, I was under the impression that we want something in so that we can start working on it. As this is the way you feel about the current wineboot, I think I'll go a completely new route. Please let me know your thoughts about the new proposed process. In windows, some of the boot operations are done by the core windows. These include wininit processing, win.ini, rename registry keys, and the services (can probably wait with these, however). Other things are performed by explorer when it first starts. These include the run and runonce keys. What I'm thinking is incorporating the first group into the wine code itself (I'm thinking the server startup, synchroniously done). For the second group, create a wineboot program, and have a single option saying whether the wineserver should run it on startup or not. Ideas, comments, opinions are welcome. Shachar Alexandre Julliard wrote: Shachar Shemesh [EMAIL PROTECTED] writes: Just wanted to know whether this fell through the cracks, or whether there was another reason this was not commited to CVS. I was hoping you would clean it up, not simply resubmit Andi's stuff. As discussed with Andi already, this thing is much too complex and over-engineered. It has to be a simple application that doesn't require user interaction or a dozen configuration parameters.
Re: __WINE__ vs. __WINESRC__
Dimitrie O. Paun [EMAIL PROTECTED] wrote: Here is another problem: we are currently defining the __WINE__ symbol to signal the headers that we are compiling Wine. This is fine. The problem that I'm facing is that there are apps (such as wxWindows) that want to know that they are _compiled_ (not run) under Wine. All platforms (and Wine is a platform, even if a virtual one) define standard symbols by default: __WIN32__, __MINGW32__, you name it. Compiling under Wine should not IMO require defining additional symbols except probably __WIN32__. There are valid reasons for a program to be able to test that is being compiled under Wine, and not under MinGW for example. What are that reasons? Care to list some of them? -- Dmitry.
Re: [RFH] _FORCENAMELESSUNION
On Sun, 22 Dec 2002, Dimitrie O. Paun wrote: Folks, Why do we need to define _FORCENAMELESSUNION to get nameless unions in oleauto.h? Is this a standard feature, or is it just another Wine extension? It's a standard MS feature, and Wine defines VARIANT exactly like Windows. Perhaps the problem is more that MS defines __STDC__ only in strict ANSI C compatibility without nameless unions mode or something, and mingw defines it always? Perhaps you could investigate the mingw headers to see if they've changed the #ifs around to get around this. If you come up with something, I could make the necessary changes to my coming-soon oaidl.idl.
Re: [RFH] _FORCENAMELESSUNION
On Sun, 22 Dec 2002, Dimitrie O. Paun wrote: Folks, Why do we need to define _FORCENAMELESSUNION to get nameless unions in oleauto.h? Is this a standard feature, or is it just another Wine extension? Can someone please check the Windows headers to see how struct tagVARIANT is defined? Our is as follows: _FORCENAMELESSUNION is a Windows 'feature' (checked against the latest SDK afaik). We do it like they do. Our variant type matches the Windows one except for tiny differences (e.g. short instead of SHORT) and we lack the __tagBRECORD field. I can send a patch to add these (tomorrow, it's late here). -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Avoid the Gates of Hell - use Linux.
Re: [RFH] _FORCENAMELESSUNION
On Sun, 22 Dec 2002, Francois Gouget wrote: On Sun, 22 Dec 2002, Dimitrie O. Paun wrote: Folks, Why do we need to define _FORCENAMELESSUNION to get nameless unions in oleauto.h? Is this a standard feature, or is it just another Wine extension? Can someone please check the Windows headers to see how struct tagVARIANT is defined? Our is as follows: _FORCENAMELESSUNION is a Windows 'feature' (checked against the latest SDK afaik). We do it like they do. Our variant type matches the Windows one except for tiny differences (e.g. short instead of SHORT) and we lack the __tagBRECORD field. I can send a patch to add these (tomorrow, it's late here). BRECORD is already in my oaidl.idl (should be submitted sometime after the holidays), so it's not necessary.
Re: Conditional to support Solaris
On Sun, 22 Dec 2002 05:42, Alexandre Julliard wrote: Robert Lunnon [EMAIL PROTECTED] writes: I need to introduce a compile time conditional to better facilitate Solaris, in particular the macro ADDRESS_SPACE_LIMIT in virtual.c. I understand HAVE_SOLARIS is frowned upon so can anyone suggest a more targetted alternative (Could use __sysv__ but who knows whether all SYSV implementations need to define ADDRESS_SPACE_LIMIT the same way !) As has been discussed already, ADDRESS_SPACE_LIMIT is a Windows limitation, not a Linux one, so it must not be changed for Solaris. The right way is to somehow reserve the area above ADDRESS_SPACE_LIMIT so that it's not used for normal allocations. Either way, there needs to be a conditional (or run-time test)
Re: Some strange winedbg regression...
On Sat, 21 Dec 2002, Lionel Ulmer wrote:
On Sat, Dec 21, 2002 at 05:49:23PM +0100, Eric Pouech wrote:
So I was wondering how to debug this ? I tried to attach 'gdb' to it (and it
works) but how do I know which symbols to load (winedbg being a script, wine
having no code except linking to DLLs, ) ?
load miscemu/wine in gdb, it'll get what you're looking for
OK, what happens is that the application is loading the DINPUT library...
And at DLL load time, it adds a low-level hook for the keyboard (I wonder
why only for the keyboard and not the mouse, but well, that's another
problem :-) ).
And it seems that the invocation of this hook from the wineconsole makes
Wine crash. I think that the problem is that the DLL is loaded from the
application's context and called from the console context.
Now, one could do the same for the mouse, ie install the hook only later on
when acquiring the keyboard,
Or when creating the device (since Arjen Nienhuis made it hook on startup
because some app used GetDeviceState without acquiring the device), like
in this WineX patch I just wrote to fix a game that didn't like the dinput
hook to be installed before its own keyboard hook:
Index: dinput_main.c
===
RCS file: /cvsroot/winex/wine/dlls/dinput/dinput_main.c,v
retrieving revision 1.18
diff -u -r1.18 dinput_main.c
--- dinput_main.c 25 Sep 2002 20:23:15 - 1.18
+++ dinput_main.c 22 Dec 2002 14:52:02 -
@@ -43,10 +43,8 @@
switch(reason)
{
case DLL_PROCESS_ATTACH:
-keyboard_hook = SetWindowsHookExW( WH_KEYBOARD_LL, KeyboardCallback, 0, 0 );
break;
case DLL_PROCESS_DETACH:
-UnhookWindowsHookEx(keyboard_hook);
break;
}
return TRUE;
Index: dinput_private.h
===
RCS file: /cvsroot/winex/wine/dlls/dinput/dinput_private.h,v
retrieving revision 1.8
diff -u -r1.8 dinput_private.h
--- dinput_private.h5 Sep 2002 11:52:43 - 1.8
+++ dinput_private.h22 Dec 2002 14:52:02 -
@@ -26,10 +26,6 @@
extern void dinput_register_device(dinput_device *device) ;
-HHOOK keyboard_hook;
-
-LRESULT CALLBACK KeyboardCallback( int code, WPARAM wparam, LPARAM lparam );
-
HRESULT DeviceThunkA_create_device(dinput_device* device, IDirectInputImpl* dinput,
REFGUID rguid, REFIID riid, LPDIRECTINPUTDEVICEA* pdev);
HRESULT DeviceThunkW_create_device(dinput_device* device, IDirectInputImpl* dinput,
REFGUID rguid, REFIID riid, LPDIRECTINPUTDEVICEW* pdev);
HRESULT DeviceThunkA_enum_device(dinput_device* device, DWORD dwDevType, DWORD
dwFlags, LPDIDEVICEINSTANCEA lpddi);
Index: keyboard/main.c
===
RCS file: /cvsroot/winex/wine/dlls/dinput/keyboard/main.c,v
retrieving revision 1.16
diff -u -r1.16 main.c
--- keyboard/main.c 25 Sep 2002 20:23:15 - 1.16
+++ keyboard/main.c 22 Dec 2002 14:52:02 -
@@ -59,6 +59,8 @@
static BYTE DInputKeyState[256]; /* array for 'GetDeviceState' */
+CRITICAL_SECTION keyboard_crit = CRITICAL_SECTION_INIT(dinput_keyboard);
+DWORD keyboard_users;
HHOOK keyboard_hook;
LRESULT CALLBACK KeyboardCallback( int code, WPARAM wparam, LPARAM lparam )
@@ -147,6 +149,11 @@
memcpy((newDevice-guid),rguid,sizeof(*rguid));
newDevice-dinput = dinput;
+EnterCriticalSection(keyboard_crit);
+if (!keyboard_users++)
+ keyboard_hook = SetWindowsHookExW( WH_KEYBOARD_LL, KeyboardCallback, 0, 0 );
+LeaveCriticalSection(keyboard_crit);
+
return newDevice;
}
@@ -179,6 +186,31 @@
DECL_GLOBAL_CONSTRUCTOR(keyboarddev_register) { dinput_register_device(keyboarddev);
}
+static ULONG WINAPI SysKeyboardAImpl_Release(LPDIRECTINPUTDEVICE8A iface)
+{
+ ICOM_THIS(SysKeyboardAImpl,iface);
+
+ This-ref--;
+ if (This-ref)
+ return This-ref;
+
+ EnterCriticalSection(keyboard_crit);
+ if (!--keyboard_users) {
+ UnhookWindowsHookEx( keyboard_hook );
+ keyboard_hook = 0;
+ }
+ LeaveCriticalSection(keyboard_crit);
+
+ /* Free the data queue */
+ if (This-buffer != NULL)
+ HeapFree(GetProcessHeap(),0,This-buffer);
+
+ DeleteCriticalSection((This-crit));
+
+ HeapFree(GetProcessHeap(),0,This);
+ return 0;
+}
+
static HRESULT WINAPI SysKeyboardAImpl_SetProperty(
LPDIRECTINPUTDEVICE8A iface,REFGUID rguid,LPCDIPROPHEADER ph
)
@@ -381,7 +413,7 @@
ICOM_MSVTABLE_COMPAT_DummyRTTIVALUE
IDirectInputDevice2AImpl_QueryInterface,
IDirectInputDevice2AImpl_AddRef,
- IDirectInputDevice2AImpl_Release,
+ SysKeyboardAImpl_Release,
SysKeyboardAImpl_GetCapabilities,
IDirectInputDevice2AImpl_EnumObjects,
IDirectInputDevice2AImpl_GetProperty,
Re: [RFC] wintab dll design: how to intergrate with current X11 code.
Right, can now ignore my original post, and comment on the following. Ok, I've sort of found a template for the X11_drv wintab seperation: The tablate is the direct X drirect draw, and open GL dlls. These dlls do the following: X11_drv thread synchronisation Grab the X device the GDI code uses. (I only want to grab the same display string, and build my own XDisplay object). Get the X window handle from a win32 window handle. This is all that's needed to attach the wintab dll to the XInput code. I shall put no extra code in the X11_drv. All XInput calls will live in the wintab dll. One fly may appear in the ointment: It is possible for the X11 driver to insert wintab messages into wthe win32 message queue. This can be handled entirely inside the wintab dll, but the tablet messages may get out of sync with the rest of the windows messages. If the messages do get out of sync, then wintab may need to hook into the event code int x11_drv/event.c. For the moment I'm assuming this won't happen. That's all for now Merry Christmas -Rob.
Re: __WINE__ vs. __WINESRC__
On December 22, 2002 04:44 am, Dmitry Timoshkov wrote: Compiling under Wine should not IMO require defining additional symbols except probably __WIN32__. It shouldn't. In theory. But the difference between practice and theory is that while in theory practice and theory are the same, in practice they are different ((c) Larry McVoy) :). For example, they may test for it to work around bugs in Wine. Yeah, Wine shouldn't have bugs, but it does, and will continue to do so for the forseeable future. Yes, they should submit a patch instead, but they are 3rd party apps, they can't wait for the change to propagate to all users. Just like we asked for -fshort-char in gcc, but we can't assume all gccs out there support it the moment it got into the gcc tree. Or they may want to use glibc functions not available on MinGW. And so on. Of course, you will say, all these are better served by a configure script, and I agree with you. But this is _their_ project, not ours to decide how they do it. Some don't even have a configure script, and it may be way easier for them to add 1-2 #ifdefs than to completely change their build to port to Wine. Some may be libraries (e.g. wxWindows) that don't want their headers to depend on configure scripts, just like we don't want ours, because they will be used by 3rd party apps and they don't want to force them to have a configure script (as we shouldn't force our users). But all this is irrelevant: current practice is to define a standard symbol to mark the platform. Unless we have overriding concerns (and I can't see any, defining a symbol that we don't test for in Wine is a noop), we should do the same. It is the user's prerogative to make use of it as they see fit. -- Dimi.
Re: [RFH] _FORCENAMELESSUNION
On December 22, 2002 06:03 am, Ove Kaaven wrote: Perhaps you could investigate the mingw headers to see if they've changed the #ifs around to get around this. This is how they do it: #ifdef NONAMELESSUNION #define __VARIANT_NAME_1 n1 #define __VARIANT_NAME_2 n2 #define __VARIANT_NAME_3 n3 #define __VARIANT_NAME_4 n4 #else #define __tagVARIANT #define __VARIANT_NAME_1 #define __VARIANT_NAME_2 #define __VARIANT_NAME_3 #define __VARIANT_NAME_4 #endif Maybe our way is the right way. But it seems like wxWindows expects nameless structures under all compilers, without defining _FORCENAMELESSUNION... I can just define it, it's not a big deal, just a small incompatibility. Many things to fix, I'll get to it later on. -- Dimi.
Usage of strtolW in Setupapi install
Hallo,
for me it looks as if the same fix as to files/drive.c with regard to the
usage of strtolW versus strtoulW should be applied to
dlls/setupapi/install.c too.
Bye
--
Uwe Bonnes[EMAIL PROTECTED]
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
- Tel. 06151 162516 Fax. 06151 164321 --
Index: wine/dlls/setupapi/install.c
===
RCS file: /home/wine/wine/dlls/setupapi/install.c,v
retrieving revision 1.5
diff -u -r1.5 install.c
--- wine/dlls/setupapi/install.c18 Oct 2002 23:48:58 - 1.5
+++ wine/dlls/setupapi/install.c22 Dec 2002 16:56:27 -
@@ -315,7 +315,7 @@
if (type == REG_DWORD)
{
-DWORD dw = str ? strtolW( str, NULL, 16 ) : 0;
+DWORD dw = str ? strtoulW( str, NULL, 16 ) : 0;
TRACE( setting dword %s to %lx\n, debugstr_w(value), dw );
RegSetValueExW( hkey, value, 0, type, (BYTE *)dw, sizeof(dw) );
}
Re: __WINE__ vs. __WINESRC__
Dimitrie O. Paun wrote: It shouldn't. In theory. But the difference between practice and theory is that while in theory practice and theory are the same, in practice they are different ((c) Larry McVoy) :). That works great in practice, but it will never fly in theory (anonymous). Sh.
Winemaker line 3041: WRCFLAGS = -r -L - WRCFLAGS = -r ?
Shouldnt it? Breaks the compilation of the vstserver. Please apply. :) --
Re: [RFH] _FORCENAMELESSUNION
On Sun, 22 Dec 2002, Dimitrie O. Paun wrote: On December 22, 2002 06:03 am, Ove Kaaven wrote: Perhaps you could investigate the mingw headers to see if they've changed the #ifs around to get around this. This is how they do it: #ifdef NONAMELESSUNION #define __VARIANT_NAME_1 n1 #define __VARIANT_NAME_2 n2 #define __VARIANT_NAME_3 n3 #define __VARIANT_NAME_4 n4 #else #define __tagVARIANT #define __VARIANT_NAME_1 #define __VARIANT_NAME_2 #define __VARIANT_NAME_3 #define __VARIANT_NAME_4 #endif Maybe our way is the right way. But it seems like wxWindows expects nameless structures under all compilers, without defining _FORCENAMELESSUNION... I can just define it, it's not a big deal, just a small incompatibility. Maybe you should submit patches to wxWindows and/or MinGW. I think this could only improve these projects to be more compatible with the Windows headers... -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ I haven't lost my mind, it's backed up on tape around here somewhere...
Re: A crash destroying imagelists
Duane Clark wrote: I am trying to track down a crash when exiting an application. Here is what I think are relevant parts of the trace. Does it appear that I am in the right area? Any hints on how to proceed would be appreciated. I think the problem comes down to this. The application explicitly destroys the imagelist that belongs to a listview: 08073208:Call comctl32.ImageList_Destroy(41691ba0) ret=005027f5 ... That area is then freed. When freed, COMCTL32_Free writes prev and next entries into himl. trace:commctrl:COMCTL32_Free (0x41691ba0) trace:heap:RtlFreeHeap (0x4169,0002,41691ba0): returning TRUE 08073208:Ret comctl32.ImageList_Destroy() retval=0001 ret=005027f5 ... Then LISTVIEW_NCDestroy is called. trace:listview:LISTVIEW_NCDestroy () trace:listview:LISTVIEW_DeleteAllItems () trace:commctrl:DPA_DeleteAllPtrs (0x41690d98) ... trace:listview:notify_hdr = 0 trace:listview:LISTVIEW_NCDestroy Start destroying data structures. ... The listview does not know that the imagelist was already destroyed, so it again calls ImageList_Destroy. trace:listview:LISTVIEW_NCDestroy Start destroying image lists. 08073208:Call gdi32.DeleteObject() ret=409fcadd 08073208:Ret gdi32.DeleteObject() retval= ret=409fcadd 08073208:Call gdi32.DeleteObject() ret=409fcaea 08073208:Ret gdi32.DeleteObject() retval= ret=409fcaea 08073208:Call gdi32.DeleteObject() ret=409fcaf7 08073208:Ret gdi32.DeleteObject() retval= ret=409fcaf7 08073208:Call gdi32.DeleteObject() ret=409fcb04 08073208:Ret gdi32.DeleteObject() retval= ret=409fcb04 At the end of ImageList_Destroy, there is a call to ZeroMemory, which obliterates the prev and next pointers which had been written there. Then another COMCTL32_Free call detects the error. At least I assume it is an error. trace:commctrl:COMCTL32_Free (0x41691ba0) err:heap:HEAP_ValidateFreeArena Heap 4169: bad next ptr for arena 41691b98
Re: __WINE__ vs. __WINESRC__
On Sun, 22 Dec 2002, Dimitrie O. Paun wrote: [...] So, my proposal is: let's rename the __WINE__ symbol (as it's currently used) to something else (__WINESRC__, or whatever, suggestions welcome), once that's done, define __WINE__ when __WINESRC__ is not defined (the symbols would be mutually exclusive). winemaker defines 'WINELIB'. But I'm open to change, '__WINE__' looks more like the others. Maybe '__WINELIB__' would do? (but I prefer '__WINE__') -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Cahn's Axiom: When all else fails, read the instructions.
Re: A crash destroying imagelists
Duane Clark wrote: ... At the end of ImageList_Destroy, there is a call to ZeroMemory, which obliterates the prev and next pointers which had been written there. Then another COMCTL32_Free call detects the error. At least I assume it is an error. And indeed simply commenting out the ZeroMemory fixes the application. Though I have no idea what the correct fix would be.
Re: wineboot - Andy's version
On Sun, 22 Dec 2002, Shachar Shemesh wrote: [...] What I'm thinking is incorporating the first group into the wine code itself (I'm thinking the server startup, synchroniously done). For the second group, create a wineboot program, and have a single option saying whether the wineserver should run it on startup or not. It is my understanding that if you put these in the wine server you will not be able to use the Windows APIs. This will make it unnecessarily complex to handle the move and renames since the paths will be windows paths. Putting this code in a standalone utility will allow you to use the Windows API and then calling it from the Wine server (if that is the way we go) is just a fork away. It also makes the 'when is it called' more flexible which can come in handy. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ It really galls me that most of the computer power in the world is wasted on screen savers. Chris Caldwell from the GIMPS project http://www.mersenne.org/prime.htm
Re: Winemaker line 3041: WRCFLAGS = -r -L - WRCFLAGS = -r ?
Kjetil S. Matheussen wrote: Shouldnt it? Breaks the compilation of the vstserver. Please apply. :) Please refer to http://www.winehq.org/Docs/wine-devel/patches.shtml for how to submit future patches. Change Log: fix for compiling wstserver Files: tools/winemaker -- Tony Lambregts Index: winemaker === RCS file: /home/wine/wine/tools/winemaker,v retrieving revision 1.59 diff -u -r1.59 winemaker --- winemaker 15 Dec 2002 03:00:40 - 1.59 +++ winemaker 23 Dec 2002 01:45:47 - @@ -3038,7 +3038,7 @@ WRC = @WRC@ CFLAGS= @CFLAGS@ CXXFLAGS = @CXXFLAGS@ -WRCFLAGS = -r -L +WRCFLAGS = -r OPTIONS = @OPTIONS@ -D_REENTRANT -DWINELIB $(GLOBAL_DEFINES) $(GLOBAL_INCLUDE_PATH) LIBS = @LIBS@ $(LIBRARY_PATH) ALLFLAGS = $(DEFINES) -I$(SRCDIR) $(INCLUDE_PATH) $(WINE_INCLUDE_PATH)
Re: MSVC4, next two buttons on installer
Eric Pouech wrote: so you're stuck with either using native riched20.dll, or doing lots of hard work to implement version 1.0 and 2.0 Er, ok, I'll stick with native for now :-) Q2. Any idea what I'd need to do to get a Windows Explorer going without actually installing the real Windows Explorer?-) Does Wine have a builtin Windows Explorer clone yet? there's a winfile compatible (winefile) in the programs directory, but this isn't really an explorer clone. however making it explorer.exe compatible (from the command line point of view) shouldn't be too difficult. but there are lots of other stuff in there (DDE server for example) which will require quite some work too. Cool. OK, here's how things stand, then: With native mfc42.dll, riched20.dll, and wordpad.exe, and winefile running, I can put the msvc4.0 cd-rom in the drive, mount it, click on the 'd:' drive icon in winefile, double-click on setup.exe, and the setup program launches properly; clicking on Standard Template Library properly brings up WordPad (yay!), but with a display problem (see below); clicking on Explore the CD does nothing (because I didn't install native Windows Explorer). Q3. Although I'm using native riched20 and wordpad, all the section headers in the stl\Readme.WRI file are screwed up under Wine. Anyone seen that problem before, or know how to fix it? I've uploaded the file as http://www.kegel.com/readme.wri in case anyone wants to see it. Q4. Is winefile going to be installed in some standard place? I'm quite willing to write a tiny, stunted windows\explorer.exe that's just a wrapper around winefile, but that won't help if the standard installer isn't yet installing winefile. Also, is it a problem that winefile is a winelib application? Wouldn't we rather it be a straight Windows application if we're going to invoke it from inside wine? Thanks, Dan -- Dan Kegel Linux User #78045 http://www.kegel.com
Re: [RFH] _FORCENAMELESSUNION
On December 22, 2002 02:22 pm, Francois Gouget wrote: Maybe you should submit patches to wxWindows and/or MinGW. I think this could only improve these projects to be more compatible with the Windows headers... Well, but of course, I just want to make sure I fix the right thing. You see, I don't have the any MS devel stuff, so I have to ask if our implementation is correct or not. If it is, a fix we'll go to the other projects, don't worry :) -- Dimi.
MSVC4, install button. Possible wine bug.
Big progress. Turns out the best way to trace these installer splash screens is wine --debugmsg +exec since all they do is exec other programs. The only problem with this button under Wine is that the current working directory MUST be /mnt/cdrom before starting setup.exe for the install button to work, else it doesn't find the subdirectory's setup.exe to launch. This is not true under Windows. This seems like an important little difference to track down. I guess something in Windows might implicitly change the working directory of a newly launched program, or...? I suppose I could write a little win32 program to mimic what setup.exe is doing, and see if it behaves differently on Windows and on Wine. I feel a regression test coming on... I might not have time to get to this for a bit, so I'm posting the output of wine --debugmsg +exec,+dosfs,+file d:setup.exe (click on Install Visual C++ button) to http://kegel.com/msvc4/install.txt.gz in case someone else wants to look. Search for ShellExecute to find the interesting bits. The current directory is my Wine directory... disappointing the program, which expected it to be the root of the cd-rom. - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com
Re: Serious problem with / and mount points
Sylvain Petreolle wrote:
--- Tony Lambregts [EMAIL PROTECTED] a écrit : Jeff
Smith wrote:
What I have so far:
in files/dos_fs.c:1343, drive is receiving the value -1.
at line 1358, this is blindly added to 'A'. As you may
know, in ASCII, 'A' - 1 = '@'.
The problem is that we don't check the status of DRIVE_FindDriveRoot,
as you spotted it.
The sources clearly states that -1 is error.
Well I was convinced it should not be an error. The path is valid if
you are sitting at the mount point. Part of the problem is that the
drives are initialized when the program starts, this sets the .ino for
that drive, however the ino for a removeable drive can change depending
on whether it is mounted or not.
DRIVE_FindDriveRootW does the same thing without relying on the .ino. I have modified DRIVE_FindDriveRoot to work the same way.
The way I see it is that if the drive is removable (or network) .ino is not a good way of dealing with it.
Change Log: Modify DRIVE_FindDriveRoot to not use .ino
Files: files/drive.c
Tony Lambregts
Index: drive.c
===
RCS file: /home/wine/wine/files/drive.c,v
retrieving revision 1.80
diff -u -r1.80 drive.c
--- drive.c 7 Dec 2002 23:47:01 - 1.80
+++ drive.c 23 Dec 2002 05:21:21 -
@@ -408,63 +408,36 @@
*/
int DRIVE_FindDriveRoot( const char **path )
{
-/* Starting with the full path, check if the device and inode match any of
- * the wine 'drives'. If not then remove the last path component and try
- * again. If the last component was a '..' then skip a normal component
- * since it's a directory that's ascended back out of.
- */
-int drive, level, len;
+int drive, rootdrive = -1;
char buffer[MAX_PATHNAME_LEN];
char *p;
-struct stat st;
+int len = -1, match_len = -1 ;
strcpy( buffer, *path );
while ((p = strchr( buffer, '\\' )) != NULL)
-*p = '/';
-len = strlen(buffer);
-
-/* strip off trailing slashes */
-while (len 1 buffer[len - 1] == '/') buffer[--len] = 0;
-
-for (;;)
+ *p = '/';
+
+for (drive = 0; drive MAX_DOS_DRIVES; drive++)
{
-/* Find the drive */
-if (stat( buffer, st ) == 0 S_ISDIR( st.st_mode ))
-{
-for (drive = 0; drive MAX_DOS_DRIVES; drive++)
-{
- if (!DOSDrives[drive].root ||
- (DOSDrives[drive].flags DRIVE_DISABLED))
- continue;
-
- if ((DOSDrives[drive].dev == st.st_dev)
- (DOSDrives[drive].ino == st.st_ino))
- {
- if (len == 1) len = 0; /* preserve root slash in returned path */
- TRACE( %s - drive %c:, root='%s', name='%s'\n,
- *path, 'A' + drive, buffer, *path + len);
- *path += len;
- if (!**path) *path = \\;
- return drive;
- }
-}
-}
-if (len = 1) return -1; /* reached root */
-
-level = 0;
-while (level 1)
-{
-/* find start of the last path component */
-while (len 1 buffer[len - 1] != '/') len--;
-if (!buffer[len]) break; /* empty component - reached root */
-/* does removing it take us up a level? */
-if (strcmp( buffer + len, . ) != 0)
-level += strcmp( buffer + len, .. ) ? 1 : -1;
-buffer[len] = 0;
-/* strip off trailing slashes */
-while (len 1 buffer[len - 1] == '/') buffer[--len] = 0;
-}
+if (!DOSDrives[drive].root ||
+(DOSDrives[drive].flags DRIVE_DISABLED)) continue;
+
+len = strlen(DOSDrives[drive].root);
+if(strncmp(DOSDrives[drive].root, buffer, len)) continue;
+
+ if(len = match_len) continue;
+match_len = len;
+rootdrive = drive;
+ drive = MAX_DOS_DRIVES + 1;
+}
+if (rootdrive != -1)
+{
+TRACE(%s - drive %c:, root='%s', name=%s\n,
+*path, 'A' + rootdrive, DOSDrives[rootdrive].root, *path + len) ;
+*path += len;
+if (!**path) *path = \\;
}
+return rootdrive;
}
Re: A crash destroying imagelists
On December 22, 2002 02:50 pm, Duane Clark wrote:
That area is then freed. When freed, COMCTL32_Free writes prev and next
entries into himl.
Where? COMCTL32_Free() simply calls HeapFree():
BOOL WINAPI COMCTL32_Free (LPVOID lpMem)
{
TRACE((%p)\n, lpMem);
return HeapFree (COMCTL32_hHeap, 0, lpMem);
}
The listview does not know that the imagelist was already destroyed, so
it again calls ImageList_Destroy.
Yes, a common problem.
At the end of ImageList_Destroy, there is a call to ZeroMemory, which
obliterates the prev and next pointers which had been written there.
Then another COMCTL32_Free call detects the error. At least I assume it
is an error.
Does this work any better? It shouldn't make any difference, but ...
There is something else funny here. I can't see why zeroing out an
area we're just about to free is problematic.
Index: dlls/comctl32/imagelist.c
===
RCS file: /var/cvs/wine/dlls/comctl32/imagelist.c,v
retrieving revision 1.68
diff -u -r1.68 imagelist.c
--- dlls/comctl32/imagelist.c 5 Dec 2002 20:33:09 - 1.68
+++ dlls/comctl32/imagelist.c 23 Dec 2002 04:37:55 -
@@ -693,7 +693,7 @@
if (himl-hbrBlend50)
DeleteObject (himl-hbrBlend50);
-ZeroMemory(himl, sizeof(*himl));
+ZeroMemory(himl, sizeof(struct _IMAGELIST));
COMCTL32_Free (himl);
return TRUE;
--
Dimi.
DDE command 'ActivateProgMan'?
With current CVS wine, doing a minimum install of MSVC4 works fine (once you jump through the proper hoops), but at the very end, I get the dialog box Setup cannot execute the DDE command 'ActivateProgMan' Press Abort to to (sic) stop installing shortcuts and continue Setup. I googled for ActivateProgMan, but found nothing... For the moment, I'm just going to say Press Abort in my recipe for running msvc4 under Wine. I'd be willing to track this down further if someone feels like pointing me in the right direction. - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com
msvc4 success!
wine still needs some polish before it can install msvc4 nicely, but it can indeed install it, and the installed copy of msdev appears to work! I used the IDE to create a hello, world console app, and it compiled and ran perfectly! The UI seems snappy enough on my dual pentium 650, too. I'm sure I'll find many problems with this later, but for now, I think it's awesome that Wine can install and run msvc4 at all! - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com
