Re: RFC on our new initiative
On Thu, 22 Jan 2004, Mike Hearn wrote: On Thu, 22 Jan 2004 11:17:55 -0600, Gregory M. Turner wrote: Mono is LGPL/X11 (except the compiler) so we could beat them at their own game by forking /their/ code, turning it into a winelib app, and implementing Windows.Forms properly ;) It's not that simple. Unsurprisingly they don't want a hard dependency on Wine when many .NET apps they write don't use SWF, so they need to be able to use wine without being a winelib app. We simply don't support that. I believe that's why Gregory proposed to fork their code: because he just wants a 100% open-source way to run .Net apps in Wine and thus for him the hard-dependency on Wine is not an issue. Can Mono work on Windows? Or, in other words, is there an open-source .Net implementation on Windows? If yes we could try to make that work in Wine (as a PE binary first, then via a MinGW + Winelib port). -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ The software said it requires Win95 or better, so I installed Linux.
Re: RFC on our new initiative
On Fri, 2004-01-23 at 10:54, Francois Gouget wrote: I believe that's why Gregory proposed to fork their code: because he just wants a 100% open-source way to run .Net apps in Wine and thus for him the hard-dependency on Wine is not an issue. Can Mono work on Windows? Or, in other words, is there an open-source .Net implementation on Windows? If yes we could try to make that work in Wine (as a PE binary first, then via a MinGW + Winelib port). It can yes, I can imagine that you'd be able to build Mono as a winelib app. We really need to think about this carefully. The situation is a bit sticky: * Sometimes Wine will require Mono to run apps (for instance you can have normal Win32 apps that link against the .NET runtime or use COM activation to get .NET components at runtime) * Sometimes Mono will require Wine to run apps, for programs that require System.Windows.Forms, but also for IJW binaries and for when .NET apps depend on unmanaged win32 COM components. So it goes both ways. This is really tricky. One way to do is to fork each others code and merge them into each other but that just makes me feel dirty :) There has to be a better way. I'm not sure what it is yet though. We could probably implement our own mscorlib.dll which does the unmanaged setup then relays to libmscorlib.so or whatever it is mono uses.
RE: comctl32 resources / shlwapi prototype fixes
Changelog:
Sync with ReactOS 0.2
Fix various function prototypes to conform to PSDK
Index: dlls/shlwapi/ordinal.c
===
RCS file: /home/wine/wine/dlls/shlwapi/ordinal.c,v
retrieving revision 1.75
diff -u -r1.75 ordinal.c
--- dlls/shlwapi/ordinal.c1 Oct 2003 03:10:42 - 1.75
+++ dlls/shlwapi/ordinal.c22 Jan 2004 23:41:41 -
@@ -3414,7 +3414,8 @@
* Success: A handle to the loaded module
* Failure: A NULL handle.
*/
-HMODULE WINAPI MLLoadLibraryA(LPCSTR new_mod, HMODULE inst_hwnd,
DWORD dwFlags)
+HMODULE WINAPI MLLoadLibraryA(LPCSTR new_mod, HANDLE inst_hwnd,
DWORD dwFlags,
+ LPCSTR component, BOOL cross_code_page)
This is wrong. Please resubmit without this change until we can discover why
the prototype has 5 parameters, yet on my system the implementation only
takes 3.
{
/* FIXME: Native appears to do DPA_Create and a DPA_InsertPtr for
*each call here.
@@ -3453,7 +3454,8 @@
*
* Unicode version of MLLoadLibraryA.
*/
-HMODULE WINAPI MLLoadLibraryW(LPCWSTR new_mod, HMODULE
inst_hwnd, DWORD dwFlags)
+HMODULE WINAPI MLLoadLibraryW(LPCWSTR new_mod, HANDLE inst_hwnd,
DWORD dwFlags,
+ LPCWSTR component, BOOL cross_code_page)
Same again
{
WCHAR mod_path[2*MAX_PATH];
LPWSTR ptr;
Re: LockResource16 in ole32.dll
From: Dmitry Timoshkov
Casper Hornstrup [EMAIL PROTECTED] wrote:
I would like to have the call to the Win16 API LockResource16 removed
from ole32.dll. I guess there is a reason for it being LockResource16
and not LockResource. What is the reason?
Because LoadAcceleratorsA/W returns a value allocated by GlobalAlloc16.
How can the call be removed?
Only if you or someone else can prove that under real windows
LoadAcceleratorsA/W behaves differently (taking into account Win9x
weirdness).
Would the attached patch be an acceptable solution? Basically it does a
GetProcAddress on LockResource16 and uses it if found (Wine case). If it's
not found, it uses LockResource().
Ge van Geldorp.
Index: dlls/ole32/ole2.c
===
RCS file: /home/wine/wine/dlls/ole32/ole2.c,v
retrieving revision 1.48
diff -u -r1.48 ole2.c
--- dlls/ole32/ole2.c 8 Dec 2003 22:46:08 - 1.48
+++ dlls/ole32/ole2.c 23 Jan 2004 14:17:06 -
@@ -1422,9 +1422,34 @@
/* YES, Accel16! */
LPACCEL16 lpAccelTbl;
int i;
+HMODULE Kernel32;
+LPVOID (WINAPI *LockResource16Ptr)(HGLOBAL16 ResData);
if(!lpMsg) return FALSE;
-if (!hAccel || !(lpAccelTbl = (LPACCEL16)LockResource16(HACCEL_16(hAccel
+if (!hAccel)
+{
+ WARN_(accel)(NULL accel handle\n);
+ return FALSE;
+}
+Kernel32 = GetModuleHandleA(kernel32.dll);
+if (NULL != Kernel32)
+{
+ LockResource16Ptr = (LPVOID (WINAPI *)(HGLOBAL16))
+GetProcAddress(Kernel32, LockResource16);
+}
+else
+{
+ LockResource16Ptr = NULL;
+}
+if (NULL != LockResource16Ptr)
+{
+lpAccelTbl = (LPACCEL16) LockResource16Ptr(HACCEL_16(hAccel));
+}
+else
+{
+ lpAccelTbl = (LPACCEL16) LockResource(hAccel);
+}
+if (NULL == lpAccelTbl)
{
WARN_(accel)(invalid accel handle=%p\n, hAccel);
return FALSE;
RE: shlwapi prototype fixes
From: Robert Shearman MLLoadLibrary was recently documented by Microsoft. My changes makes it conform to the now-documented prototype so I don't see what's wrong with it? Either it is different on Windows XP (my system is Windows 2000 SP4 with IE6 SP1), or they just got it wrong. The fact remains that I have seen an application working perfectly well on Wine whilst using this function as it stands. Yes, you're right. Ordinals 377 and 378 (MLLoadLibraryA/MLLoadLibraryW) in both the Win2k and WinXP shlwapi.dll pop 12 bytes from the stack on return. I'll resubmit my patch for the other prototypes. Gé van Geldorp.
RE: LockResource16 in ole32.dll
From: Dmitry Timoshkov [mailto:[EMAIL PROTECTED] Ge van Geldorp [EMAIL PROTECTED] wrote: Would the attached patch be an acceptable solution? Basically it does a GetProcAddress on LockResource16 and uses it if found (Wine case). If it's not found, it uses LockResource(). That will not work. 32-bit LockResource can't be used on a memory block allocated by GlobalAlloc16, as I explained before. No, not in Wine. But Wine will still use LockResource16, so there's no problem. I can assure you that the memory block won't be allocated by GlobalAlloc16 in ReactOS, simply because there is no GlobalAlloc16 in ReactOS. Since there is also no LockResource16 in ReactOS it would take the other code path. I'm just trying to find a solution which allows umodified source code to be used by both Wine and ReactOS. Ge van Geldorp.
Re: LockResource16 in ole32.dll
Ge van Geldorp [EMAIL PROTECTED] wrote: That will not work. 32-bit LockResource can't be used on a memory block allocated by GlobalAlloc16, as I explained before. No, not in Wine. But Wine will still use LockResource16, so there's no problem. I can assure you that the memory block won't be allocated by GlobalAlloc16 in ReactOS, simply because there is no GlobalAlloc16 in ReactOS. Since there is also no LockResource16 in ReactOS it would take the other code path. I'm just trying to find a solution which allows umodified source code to be used by both Wine and ReactOS. Then it's better to fix LoadAcceleratorsA/W to use a proper allocator and use the same aproach in both Wine and ReactOS. But in that case you have to write a test case which works at least on NT/2000 and Wine. -- Dmitry.
Re: Systray integration patch
I maintain that patch - does it no longer apply? I noted a single merge conflict when I recently updated CVS but it's trivial to fix. Is this the issue? I got: 1 out of 10 hunks FAILED -- saving rejects to file dlls/shell32/systray.c.rej 5 out of 16 hunks FAILED -- saving rejects to file dlls/x11drv/window.c.rej The systray.c problem is just in comments. The others are not (don't appear to be from my inexperienced perspective) trivial. Maybe I'm using an old version of the patch. Is there somewhere where the latest version lives? Regards, Martin.
Re: WINMM problem with Half-Life
Here you go. wine --debugmsg +mciavi,+winmm,+seh hl.exe hl-winmm.log Pressed ^C after it hung. Mike Eric Pouech wrote: yup. can you post a -debugmsg +mciavi trace A+ hl-winmm.log.gz Description: Unix tar archive
warning to wine on cygwin experimenters
I got cygwin to compile wine to the point where wine-install tried to run regedit on winedefault.reg. I should have been paying closer attention. The good news is that the wine regedit.exe works like a charm. The bad news is that it overwrote my actual windows registry with the bunk values in winedefault.reg. Not gonna be very easy to roll back. So... WATCH OUT! That last step's a doozy.
RE: LockResource16 in ole32.dll
From: Dmitry Timoshkov Then it's better to fix LoadAcceleratorsA/W to use a proper allocator and use the same aproach in both Wine and ReactOS. But in that case you have to write a test case which works at least on NT/2000 and Wine. Another idea just popped up: the basic problem we're having is translating the handle passed in to a table containing the accelerator entries. How about using CopyAcceleratorTableA/W to do that? This function is designed to do that job and is located in user32. That dll is not shared between Wine and ReactOS anyway, so we can mess around in it anyway we like without disturbing Wine. Ge van Geldorp.
Re: LockResource16 in ole32.dll
Ge van Geldorp [EMAIL PROTECTED] wrote: Would the attached patch be an acceptable solution? Basically it does a GetProcAddress on LockResource16 and uses it if found (Wine case). If it's not found, it uses LockResource(). That will not work. 32-bit LockResource can't be used on a memory block allocated by GlobalAlloc16, as I explained before. -- Dmitry.
Variable in Visual Basic
Hi,
I am using wine with fake_windows. A Program don't works and return the message below.
Any help?
[]'s
Run time error '458'
Variable uses an Automation type not supported in Visual Basic
Invoking /usr/bin/wine.bin SISUPFOR.exe ...
fixme:ole:CoRegisterMessageFilter stub
fixme:ole:OleLoadPictureEx
(0x4140292c,47552,1,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=0,y=0,f=0,0x406bf958),
partially implemented.
fixme:ole:OleLoadPictureEx
(0x4140292c,1086,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=0,y=0,f=0,0x406bf958),
partially implemented.
fixme:ole:OleLoadPictureEx
(0x4140292c,334,1,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=0,y=0,f=0,0x406bf958),
partially implemented.
fixme:ole:OLEPictureImpl_get_hPal (0x403adbc0)-(0x406bf86c): stub
fixme:ole:OLEPictureImpl_SaveAsFile (0x403b9d58)-(0x403c4168, 0, (nil)), hacked stub.
fixme:ole:OLEPictureImpl_get_hPal (0x403adbc0)-(0x406bf0a0): stub
fixme:ole:OLEPictureImpl_get_hPal (0x403adbc0)-(0x406bf1dc): stub
fixme:ole:VarCat Failed to convert right side from vt 8 to VT_BSTR?
fixme:ole:OLEPictureImpl_get_hPal (0x403adbc0)-(0x406bf214): stub
fixme:ole:OLEPictureImpl_get_hPal (0x403adbc0)-(0x406bf214): stub
fixme:ole:OLEPictureImpl_get_hPal (0x403adbc0)-(0x406bf214): stub
fixme:ole:CoRegisterMessageFilter stub
Wine exited with a successful status
--
Savio Martins Ramos Arquiteto
Rio de Janeiro ICQ 174972645
Pirataria não! Use GNU/Linux
Debian-br #705 Unstable
http://www.debian.org
Re: warning to wine on cygwin experimenters
--- Anonymous [EMAIL PROTECTED] wrote: I got cygwin to compile wine to the point where wine-install tried to run regedit on winedefault.reg. I should have been paying closer attention. The good news is that the wine regedit.exe works like a charm. The bad news is that it overwrote my actual windows registry with the bunk values in winedefault.reg. we need to add some checking to the configure and wineinstall system so that if the host or target platform is Mingw/Cygwin then we can skip winedefault.reg Thanks Steven __ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/
Re: Variable in Visual Basic
On Fri, Jan 23, 2004 at 04:36:58PM -0200, Savio Ramos wrote:
Hi,
I am using wine with fake_windows. A Program don't works and return the message
below.
fixme:ole:VarCat Failed to convert right side from vt 8 to VT_BSTR?
The code for this fixme is slightly broken, it really failed to convert
the left side, and doesn't tell us which vt it is trying to convert from.
If you built from source could you apply the attached patch to
dlls/oleaut32/variant.c, re-build, re-run your program and post the
updated output?
Thanks.
--Alastair Bridgewater
Index: variant.c
===
RCS file: /home/wine/wine/dlls/oleaut32/variant.c,v
retrieving revision 1.85
diff -u -r1.85 variant.c
--- variant.c 13 Jan 2004 23:16:04 - 1.85
+++ variant.c 23 Jan 2004 20:38:54 -
@@ -2276,7 +2276,7 @@
V_VT(out) = VT_BSTR;
hres = VariantChangeTypeEx(bstrvar,left,0,0,VT_BSTR);
if (hres) {
- FIXME(Failed to convert right side from vt %d to VT_BSTR?\n,V_VT(right));
+ FIXME(Failed to convert left side from vt %d to VT_BSTR?\n,V_VT(left));
return hres;
}
VarBstrCat (V_BSTR(bstrvar), V_BSTR(right), V_BSTR(out));
Debugging problem
I've got an application that is crashing in Wine and I am trying to debug it. However, I am runnign into a problem before I even get started... When I go into the debugger (winedbg) it complains that it cannot find debug information in any of the 32bit DLL's. Indeed, from within the debugger I cannot find nor break at any of the DLL functions... which is quite a drag. I'm sure there is some simple solution to this relted to a problem with my setup or the way I am running the debugger, but I can't figure it out. I have tried recompiling and reinstalling all of wine with the -g compiler option (seems reasonable, I suppose) but that doesn't solve it. I've told wine/configure to --enable-debug, to no avail. I don;t know what I'm missing and I can't find any useful suggestions in any of the documentation or FAQ's (not that thtere is nothing useful... just I haven't yet found it, though I have looked) Any hints/help would be most appreciated. sample error message: No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\USER32.DLL' (0x4069) -- Andrew L. Bereson [EMAIL PROTECTED] (800)307-5754
Re: Systray integration patch
On Fri, 23 Jan 2004 10:44:54 +, Martin Garton wrote: The systray.c problem is just in comments. The others are not (don't appear to be from my inexperienced perspective) trivial. Sounds like it collided with the atom interning code. Maybe I'm using an old version of the patch. Is there somewhere where the latest version lives? Yes, that's likely, search the archives of wine-patches for the latest one, I submitted it back in December I think. thanks -mike
Dungeon Keeper thread(s) recently
Just a thank you for the people who followed up on this recently, including the recent patch. (I have been offline due to a failing modem, so couldnt participate towards the end.) Jason
segmentation fault when using kernel32.dll.so and oleaut32.dll.so
Hi, I need functions like 'MultiByteToWideChar', 'SysAllocStringLen', etc which are in kernel32.dll.so and oleaut32.dll.so libraries. I have some of questions regarding using them. - How can I link these libraries with my program. Using option -lkernel32.dll looks for libkernel32.dll.so file. - I tried renaming the files and also creating soft links using libkernel32.dll.so to kernel32.dll.so. - If I link like that, my program is giving a 'segmentation fault' error. - I tried using libraries produced by compiling on my uptodate RH8.0 machine and also the libraries from the RH8.0 rpm available on sourceforge.net. - I implement an XPCOM class using these libraries and when I try to create an object, it gives the 'Segmentation Fault'. - I tried using libwine.so but it doesn't contain the above functions I need. If anybody knows how to use these libraries, please mail back. Thanks in advance. Regards, Anil
Re: Debugging problem
sample error message: No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\USER32.DLL' (0x4069) From thread 'Need help debugging' Jan 15 with aswer from Mike Hearn: 2. How to compile debug information into the 32bit DLL's so I don't get 'No debug information in 32bit DLL' anymore and maybe some better info? I tried 'configure --enable-debug make depend make su -c make install' to no avail. They have debugging info in, but unfortunately there has been breakage in the debugger recently which has not yet been fixed in CVS. This is very bad EricP sent a patch here which works great for me and fixed all my debugger problems, try looking in the archives for Jan and December looking for it (it was sent to wine-devel not wine-patches iirc). For now try setting WINELOADER to the path to your actual wine binary (wine-pthread) Eric, could you please submit that patch? Even if it's not correct, having the debuggers out of action like this is causing big problems.
Re: segmentation fault when using kernel32.dll.so and oleaut32.dll.so
On Fri, 23 Jan 2004 11:21:14 -0800, Anil Akurathi wrote: Hi, I need functions like 'MultiByteToWideChar', 'SysAllocStringLen', etc which are in kernel32.dll.so and oleaut32.dll.so libraries. I have some of questions regarding using them. First off, you can't use these functions from outside a WineLib app. I'll assume you're using winegcc because of that. - How can I link these libraries with my program. Using option -lkernel32.dll looks for libkernel32.dll.so file. You shouldn't need to, apps are automatically linked against kernel32 iirc. Something like this for oleaut32: winegcc -o fooapp -loleaut32 fooapp.c - I implement an XPCOM class using these libraries and when I try to create an object, it gives the 'Segmentation Fault'. - I tried using libwine.so but it doesn't contain the above functions I need. You should read the WineLib developer guide - you cannot use Wine code from a standard Linux app I'm afraid. thanks -mike
Lotus Notes broken in recent CVS
Through iterative CVS pulls, I have established that the problem I see with Lotus Notes not working occurred between 01/02/2004 and 01/03/2004. I had thought that the problem came up only in the last week, but I must have been mistaken. The 01/03 CVS snapshot gives the symptoms that I mentioned before (appended below), and I was able to send this note with the 01/02 snapshot. I did try copying my Notes directory to a linux drive (ext3) and reconfiguring my configuration file to use it, but saw the same problem (except of course for the path name in the error messages). Paul z/OS core components development Internet: [EMAIL PROTECTED] [paul: ~]wine nlnotes Warning: could not find wine config [Drive x] entry for current working directory /home/paul; starting in windows directory. fixme:reg:_nt_dump_lf unknown Win XP node id 0x686c: do we need to add support for it ? fixme:reg:_nt_dump_lf unknown Win XP node id 0x686c: do we need to add support for it ? fixme:reg:_nt_dump_lf unknown Win XP node id 0x686c: do we need to add support for it ? err:module:map_image Could not map section .rdata, file probably truncated err:module:import_dll Loading module (file) LTOUIN22.dll (which is needed by LC:\\Lotus\\notes\\nnotesws.dll) failed (error c07b). err:module:import_dll No implementation for LTOUIN22.dll.130 imported from LC:\\Lotus\\notes\\nnotesws.dll, setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.141 imported from LC:\\Lotus\\notes\\nnotesws.dll, setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.123 imported from LC:\\Lotus\\notes\\nnotesws.dll, setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.60 imported from LC:\\Lotus\\notes\\nnotesws.dll, setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.77 imported from LC:\\Lotus\\notes\\nnotesws.dll, setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.127 imported from LC:\\Lotus\\notes\\nnotesws.dll, setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.136 imported from LC:\\Lotus\\notes\\nnotesws.dll, setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.72 imported from LC:\\Lotus\\notes\\nnotesws.dll, setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.101 imported from LC:\\Lotus\\notes\\nnotesws.dll, setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.94 imported from LC:\\Lotus\\notes\\nnotesws.dll, setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.135 imported from LC:\\Lotus\\notes\\nnotesws.dll, setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.131 imported from LC:\\Lotus\\notes\\nnotesws.dll, setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.74 imported from LC:\\Lotus\\notes\\nnotesws.dll, setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.61 imported from LC:\\Lotus\\notes\\nnotesws.dll, setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.76 imported from LC:\\Lotus\\notes\\nnotesws.dll, setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.58 imported from LC:\\Lotus\\notes\\nnotesws.dll, setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.67 imported from LC:\\Lotus\\notes\\nnotesws.dll, setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.68 imported from LC:\\Lotus\\notes\\nnotesws.dll, setting to 0xdeadbeef err:module:import_dll No implementation for LTOUIN22.dll.71 imported from LC:\\Lotus\\notes\\nnotesws.dll, setting to 0xdeadbeef err:module:import_dll Module (file) nnotesws.dll (which is needed by LC:\\Lotus\\notes\\nlnotes.exe) not found err:module:import_dll No implementation for nnotesws.dll.1 imported from LC:\\Lotus\\notes\\nlnotes.exe, setting to 0xdeadbeef err:module:LdrInitializeThunk Main exe initialization for LC:\\Lotus\\notes\\nlnotes.exe failed, status c135
RE: Lotus Notes broken in recent CVS
Through iterative CVS pulls, I have established that the problem I see with Lotus Notes not working occurred between 01/02/2004 and 01/03/2004. I had thought that the problem came up only in the last week, but I must have been mistaken. The 01/03 CVS snapshot gives the symptoms that I mentioned before (appended below), and I was able to send this note with the 01/02 snapshot. As a wild guess, try backing out these patches in order, testing after each one: 1. http://cvs.winehq.com/patch.py?id=10552 2. http://cvs.winehq.com/patch.py?id=10547 3. http://cvs.winehq.com/patch.py?id=10546 Rob
make html not working
Hy, Looks like 'make html' in documentation is using 'db2hml -u' which is not working on my system. If I remove the '-u' from the Makefile it works ok. Don't know what the '-u' option is for though. ERROR IS: [EMAIL PROTECTED]:/usr/tmp/work/bld/wine/wine/documentation make html db2html -u wine-devel.sgml Try 'db2html --help' for more information. make: *** [wine-devel.html] Fehler 1 MY DB2HML VERSION: [EMAIL PROTECTED]:/usr/tmp/work/bld/wine/wine/documentation db2html --version db2html - docbook-toys 1.51.0 PROBLEMATIC LINE IN Makefile: $(DB2HTML) -u $
Re: Dungeon Keeper thread(s) recently
Jason Edmeades wrote: Just a thank you for the people who followed up on this recently, including the recent patch. Yep, that was really great teamwork. I also thank you all, especially you Jason for cornering the bug! (I have been offline due to a failing modem, so couldnt participate towards the end.) Jason Great you're back! Maybe you could shed some light :-) You remember that you came until a not moving cursor after starting DK. I applied your second workaround for now and am stuck in the same situation. I'll elaborate this a bit: - I have two mouse pointers. - The first is trapped in the upper left corner and looks like a standard mousepointer. When the mouse is moved down or right it follows a bit and then always jumps back to it's corner. - The second one is the Dungeon Keeper mouse pointer (some picture of a monsters head). This one moves down and right if the mouse is moved in this directions but doesn't move up or left. Except this the mousepointer behaves absolutely normal. That's the situation. Any ideas for a starting point for debugging? -- Thanks, Frank Schruefer
Re: warning to wine on cygwin experimenters
I wont believe any word that comes from an anonymous mail. Alexandre, shouldnt we close this subject ? = Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) ICQ #170597259 Say NO to software patents Dites NON aux brevets logiciels You believe it's the year 1984, when in fact, its closer to 21841984 / Matrix _ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
Sorry for the duplicate messages
Sorry for the duplicate messages. I've just been debugging a problem with Outlook and every time it started up, it sent the message and then crashed, not registering that it had sent it. Rob
Re: shell32 patch 20
Martin Fuchs [EMAIL PROTECTED] wrote: Changelog: - don't link directly to NTDLL; use MultiByteToWideChar() instead of RtlCreateUnicodeStringFromAsciiz() Why do you need that? -- Dmitry.
Re: Debugging problem
Eric, could you please submit that patch? Even if it's not correct, having the debuggers out of action like this is causing big problems. as I already wrote, the patch I sent to wine-devel is: 1/ a dirty hack 2/ doesn't address all the issues 3/ a wrong solution to the real problem For the time being, setting WINELOADER to the wine exec is the best solution. A+
