Re: Reload a DLL and _getptd returns zero
On 01/15/2013 03:39 AM, Piotr Caban wrote: On 01/15/13 00:32, Michael Ost wrote: Here's a link to a zip file that includes the prebuilt .exe and .dll windows binaries that crash in wine. Plus the code. https://dl.dropbox.com/u/97386125/msvcrt-dll-problem.zip The crash is caused by incomplete FlsFree implementation. There's a comment in it's code that says what needs to be added: /* FIXME: add equivalent of ThreadZeroTlsCell here */ Really? Are you sure that's it? By the way, to aid my future Wine sleuthing, can you share any hints on how you figured this out? I guess it would be best to create a bug describing this issue (http://bugs.winehq.org/). OK. Do you know if it is acceptable form to post a windows binary as an example case on the bug? The DLL part of the bug has to be a windows binary. Thanks for the tip! -- mo
Re: Reload a DLL and _getptd returns zero
On 01/15/2013 01:08 PM, Piotr Caban wrote: On 1/15/13 7:59 PM, Michael Ost wrote: On 01/15/2013 03:39 AM, Piotr Caban wrote: The crash is caused by incomplete FlsFree implementation. There's a comment in it's code that says what needs to be added: /* FIXME: add equivalent of ThreadZeroTlsCell here */ Really? Are you sure that's it? Yes. If you need a workaround to run you app you can comment FlsAlloc export. If this function is not available msvcrt will use TlsAlloc. I've I can confirm that commenting out FlsAlloc does fix this crash. Wow! Do you know what the implications are of using this hack? Would it simply be that any windows code that wants to use FlsAlloc would fail to load with a wine linkage error? Also, is this what the VC runtimes that are statically compiled into a windows DLL do if FlsAlloc is unavailable? For backwards compatibility, I presume...? also confirmed it by adding a hacky implementation of zeroing the memory on free. Is the hacky implementation the line: if (NtCurrentTeb()-FlsSlots) NtCurrentTeb()-FlsSlots[index] = 0; that I see in FlsFree? Because, if so, that doesn't fix the crash. If not, I'd be interested in seeing your hack because we might just use it. By the way, to aid my future Wine sleuthing, can you share any hints on how you figured this out? There's no easy answer to this question. I've looked on the relay log and after figuring out it may be related to Fls* functions I have added some more traces to it. Afterwards it was quite obvious that application was using a value that was supposed to be no longer valid (FlsGetValue was returning old pointer instead of NULL). Thanks for this work! -- mo
Re: Reload a DLL and _getptd returns zero
On 01/12/2013 05:21 PM, Dan Kegel wrote: The library in question is using static vc runtime linkage, so _getptd() is linked in That's somewhat worrisome. So you have multiple instances of the C runtime library active in the same app? Maybe you're not unloading that dll gracefully enough. Might be heap corruption. I wonder if Valgrind might be helpful. I second the suggestion to post a minimal testcase. Here's a link to a zip file that includes the prebuilt .exe and .dll windows binaries that crash in wine. Plus the code. https://dl.dropbox.com/u/97386125/msvcrt-dll-problem.zip So, again, the bug is that MSVCRT calls are failing when called from a DLL that has been reloaded. If the calls come from a thread and if the DLL is built with static MSVCRT runtimes. There is no crash for the program in Windows. I also tried rebuilding the code for winelib, and it doesn't appear to have the same behavior. So the problem doesn't happen if Wine's MSVCRT is used, only if a windows DLL that uses static MSVCRT linkage is reloaded. Thanks -- mo
Re: Reload a DLL and _getptd returns zero
On 1/13/13 1:17 PM, Marcus Meissner wrote: On Fri, Jan 11, 2013 at 11:24:55AM -0800, Michael Ost wrote: Hi list, Does anyone know why _getptd() calls would return zero on a DLL that has been reloaded? Does something happen to the TLS used by _getptd? At Muse Research we have been struggling with a deep bug for years where there is a crash _sometimes_ if you load a DLL a second time. Finally (with a big tip of the hat to Julien Pommier at PianoTeq!) we have a test case that demonstrates a (if not _the_) crash. The sequence is: 1. [main] start a thread 2. [main] load a library 3. [thread] call std::cout from the library 4. [main] free the library 5. [main] reload the library 6. [thread] call std::cout from the library - crash! It looks like the crash happens because the MSVCRT function _getptd() is returning zero in step 6. This is dereferenced and crashes. In windows, there is no crash. The library in question is using static vc runtime linkage, so _getptd() is linked in and I don't know exactly what it is doing. But Wine's MSVCRT implementation of _getptd() gets its data from TlsGetValue. And I can see that just before the crash there is a TlsGetValue call that returns zero. Looking at TlsGetValue(), there must be something wrong with the values in TlsSlots. Maybe they persist for DLLs in Windows in a way they don't for Wine...? Or maybe Wine doesn't reinitialize them the same way when the DLL is reloaded? Any hints, thoughts? clues? Thanks! Is this statically linked msvcrt from Wine or Windows? It's statically linked in Windows. And why free/reload a statically linked library? We load and unload the DLL that has MSCVRT statically linked into it. Our program is a plugin player, that loads (and unloads) VST sound plugins for musicians to perform with. -- mo
Reload a DLL and _getptd returns zero
Hi list, Does anyone know why _getptd() calls would return zero on a DLL that has been reloaded? Does something happen to the TLS used by _getptd? At Muse Research we have been struggling with a deep bug for years where there is a crash _sometimes_ if you load a DLL a second time. Finally (with a big tip of the hat to Julien Pommier at PianoTeq!) we have a test case that demonstrates a (if not _the_) crash. The sequence is: 1. [main] start a thread 2. [main] load a library 3. [thread] call std::cout from the library 4. [main] free the library 5. [main] reload the library 6. [thread] call std::cout from the library - crash! It looks like the crash happens because the MSVCRT function _getptd() is returning zero in step 6. This is dereferenced and crashes. In windows, there is no crash. The library in question is using static vc runtime linkage, so _getptd() is linked in and I don't know exactly what it is doing. But Wine's MSVCRT implementation of _getptd() gets its data from TlsGetValue. And I can see that just before the crash there is a TlsGetValue call that returns zero. Looking at TlsGetValue(), there must be something wrong with the values in TlsSlots. Maybe they persist for DLLs in Windows in a way they don't for Wine...? Or maybe Wine doesn't reinitialize them the same way when the DLL is reloaded? Any hints, thoughts? clues? Thanks! -- Michael Ost
Re: Patchsets that need review by experienced Wine Developers
[-Werror] 0063-disable-winedbg-auto-crash-dialog.patch local hacks Yep. One-offs for us. k. 0062-disable-crashing-alpha-bitmaps-for-gdb.patch Seems like a mistaken patch that was needed as we had the old DIB sections. gdb would have accepted continue here. Should not be necessary anymore these days with the DIBENGINE. Okay, i will try reverting it locally and make sure everything is good. Yes to all of that. I just hated having to hit CONTINUE all the time. And, right, my understanding is that the DIBENGINE no longer uses the same tricks with memory that it used to. add-implementation-setProcessWorkingSetSize.patch Might be submittable as-is. Might need autoconf checks for non-Linux. good. but i am not the guy to do this ~ i have a _ton_ of work right now, both professionally and for my own projects. I just wanted to make sure anything that _should_ be in wine goes into Wine to improve the experience for everyone. Ditto that on the busy thing. ;) Fix-disk-geometry-ioctl.patch Alexandre usually does not like override files like this unless necessary. What is actually expected? you mentioned rendering issues? I am not sure about this one. it needs investigating but i have it applied. As far as rendering issues, yes upstream wine causes ugly The drive geometry from a disk wasn't being reported correctly or consistently. It caused problems with SampleTank from IK Multimedia. flickering in some apps/VSTs, while L_pa-Wine does not (at all, ever). fix-obscured-windows.patch Hmm, needs user32 windowing guru review. probably. The 'prefs' menu from SampleTank wasn't opening with Metacity. Old bugzilla notes say It comes down to the WS_DLGFRAME|WS_THICKFRAME flags. If they are both present then the window is not visible. Turn on or the other off in the example and the window shows up. The second window must have a parent and have the WS_OVERLAPPED style as well. Hope that helps. -- Michael Ost Muse Research and Development
FindFirstVolume crash
Hi list, Can someone help me get through the wineserver code for passing data through a buffer in response to an ioctl? Our (slightly out of date 1.3.24 version of) Wine is getting INVALID_HANDLE_VALUE returned for FindFirstVolume. The problem is that the FindNextVolume call inside FindFirstVolume fails because it is told there are no mount points. I have tracked the code through FindFirstVolume through NtDeviceIoControlFile to server_ioctl_file on the app side. On the wineserver side I can see the wineserver fielding the ioctl request, and mountmgr.sys filling a buffer with 5 mount points. But this information is being written into a buffer (address 0x12510) by the wineserver that is not making it back to FindNextVolume buffer (address 0x29820) on the app side. Where do these buffers come from? Do they use shared memory? Or is the info passed through a pipe? I'm having trouble making my way through the wineserver code, so any tips or pointers would be appreciated! Thank you, Michael Ost Muse Research, Inc.
Re: Using an IDE on Wine?
On 5/13/12 10:00 AM, wine-devel-requ...@winehq.org wrote: How many of you use an Integrated Development Environment (IDE) when working on Wine? If you do, which one do you use and how, how useful is it and how hard was it to set up? I use Qt Creator for Linux for our winelib application. Our app is a hybrid winelib + Qt/X11 app, so we get the extra Qt goodies with Qt Creator. But it does work for other project types too. Getting the integrated gdb debugger to work was a trick. The main thing is to set WINELOADERNOEXEC=1 in the environment and run /usr/bin/wine as the debuggee. We also built and copied in a debug version of /usr/bin/wine to keep Qt Creator from complaining when a debug session got underway. The last gotcha was that we had to hack out alpha channel support for cursors when running under GDB. (IIRC) the DIB engine uses segfaults in normal operation which confuses GDB. I can send along that patch if you are interested. Of course, if you are trying to debug a straight windows application then all of this is irrelevant! But if you are doing winelib, then these tricks can help. -- Michael Ost
wineapploader in wine64
Hi, Any explanation for why the wineapploader script doesn't use 'wine64' instead of 'wine' in a 64bit Linux with 64bit wine? That's the script that is used to build /usr/bin/wineboot and /usr/bin/regedit, for instance. In Fedora 15 with wine 1.3.24, the upshot is that the 'wineboot' command doesn't work. /usr/lib/wine/wineboot.exe.so is not installed; only /usr/lib64/wineboot.exe.so is. Since the /usr/bin/wineboot is running 'wine' instead of 'wine64' it is looking for the 32bit /usr/lib/wine/wineboot.exe.so. It can't be found since it isn't installed so the loader gives up. $ wineboot wine: cannot find LC:\\windows\\system32\\wineboot.exe If it used wine64 instead, it would work. There must be a reason that wine64 is starting 32bit apps, but I haven't been able to glean anything from the web. Thanks for any info, -- Michael Ost
Re: wineapploader in wine64
On 02/16/2012 11:57 AM, Alexandre Julliard wrote: prefix (besides, there shouldn't be any reason to run wineboot by hand). We use it with --shutdown to cleanly terminate (as in WM_CLOSE, not kill) all wine apps from a hardware button press. Is there a preferred way? Thanks! -- Michael Ost
Re: DIB crash with gdb
On 12/23/2011 09:56 PM, Ken Thomases wrote: On Dec 23, 2011, at 3:10 PM, Michael Ost wrote: This all makes sense, and pulls the code together for me. Thanks! You're welcome. I assume this is a recent development, because I was successfully using gdb with our last wine version - 1.1.7. Nope. This is how it has worked for a long, long time. Don't know what else has changed. Maybe some of the other work on the DIB engine has changed whether/when the DIB accesses cause access violations that you're seeing. Interesting. Maybe a resource that is loaded at startup changed so it needs alpha blending now. I'll see if I can hack around that for my local use with gdb. Thanks again, Michael Ost But it no longer sounds workable to use gdb for debugging winelib applications, which is a drag. Are you suggesting using winedbg instead? Well, you can use winedbg with $BreakOnFirstChance set to 0, for some apps. (Setting $BreakOnFirstChance to 0 only has to be done once for a given WINEPREFIX. It's saved in the registry.) You can also try that handle SIGSEGV nostop noprint pass command I gave you. You might try starting with that signal-handling setup and then, when you get close to where you expect a true crash to happen, switch it back (handle SIGSEGV stop print nopass). Some day, the DIB engine will be complete and this memory protection scheme will not be necessary to coordinate DIB access between memory and the X server. Do you know if it can be used as a drop-in replacement in, say, Qt Creator (which is my IDE of choice)? No, it can't. Its interface is not identical to gdb's. Regards, Ken
Re: DIB crash with gdb
On 12/22/11 8:20 PM, Ken Thomases wrote: On Dec 22, 2011, at 8:14 PM, Vitaliy Margolen wrote: On 12/22/2011 04:45 PM, Michael Ost wrote: I'm seeing a SEGV crash when running any wine program with wine 1.3.24 in gdb but not when running without the debugger. The crash is happening when writing to memory allocated by CreateDIBSection in the function create_alpha_bitmap(). The code is in user32/cursoricon.c. This is not a crash, this is the way it supposed to work. At least until DIB is finished and this hack isn't needed. Wine uses this trick to detect when DIB memory needs to be synchronized with the X server. To elaborate: With the debugger on, writing to ptr[0] causes the segfault. And, indeed, when I look at /proc/PID/maps for the problem address (0x35) it is read only. Without the debugger, the memory is read-write and the calls work. The memory is not read-write, at least not at first. Wine handles the SEGV by reading the image back from the X server and making the memory read-write. If and when the app uses GDI to draw to the DIB, then the memory will be made read-only again and the image will be uploaded to the X server before X graphics operations are performed on it. But under gdb the exception handler is not called. The memory is not unlocked and the SEGV happens. You have the order of operations the wrong way around. The memory access is attempted. The SEGV is generated (happens), whether or not gdb is attached. Gdb, being a debugger, stops the process when most signals are raised, to give the programmer an opportunity to investigate. If you were to tell gdb to deliver the signal and let the process proceed, using the command signal SIGSEGV, Wine's signal handler would be invoked and would do the appropriate thing. This will be extremely tedious, though, since DIB accesses can happen a lot. You can tell gdb to ignore the SEGV using a command like handle SIGSEGV nostop noprint pass. Unfortunately, that will prevent you from debugging SEGVs other than DIB access. (It also doesn't extract the debugger entirely from the signal handling, making DIB operations somewhat slower than normal, but that can't really be avoided.) This is where winedbg's set $BreakOnFirstChance=0 can be very valuable. It doesn't help with gdb, though, and it also doesn't help for those applications which use exception handlers to die gracefully rather than crashing. This all makes sense, and pulls the code together for me. Thanks! I assume this is a recent development, because I was successfully using gdb with our last wine version - 1.1.7. But it no longer sounds workable to use gdb for debugging winelib applications, which is a drag. Are you suggesting using winedbg instead? Do you know if it can be used as a drop-in replacement in, say, Qt Creator (which is my IDE of choice)? -- Michael Ost
DIB crash with gdb
Hi, Is it possible that AddVectoredExceptionHandler doesn't work when running wine under gdb? Or maybe it doesn't work in a 32bit wine running in a 64bit system? I'm seeing a SEGV crash when running any wine program with wine 1.3.24 in gdb but not when running without the debugger. The crash is happening when writing to memory allocated by CreateDIBSection in the function create_alpha_bitmap(). The code is in user32/cursoricon.c. Here's where the crash happens, at line 791 in user32/cursoricon.c create_alpha_bitmap(): unsigned int alpha = ptr[3]; ptr[0] = ptr[0] * alpha / 255; -- SEGV here With the debugger on, writing to ptr[0] causes the segfault. And, indeed, when I look at /proc/PID/maps for the problem address (0x35) it is read only. Without the debugger, the memory is read-write and the calls work. WINEDEBUG=+relay,+cursor,+icon,+resource,+bitmap,+virtual,+seh shows that exceptions are used to unlock the DIB as needed. The X11DRV_DIB_FaultHandler is installed and supposed to get invoked when writing to the memory. And, without gdb running there are exceptions which leads to X11DRV_DIB_Unlock. Here's the trace: trace:cursor:create_alpha_bitmap line=790 i 0, ptr 0x35, alpha ac trace:seh:raise_exception code=c005 flags=0 addr=0x7e7ea0d8 ip=7e7ea0d8 tid=0028 trace:seh:raise_exception info[0]=0001 trace:seh:raise_exception info[1]=0035 trace:seh:raise_exception eax= ebx=7e8a5e2c ecx= edx=0067 esi=0035 edi=00ac trace:seh:raise_exception ebp= esp=0032f860 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010a02 trace:seh:call_vectored_handlers calling handler at 0x7e14beb0 code=c005 flags=0 trace:bitmap:X11DRV_DIB_Lock Locking 0x330 from thread 0028 trace:bitmap:X11DRV_DIB_Coerce AppMod requested in status InSync trace:virtual:NtProtectVirtualMemory 0x 0x35 0400 0004 trace:virtual:VIRTUAL_SetProt 0x35-0x350fff c-rw- trace:virtual:VIRTUAL_DumpView View: 0x35 - 0x350fff (valloc) trace:virtual:VIRTUAL_DumpView 0x35 - 0x350fff c-rw- trace:bitmap:X11DRV_DIB_DoProtectDIBSection Changed protection from 2 to 4 trace:bitmap:X11DRV_DIB_Unlock Unlocking in status AppMod trace:bitmap:X11DRV_DIB_Unlock Unlocked 0x330 trace:seh:call_vectored_handlers handler at 0x7e14beb0 returned trace:cursor:create_alpha_bitmap 804 i 0, ptr 0x35 That all works. But under gdb the exception handler is not called. The memory is not unlocked and the SEGV happens. This is all happening in a 64bit Fedora bit system where we have cross compiled a 32bit version of wine. Could that be an issue? Hopefully someone out there knows the answer to this readily. Thanks for your time! -- Michael Ost
Adopt a patch?
I have a patch for a bug that I won't be able to shepherd through the
patch submission process for some time. The bug is that
GetFileVersionInfoSize doesn't work for files with path names longer
than 128 characters.
The patch includes an untried unit test. And I've confirmed the behavior
in Windows Vista.
We use an older version of Wine, and my boss won't let me take the time
right now to rework the patch for the newest Wine sources. If someone
wants to they can take this patch, tweak it for the new wine, update it
to wine-patch requirements and push it through the system.
Otherwise I'll submit as soon as I can.
Cheers,
Michael Ost
--- wine-1.1.7/dlls/kernel32/file.c.RPM 2011-11-02 14:04:34.0 -0700
+++ wine-1.1.7/dlls/kernel32/file.c 2011-11-02 14:06:42.0 -0700
@@ -2476,8 +2476,29 @@
{
/* Now look for the file */
-if (!SearchPathA( NULL, name, NULL, sizeof(ofs-szPathName), ofs-szPathName, NULL ))
-goto error;
+#if 1 // todo
+ CHAR pathName[MAX_PATH];
+ DWORD len;
+
+ len = SearchPathA( NULL, name, NULL, MAX_PATH, pathName, NULL );
+ if (len == 0)
+ goto error;
+ lstrcpynA(ofs-szPathName, pathName, sizeof(ofs-szPathName));
+// todo: copy as much as you can into ofs ... and confirm this in windows
+
+ TRACE(found %s\n, debugstr_a(pathName) );
+
+ if (mode OF_DELETE)
+ {
+ if (!DeleteFileA( pathName )) goto error;
+ TRACE((%s): OF_DELETE return = OK\n, name);
+ return TRUE;
+ }
+
+ handle = LongToHandle(_lopen( pathName, mode ));
+#else
+ if (!SearchPathA( NULL, name, NULL, sizeof(ofs-szPathName), ofs-szPathName, NULL ))
+ goto error;
TRACE(found %s\n, debugstr_a(ofs-szPathName) );
@@ -2489,6 +2510,7 @@
}
handle = LongToHandle(_lopen( ofs-szPathName, mode ));
+#endif
if (handle == INVALID_HANDLE_VALUE) goto error;
GetFileTime( handle, NULL, NULL, filetime );
--- wine-1.1.7/dlls/kernel32/file16.c.RPM 2011-11-02 14:10:28.0 -0700
+++ wine-1.1.7/dlls/kernel32/file16.c 2011-11-02 15:30:13.0 -0700
@@ -122,6 +122,10 @@
FILETIME filetime;
WORD filedatetime[2];
const char *p, *filename;
+#if 1 // todo
+ CHAR pathName[MAX_PATH];
+ DWORD len;
+#endif
if (!ofs) return HFILE_ERROR;
@@ -194,11 +198,32 @@
if (filename)
{
-BOOL found;
+#if 1 // todo
char *path = get_search_path();
if (!path) goto error;
-found = SearchPathA( path, filename, NULL, sizeof(ofs-szPathName),
+ len = SearchPathA( path, filename, NULL, MAX_PATH, pathName, NULL );
+ HeapFree( GetProcessHeap(), 0, path );
+ if (len == 0) goto error;
+ lstrcpynA(ofs-szPathName, pathName, sizeof(ofs-szPathName));
+ }
+
+ TRACE(found %s\n, debugstr_a(pathName) );
+
+ if (mode OF_DELETE)
+ {
+ if (!DeleteFileA( pathName )) goto error;
+ TRACE((%s): OF_DELETE return = OK\n, name);
+ return 1;
+ }
+
+ handle = (HANDLE)_lopen( pathName, mode );
+#else
+ BOOL found;
+ char *path = get_search_path();
+
+ if (!path) goto error;
+ found = SearchPathA( path, filename, NULL, sizeof(ofs-szPathName),
ofs-szPathName, NULL );
HeapFree( GetProcessHeap(), 0, path );
if (!found) goto error;
@@ -214,6 +239,7 @@
}
handle = (HANDLE)_lopen( ofs-szPathName, mode );
+#endif
if (handle == INVALID_HANDLE_VALUE) goto error;
GetFileTime( handle, NULL, NULL, filetime );
--- wine-1.1.7/dlls/version/tests/info.c.RPM 2011-11-08 10:31:24.0 -0800
+++ wine-1.1.7/dlls/version/tests/info.c 2011-11-02 16:17:00.0 -0700
@@ -183,6 +183,19 @@
Expected ERROR_RESOURCE_DATA_NOT_FOUND, got %d\n, GetLastError());
DeleteFileA(test.txt);
+
+ static const char* const kVeryLongFileName = c:\\a very very long and absolute pathname that is longer than the one hundred and twenty-eight character limit of the OFSTRUCT szPathName member;
+ create_file(kVeryLongFileName);
+ SetLastError(0xdeadbeef);
+ hdl = 0xcafe;
+ retval = GetFileVersionInfoSizeA(kVeryLongFileName, hdl);
+ ok(retval == 0, Expected 0, got %d\n, retval);
+ ok(hdl == 0, Expected 0, got %d\n, hdl);
+ ok(GetLastError() == ERROR_RESOURCE_DATA_NOT_FOUND ||
+ GetLastError() == ERROR_BAD_FORMAT || /* win9x */
+ GetLastError() == ERROR_SUCCESS, /* win2k */
+ Expected ERROR_RESOURCE_DATA_NOT_FOUND, got %d\n, GetLastError());
+ DeleteFileA(kVeryLongFileName);
}
static void VersionDwordLong2String(DWORDLONG Version, LPSTR lpszVerString)
Re: wine-devel Digest, Vol 73, Issue 58
Louis, I wonder if the patch referred to here is relevant for the device detection we need for the ilok...? I'm kinda shooting in the dark, without much background, but the message jumped out at me. - mo On 08/22/2011 08:06 AM, wine-devel-requ...@winehq.org wrote: Message: 3 Date: Mon, 22 Aug 2011 14:34:59 +0200 (CEST) From: Francois Gougetfgou...@free.fr Subject: Re: [PATCH] mountmgr: Support the dbus service udisks for dynamic devices :-) [try 5] To: wine-devel@winehq.org Cc: Detlef Riekenbergwine@web.de, wine-patc...@winehq.org Message-ID:alpine.DEB.2.02.1108221431200.19831@amboise.dolphin Content-Type: text/plain; charset=iso-8859-15 On Tue, 16 Aug 2011, Detlef Riekenberg wrote: [...] Recent distributions depend on udisks, so the libhal development package should be uninstalled or disabled when building Wine (--without-hal). I don't understand this recommendation to build with '--without-hal'. It should be possible to build a Wine binary that will run on both old HAL-based Linux distributions and the new usdisks-based ones. Such a binary would need to be built with both HAL and udisks support. Are you saying your patch makes that is impossible?
Re: wine-devel Digest, Vol 73, Issue 58
Dear list, sorry for the accidental posting! Gah! I hit a premature ctrl+enter! ... Michael Ost On 08/22/2011 09:16 AM, Michael Ost wrote: Louis, I wonder if the patch referred to here is relevant for the device snip
Re: WINEDLLPATH and /usr/lib/wine
Alexandre Julliard wrote: Michael Ost m...@museresearch.com writes: I agree. And that's what your patch does, right? Would you like to submit it to the wine-patches list? I think the case for it is strong, especially since (1) you found that it fixes a behavior change in WINEDLLPATH from November 2006 --- arguably a regression; and (2) it works in the same way that LD_LIBRARY_PATH works, which is what Linux programmers would expect. Actually the current way is precisely what LD_LIBRARY_PATH does for relocatable installs. The loader first looks in the rpath $ORIGIN path, then in LD_LIBRARY_PATH, then in system directories. Wine does exactly the same thing. I did a quickie review of 'rpath'. It isn't standard, though, is it? I'm not using it with my APP.exe.so. LD_LIBRARY_PATH is searched first on my system. Anyway, is the next step that I (or Hin-Tak) submit a patch and you bless it or not? - mo PS: LD_LIBRARY_PATH behavior with my .exe.so shows that LD_LIBRARY_PATH can jump in front of even /lib... [m...@deceptor make]$ ldd wine-debug/host-engine.exe.so libdl.so.2 = /lib/libdl.so.2 (0xb7b9b000) snip [m...@deceptor make]$ ls /lib/libdl.so.2 /lib/libdl.so.2 [m...@deceptor make]$ touch libdl.so.2 [m...@deceptor make]$ LD_LIBRARY_PATH=`pwd` ldd wine-debug/host-engine.exe.so /bin/bash: error while loading shared libraries: /home/most/Desktop/cvs/muse/applications/host-engine/make/libdl.so.2: file too short
Re: WINEDLLPATH and /usr/lib/wine
Alexandre Julliard wrote: Michael Ost m...@museresearch.com writes: The first step would probably be to explain why you need to have an app with the same name as an existing builtin. Right, ok. I'm not replacing a builtin. I install APP.exe.so in /usr/lib/wine so all users from any .wine directory can launch it with a script that contains 'exec wine APP.exe'. I'm mimicking how, say, regedit works. During development I want to run a development-local APP.exe.so in place of the version installed in /usr/lib/wine. 'WINEDLLPATH=/DEVDIR wine APP.exe' was my solution. The solution of using a hardcoded path doesn't work for me because (a) my development directory is not accessible through a wine drive so wine can't find APP.exe.so and (b) we have code that uses 'pidof APP.exe' to find APP's pid, so if it were named APP.exe.so it would not be found. Granted there are other solutions to these issues. But using WINEDLLPATH is an elegant one. Unfortunately WINEDLLPATH does not work as I expected it to, based on experience with other similar Linux features (like ld) and reading the wine man page. Thanks... mo PS: Did you know that currently the search path is (mysteriously) /usr/lib/wine:WINEDLLPATH:/usr/lib/wine? That doesn't look intentional to me...
Re: WINEDLLPATH and /usr/lib/wine
Alexandre Julliard wrote: Michael Ost m...@museresearch.com writes: I'm not replacing a builtin. I install APP.exe.so in /usr/lib/wine so all users from any .wine directory can launch it with a script that contains 'exec wine APP.exe'. I'm mimicking how, say, regedit works. During development I want to run a development-local APP.exe.so in place of the version installed in /usr/lib/wine. 'WINEDLLPATH=/DEVDIR wine APP.exe' was my solution. If it's just for development I don't think this justifies changing it. You could simply use your own Wine build and then it will ignore the one in /usr/lib/wine, or configure a drive for your development dir. Alright, I'll just add the patch to our own internal wine build then. Well I tried! ... mo
Re: WINEDLLPATH and /usr/lib/wine
Hin-Tak Leung wrote: --- On Mon, 25/1/10, Michael Ost m...@museresearch.com wrote: Alexandre Julliard wrote: Not necessarily, the behavior could probably be tweaked, feel free to suggest changes. You can't require users to set WINEDLLPATH for normal usage though, including running from the build tree or from a relocated install. Two easy options would be: 1. put /usr/lib/wine at the end of the list automatically. This is Hin-Tak Leung's approach. 2. require users to add /usr/lib/wine themselves. I could make a patch for that. #1 is easier for me :) but #2 is a little more standard, acting like LD_LIBRARY_PATH or PATH do. Which would you prefer? ... mo If I understand that bit of code correctly, the current behavior is such that built-ins comes before WINEDLLPATH *and* after, so there is no way a user per-application built-ins can override (even temporarily on a per application basis) the system-wide built-ins. Yes, I can confirm this. Strange to have it in the list twice. That sure looked unintentional to me. As ddiwrapper - the application I was interested in - tried to provide a gdl32.dll.so which does different things - it stopped working when the system-wide built-ins is both prepended and appended to library search. I think it should work like LD_LIBRARY_PATH, really as they are platform shared libraries. I agree. And that's what your patch does, right? Would you like to submit it to the wine-patches list? I think the case for it is strong, especially since (1) you found that it fixes a behavior change in WINEDLLPATH from November 2006 --- arguably a regression; and (2) it works in the same way that LD_LIBRARY_PATH works, which is what Linux programmers would expect. If you want to help future WINEDLLPATH users, you could also tweak the man page from something like: WINEDLLPATH Specifies the path(s) in which to search for builtin dlls and Winelib applications. This is a list of directories separated by :. In addition to any directory specified in WINEDLLPATH, Wine will also look in /usr/lib/wine. to something like: WINEDLLPATH Specifies the path(s) in which to search for builtin dlls and Winelib applications. This is a list of directories separated by :. After looking in directories specified in WINEDLLPATH, Wine will also look in /usr/lib/wine. Cheers... mo
WINEDLLPATH and /usr/lib/wine
Hi, I am wanting to direct wine to launch a specific APP.exe.so program by using WINEDLLPATH during the development of APP.exe. Unfortunately (and undocumented-ely if you know what I mean) WINEDLLPATH is superseded by /usr/lib/wine. So if /usr/lib/wine/APP.exe.so exists, WINEDLLPATH will find that one instead of the one I am trying to target. So, if these files exist: /usr/lib/wine/APP.exe.so /MY_DIR/APP.exe.so Then this command... WINEDLLPATH=MY_DIR wine APP.exe ... will start /usr/lib/wine/APP.exe.so and not /MY_DIR/APP.exe.so. Is this on purpose? It doesn't seem right at first glance. I would assume that WINEDLLPATH would take precedence. Otherwise what purpose would it serve? Thanks for tips or background, Michael Ost Muse Research, Inc.
Re: WINEDLLPATH and /usr/lib/wine
Hin-Tak Leung wrote: I asked about the same problem a while ago without any response, but I have a patch for it: https://www.linuxfoundation.org/en/User:Htl10#Ddiwrapper_.28a.k.a._.22Using_Vendor_win32_printer_driver_in_Linux.22.29 I can see how that patch would work. Though I can also see why it wouldn't be accepted! :) I'll let you know if I come up with something else that doesn't need a patch - though I am not hopeful. Thanks ... mo I reckon it is because the wine devs don't want people to override certain things. WINEDLLPATH used to work until Feb/March 2006 . --- On Mon, 25/1/10, Michael Ost m...@museresearch.com wrote: Hi, I am wanting to direct wine to launch a specific APP.exe.so program by using WINEDLLPATH during the development of APP.exe. Unfortunately (and undocumented-ely if you know what I mean) WINEDLLPATH is superseded by /usr/lib/wine. So if /usr/lib/wine/APP.exe.so exists, WINEDLLPATH will find that one instead of the one I am trying to target. So, if these files exist: /usr/lib/wine/APP.exe.so /MY_DIR/APP.exe.so Then this command... WINEDLLPATH=MY_DIR wine APP.exe ... will start /usr/lib/wine/APP.exe.so and not /MY_DIR/APP.exe.so. Is this on purpose? It doesn't seem right at first glance. I would assume that WINEDLLPATH would take precedence. Otherwise what purpose would it serve? Thanks for tips or background, Michael Ost Muse Research, Inc.
Re: WINEDLLPATH and /usr/lib/wine
Alexandre Julliard wrote: Michael Ost m...@museresearch.com writes: Is this on purpose? It doesn't seem right at first glance. I would assume that WINEDLLPATH would take precedence. Otherwise what purpose would it serve? It serves as an extra path where dlls can be found, but dlls from the current running installation are used first. This is to enable relocatable installs, and running from inside the build tree. Note that you can always specify the full exe path on the command line. That doesn't work without a wine drive that includes APP.exe.so --- we run without z:/. I think it makes more sense to require, as Hin-Tak Leung's patch does, that a user put /usr/lib/wine in WINEDLLPATH if they use WINEDLLPATH. This is how LD_LIBRARY_PATH works for ld and PATH works in bash --- so it's expected behavior. Also, from my reading of the code, you jump through some special hoops to deal with running from the build directory which could be more easily solved by putting WINEDLLPATH first. Anyway, I'm guessing that I'm whistling in the wind here since so much is built on how WINEDLLPATH currently works...? Thanks... mo
Re: WINEDLLPATH and /usr/lib/wine
Alexandre Julliard wrote: Michael Ost m...@museresearch.com writes: I think it makes more sense to require, as Hin-Tak Leung's patch does, that a user put /usr/lib/wine in WINEDLLPATH if they use WINEDLLPATH. This is how LD_LIBRARY_PATH works for ld and PATH works in bash --- so it's expected behavior. Also, from my reading of the code, you jump through some special hoops to deal with running from the build directory which could be more easily solved by putting WINEDLLPATH first. Anyway, I'm guessing that I'm whistling in the wind here since so much is built on how WINEDLLPATH currently works...? Not necessarily, the behavior could probably be tweaked, feel free to suggest changes. You can't require users to set WINEDLLPATH for normal usage though, including running from the build tree or from a relocated install. Two easy options would be: 1. put /usr/lib/wine at the end of the list automatically. This is Hin-Tak Leung's approach. 2. require users to add /usr/lib/wine themselves. I could make a patch for that. #1 is easier for me :) but #2 is a little more standard, acting like LD_LIBRARY_PATH or PATH do. Which would you prefer? ... mo
Re: WINEDLLPATH and /usr/lib/wine
Ben Klein wrote: 2010/1/26 Michael Ost m...@museresearch.com: Alexandre Julliard wrote: I think it makes more sense to require, as Hin-Tak Leung's patch does, that a user put /usr/lib/wine in WINEDLLPATH if they use WINEDLLPATH. This is how LD_LIBRARY_PATH works for ld and PATH works in bash --- so it's expected behavior. Actually, it's not how LD_LIBRARY_PATH works. $ LD_LIBRARY_PATH=/path/that/does/not/exist/ /bin/echo Hi there Hi there It is the way it works for PATH in all shells (not just bash), but this is a different matter because your shell environment (often a login or profile script) provides a default, sensible value for PATH. $ echo $PATH /usr/local/bin:/usr/bin:/bin:/usr/games $ echo $LD_LIBRARY_PATH OK - fair enough. But, if I read the man page correctly LD_LIBRARY_PATH _prepends_ your path before the standard paths. That would do fine for me. WINEDLLPATH is appended after /usr/lib/wine. WINEDLLPATH should certainly behave more like LD_LIBRARY_PATH than PATH, but wine should always follow the same DLL search pattern as Windows. How would Windows handle adding a directory to the DLL search path? (Is this even possible?) I'm not getting why Windows DLL searching is relevant here. This is a Linux-side issue. Also, from my reading of the code, you jump through some special hoops to deal with running from the build directory which could be more easily solved by putting WINEDLLPATH first. How, exactly? This was a slightly uninformed comment on my part, so I could be totally off base here. And the code supporting dll directory lookups is complicated. But ... I saw special cases for dealing with the build directory, including this comment /* if no build dir skip all the build dir magic cases */ libs/wine/loader.c/first_dll_path. Those suggest to me that someone was trying to stick a path in before /usr/lib/wine. All that said, this isn't at all central to what I would like to do. All I want is that WINEDLLPATH comes before /usr/lib/wine. - mo PS: Hin-Tak Leung, who got bit by this before me, found that WINEDLLPATH broke/changed in November of 2006.
Re: IOCTL_DISK_GET_DRIVE_GEOMETRY in mountmgr.sys
Michael Ost wrote: The ioctl handler for IOCTL_DISK_GET_DRIVE_GEOMETRY on .\\c: in mountmgr.sys doesn't work. The call returns incorrect values that change at random intervals. snip List, Never mind this one. It turns out that the bug happened due to another patch to Wine in our source tree. We adapted ntoskrnl.exe to deal with METHOD_BUFFERED driver calls, but didn't adapt mountmgr.sys for that. Sorry for the noise! ... mo
IOCTL_DISK_GET_DRIVE_GEOMETRY in mountmgr.sys
Hi, The ioctl handler for IOCTL_DISK_GET_DRIVE_GEOMETRY on .\\c: in mountmgr.sys doesn't work. The call returns incorrect values that change at random intervals. Since the ioctl is defined as METHOD_BUFFERED I think it should be putting DRIVE_GEOMETRY data in IRP-AssociatedIrp.SystemBuffer. Instead the handler puts the data in IRP-MdlAddress.StartVa. Then process_ioctl in ntoskrnl.exe wipes out the output data with the random stuff in the allocated SystemBuffer. I am out of my depth with windows driver handling code, but a web search (http://www.cmkrnl.com/arc-ioctlbuf.html) says that SystemBuffer should be where the data is put. Indeed, when I change to SystemBuffer the user call to DeviceIoControl gets the right values back. Am I on the right track? Thanks, Michael Ost PS: here's a proposed patch... --- wine-1.1.7/dlls/mountmgr.sys/device.c.ORIG 2009-03-23 14:04:30.0 -0700 +++ wine-1.1.7/dlls/mountmgr.sys/device.c 2009-03-25 17:06:24.0 -0700 @@ -607,7 +607,7 @@ info.TracksPerCylinder = 255; info.SectorsPerTrack = 63; info.BytesPerSector = 512; -memcpy( irp-MdlAddress-StartVa, info, len ); +memcpy( irp-AssociatedIrp.SystemBuffer, info, len ); irp-IoStatus.Information = len; irp-IoStatus.u.Status = STATUS_SUCCESS; break;
Re: winecfg volume serial number
wine-devel-requ...@winehq.org wrote: Date: Tue, 16 Dec 2008 13:52:00 +0100 From: Hoehle, Joerg-Cyril joerg-cyril.hoe...@t-systems.com Subject: winecfg volume serial number To: wine-devel@winehq.org Message-ID: 47cc5abb01651443a88db8ec5b4d657b01c8f...@s4de8psaank.mitte.t-com.de Content-Type: text/plain;charset=iso-8859-1 Hi, I just sent a bug-fix to wine-patches to prevent a crash in winecfg when editing the volume serial number input field, together with some unrelated thoughts about winecfg and the device/volume serial number handling. Then I realized that wine-patches is not a good place for discussion. So here are the ideas about winecfg's GUI: It doesn't make sense to me to rely on writing to a file to set the windows serial number or label. What about readonly disks? I think those values should be in the registry. Or at least check the registry should be a fallback if .windows-serial or .windows-label does not exist. I am stuck now because an installer program is looking for a CD of a certain label. I can't fudge in the label because it's a CD that I can't write to. Is anyone working on this issue, or agree/disagree? ... mo
Re: winecfg volume serial number
James Hawkins wrote: On Thu, Dec 18, 2008 at 12:31 PM, Michael Ost m...@museresearch.com wrote: wine-devel-requ...@winehq.org wrote: Date: Tue, 16 Dec 2008 13:52:00 +0100 From: Hoehle, Joerg-Cyril joerg-cyril.hoe...@t-systems.com Subject: winecfg volume serial number To: wine-devel@winehq.org Message-ID: 47cc5abb01651443a88db8ec5b4d657b01c8f...@s4de8psaank.mitte.t-com.de Content-Type: text/plain;charset=iso-8859-1 Hi, I just sent a bug-fix to wine-patches to prevent a crash in winecfg when editing the volume serial number input field, together with some unrelated thoughts about winecfg and the device/volume serial number handling. Then I realized that wine-patches is not a good place for discussion. So here are the ideas about winecfg's GUI: It doesn't make sense to me to rely on writing to a file to set the windows serial number or label. What about readonly disks? I think those values should be in the registry. Or at least check the registry should be a fallback if .windows-serial or .windows-label does not exist. I am stuck now because an installer program is looking for a CD of a certain label. I can't fudge in the label because it's a CD that I can't write to. Is anyone working on this issue, or agree/disagree? ... mo The label of the CD is read from the disk. If you're using a mounted ISO, you have to fix the access rights of the loopback file representing the ISO file. Yes, you are right. And this does work. In my system I am mounting a remote CD over samba and creating a drive letter for it in Wine. That's the disc that the installer wants to query. I was hoping to be able to set the label for the network drive to work around this issue. But the CD is read only so I can't write the file. So I am trying to do something tricky, that is probably not even possible in Windows. And I'll probably just have to my own internal Wine hack to get this to work. - mo
Re: Status of 64 bit Wine
Maarten Lankhorst wrote: Hi Michael, Michael Ost schreef: Hi list, Every once in a while my boss asks me about 64 bit wine. And today was the day. So what's the status? From my understanding there are two parts to the question. First, is anyone using a 64 bit build of Wine? How successfully? Does it pass the internal wine tests? Been playing around with it a little bit for fun and profit. If you look at the Wine64 wiki page you see the current state. Thanks for the link. It says AMD64 --- I hope this doesn't sound stupid but will that work on 64 bit Intels too? Is this an afterhours project for you, or something more serious? And second, is there any progress on loading 64 bit windows binaries in Wine? My understanding was that changes were needed to gcc to make that happen. Is that correct? Is there any progress on that score? The changes are mostly in, there is a bug in gcc with handling it, but I got the patch for it so locally it works. Basic programs winelib programs like winecfg work. The most succesful binary I ran was a pacman for win64, but the only thing it does is throw up a messagebox 'unable to load resources'. Pacman is a windows 64 binary, with the windows ABI? And that required your local gcc patch to work, right? Does --enable-win64 alter gcc so it builds code that can deal with the windows 64 bit conventions? Knowing that you got past that would be good news, because this sounded like the biggest, scariest part when I looked into it a while back. Getting it in an AJ approved form is a bit harder, but I'm working on it. Right-o! Glad to hear you are at it. Thanks! ... mo
Status of 64 bit Wine
Hi list, Every once in a while my boss asks me about 64 bit wine. And today was the day. So what's the status? From my understanding there are two parts to the question. First, is anyone using a 64 bit build of Wine? How successfully? Does it pass the internal wine tests? And second, is there any progress on loading 64 bit windows binaries in Wine? My understanding was that changes were needed to gcc to make that happen. Is that correct? Is there any progress on that score? And please correct any misunderstandings I may have. Thanks... mo
Re: What happened to __TRY?
Rob Shearman wrote:
2008/11/6 Michael Ost [EMAIL PROTECTED]:
Hi all,
When I upgraded wine-develfrom 1.0 to 1.1.7, my winelib app that uses
__TRY no longer links. It complains that RtlUnwind cannot be found. I
can see that RtlUnwind was added to wine/exception.h, but I am not sure
how to fix it.
I tried adding -lntdll and -lwine to the link command line but it didn't
help. Any suggestions?
Yes, you need to link to ntdll. Linking to libwine shouldn't be
necessary. Please post the command line you are using and errors you
are getting even when you link to ntdll.
I tried linking to ntdll and kernel32, but same result. Unless I am
linking in the wrong way? Command line and result are below.
BTW - I thought that wineg++ linked in ntdll and kernel32 automatically...?
Thanks! ... mo
PS: Command line that builds test.o and links the app that fails:
wineg++ -UNDEBUG -g -O0 -Wall -Werror
-I/home/most/Desktop/cvs/sandbox/mo/vst-player/make/../source
-I/home/most/Desktop/cvs/sandbox/mo/vst-player/make/../../../..//muse/libraries/medioid
-I/home/most/Desktop/cvs/sandbox/mo/vst-player/make/../../../..//muse/libraries/muselock
-c -MMD -MP -o test.o
/home/most/Desktop/cvs/sandbox/mo/vst-player/make/../source/win32/test.cpp
wineg++ -UNDEBUG -g -O0 -Wall -Werror
-I/home/most/Desktop/cvs/sandbox/mo/vst-player/make/../source
-I/home/most/Desktop/cvs/sandbox/mo/vst-player/make/../../../..//muse/libraries/medioid
-I/home/most/Desktop/cvs/sandbox/mo/vst-player/make/../../../..//muse/libraries/muselock
-o vst-player.exe.so VstPlayerApp.o test.o PaceablePlugin.o
PlayerMixer.o
/home/most/Desktop/cvs/sandbox/mo/vst-player/make/../../../..//muse/libraries/medioid/wine-debug/libmedioid.a
-lboost_filesystem -ldl -lrt -lasound -lpthread
/home/most/Desktop/cvs/sandbox/mo/vst-player/make/../../../..//muse/libraries/muselock/wine-debug/libmuselock.a
/home/most/Desktop/cvs/sandbox/mo/vst-player/make/../../../..//muse/libraries/muselock/source/win32/PlugInLib.a
-lusb -lcomdlg32 -lgdi32 -lcomdlg32 -lntdll -lkernel32
test.o: In function `__wine_rtl_unwind':
/usr/include/wine/exception.h:250: undefined reference to
`RtlUnwind(void*, void*, _EXCEPTION_RECORD*, void*)'
PlayerMixer.o: In function `__wine_rtl_unwind':
/usr/include/wine/exception.h:250: undefined reference to
`RtlUnwind(void*, void*, _EXCEPTION_RECORD*, void*)'
collect2: ld returned 1 exit status
winegcc: g++ failed
PPS: test.cpp source that uses __TRY:
#include windows.h// WinMain
#include wine/exception.h // __TRY
void test_function();
LONG WINAPI process_exception_handler(EXCEPTION_POINTERS* exceptions)
{
return(EXCEPTION_EXECUTE_HANDLER);
}
void test_function()
{
__TRY {
}
__EXCEPT(process_exception_handler) {
}
__ENDTRY
}
Re: What happened to __TRY?
Alexandre Julliard wrote: Michael Ost [EMAIL PROTECTED] writes: When I upgraded wine-develfrom 1.0 to 1.1.7, my winelib app that uses __TRY no longer links. It complains that RtlUnwind cannot be found. I can see that RtlUnwind was added to wine/exception.h, but I am not sure how to fix it. I tried adding -lntdll and -lwine to the link command line but it didn't help. Any suggestions? http://source.winehq.org/git/wine.git/?a=commitdiff;h=e21cbfe7e81c1d8d0bffdefaed8f73f7d0309d50 That did it. Thanks, you old wine-o you... mo
What happened to __TRY?
Hi all, When I upgraded wine-develfrom 1.0 to 1.1.7, my winelib app that uses __TRY no longer links. It complains that RtlUnwind cannot be found. I can see that RtlUnwind was added to wine/exception.h, but I am not sure how to fix it. I tried adding -lntdll and -lwine to the link command line but it didn't help. Any suggestions? Thanks! ... mo PS: Here's the linker line I am using and the error returns... wineg++ -DNDEBUG=1 -O3 -DBOOST_POSIX_API -DBOOST_POSIX_PATH -DALSA=1 -DMUSE_SSE -Wall -Werror -D__STDC_LIMIT_MACROS=1 -I/home/most/Desktop/cvs/muse/receptor2/rm-host -I/home/most/Desktop/cvs/muse/receptor2/rm-host/../../../muse/libraries/hotspot -I/home/most/Desktop/cvs/muse/receptor2/rm-host/../../../muse/libraries/medioid -I/home/most/Desktop/cvs/muse/receptor2/rm-host/../../../muse/libraries/uniwire -I/home/most/Desktop/cvs/muse/receptor2/rm-host/../../../muse/libraries/muselock -I/home/most/Desktop/cvs/muse/receptor2/rm-host/../../../external/vst/vstsdk2.4 -I/usr/include/xmlwrapp -I/usr/include/libxml2 -Wb,--3gb -o rm-host.exe.so ChildView.o IsFileOpen.o SerialDevice.o SystemInterface.o Alert.o AudioFader.o AutoAddPage.o Balancer.o BankButton.o BankPatch.o BankPatchPanel.o BufferSizePanel.o BypassPanel.o ChannelDetail.o ChannelStrip.o CopyPanel.o CopyPatchPanel.o CopySwitch.o CPUGauge.o DeletePanel.o Dial.o DualCorePanel.o EditorMenu.o EditPage.o EditParametersPanel.o EditStrip.o EffectPage.o FacelessPage.o FrontPanel.o FrontPanelPage.o GeberDevice.o GeberFrontPanel.o GuitarMonitor.o HostApp.o Host.o HostHandleMidi.o HostInput.o HostLevels.o HostMixer.o HostPage.o HostPlugin.o HostPluginList.o HostPluginOutput.o HostTrack.o Icon.o InformationPanel.o InitializePanel.o InputLevelPanel.o InstallPanel.o InstStrip.o ListenToMidiPanel.o LoadBlankPanel.o LockPanel.o MasterStack.o MetersPanel.o MidiFilterPopup.o MidiMonitorPanel.o MixerStatus.o MixPage.o MultiPage.o MutePanel.o Navigation_hotspot.o OneColumnPopup.o OutputAssignmentPanel.o OutputPopup.o OtherProgramChangesPanel.o PanelParameters.o PanicPanel.o ParameterPanel.o PatchButton.o PatchReport.o PluginControllersPanel.o PluginMenu.o PluginPanel.o PluginsToIgnore.o PluginTypePanel.o Preferences.o PrePostPanel.o ProgramChannelPanel.o ProgramChangeModePanel.o ReceptorAudioControl.o ReceptorNamePanel.o ReceptorXmlRpc.o RemapPanel.o RenamePanel.o RenamePatchPanel.o ReorderPopup.o RoutePanel.o RouteStack.o SampleClockPanel.o SampleClockPopup.o SampleRatePanel.o SampleRatePopup.o SavePatch.o SavePatchPanel.o SelectChannelPanel.o SendStack.o SendStrip.o SetupPage.o SignalLevel.o SinglePage.o SoloPanel.o SourcePage.o SwitchPanel.o TcpipPanel.o TempoAndTransport.o TempoPanel.o TempoPopups.o TempoSourcePanel.o TimeSignaturePanel.o TrackNamePopup.o TrackStack.o TransposePanel.o TransposePopup.o UninstallPluginsPanel.o UninstallPopup.o UniWirePanel.o UniWireXmlRpcServer.o UnsupportedPlugins.o ViewBankPanel.o ViewBar.o ViewPopup.o VstSettingsCache.o VstSettings.o XmlRpcServer.o XmlSupport.o ZloadPanel.o ZombiePlugins.o ZonePanel.o /home/most/Desktop/cvs/muse/receptor2/rm-host/../../../muse/libraries/uniwire/wine-release/libuniwire.a /home/most/Desktop/cvs/muse/receptor2/rm-host/../../../muse/libraries/medioid/wine-release/libmedioid.a /home/most/Desktop/cvs/muse/receptor2/rm-host/../../../muse/libraries/hotspot/wine-release/libhotspot.a /home/most/Desktop/cvs/muse/receptor2/rm-host/../../../muse/libraries/muselock/wine-release/libmuselock.a /home/most/Desktop/cvs/muse/receptor2/rm-host/../../../muse/libraries/muselock/source/win32/PlugInLib.a -ldl -lrt -lasound -lpng -lusb -lcomdlg32 -lxml2 -lxslt -lxmlwrapp -lboost_filesystem -lboost_thread-mt -lgdi32 -lshell32 HostApp.o: In function `__wine_exception_handler(_EXCEPTION_RECORD*, _EXCEPTION_REGISTRATION_RECORD*, _CONTEXT86*, _EXCEPTION_REGISTRATION_RECORD**)': HostApp.cpp:(.text+0x4cb): undefined reference to `RtlUnwind(void*, void*, _EXCEPTION_RECORD*, void*)' HostMixer.o: In function `__wine_exception_handler(_EXCEPTION_RECORD*, _EXCEPTION_REGISTRATION_RECORD*, _CONTEXT86*, _EXCEPTION_REGISTRATION_RECORD**)': HostMixer.cpp:(.text+0x60b): undefined reference to `RtlUnwind(void*, void*, _EXCEPTION_RECORD*, void*)' collect2: ld returned 1 exit status winegcc: g++ failed
Wineg++ and structured exception handling
Hi, Is there a way for wineg++ to catch windows exceptions and handle them as g++ does --- cleaning up stack variables, etc? My C++ winelib app, built with wineg++, is loading Windows DLLs. I want to catch windows exceptions from functions that I call from those DLLs. I need to do some cleanup if there are exceptions, and tried creating some stack variables to manage that. I found __TRY and __CATCH in wine/exception.h. Wrapping the DLL function calls with __TRY and __CATCH does indeed catch exceptions, but there is no stack cleanup. There is some deep code in exception.h that implements __TRY/__CATCH (which I sure could be misreading) but they look more C like than C++ like... just taking care to jump to the right location without trying to do any cleanup. Window's c++ compiler evidently does that now, per this page: http://msdn.microsoft.com/en-us/library/7w0chfbk(VS.80).aspx I'm guessing I am out of luck here, but am hoping I'm just missing something. Thanks... mo
Re: Fullscreen window in metacity hides owned window
Dmitry Timoshkov wrote: Michael Ost [EMAIL PROTECTED] wrote: We are seeing a problem in Metacity where a fullscreen window obscures a second created window that has a particular style: WS_DLGFRAME | WS_THICKFRAME. When window A is created fullscreen (WS_POPUP, size matches screen res) and window B is created as an owned window (WS_DLGFRAME|WS_THICKFRAME|WS_OVERLAPPED style with A as its parent) you cannot see B if Metacity is running. You can if other window managers are running. We tried kwin, xfce, fluxbox, enlightenment or fvvm. So the problem is something specific to Metacity. You can also see window B if you remove either the WS_DLGFRAME or WS_THICKFRAME bit from the style. Any hints about where to look within Wine or what could be happening? Have a look at dlls/winex11.drv/window.c. It looks like windows of type _NET_WM_WINDOW_TYPE_DIALOG have a similar problem to the one related to _NET_WM_WINDOW_TYPE_UTILITY. Try to comment out appropriate line of code and see if that helps. The problem happens because the first test in set_wm_hints catches the WS_THICKFRAME bit and sets the window style to _NET_WM_WINDOW_TYPE_NORMAL. If I move the WS_DLGFRAME test first, and set the style to _NET_WM_WINDOW_TYPE_DIALOG, then it works. As I read the MSDN window style docs, it seems like a dialog style should trump a THICKFRAME style. But I am not so familiar with what the _NET_WM_WINDOW_TYPE_* styles mean and how to map them to Windows' styles. So, what's the preferred fix? Should I change set_wm_hints to catch the DIALOG styles first (see diff below)? That seems reasonable to me. Does that sound safe to you? Is this something that should be generally available or just a one off hack for my version of wine? Thanks for your help! ... mo PS: diff showing change to catch dialog styles first in set_wm_hints... [EMAIL PROTECTED] winex11.drv]# diff -Naur window.c-1.0-1.fc8.5muse window.c --- window.c-1.0-1.fc8.5muse2008-10-02 09:27:09.0 -0700 +++ window.c2008-10-02 09:38:22.0 -0700 @@ -903,10 +903,10 @@ set_size_hints( display, data, style ); /* set the WM_WINDOW_TYPE */ -if (style WS_THICKFRAME) window_type = x11drv_atom(_NET_WM_WINDOW_TYPE_NORMAL); -else if (ex_style WS_EX_APPWINDOW) window_type = x11drv_atom(_NET_WM_WINDOW_TYPE_NORMAL); -else if (style WS_DLGFRAME) window_type = x11drv_atom(_NET_WM_WINDOW_TYPE_DIALOG); +if (style WS_DLGFRAME) window_type = x11drv_atom(_NET_WM_WINDOW_TYPE_DIALOG); else if (ex_style WS_EX_DLGMODALFRAME) window_type = x11drv_atom(_NET_WM_WINDOW_TYPE_DIALOG); +else if (style WS_THICKFRAME) window_type = x11drv_atom(_NET_WM_WINDOW_TYPE_NORMAL); +else if (ex_style WS_EX_APPWINDOW) window_type = x11drv_atom(_NET_WM_WINDOW_TYPE_NORMAL); else if ((style WS_POPUP) owner) window_type = x11drv_atom(_NET_WM_WINDOW_TYPE_DIALOG); #if 0 /* many window managers don't handle utility windows very well */ else if (ex_style WS_EX_TOOLWINDOW) window_type = x11drv_atom(_NET_WM_WINDOW_TYPE_UTILITY);
Fullscreen window in metacity hides owned window
We are seeing a problem in Metacity where a fullscreen window obscures a
second created window that has a particular style: WS_DLGFRAME |
WS_THICKFRAME.
When window A is created fullscreen (WS_POPUP, size matches screen res)
and window B is created as an owned window
(WS_DLGFRAME|WS_THICKFRAME|WS_OVERLAPPED style with A as its parent)
you cannot see B if Metacity is running.
You can if other window managers are running. We tried kwin, xfce,
fluxbox, enlightenment or fvvm. So the problem is something specific to
Metacity.
You can also see window B if you remove either the WS_DLGFRAME or
WS_THICKFRAME bit from the style.
Any hints about where to look within Wine or what could be happening?
- mo
PS: the code (ctrl+c to quit)...
#include windows.h
const char g_szClassName[] = myWindowClass;
// Step 4: the Window Procedure
LRESULT CALLBACK WndProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
switch(msg)
{
case WM_CLOSE:
DestroyWindow(hwnd);
break;
case WM_DESTROY:
PostQuitMessage(0);
break;
default:
return DefWindowProc(hwnd, msg, wParam, lParam);
}
return 0;
}
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPSTR lpCmdLine, int nCmdShow)
{
WNDCLASSEX wc;
HWND hwnd, hwnd4;
MSG Msg;
//Step 1: Registering the Window Class
wc.cbSize= sizeof(WNDCLASSEX);
wc.style = 0;
wc.lpfnWndProc = WndProc;
wc.cbClsExtra= 0;
wc.cbWndExtra= 0;
wc.hInstance = hInstance;
wc.hIcon = LoadIcon(NULL, IDI_APPLICATION);
wc.hCursor = LoadCursor(NULL, IDC_ARROW);
wc.hbrBackground = (HBRUSH)(COLOR_WINDOW+1);
wc.lpszMenuName = NULL;
wc.lpszClassName = g_szClassName;
wc.hIconSm = LoadIcon(NULL, IDI_APPLICATION);
if(!RegisterClassEx(wc))
{
MessageBox(NULL, Window Registration Failed!, Error!,
MB_ICONEXCLAMATION | MB_OK);
return 0;
}
// Step 2: Creating the Window
int width = ::GetSystemMetrics(SM_CXSCREEN);
int height = ::GetSystemMetrics(SM_CYSCREEN);
hwnd = CreateWindowEx(
WS_EX_CLIENTEDGE,
g_szClassName,
A,
WS_POPUP,
CW_USEDEFAULT, CW_USEDEFAULT, width, height,
NULL, NULL, hInstance, NULL);
if(hwnd == NULL)
{
MessageBox(NULL, Window Creation Failed!, Error!,
MB_ICONEXCLAMATION | MB_OK);
return 0;
}
hwnd4 = CreateWindowEx(
WS_EX_CLIENTEDGE,
g_szClassName,
B,
#if 1 // invisible
WS_DLGFRAME|WS_THICKFRAME|WS_OVERLAPPED,
#else // visible
WS_THICKFRAME|WS_OVERLAPPED,
#endif
300, 300, 240, 120,
hwnd, NULL, hInstance, NULL);
if(hwnd4 == NULL)
{
MessageBox(NULL, Window Creation Failed!, Error!,
MB_ICONEXCLAMATION | MB_OK);
return 0;
}
ShowWindow(hwnd, nCmdShow);
ShowWindow(hwnd4, nCmdShow);
UpdateWindow(hwnd);
UpdateWindow(hwnd4);
// Step 3: The Message Loop
while(GetMessage(Msg, NULL, 0, 0) 0)
{
TranslateMessage(Msg);
DispatchMessage(Msg);
}
return Msg.wParam;
}
Re: Wine malware story
Dan Kegel [EMAIL PROTECTED] wrote: http://www.thaibrother.com/blog/?p=1047 is a fairly thin article about malware in wine; it's worth mentioning only because it shows the issue is getting discussed more. As Wine gains functionality --- supporting Windows services, binary drivers, registry startup programs, etc --- it seems like it will be more vulnerable on this score. From my somewhat naive point of view regarding Windows malware, I would like to see Wine have the option of only running the app that I asked it to and not a bunch of other stuff that gets auto-loaded and run. An option like that could be billed as making Wine safer than Windows. I'm also really glad that my Wine-based product is moving away from running Wine as root! Cheers... mo
Re: Wine Kernel Handle Support Module
I know there is some discussion of what should be put in the kernel module, so I am asking for advice on what to implement... ie. just handles, everything wineserver does, etc. The first question is: Why do you want to do that and what specifically do you want to achieve? A small step towards less overhead in client - server calls? One _big_ vote for putting thread sync primitives --- events, semaphores, mutexes and critical sections --- in. We had to build a custom Wine to get acceptable realtime performance (thanks, Ulrich!). The client - server were causing high priority threads to block on low priority ones. I guess a test case would be something that shows how a high priority thread blocking on a sync primitive, while some low priority thread is doing some unrelated server heavy stuff, like lots of graphics updates. Cheers... mo
32bit winelib builds in x86_64
What's the command for building a 32bit winelib .dll.so and .exe.so with wineg++ in an x86_64 environment? I am used to doing dlls with: $ wineg++ -shared DLL.spec -o DLL.dll.so ... and exes with: $ wineg++ -o APP.exe.so ... Seems I need to use -m32 for g++, --32 for as, and -m elf_i386 for ld. But with all the nested calls of wineg++ and winebuild I can't figure out how to get those options passed in everywhere they are needed. Any hints? Cheers... Michael Ost
Re: wine-devel Digest, Vol 15, Issue 78
Michael Ost wrote: Message: 7 Date: Mon, 23 Oct 2006 14:51:34 +0200 From: Helmar Spangenberg [EMAIL PROTECTED] Subject: Starting a Linux application from a Windows application To: wine-devel@winehq.org Cc: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Hello list, we have a Windows application App1 which starts another application App2 using CreateProcessA, then doing some different work, and finally waiting for App2 to finish using WaitForSingleObject. It is important for App1 to catch the exit code of App2 as well as App2's messages on stdout. This works fine with Windows applications. Unfortunately, this does not work as soon as App2 is a Linux application; App1 seems to wait forever. Looking at the code of process.c and sync.c in kernel32, it seems to me that wine forgets everything about the Linux process once it is started. I had the same experience. It seems that you can't do a synchronous call of a linux process from a windows one. My solution was to create a DLL interface that implements a function called linux_command. On Windows it is stubbed out, but in Linux it a system() type call. App1 can link against it in Windows, but do nothing. When you link against it at runtime in Wine, you can do the linux command. Then I run an async bash command, capture the pid, and check for it later. This, after long hours of attempts and dead ends. App1 char out[1024]; linux_command(App2 echo $! /var/tmp/my.pid, out, sizeof(out)); linux_command(cat /var/tmp/my.pid, out, sizeof(out)); do your work char command[1024]; sprintf(command, test -e /proc/%s || echo finished, out); forever linux_command(command, out, sizeof(out)); if (strcmp(out, finished) == 0) break sleep If you are interested I can post the linux_command sources. - Michael Ost
setup_dos_mem error dutifully reported
As of wine-0.9.16 my winelib app now prints this message at startup: err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report Quick googling finds an old closed bug about this here: http://bugs.winehq.org/show_bug.cgi?id=2062 Is this important? Is there any more info I can provide? ... mo
Tooltips not on top in wxWidgets app
When I run my wxWidgets 2.6.3 app in Wine 0.9.11 the tooltips show up behind the main window instead of on top as they should. Before I start digging into this to figure out why, can anyone give me any tips on where in the code to start looking? I have been seeing this for a while --- with wxwidgets 2.6.2 and back to wine 0.9.2 --- so it's not a recent problem. I am also running FC4 with Gnome in case that matters. Thanks for any tips (ouch!)... mo === Michael Ost, Software Architect Muse Research, Inc. [EMAIL PROTECTED]
boost and winthreads
Does boost::threads + wine threads == happiness?
I would like to use boost threads in my winelib application, but they
need to coexist with threads created using the windows APIs by 3rd party
plugin DLLs. I built a test app that uses the two and they appear to
share both a CRITICAL_SECTION and a boost::mutex fine, so it looks like
I am in the clear. But I don't have alot of confidence in my
understanding of how Wine implements threads, so I thought it would be
wise to ask.
Attached is my test program. To build and run:
$ wineg++ -c boost-win.cpp
$ wineg++ -o boost-win.exe.so boost-win.o -lboost_threads
$ wine ./boost-win.exe.so
Cheers... mo
PS: thanks to whoever is responsible for wineg++. What a timesaver!
boost-win.cpp:
#include boost/thread.hpp
#include pthread.h// pthread_create
#include sys/resource.h // PRIO_PROCESS
#include stdio.h // printf
#include windows.h// CreateThread
#define INDENT
DWORD WINAPI CSTestA(void* arg)
{
CRITICAL_SECTION* cs = (CRITICAL_SECTION*) arg;
puts(in, try CS);
::EnterCriticalSection(cs);
puts(CS locked);
sleep(2);
puts(wake up);
::LeaveCriticalSection(cs);
puts(unlock);
sleep(1);
puts(wake up, try CS);
::EnterCriticalSection(cs);
puts(CS locked);
sleep(1);
puts(wake up);
::LeaveCriticalSection(cs);
puts(unlock);
puts(out);
}
struct CSTestB
{
CSTestB(CRITICAL_SECTION* cs) :
m_criticalSection(cs)
{
}
void operator()()
{
puts(INDENT in, try CS);
::EnterCriticalSection(m_criticalSection);
puts(INDENT CS locked);
boost::xtime t;
boost::xtime_get(t, boost::TIME_UTC);
t.sec += 3;
boost::thread::sleep(t);
puts(INDENTwake up);
::LeaveCriticalSection(m_criticalSection);
puts(INDENT unlocked, out);
boost::xtime_get(t, boost::TIME_UTC);
t.sec += 3;
boost::thread::sleep(t);
puts(INDENT out);
}
CRITICAL_SECTION* m_criticalSection;
};
struct MutexTestA
{
MutexTestA(boost::mutex* mutex) :
m_mutex(mutex)
{
}
void operator()()
{
puts(in - try mutex);
boost::xtime t;
{ // scope
boost::mutex::scoped_lock lock(*m_mutex);
puts(mutex locked);
boost::xtime_get(t, boost::TIME_UTC);
t.sec += 2;
boost::thread::sleep(t);
puts(wake up);
}
puts(unlock);
boost::xtime_get(t, boost::TIME_UTC);
t.sec += 1;
boost::thread::sleep(t);
puts(wake up, try mutex);
{ // scope
boost::mutex::scoped_lock lock(*m_mutex);
puts(mutex locked);
boost::xtime_get(t, boost::TIME_UTC);
t.sec += 1;
boost::thread::sleep(t);
puts(wake up);
}
puts(unlock);
puts(out);
}
boost::mutex* m_mutex;
};
DWORD WINAPI MutexTestB(void* arg)
{
boost::mutex* mutex = (boost::mutex*) arg;
puts(INDENT in - try mutex);
{ // scope
boost::mutex::scoped_lock lock(*mutex);
puts(INDENT mutex locked);
boost::xtime t;
boost::xtime_get(t, boost::TIME_UTC);
t.sec += 3;
boost::thread::sleep(t);
puts(INDENT wake up);
}
puts(INDENT unlock);
puts(INDENT out);
}
int main(int argc, char *argv[])
{
// boost blocks on CS held by winthread
if (argc 1 memcmp(argv[1], cs, 2) == 0) {
puts(Testing CRITICAL_SECTIONS...\n);
puts(winThread and boostThread share a CRITICAL_SECTION.
winThread grabs);
puts(it and sleeps, while boostThread waits for winThread
to wake
up and);
puts(release. Then vice-versa.);
puts();
puts(winThread boostThread);
puts(--);
CRITICAL_SECTION* criticalSection = new CRITICAL_SECTION();
::InitializeCriticalSection(criticalSection);
DWORD junk;
HANDLE winThread = ::CreateThread(NULL, 0, CSTestA,
criticalSection,
0, junk);
Winelib: SIGTERM or SIGQUIT?
I would like my Winelib application to do a normal shutdown from a signal, that is save files and exit normally. From scanning the web SIGTERM seems like the natural choice. It looks like it is _supposed_ to be used for a normal exit. But Wine seems to reserve SIGTERM for a summary execution with pthread_abort. It looks like I could use SIGQUIT, since Wine doesn't seem to care about it. But, again from scanning the web, SIGQUIT is _supposed_ to be used for non-normal exits. So, is it best to use SIGQUIT in a non-canonical way or try to change how SIGTERM is handled by Wine and make it more canonical? Or maybe my reading of the canon of signals is incorrect? Thanks for any help... mo PS: recently someone was asking a question about winelib and was directed to wine-user. What's the protocol here? Where should winelib questions be asked? The wine-user looks too user level and wine-devel is for Wine coders. I'd appreciate any help with the protocol of all this... === Michael Ost, Software Architect Muse Research, Inc. [EMAIL PROTECTED]
Re: Guitar Rig 2 in Linux/Wine
On Thu, 2006-02-23 at 09:30 -0500, Kuba Ober wrote: On Monday 20 February 2006 19:34, Michael Ost wrote: We are interested in getting the new Guitar Rig 2 USB foot controller supported in Linux/Wine. It's described here: http://www.native-instruments.com/index.php?id=guitarrig2_us I assume from looking at it, that a USB driver would be required and then perhaps some Wine tweaks to let the plugin open the USB driver. It'd be probably helpful to know more about the device itself. Does it expose snip Kuba, A guy from the linux-audio developers mailing list named Brian Sturk replied and is interested in doing the work. He should be fine with the linux driver side, but pointers in the Wine part of the project might be useful. For now, I am assuming that the work would be open source and integrated into linux and wine in the normal way. I believe the company will be cooperative. Would you care to be CCd on my exchanges with him, or rather just let this one go? I'm fine either way. Thanks for the reply... mo
Guitar Rig 2 in Linux/Wine
We are interested in getting the new Guitar Rig 2 USB foot controller supported in Linux/Wine. It's described here: http://www.native-instruments.com/index.php?id=guitarrig2_us I assume from looking at it, that a USB driver would be required and then perhaps some Wine tweaks to let the plugin open the USB driver. Anyone interested in taking this on? We are hoping to do this as a trade --- like you do this work and get a Receptor and/or some VST plugins for your time. BTW, we also have a job opening, posted here: http://www.craigslist.org/pen/sof/132110028.html Thanks ... mo === Michael Ost, Software Architect Muse Research, Inc. [EMAIL PROTECTED]
Re: Remove %1 from [http|htmlfile]\shell\open\command
While you're playing with wine's default registry, could you create a registry entry for https? It can be just the same as the http rule, e.g. HKEY_CLASSES_ROOT/https/shell/open/command = winebrowser %1 (or whatever the http rule ends up being. I have an app that assumes that entry exists and it exists in my windows XP registry, tho I am not sure who created it. Thanks... mo
Re: HW address w/o connection in iphlpapi
On Tue, 2006-01-24 at 21:44 -0800, Juan Lang wrote: Right. if_nameindex does not return eth0 if I boot up without an ethernet connection. Maybe this is a system dependent thing? I am running on a RH8 based system. Or a libc thing? I'm running on FC2. The if_nameindex code looked a little nicer, but a loop on if_indextoname() is not so bad. Although I don't like the idea of predefined limits :) I'll probably Me neither, which is why I used that prominent macro MOST_INTERFACES_IMAGINABLE. Can you even imagine a system with 50 (or 100?) ethernet interfaces? How about an application that needs more than 256K (showing my age with that one... %)? submit a patch based on if_nameindex in the meantime, hopefully tomorrow Well... that's not too thrilling since it doesn't actually fix the problem I found. Maybe we need to drill down into which systems if_nameindex works and doesn't work with and have alternate versions of enumerateInterfaces based on that. I have a FC4 system and I'll see how it behaves and let you know. ... mo
Re: HW address w/o connection in iphlpapi
On Wed, 2006-01-25 at 10:42 -0800, Juan Lang wrote: Although I don't like the idea of predefined limits :) I'll probably Me neither, which is why I used that prominent macro MOST_INTERFACES_IMAGINABLE. Can you even imagine a system with 50 (or 100?) ethernet interfaces? How about an application that needs more than 256K (showing my age with that one... %)? Yes, you're right, it is changeable, but it's less the number of interfaces than the value of the indexes. The interface implies that there will never be an interface with index 0, since if_nametoindex returns 0 to indicate no such interface, but what's to prevent interface indexes to be something other than 1, 2, 3, 4? They don't happen to be at the moment, but if some enterprising kernel guy decides to randomize them for some cute reason, this approach won't work. Agreed. I can't find any docs explaining what indexes are legal or their order. I guess the reality is that it isn't specified. The function does seem to be provided by libc. And so the diff must be in the implementations of that. Is there any precedent in Wine of making a runtime decision based on the c library? Would you be OK with a patch that uses if_indextoname() only in the special case of glibc-2.2.93 (I believe that's the RH8 libc), but if_nameindex() otherwise? - mo
Re: HW address w/o connection in iphlpapi
On Wed, 2006-01-25 at 11:13 -0800, Juan Lang wrote: I'm not the decider here, really. Alexandre is. While I'd like to see my recent patch get in because it removes a lot of unnecessary junk from ifenum.c and improves the situation for most people, it's not the end of the story. Wine's policy is to try to run on as many systems as possible, regardless of what system it was built on. From that perspective, using your approach is more correct. Assuming my patch from today gets in, feel free to improve on it. Got it. I have something that works for my product (rh8 based, wine 20050419). I'll keep an eye on this when we get around to upgrading. I think what makes most sense is to use if_nameindex() unless it is known not to work, using if_indextoname() only as a work around. Seems like this could be done with a config flag, given that the only time you'll see the problem is on a system with the old libc which means that the wine was also built against the old libc. So a compile time flag would do the trick. Does that sound right, or does it have to be detected at runtime? - mo
Re: Winelib debugging with eclipse in fc4
On Sat, 2006-01-07 at 18:04 +0100, Eric Pouech wrote: Michael Ost wrote: A while back I posted a question about how to get debugging working with eclipse in fedora 4. I am having some success, so if anyone else out there is interested here's how it is set up. you could (not tested) alternatively: - set winegdb --gdb as the name for executing gdb - not reset the AeDebug key - set the executable to be the real exec (+ .so extension if run from the build tree) that should work also Just tried this and eclipse says Exec error: Cannot run winedbg --gdb. winedbg --gdb MYAPP does launch from the command line, however. Any suggestions? BTW winedbg MYAPP ARGS works better. with the --gdb flag MYAPP doesn't terminate properly. But I'll get to that later. you would this way: - keep all the preloader stuff, so that your memory layout is better (and the same than when run from command line) - still be compatible with the segfault stuff Agreed, if I can get it to work! Thanks ... mo
Re: Winelib debugging with eclipse in fc4
On Tue, 2006-01-24 at 22:27 +0100, Eric Pouech wrote: Michael Ost wrote: BTW winedbg MYAPP ARGS works better. with the --gdb flag MYAPP doesn't terminate properly. But I'll get to that later. you mean (about MYAPP ARGS) when run in eclipse (that it does work to some extend, wheread MYAPP fails) ? No, that running winedbg MYAPP from the command line works. And that winedbg --gdb MYAPP from the command line doesn't terminate properly. I tried those as a way to confirm that what I am asking eclipse to do for debugging actually works from the command line. Cheers... mo
Re: HW address w/o connection in iphlpapi
Hi Michael,
When you boot a linux box without an ethernet connection, and eth0
configuration fails, GetAdaptersInfo does not return MAC address info
for eth0.
The problem seems to be that enumerateInterfaces (in
dlls/iphlpapi/ifenum.c) doesn't create a record for eth0, because
SIOCGIFCONF doesn't return one.
Mmm. Yeah, I think an alternative to SIOCGIFCONF might be the thing.
Wait. This works better than getifaddrs. It successfully returns info
for down devices on my RH8 based linux box, with my creaky old
wine-20050419. get_ifaddrs makes the same calls that you were, in its
implementation. So it has the same problem. But it's alot easier to
program with than the ioctl you used.
You made comments in the source about if_indextoname having issues. So
perhaps this patch won't be useful to you. But it works for us, so I'll
apply it to our wine sources unless/until something better comes along.
Have at it!
Cheers... mo
--- wine-20050419/dlls/iphlpapi/ifenum.c.20050419 2006-01-16
17:33:15.0 -0800
+++ wine-20050419/dlls/iphlpapi/ifenum.c2006-01-17 17:26:01.0
-0800
@@ -184,40 +184,6 @@
return map;
}
-static int isLoopbackInterface(int fd, const char *name)
-{
- int ret = 0;
-
- if (name) {
-struct ifreq ifr;
-
-lstrcpynA(ifr.ifr_name, name, IFNAMSIZ);
-if (ioctl(fd, SIOCGIFFLAGS, ifr) == 0)
- ret = ifr.ifr_flags IFF_LOOPBACK;
- }
- return ret;
-}
-
-static void countInterfaces(int fd, caddr_t buf, size_t len)
-{
- caddr_t ifPtr = buf;
- DWORD numNonLoopbackInterfaces = 0, numLoopbackInterfaces = 0;
-
- while (ifPtr ifPtr buf + len) {
-struct ifreq *ifr = (struct ifreq *)ifPtr;
-
-if (isLoopbackInterface(fd, ifr-ifr_name))
- numLoopbackInterfaces++;
-else
- numNonLoopbackInterfaces++;
-ifPtr += ifreq_len(ifr);
- }
- gNonLoopbackInterfaceMap = sizeMap(gNonLoopbackInterfaceMap,
- numNonLoopbackInterfaces);
- gLoopbackInterfaceMap = sizeMap(gLoopbackInterfaceMap,
- numLoopbackInterfaces);
-}
-
/* Stores the name in the given map, and increments the map's numInterfaces
* member if stored successfully. Will store in the same slot as previously if
* usedLastPass is set, otherwise will store in a new slot.
@@ -272,6 +238,104 @@
}
}
+#ifdef HAVE_NET_IF_H
+static int isLoopbackInterface(int fd, const char *name)
+{
+ int ret = 0;
+
+ if (name) {
+struct ifreq ifr;
+
+lstrcpynA(ifr.ifr_name, name, IFNAMSIZ);
+if (ioctl(fd, SIOCGIFFLAGS, ifr) == 0)
+ ret = ifr.ifr_flags IFF_LOOPBACK;
+ }
+ return ret;
+}
+
+static void enumerateInterfaces(void)
+{
+ int fd;
+ int nonLoopbacks;
+ int loopbacks;
+ struct if_nameindex* ifnames;
+ struct if_nameindex* ifn;
+
+ fd = socket(PF_INET, SOCK_DGRAM, 0);
+ if (fd != -1) {
+ifnames = if_nameindex();
+ if (ifnames) {
+ EnterCriticalSection(mapCS);
+
+ nonLoopbacks = 0;
+ loopbacks = 0;
+ for (ifn = ifnames; ifn-if_name != 0; ifn = ifn[1]) {
+ if (isLoopbackInterface(fd, ifn-if_name))
+ loopbacks++;
+else
+ nonLoopbacks++;
+ }
+
+ gNonLoopbackInterfaceMap = sizeMap(gNonLoopbackInterfaceMap,
+ nonLoopbacks);
+ gLoopbackInterfaceMap = sizeMap(gLoopbackInterfaceMap,
+ loopbacks);
+
+ markOldInterfaces(gNonLoopbackInterfaceMap);
+ markOldInterfaces(gLoopbackInterfaceMap);
+
+ /* add table entries for them them */
+ for (ifn = ifnames; ifn-if_name != 0; ifn = ifn[1]) {
+ if (isLoopbackInterface(fd, ifn-if_name))
+ storeInterfaceInMap(gLoopbackInterfaceMap, ifn-if_name);
+else
+ storeInterfaceInMap(gNonLoopbackInterfaceMap, ifn-if_name);
+ }
+
+ LeaveCriticalSection(mapCS);
+ if_freenameindex(ifnames);
+ }
+else
+ perror(iphlpapi/ifenum.c::if_nameindex());
+ }
+ else
+perror(iphlpapi/ifenum.c::socket());
+}
+#else // !HAVE_NET_IF_H
+static int isLoopbackInterface(int fd, const char *name)
+{
+ int ret = 0;
+
+ if (name) {
+struct ifreq ifr;
+
+lstrcpynA(ifr.ifr_name, name, IFNAMSIZ);
+if (ioctl(fd, SIOCGIFFLAGS, ifr) == 0)
+ ret = ifr.ifr_flags IFF_LOOPBACK;
+ }
+ return ret;
+}
+
+static void countInterfaces(int fd, caddr_t buf, size_t len)
+{
+ caddr_t ifPtr = buf;
+ DWORD numNonLoopbackInterfaces = 0, numLoopbackInterfaces = 0;
+
+ while (ifPtr ifPtr buf + len) {
+struct ifreq *ifr = (struct ifreq *)ifPtr;
+
+if (isLoopbackInterface(fd, ifr-ifr_name))
+ numLoopbackInterfaces++;
+else
+ numNonLoopbackInterfaces++;
+ifPtr += ifreq_len(ifr);
+ }
+ gNonLoopbackInterfaceMap = sizeMap(gNonLoopbackInterfaceMap,
+ numNonLoopbackInterfaces);
+ gLoopbackInterfaceMap = sizeMap(gLoopbackInterfaceMap,
+ numLoopbackInterfaces);
+}
+
static void classifyInterfaces(int fd, caddr_t buf, size_t len)
{
caddr_t ifPtr = buf;
@@ -335,6 +399,7 @@
close(fd);
}
}
+#endif
DWORD
Re: Winelib debugging with eclipse in fc4
On Sat, 2006-01-07 at 18:04 +0100, Eric Pouech wrote: you could (not tested) alternatively: - set winegdb --gdb as the name for executing gdb - not reset the AeDebug key - set the executable to be the real exec (+ .so extension if run from the build tree) that should work also you would this way: - keep all the preloader stuff, so that your memory layout is better (and the same than when run from command line) - still be compatible with the segfault stuff I'll try that and let you know what I find once my development tree gets usable again. It's pretty hacked up right now. Thanks ... mo
Winelib debugging with eclipse in fc4
A while back I posted a question about how to get debugging working with eclipse in fedora 4. I am having some success, so if anyone else out there is interested here's how it is set up. In regedit: * disabled auto winedbg by renaming AeDebug I changed HKEY_LOCAL_MACHINE/Software/Microsoft/Windows NT/Current Version/AeDebug to AeDebug-DISABLED. Without this gdb doesn't seem to be able to get a hold of SEGFAULTs. In eclipse's Run/Debug dialog box: * set the c/c++ application to WINE_SRC/loader/wine-pthread WINE_SRC points to a compiled version of wine. For me, I got the wine src rpm and ran rpmbuild -bb. This is where main() is, which eclipse looks for at start up. * put your .exe.so file on the Arguments tab * choose the GDB Debugger on the Debugger tab * add WINE_SRC on the Source tab as a Filesystem directory with subdirectories The only weirdness so far is that sometimes (not always) the debugger suspends when a new thread is created. I just resume (F8) past that. And I am not sure what impact bypassing wine-preload's exec-shield workaround will have on me. More on that if I learn more. But I gotta say that having a functioning IDE with integrated debugging on Linux is a major relief and, for me at least, a long time coming! ... mo PS: I installed FC4, and then did yum update. eclipse is version 3.1.1 updated from the eclipse UI from the version that came with FC4.
Unloading implicitly loaded DLLs
I am looking for some expert advice in how to handle unloading
implicitly loaded DLLs. I have found two issues.
(1) The first is a crash that happens in dlls/ntdll/loader.c
MODULE_FlushModrefs. wine_unload_dll() is called for such a DLL, but
SectionHandle is NULL so the call crashes.
My solution was to turn off the LDR_WINE_INTERNAL flag in
attach_implicitly_loaded_dlls() but I am not real clear what that flag
is or whether that approach is good. An alternative is to add a check
for a null SectionHeader before calling wine_unload_dll().
(2) Second is that these DLLs are DLL_PROCESS_DETACHED in
process_detach() every time _any_ DLL is unloaded. This happens because
the LoadCount is 0. I set it to -1 in attach_implicitly_loaded_dlls()
which does the trick. But again I don't know what the heck I am messing
with. Is that OK?
Attached is a diff of the two changes. I'm not looking for points for
style. But just a check on the approach for now. Thanks ... mo
--- loader.c.0_9_2 2006-01-02 13:40:27.0 -0800
+++ loader.c 2006-01-03 14:11:16.0 -0800
@@ -937,9 +937,15 @@
LDR_MODULE *mod = CONTAINING_RECORD(entry, LDR_MODULE, InLoadOrderModuleList);
if (mod-Flags (LDR_LOAD_IN_PROGRESS | LDR_PROCESS_ATTACHED)) continue;
+if (mod-Flags LDR_WINE_INTERNAL) // todo
+{
+ mod-Flags = ~LDR_WINE_INTERNAL;
+ TRACE(Turned off LDR_WINE_INTERNAL (%ld), mod-Flags);
+}
TRACE( found implicitly loaded %s, attaching to it\n,
debugstr_w(mod-BaseDllName.Buffer));
process_attach( CONTAINING_RECORD(mod, WINE_MODREF, ldr), reserved );
+mod-LoadCount = -1; /* exclude from the unload mechanism */
break; /* restart the search from the start */
}
if (entry == mark) break; /* nothing found */
Debugging winelib apps in Eclipse
Does anyone know how to set up Eclipse to debug winelib applications? I tried just replacing 'gdb' with 'winedbg' on the Debugger tab on the Debug window. After Eclipse says Launching... there is an error that says Process terminated. After reviewing the winelib debug docs, I found that there is a --gdb switch to winedbg so I added that as a C/C++ Program Argument on the Arguments tab of the same window... a long shot, and it didn't work. This is on Fedora Core 4, with Eclipse 3.1 (yum updated from the 3.1M6 version that comes with FC4), and with the wine 0.99.2 FC4 rpm. Any leads? Thanks ... mo
Re: Linking wine *dll.so libraries with Linux applications ?!
is it possible to link Win32 Wine libraries (*.dll.so) with a Linux
application. Suppose we have a simple Linux gcc program main.cc
#include vfw.h
int main(int argc, char** argv)
{
AVIFileInit();
}
which utilizes Win32 library features. When I try to compile it and
link I do not have any problems:
g++ -Wall -g main.cc -lavifil32 -o main
If I understand your question correctly you want to use wineg++ instead
of g++. We run linux apps that use Wine APIs all the time and that's the
key tool.
I can't give you specific commands that work because I am working in an
older vintage but you should be able to sort it out. wineg++ has a -v
option that is very useful for sorting out what's going on.
- mo
Re: Reality check
John Smith wrote: Before y'all take this too seriously, consider the email address and the name. John Smith at an anonymous hotmail account smells like a troll to me. From my point of view, Wine is a godsend and the amount of work going into it is fabulous. We at Muse Research depend on your work for our business and are greatly appreciative. Major congratulations on getting to the code freeze, by the way. Thanks to you all. Sure there are bugs to fix and maybe you have to fix them yourself or pay someone to do it. The alternative for John is clear: buy MS Windows. It works pretty well. - mo
Re: winelib .so change in 20050930?
On Fri, 2005-10-07 at 11:02, Alexandre Julliard wrote:
You shouldn't need to export them, you can still link to the library
directly at the Unix level, a Winelib dll is still an ELF library.
You are right, and using winegcc helped alot. I can link, but ... then
the program crashes when it runs. I attached a bash script that
demonstrates the problem. It builds two winelib apps: good and bad.
bad has the problem and won't run. good doesn't, and will.
It seems that winebuild --exe is not working correctly when linking if
there are no winelib DLLs with exports or perhaps it's still user
error %) ?
The winebuild step triggered by wineg++ is not generating
__wine_spec_init or __wine_dll_register entry points. These entry points
*are* made if there are exports in the shared library's spec file. The
entry points should be pulled in with libwinecrt0.a, since they are
defined there. But they are not and I can't figure out why.
The .exe.so file is created without complaints, but when you try to run
it it seg faults. The crash is related to the absent __wine_spec_init
entry point. I found where (in kernel/process.c) and will submit a patch
to make wine quit gracefully in such a case, by the way.
The 'nm' output of the two looks very similar except bad.exe.so:
* has no __wine_spec_init
* has no __wine_dll_register
* has undefined __wine_spec_init_ctor
* has undefined __wine_spec_init_state
I'm so close! Hopefully it's just some little missing param or
something. I am guessing that making Wine calls in a shared library
without exports is not common, but that's how our code works. I am
hoping that it's your intention that it work... or else I gotta spec out
hundreds and hundreds of mangled C++ function names!
- mo
set -x
cat EOF shared.cpp
#include windows.h
#include unistd.h
void show_window()
{
char bufr[128];
gethostname(bufr, sizeof(bufr));
strcat(bufr, says, 'Howdy World!');
::MessageBox(NULL, bufr, App, MB_OK);
}
EOF
wineg++ -c shared.cpp -o shared.o
cat EOF app.cpp
#include stdio.h
extern void show_window();
int main(int argc, char* argv[])
{
show_window();
return(0);
}
EOF
wineg++ -c app.cpp -o app.o
echo shared.spec
wineg++ -shared shared.spec shared.o -o libshared.dll.so
wineg++ -o bad.exe.so app.o -L`pwd` -lshared.dll
wineg++ -o bad bad.exe.so
echo '@ stdcall _Z11show_windowv()' shared.spec
wineg++ -shared shared.spec shared.o -o shared.dll.so
winebuild -w --def -o libshared.def --export shared.spec
wineg++ app.o -o good.exe.so -L`pwd` -lshared
wineg++ -o good good.exe.so
set +x
echo CRASHES: LD_LIBRARY_PATH=`pwd` ./bad
echo WORKS: ./good
Re: winelib .so change in 20050930?
On Wed, 2005-10-12 at 07:08, Alexandre Julliard wrote: The problem is that they resolve to the same symbols in the dll. Something like this should fix it: That did it! Thanks... mo
Re: winelib .so change in 20050930?
On Fri, 2005-10-07 at 11:02, Alexandre Julliard wrote:
Michael Ost [EMAIL PROTECTED] writes:
I started down this path with some success and then realized that, gulp,
I would have to create a spec file for my libraries. Hundreds of C++
functions in several libraries. If this is indeed required, is there any
help in building a spec file? Is it possible to export C++ functions as
opposed to straight C?
You shouldn't need to export them, you can still link to the library
directly at the Unix level, a Winelib dll is still an ELF library.
OK. That's right. But I'm still flailing trying to build my winelib app
with 20050930. Could you tell me what's missing from the steps below? Or
point me to some docs? This used to work in 20050419, except that I had
to compile the C output from winebuild. A million thanks. ... mo
* junk.cpp
#include stdio.h
#include windows.h
int main(int argc, char* argv[])
{
::MessageBox(NULL, Howdy World, Junk, MB_OK);
return(0);
}
* build steps
$ cc -I/usr/include/wine/windows -c junk.cpp -o junk.o
$ winebuild --exe -o junk.spec.o --filename junk.exe.so -L/usr/lib/wine junk.o
-luser32
$ g++ -shared -o junk.exe.so junk.o junk.spec.o
* run it
$ wine ./junk.exe.so
wine: could not load
LZ:\\home\\most\\cvs-muse\\sandbox\\mo\\junk\\junk.exe.so:
/home/most/.wine/dosdevices/z:/home/most/cvs-muse/sandbox/mo/junk/junk.exe.so:
undefined symbol: __wine_spec_init_ctor
CreateFile access/sharing problem
Vitaliy wrote on Oct 6: I think this is the way it might look like. It's a hack and not the real solution. I tested out your patch from Oct 6 on my CreateFile() ReadFile() test program and it worked. Just thought you might like to know... mo
winelib .so change in 20050930?
With the advent of 20050930 wine can no longer load the shared libraries used by my winelib app. Are there any docs or descriptions about how to deal with this change? I have an app that gets built into, say, ./app/app.exe.so. It uses a shared library, say ./lib/liblib.so, that uses win32 APIs. To build ./lib/liblib.so I just compiled and linked using gcc. To build app.exe.so I would use winebuild to scan the object files at ./app/*.o and ./lib/*.o. That created wrappers for all the win32 functions both in ./app and ./lib. The wrappers code from winebuild gets linked in to app.exe.so. Wine used to be able to deal with this. With 20050930 wine complains that the win32 references in liblib.so can't be resolved and quits. I am guessing that something about wine dll loading has changed, so that the function wrappers for a wine DLL have to be in the file itself. That is, I would have to run winebuild on the lib object files, create lib.dll.so and then link app.exe.so against that. I started down this path with some success and then realized that, gulp, I would have to create a spec file for my libraries. Hundreds of C++ functions in several libraries. If this is indeed required, is there any help in building a spec file? Is it possible to export C++ functions as opposed to straight C? Winelib has always been the wild and woolly frontier. We haven't been bitten in a while; I guess we were due! ... mo
Re: RH8 spec for 20050830
On Tue, 2005-10-04 at 04:38, Vincent Béron wrote: I posted the RH7.3 RH8 to sf.net. I intended to make them available once all distributions would be compiled/uploaded, but since there's demand for them, go to Thanks! That's a great help. ... mo
Re: CreateFile access/sharing problem
On Mon, 2005-10-03 at 21:08, Dmitry Timoshkov wrote:
Michael Ost [EMAIL PROTECTED] wrote:
My solution (polite term) was to force GENERIC_READ|GENERIC_WRITE
access in ntdll/NtCreateFile if the sharing type is FILE_SHARE_WRITE.
Most likely sharing mode has nothing to do with access rights. The problem is
that the app doesn't specify neither of GENERIC_ flags. But it does
specify
STANDARD_RIGHTS_ALL ==
(DELETE|READ_CONTROL|WRITE_DAC|WRITE_OWNER|SYNCHRONIZE).
It appears that Windows treats GENERIC_ rights as an addition to the
STANDARD_RIGHTS_xxx flags, and missing GENERIC_ rights are normally
ignored.
While I wait for a real solution, I need to hack wine 20050930 to get
this app running. I tweaked my patch based on your feedback (thanks!)
and included it below.
Does this patch look dangerous in any way to those of you who know your
way around this code? It's done in NtCreateFile after a bunch of
non-file types (like mail slots, etc) are handled.
--- wine-20050930/dlls/ntdll/file.c 2005-09-26 04:02:45.0 -0700
+++ wine-20050930.new/dlls/ntdll/file.c 2005-10-05 15:16:18.0 -0700
@@ -206,6 +206,14 @@
if (io-u.Status == STATUS_SUCCESS)
{
+ /* hack for Ivory Library Installer - force GENERIC_xxx access
on */
+ if ((access STANDARD_RIGHTS_ALL) == STANDARD_RIGHTS_ALL) {
+ if ((access (GENERIC_READ|GENERIC_WRITE)) == 0) {
+ FIXME(Forcing GENERIC_xxx access\n);
+ access |= (GENERIC_READ|GENERIC_WRITE);
+ }
+ }
+
SERVER_START_REQ( create_file )
{
req-access = access;
Thanks... mo
Re: CreateFile access/sharing problem
On Wed, 2005-10-05 at 20:05, Dmitry Timoshkov wrote: Michael Ost [EMAIL PROTECTED] wrote: Does this patch look dangerous in any way to those of you who know your way around this code? It's done in NtCreateFile after a bunch of non-file types (like mail slots, etc) are handled. While this patch may work for you it's certainly not correct. Access rights mapping should be performed by wineserver, see Rob's answer in this thread. Right. I understand. I just wanted to avoid doing an ugly hack that causes unexpected problems elsewhere. I am not strong enough with Wine to _really_ fix the problem, but I need to do something temporary. - mo
CreateFile access/sharing problem
Any suggestions for how to handle a difference in file access and
sharing handling between Wine (20050830) and WinXP? A program
demonstrating the problem is attached below.
A 3rd party installer program for a VST plugin is calling CreateFile
with dwDesiredAccess = 0x1f01ff and dwSharedMode = FILE_SHARE_WRITE. It
then calls ReadFile, which fails in Wine (error 5) but succeeds in
WinXP.
My solution (polite term) was to force GENERIC_READ|GENERIC_WRITE
access in ntdll/NtCreateFile if the sharing type is FILE_SHARE_WRITE.
I have not been able to figure out from the header files what named
constants the program used for dwDesiredAccess, so I hard coded it with
the values the program used in my example.
But I did notice that FILE_ALL_ACCESS is a different value in Wine and
my VC98 headers from DevStudio 6. In Wine it is:
(STANDARD_RIGHTS_REQUIRED|SYNCHRONIZE|0x1ff)
In VC98:
(STANDARD_RIGHTS_REQUIRED|SYNCHRONIZE|0x3ff)
Is this a Wine bug?
The access and sharing parameters to CreateFile are making me feel
stupid. I read and read and read the docs at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/createfile.asp
and still can't really figure out what they are supposed to do! I am
pretty sure that my hack wouldn't stand and would love to hear the right
way to fix this problem.
Thanks... mo
#include stdio.h // printf
#include windows.h
int main(int argc, char *argv[])
{
if (argc 2) {
puts(usage: wine file-access-test.exe.so PATH);
puts(Tests the access used by the Ivory Library Tools program
that doesn't work with wine.);
return(1);
}
HANDLE file = ::CreateFile(argv[1], 0x1f01ff, FILE_SHARE_WRITE, NULL,
OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
if (file != INVALID_HANDLE_VALUE) {
DWORD bytesRead;
char bufr[32];
// passes in winxp; fails (error 5) in wine
if (::ReadFile(file, bufr, sizeof(bufr), bytesRead, NULL))
printf(Read %ld bytes\n, bytesRead);
else
printf(ReadFile error: %d\n, ::GetLastError());
::CloseHandle(file);
}
else
printf(CreateFile error: %d\n, ::GetLastError());
return(0);
}
Re: CreateFile access/sharing problem
On Mon, 2005-10-03 at 12:14, Dan Kegel wrote: On 03 Oct 2005 11:20:16 -0700, Michael Ost [EMAIL PROTECTED] wrote: Any suggestions for how to handle a difference in file access and sharing handling between Wine (20050830) and WinXP? A program demonstrating the problem is attached below. Bless your soul. It ought to be pretty easy for someone to convert that little program from C++ into C and add it to the Wine test suite. (Would you consider doing that?) That will make life easier for whoever fixes the bug. Sure, but I don't know where the tests are. Somehow I haven't run across that yet. Can you point me? - mo
Re: RH8 spec for 20050830
On Mon, 2005-10-03 at 14:31, Bill Medland wrote: So what is the status of getting RedHat RPMS again? Are you having any luck, Michael? I am going to be needing RedHat RPMS for Wine very soon, for testing purposes. I'd be quite willing to help out but it would suit me best if you were to take the lead. I can provide you with a source RPM that works on my redhat 8-ish system. I don't have the machines to build bona fide rh8, rh9, etc binary RPMs but I'd be happy to post the source one. Is there a good spot? I based it on the spec file from Vincent, with a couple of mods to the patches for the new sources. There was some sort of change involving fonts that I didn't satisfactorily resolve. His spec includes wine-fonts-VERSION.tar.gz. I couldn't find that file via google, so I copied the 20050524 file over. I don't _think_ that's right, but I am not sure... Anyway it's all yours (or anyone else's) if you want it. - mo
RH8 spec for 20050830
Can someone who understands wine build issues review this RPM spec file
for me, please?
The RPMs for Redhat 8 are getting pretty long in the tooth on the Wine
downloads page... dating back to May 24. I wanted to build a source RPM
to work with, so I modified the 20050524 spec file for 20050830.
It seems that there are changes in fonts and documentation. I removed
some lines that were keeping rpmbuild from working. But I feel like I am
tampering with issues beyond my grasp. Do the attached changes to the
spec file look ok (temporarily marked with todo)? Any gotchas?
Anything missing?
Thanks... mo
--- wine-20050524-1rh8winehq.spec 2005-05-30 19:48:05.0 -0700
+++ wine-20050830-1rh8winehq.spec 2005-09-26 11:46:08.0 -0700
@@ -1,4 +1,4 @@
-%define DATE 20050524
+%define DATE 20050830
Summary: A Windows 16/32 bit emulator.
Name: wine
Version: %{DATE}
@@ -8,7 +8,7 @@
URL: http://www.winehq.org/
Source0:
ftp://metalab.unc.edu/pub/Linux/ALPHA/wine/development/Wine-%{version}.tar.gz
Source1: wine.init
-Source2: wine-fonts-%{version}.tar.gz
+# todo Source2: wine-fonts-%{version}.tar.gz
Patch0: wine-%{version}-stabs+2.patch
Patch1: wine-%{version}-nvidia-opengl.patch
Patch2: wine-%{version}-generated.patch
@@ -66,7 +66,7 @@
UPDATE_DESKTOP_DATABASE=/bin/true
mkdir -p $RPM_BUILD_ROOT%{_sysconfdir}/wine
-install -c -m 0644 documentation/samples/config
$RPM_BUILD_ROOT%{_sysconfdir}/wine/config
+# todo - install -c -m 0644 documentation/samples/config
$RPM_BUILD_ROOT%{_sysconfdir}/wine/config
cat RedHat EOF
Wine directory structure used in Red Hat Linux:
@@ -91,8 +91,8 @@
install -c -m 755 %SOURCE1 $RPM_BUILD_ROOT%{_initrddir}/wine
# Install Wine's fonts
-mkdir -p $RPM_BUILD_ROOT%{_datadir}/fonts/wine
-tar xzf %SOURCE2 -C $RPM_BUILD_ROOT%{_datadir}/fonts/wine
+# todo mkdir -p $RPM_BUILD_ROOT%{_datadir}/fonts/wine
+# todo tar xzf %SOURCE2 -C $RPM_BUILD_ROOT%{_datadir}/fonts/wine
%clean
rm -rf $RPM_BUILD_ROOT
@@ -154,12 +154,12 @@
%{_libdir}/wine/*.so
%{_mandir}/man1/wine.1*
%{_mandir}/man1/winedbg.1*
-%{_mandir}/man5/wine.conf.5*
+# todo %{_mandir}/man5/wine.conf.5*
%{_datadir}/aclocal/wine.m4
%{_datadir}/applications/wine.desktop
-%attr(0755, root, root) %dir %{_datadir}/fonts/wine
-%{_datadir}/fonts/wine/*.fon
-%{_datadir}/fonts/wine/*.ttf
+# todo %attr(0755, root, root) %dir %{_datadir}/fonts/wine
+# todo %{_datadir}/fonts/wine/*.fon
+# todo %{_datadir}/fonts/wine/*.ttf
%attr(0755, root, root) %dir %{_datadir}/wine
%{_datadir}/wine/generic.ppd
%{_datadir}/wine/wine.inf
@@ -196,6 +196,9 @@
%{_libdir}/wine/*.def
%changelog
+* Thu Sep 22 2005 Michael Ost [EMAIL PROTECTED] 20050830-1rh8winehq
+- Update to 20050830
+
* Mon May 30 2005 Vincent Béron [EMAIL PROTECTED] 20050524-1rh8
- Update to 20050524
- Remove pdf documentation build as it's no more included in the main archive
Re: IDE disk geometry
On Wed, 2005-09-21 at 00:57, Uwe Bonnes wrote: Our IOCTL handling is a mess. Seems like it has only been needed and implemented for CDs, so far. I had a patch that splitted out IOCTL code handling to separate, loadable dlls, but the patch went by unnoticed. Look for Mail from around July 10 Uniform SYS/VXD Handling x/6 In your case, when you did CreateFile(\\c:\), in file.c it would be noticed that a raw handle on the disk is needed and something like disk.sys would be loaded, where you would implement the needed IOCTL. That sounds great. I wonder why it didn't go through...? But that's a bit too much heavy lifting of the wine goblet for me to undertake! - mo
IDE disk geometry
Any suggestions for a good wineish way to implement an IOCTL_ call for
an IDE disk?
My winelib app is hosting a Windows DLL that is making an
IOCTL_DISK_DRIVE_GET_GEOMETRY call on an IDE hard disk. ntdll/file.c
NtDeviceIoControlFile is passing this off to ntdll/cdrom.c
CDROM_DeviceIoControl and, of course, since it is not a cdrom disk, that
fails.
I have some code that reads geometry information out of
/proc/ide/hd?/geometry that is working fine. But I am not sure how to
integrate it into ntdll.
Should I put my code in CDROM_DeviceIoControl? Or handle it in
NtDeviceIoControlFile? Should I pass all other IoControlCodes except
IOCTL_DISK_DRIVE_GET_GEOMETRY for a verifiable IDE drive on to the
CDROM_... function?
If anyone has a background in this code, you probably have an idea
straight off how best to fit it in.
Thanks for any help. Patch against wine-20050419 is attached for
illustrative purposes. ... mo
--- dlls/ntdll/file.c.20050419 2005-09-20 09:49:54.0 -0700
+++ dlls/ntdll/file.c 2005-09-20 17:10:17.0 -0700
@@ -790,6 +790,113 @@
return io_status-u.Status;
}
+/***
+ * FILE_IdeDeviceIoControlFile (INTERNAL)
+ *
+ * Handle device IO control for ide disks. Returns TRUE if
+ * DeviceHandle is an IDE disk, else FALSE.
+ */
+static BOOL FILE_IdeDeviceIoControlFile(HANDLE DeviceHandle, HANDLE hEvent,
+PIO_APC_ROUTINE UserApcRoutine,
+PVOID UserApcContext,
+PIO_STATUS_BLOCK IoStatusBlock,
+ULONG IoControlCode,
+PVOID InputBuffer,
+ULONG InputBufferSize,
+PVOID OutputBuffer,
+ULONG OutputBufferSize)
+{
+#if !linux
+ return FALSE;
+#else
+ BOOL releaseFd = FALSE;
+ BOOL isIde = FALSE;
+ NTSTATUS status = STATUS_SUCCESS;
+ DWORD sz = 0;
+
+ int fd;
+ FILE* file;
+ int length;
+ char linkPath[64];
+ char path[MAX_PATH];
+ char letter;
+ struct stat st;
+
+ if ((status = wine_server_handle_to_fd( DeviceHandle, 0, fd, NULL ))
!= STATUS_SUCCESS)
+ goto out;
+ releaseFd = TRUE;
+
+ // does the file descriptor point to an entry in /proc/ide?
+ // todo - isn't there a system call to get a name from a dev_t and
ino_t?
+ snprintf(linkPath, sizeof(linkPath), /proc/%d/fd/%d, getpid(), fd);
+ length = readlink(linkPath, path, sizeof(path));
+ if (length != -1)
+ path[length] = '\0';
+ else {
+ // bad proc format?
+ goto out;
+ }
+
+ // see if the device exists in /proc/ide
+puts(path); //todo
+ if (sscanf(path, /dev/hd%c, letter) != 1)
+ goto out;
+ snprintf(path, sizeof(path), /proc/ide/hd%c, letter);
+ if (stat(path, st) == -1)
+ goto out;
+ isIde = TRUE;
+
+IoStatusBlock-Information = 0;
+ switch (IoControlCode)
+ {
+ case IOCTL_DISK_GET_DRIVE_GEOMETRY:
+ strcat(path, /geometry);
+
+ if (OutputBuffer == 0)
+ IoStatusBlock-u.Status = STATUS_INVALID_PARAMETER;
+ else if (OutputBufferSize sizeof(DISK_GEOMETRY))
+ IoStatusBlock-u.Status = STATUS_BUFFER_TOO_SMALL;
+ else if ((file = fopen(path, r)) != 0) {
+ int cylinders, heads, sectors;
+ if (fscanf(file, physical %d/%d/%d, cylinders,
heads, sectors) == 3) {
+ DISK_GEOMETRY* geometry = (DISK_GEOMETRY*)
OutputBuffer;
+ geometry-Cylinders.QuadPart = cylinders;
+ geometry-MediaType = FixedMedia;
+ geometry-TracksPerCylinder = heads;
+ geometry-SectorsPerTrack = sectors;
+ // todo - is this always 512, or where is it?
+ geometry-BytesPerSector = 512;
+
+ sz = sizeof(DISK_GEOMETRY);
+ IoStatusBlock-u.Status = STATUS_SUCCESS;
+ }
+ else // unknown proc format
+ IoStatusBlock-u.Status =
STATUS_INVALID_PARAMETER;
+
+ fclose(file);
+ }
+ else // unknown proc format
+ IoStatusBlock-u.Status = STATUS_INVALID_PARAMETER;
+ break;
+
+default:
+FIXME(Unsupported IOCTL %lx (type=%lx access=%lx func=%lx
meth=%lx)\n,
+ IoControlCode, IoControlCode 16, (IoControlCode 14) 3,
+ (IoControlCode 2)
Re: IDE disk geometry
On Tue, 2005-09-20 at 18:22, Vitaliy Margolen wrote: Tuesday, September 20, 2005, 6:11:49 PM, Michael Ost wrote: Should I put my code in CDROM_DeviceIoControl? Or handle it in NtDeviceIoControlFile? Should I pass all other IoControlCodes except IOCTL_DISK_DRIVE_GET_GEOMETRY for a verifiable IDE drive on to the CDROM_... function? I don't it make any sense to create the whole new file to parse just one IOCTL. So you might just add it to the cdrom.c I think that might get accepted. I don't think it was clear that the device in question is not a CDROM, but a hard disk. Are IDE hard disks supposed to be lumped in with CDROMs in the code? But before you go too far, pleas look at kernel/oldconfig.c. It does some parsing of /proc already. So all you need to do is to find where this information is stored on windows (it has to be somewhere in registry) and add to that. Then you don't need to parse /proc all the time but just read info from the registry. One possible option would be to use IOCTL_SCSI_GET_INQUIRY_DATA to OK. That's a good idea, except that in the Wine version my company is using there is no oldconfig.c. So for our version I guess I would patch dlls/ntdll/cdrom.c by reading out of proc directly. But I would submit a version that stores disk geometry in the registry. I'll look in to that. Thanks for the feedback... mo
Anyone working on implementing AccessCheck?
We have an installer program (for the Native Instruments Komplete VST plugin package) that fails to run because NtAccessCheck is stubbed out --- that's our best guess at this point, anyway, from watching the WINEDBG trace while the program ran. I noticed that in the last few months someone implemented GetFileSecurity that the installer uses as well --- it looks like Troy Rollo? from scanning the cvs archives. Thanks for that. But NtAccessCheck is still stubbed out. Is that call at all related? any work underway? any suggestions on direction for implementing it? And, how seriously should I take the FIXME(returns fake SECURITY_DESCRIPTOR) in GetFileSecurity. Thanks... mo === Michael Ost, Software Architect Muse Research, Inc. [EMAIL PROTECTED]
Re: Anyone working on implementing AccessCheck?
On Wed, 2005-04-27 at 10:30, Robert Shearman wrote: Michael Ost wrote: We have an installer program (for the Native Instruments Komplete VST plugin package) that fails to run because NtAccessCheck is stubbed out --- that's our best guess at this point, anyway, from watching the WINEDBG trace while the program ran. I noticed that in the last few months someone implemented GetFileSecurity that the installer uses as well --- it looks like Troy Rollo? from scanning the cvs archives. Thanks for that. But NtAccessCheck is still stubbed out. Is that call at all related? any work underway? any suggestions on direction for implementing it? Yes. I have an implementation at the moment, but it depends on token objects storing more information than they do at the moment and it is completely untested. However, I can send a patch to you to test if you want. Yes. We'd be happy to try it out and tweak if necessary. Thanks... mo
Re: TlsAlloc limitation in winxp mode
On Fri, 2005-03-18 at 03:30, Alexandre Julliard wrote: Michael Ost [EMAIL PROTECTED] writes: With the emulation mode set to winxp I can only TlsAlloc 64 indexes, even though the MSDN docs say there should be at least 20 million. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/thread_local_storage.asp Has anyone done any work on this? Any workaround/hackarounds? ... mo It's not 20 million, it's 1088 (64 + 1024). You need to use the TLS expansion slots for the extra 1024, something like this (completely untested): snip patch Thanks. I suspected that was the way to go. Should the TlsAlloc code, or perhaps the thread init code, check on the windows emulation version and allow the right number of slots... 64, 80 or 1088? - mo === Michael Ost, Software Architect Muse Research, Inc. [EMAIL PROTECTED]
Re: Problems with VirtualAlloc/Lock
On Wed, 2005-03-16 at 00:32, Alexandre Julliard wrote: Michael Ost [EMAIL PROTECTED] writes: Wine reports that apps have 2GB of VM in GlobalMemoryStatus, but they actually only have 1GB. Isn't that a Wine bug? Not really, you do have 2GB of VM, you just can't allocate all of it with VirtualAlloc(NULL) because of kernel limitations. You can still access it by specifying explicit addresses. Here's a suggestion. Certainly naive, but would it work? The idea is to trap mmap allocations which go above user_space_limit and retry them in the space below 0x4000,. Something like this in lib/wine/mmap.c wine_anon_map() - replace: return mmap(start, size, prot, flags, fdzero, 0); with void* addr = mmap(start, size, prot, flags, fdzero, 0); /* disallow allocations above the windows limit */ /* OR can you to find this out without mmap()ing first? */ if addr + size user_space_limit) munmap(addr) addr = 0; /* look below linux's 0x4000 address if a specific */ /* address wasn't requested */ if start == 0 and addr == 0 /* 0x0800 is the start of the TEXT segment - */ /* start looking there */ addr = mmap(0x0800, size, prot, MAP_PRIVATE | MAP_ANON, -1, 0); return addr; This should start allocating memory from below 0x4000, to windows processes after the area between 0x4000, to 0x8000, is full, right? From way out of my depth %) ... mo PS: my company is very interested in getting this fixed. I might be able to shake some money loose for the development.
Re: Problems with VirtualAlloc/Lock
On Tue, 2005-03-15 at 01:09, Alexandre Julliard wrote:
Michael Ost [EMAIL PROTECTED] writes:
will stop at 1,022,976k (1GB) on any wine machine. In winxp it goes up
to 2GB, as it ought to.
That's a kernel limitation. If you hack the kernel to start allocating
from lower addresses (or implement the syscall we discussed to let us
specify the mmap range) you can get the full 2GB.
Could you point me to the kernel limitation? I can mmap() 2GB on an
unhacked 2.4.19 kernel with this loop:
int total = 0;
for (;;) {
void* leak = mmap(0, 1048576, PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANON, -1, 0);
if (leak) {
total += 1048576/1024;
printf(Allocated %ldk\r, total);
}
else {
printf(\n);
perror(mmap);
break;
}
}
- mo
PS: When building this loop, I tried to copy the behavior of
wine_anon_mmap from libs/wine/mmap.c. But frankly I am new to mmap() and
wine memory management. So maybe I am missing something...?
Re: Problems with VirtualAlloc/Lock
On Tue, 2005-03-15 at 11:12, Alexandre Julliard wrote: Michael Ost [EMAIL PROTECTED] writes: On Tue, 2005-03-15 at 01:09, Alexandre Julliard wrote: That's a kernel limitation. If you hack the kernel to start allocating from lower addresses (or implement the syscall we discussed to let us specify the mmap range) you can get the full 2GB. Could you point me to the kernel limitation? I can mmap() 2GB on an unhacked 2.4.19 kernel with this loop: That's because you can mmap above 0x800, but that's not allowed under Windows. You'll note that on a standard kernel you can only mmap 2GB even though you have a 3GB address space. If you set the large address flag when building your application you will get a 3GB address space on Wine too, which will then let you allocate 2GB; but the resulting high addresses may break your plugins. The real problem is that the kernel starts allocations at 0x4000. What's involved in doing such a hack/syscall? Are there any patches that make this change lying around somewhere that I could look at? Wine reports that apps have 2GB of VM in GlobalMemoryStatus, but they actually only have 1GB. Isn't that a Wine bug? To summarize and make sure I understand: the problem is that Linux and Windows allocate VM from different address ranges. While both can alloc 2GB, the intersection of addresses is only 1GB --- between 0x4000 and 0x8000. On Windows (based on the MSDN docs) VM is allocated from 0x0010 to 0x8000. On Linux (unhacked 2.4 kernel), mmap runs from 0x4000 to 0xC000. Thanks... mo
Re: flexible-mmap breaks application
On Tue, 2005-03-15 at 15:55, Uwe Bonnes (bon_at_elektron.ikp.physik.tu-darmstadt.de) wrote: The definition of the task is clear: Have a way to tell the kernel to not mmap memory above 0x7fff However the implementation is unclear to me: - Should this be a new syscall? - Or should we set some kernel parameter? Per task or global? There is a related problem in that Wine's VirtualAlloc won't allocate the full 2GB it should. As I understand it the problem is the different memory ranges that linux and windows allocate from --- the intersection of the two platforms is only 1GB (not the 2GB it should be) from 0x4000, to 0x8000,. Could this patch also include a lower limit, letting linux mmap from addresses in the same range that win32 does? - mo PS: the thread on this issue starts at http://www.winehq.com/hypermail/wine-devel/2005/03/0643.html. It also covers the issue of Wine's lack of mlock/munlock functionality.
Problems with VirtualAlloc/Lock
There are major differences in the handling of virtual memory in Wine vs
WinXP that are causing problems for my winelib application. Can someone
provide background and/or workarounds for these issues?
As near as I can tell the main differences are:
* VirtualLock does nothing in Wine
* Wine makes no distinction between MEM_RESERVE and MEM_COMMIT
* Wine has no implementation of Windows' process working sets
* Wine limits MEM_RESERVE to 1GB, but WinXP goes up to 2GB
The above problems seem relatively harmless on systems with 1GB RAM.
But when our units go greater than 1GB we are seeing spectacular
crash-and-burn failures. The code-only DLLs we are running on such
systems are crashing at a stage when I suspect they are attempting to
lock RAM.
I suspect that they are confused by the report from GlobalMemoryStatus
that more than 1GB of RAM is installed, but that they are only able to
VirtualLock up to 1GB. And in this unexpected situation, they are
crashing.
Further, these DLLs are audio processing plugins. The apparent fact that
VirtualLock doesn't _actually_ lock memory into RAM for real time
processing is a disaster for our system, in that it causes audio
glitches when a page fault is handled. But that is not a problem which
crashes the system.
Any suggestions on what to do? Is there any pending work on this area
out there?
I've attached a little table that describes what I found. It shows the
differences in how Wine and WinXP handle memory related calls. I have
also attached a simple program which can be run to see these
differences.
Thanks for any help... mo
Memory Function Differences Between Wine and WinXP
All sizes are in Kbytes
CALLWINXP
WINE
=
1. VirtualAlloc(MEM_RESERVE)2,096,912
1,020,976
2. VirtualAlloc(MEM_COMMIT) 1,011,712 (3)
1,020,976
3. VirtualAlloc(MEM_COMMIT) 1,024 (1)
1,020,976
+VirtualLock()
4. VirtualAlloc(MEM_COMMIT) 259,072
1,020,976 (2)
+SetProcessWorkingSetSize(260,000)
+VirtualLock()
5. GlobalMemoryStatus
RAM
392,688 386,324
Page
942,820 522,072
Virtual
2,097,024 2,097,024
6. GetProcessWorkingSetSize() hi/lo 1,380/200 32,768/32,768
(2)
tests:
1. calling VirtualAlloc with MEM_RESERVE 1MB at a time until it fails.
This
is reserving virtual space only. Without the /3GB switch windows memory
is
limited to 2GB. So each app should be able to reserve its 2GB of space.
call: drink-memory.exe.so -reserve-only -no-lock
2. VirtualAlloc(MEM_COMMIT) 1MB at at time until it fails. On WinXP
this
seems to be bounded by how big the paging file is. In Wine...? dunno.
call: drink-memory.exe.so -no-lock
3. VirtualAlloc(MEM_COMMIT) + VirtualLock() 1MB at at time until it
fails.
On WinXP this craps out right away because the working set is very
small,
1.3M (see line 6)
call: drink-memory.exe.so
4. Same as 2. but with SetProcessWorkingSetSize(260,000). That was the
largest value WinXP allowed me to set the working set size to. WinXP
let me lock down RAM up to its limit, as expected. Wine, again, isn't
doing anything special
call: drink-memory.exe.so -lock-limit=26
5. 6. For reference the memory status reported WinXP and Wine
notes:
(1) VirtualLock fails - 1453 Insufficient quota
(2) FIXME: stub
(3) VirtualAlloc fails - 1455 Paging file is too small
#if _MFC
#include stdafx.h
#else
#include stdio.h // printf
#include wine/windows/windows.h
#endif
// process command line options
const char* CheckOption(const char* check, const char* match);
// like perror() for Windows
void PrintLastError(const char* msg);
int main(int argc, char *argv[])
{
bool usage = false;
bool forever = false;
bool noLock = false;
bool reserve = false;
int chunk = 1048576;
int lockLimit = -1;
for (int arg = 1; !usage arg argc; arg++) {
const char* result;
if ((result = CheckOption(argv[arg], -chunk=)) != 0)
chunk = atoi(result) * 1024;
else if (CheckOption(argv[arg], -forever))
forever = true;
else if (CheckOption(argv[arg], -help))
usage = true;
else if ((result = CheckOption(argv[arg], -lock-limit=)) != 0)
lockLimit = atoi(result);
else if (CheckOption(argv[arg], -no-lock))
noLock = true;
else if (CheckOption(argv[arg], -reserve-only))
reserve = true;
else
usage = true;
}
if (usage) {
Re: Problems with VirtualAlloc/Lock
On Mon, 2005-03-14 at 13:16, Raphael wrote: seems we have a bug report about that problem (behavior differences) http://bugs.winehq.org/show_bug.cgi?id=890 I guess I am adding VirtualLock and VirtualAlloc to the list of APIs that don't work the same in Wine vs Windows. Bug #890 is about VirtualQuery and seems to have been patched/fixed...? The diff is that the issues I raise aren't bugs, but behaviors that just haven't been implemented like actually locking virtual memory, and using the win32 working sets. That bug dates back to 2002! Oh, no. I guess this must be a low priority issue for Wine. Bad news for me. ... mo PS: thanks for the hint about the bug db, tho. I didn't think to check there! Ooops... %)
Re: Problems with VirtualAlloc/Lock
On Mon, 2005-03-14 at 20:13, you wrote:
* VirtualLock does nothing in Wine
VirtualLock does nothing in win95,98,ME as well :)
I bet the correct behaviour for wine is to do anything in VirtualLock
only if you set windows version to NT/2000/XP. Did you do it?
Good point. But the setting is winxp. I played with the setting and it
doesn't change the behavior.
Anyway, mlock() seems to work fine, so this should be implementable.
That would be the natural call to use. The absence of mlock in the wine
source tree was one of my early clues that there was a problem! %)
* Wine makes no distinction between MEM_RESERVE and MEM_COMMIT
Assuming that we're talking about VirtualAlloc().
Yes, but I wasn't specific enough. VirtualAlloc(MEM_RESERVE) and
MEM_COMMIT are handled differently in the code. I don't understand the
code, the design, or Linux mmap() sufficiently to say if they work
correctly or not. They both end up calling mmap() which looks right.
What I was trying to say is that in winxp MEM_RESERVE and MEM_COMMIT
will VirtualAlloc() and/or VirtualLock very different amounts of memory
than wine, even on the same (dual booting) machine.
Here were my results when I tried to see how much winxp and wine would
allocate and lock. The machine has 368M of RAM on it and a ~1GB paging
file in Windows.
winxp:
1. VirtualAlloc(MEM_RESERVE) - 2,086,912k
2. SetProcessWorkingSetSize(260,000k) + VirtualAlloc(MEM_COMMIT) +
VirtualLock() - 259,072k
3. VirtualAlloc(MEM_COMMIT) - 1,011,712k
wine:
1. VirtualAlloc(MEM_RESERVE) - 1,020,928k
2. SetProcessWorkingSetSize(260,000k) + VirtualAlloc(MEM_COMMIT) +
VirtualLock() - 1,020,928k
3. VirtualAlloc(MEM_COMMIT) - 1,020,928k
What I meant by makes no distinction is that wine always lets you
MEM_RESERVE or MEM_COMMIT 1,020,928k no matter what.
In winxp,
* VirtualAlloc(MEM_COMMIT) seems bounded by the size of the paging file
* VirtualAlloc(MEM_RESERVE) seems just to be 2GB
* VirtualLock() is bounded by GetProcessWorkingSet
* GetProcessWorkingSet is bounded by how much RAM you have
* Wine has no implementation of Windows' process working sets
Linux doesn't either. At least I don't know of a documented API that
could
reliably implement semantics of Windows working sets. Maybe it could be
implemented on other OSes like some BSDs if they have such APIs. Maybe
there's something in /proc/sys/vm or somesuch to tweak those, but then
it
would probably be system-wide. I'm no expert here I'm afraid :(
I was wondering about getrtlimit/setrlimit. The upper bound of the
working set size seems to map well to RLIMIT_MEMLOCK. However I can't
see what the parallel would be for the lower bound.
Also RLIMIT_AS could be the limit for how much memory you can
MEM_RESERVE.
These are process based values. They are available in Linux. Not sure
about other platforms.
* Wine limits MEM_RESERVE to 1GB, but WinXP goes up to 2GB
Wine? Maybe linux, but I doubt wine would do anything like that.
Yep, it does. Give it a try. As far as I can tell:
int total = 0;
for (;;) {
LPVOID* leak = ::VirtualAlloc(NULL, 1048576,
MEM_RESERVE, PROT_NOACCESS);
if (leak) {
total += 1048576/1024;
printf(Allocated %ldk\r, total);
}
else {
printf(\n);
PrintWindowsError(VirtualAlloc, ::GetLastError();
break;
}
}
will stop at 1,022,976k (1GB) on any wine machine. In winxp it goes up
to 2GB, as it ought to.
Further, these DLLs are audio processing plugins. The apparent fact
that
VirtualLock doesn't _actually_ lock memory into RAM for real time
I didn't look into the code, but anyway a prerequisite for it would be
to set
windows version to NT/2000/XP. Or at least wine should behave like that,
assuming that MSDN doesn't lie here.
Apart from that, I bet you didn't raise ulimits for your processes. On
my FC3
system, ulimit -l gives a meager 32 pages. So that's how many mlock()
could
lock anyway.
There's not a problem there. My ulimit -l is unlimited.
BTW we are using an old kernel which required a hack to mlock to allow
us to lock more than half the ram (regardless of the ulimit), but that
doesn't change any of this behavior.
Thanks for your feedback... mo
Re: Can winedbg --auto backtrace all threads?
On Fri, 2005-01-28 at 12:13, Eric Pouech wrote: Michael Ost a crit : In order to help track down sporadic runtime crashes in our testing process, I have turned on winedbg --auto when wine handles exceptions via the AeDebug registry entry. don't use the --auto flag and use the 'bt all' command at the prompt A+ Well, that won't work for us. We need --auto. There isn't a console or prompt in this setup. The program is auto-started by X. So I guess I could look through the 'bt all' code and do something similar in response to, say, --auto-all on the command line...? - mo
Re: Can winedbg --auto backtrace all threads?
On Fri, 2005-01-28 at 12:58, Eric Pouech wrote: IMO, the cleanest way would be to add an option (like the --command in gdb) which would execute commands out of a file (almost everything is in place, you just need to pass the name of the file in the call to parser() in winedbg.c). Then, set up the aedebug registry to something where you execute the proper commands for your specific settings OK. I'll take a look at it. So to mirror --auto's output, but include a backtrace of all threads, my debugger commands file would be: info reg info stack info share bt all quit Is that right? ... mo PS: thanks for that 'bt all' command. It's not in the winedbg man page and will save me a lot of typing when I use winedbg in the future.
Can winedbg --auto backtrace all threads?
Is there a way to have winedbg --auto do a backtrace of all the threads in an app at exception time? In order to help track down sporadic runtime crashes in our testing process, I have turned on winedbg --auto when wine handles exceptions via the AeDebug registry entry. This is working pretty well except that often winedbg does a backtrace on a thread that I know is not the problem. If I could see a backtrace of all the threads --- lots of data, I know --- the tool might be more useful. Is this already possible? How about advisable %) ? Or must I patch winedbg to do it? Sometimes winedbg appears to hang when handling the exception, or at least doesn't print out any information. When could this happen? Is there something I could do to improve winedbg's chances of working? Cheers... mo PS: our system is using wine-20040914
Re: PerformanceCounterFrequency fix
On Tue, 2005-01-25 at 23:58, Rein Klazes wrote: On 25 Jan 2005 14:22:40 -0800, you wrote: I'm quite certain that many programs use that function for extremely time critical code (games, anyone??), and that thus the Windows function is equally highly optimized, certainly much less slow than a gettimeofday() call. This should remain based on rdtsc IMHO, or on equally suitable and fast methods (ACPI counter, ...). Or did you actually test it with programs calling it a large number of times, or test its performance behaviour on Windows? Andreas Mohr Our system uses the performance counter all the time in extremely time critical code. If the call is anything more than a few cycles with absolutely no chance of blocking, we are hosed! The application is an embedded audio plugin player. The audio is processed with SCHED_FIFO and needs to be as deterministic and fast as possible. I hope this fix/change doesn't jeopardize our product's use of Wine... You are of course in an excellent position to quantify better then extremely time critical and few cycles. Just try the patch and tell us when you are hosed. I have done a few further tests. A loop like: for(i=0;i1000;i++) QueryPerformanceCounter( count); takes under Windows 2k, on some hardware 45 seconds. Under Wine on the exact same hardware it takes (with the patch) 13 seconds. OK. Sorry. My ebullience has once again resulted in poor mailing list style! Not the first time. I'll turn on serious careful engineer mode. Let's see how I do... %) My concern isn't the number of cycles. It sounds like the function runs very quickly, even faster than in Windows. That's great news. But I am concerned about blocking or preemption. I assume that the new call doesn't hit the wineserver, right? Is there any other thread sync required (critical sections, etc) for gettimeofday() which might cause the new implementation to block? I don't know how it is implemented, but it sounds like a system call which makes me suspicious. I know that Windows developers class QueryPerformanceCounter as a system call that's safe to use in real time so that's why I am trying to keep tabs on it. We don't have control over what APIs our hosted audio plugins use. They are written by other developers, and given to us in binary form. So we have to keep a close eye on APIs that plugins commonly use during real time processing. Sometimes plugins make calls they shouldn't from a r/t priority thread --- like InvalidateRect. I guess in Windows such calls work without blocking almost all the time. But that isn't the case in Wine. The Wine Semaphore implementation has caused us problems as well. They are much more likely to block in Wine than in Windows. One plugin used it where it shouldn't and its audio processing execution time went completely erratic as it blocked on the wineserver. Anyway, thanks for your attention to this issue. It sounds like Receptor (our product) will be fine with this change. ... mo
Re: PerformanceCounterFrequency fix
On Tue, 2005-01-25 at 14:05, [EMAIL PROTECTED] wrote: Message: 1 Date: Tue, 25 Jan 2005 19:30:04 +0100 From: Andreas Mohr [EMAIL PROTECTED] To: Rein Klazes [EMAIL PROTECTED] Cc: Lionel Ulmer [EMAIL PROTECTED], [EMAIL PROTECTED], wine-devel@winehq.org Subject: Re: PerformanceCounterFrequency fix. Hi, On Tue, Jan 25, 2005 at 06:44:04PM +0100, Rein Klazes wrote: On Mon, 24 Jan 2005 15:08:56 +0100, you wrote: How bad is it to use the gettimeofday() method? In my opinion, the RTDSC method should be suppressed from the code and we should always use the 'gettimeofday' method (despite the penalty hit of a syscall). I was more concerned about the accuracy of gettimeofday (not incrementing in usec's). So I did a small test and I find it behaves very nicely. That was the only reason I could see to justify the rdtsc method, so here it goes. As the cpuHz variable is not used anymore, we might as well move it to ntdll. (sorry for not replying earlier - no time :-\) I'm not sure why you'd want to base it on gettimeofday(). This is a terrible idea IMHO. I'm quite certain that many programs use that function for extremely time critical code (games, anyone??), and that thus the Windows function is equally highly optimized, certainly much less slow than a gettimeofday() call. This should remain based on rdtsc IMHO, or on equally suitable and fast methods (ACPI counter, ...). Or did you actually test it with programs calling it a large number of times, or test its performance behaviour on Windows? Andreas Mohr Our system uses the performance counter all the time in extremely time critical code. If the call is anything more than a few cycles with absolutely no chance of blocking, we are hosed! The application is an embedded audio plugin player. The audio is processed with SCHED_FIFO and needs to be as deterministic and fast as possible. I hope this fix/change doesn't jeopardize our product's use of Wine... mo === Michael Ost, Software Architect Muse Research, Inc. [EMAIL PROTECTED]
Re: No RichEdit20A window class
On Fri, 2004-11-19 at 03:22, Mike McCormack wrote: Michael Ost wrote: (1) The wine bug (I think) is that riched32.dll is registering the wrong window class name. Here's a suggested patch: RICHEDIT_CLASS20A is provided by riched20.dll, not riched32.dll. The windows 2000 implementation uses riched20.dll to implement riched32.dll (ie. moves the richedit code to riched20.dll and implements the RICHEDIT_CLASS10A class using the new RICHEDIT_CLASS20A class. In short, the existing code registers the correct class name, but we need to make a new dll dlls/riched20, and do alot of work on the richedit control :) This isn't quite clear to me. It sounds like you are saying there is a riched20.dll in wine, but I can't find one. Are these statements correct? * Wine's only implements RichEdit10A via riched32.dll. Wine does not implement RichEdit20A. * Win2K (and later) provides riched20.dll which implements RICHEDIT_CLASS20A. This one I can verify as true on my winxp system. * There are significant differences between the two window classes My winelib app is hosting a 3rd party DLL which is specifically requesting RichEdit20A. That suggests that the DLL was built with win2K or later, from what you were saying. Sounds like my options are to: * hack their request to use the window class registered by wine's riched32.dll. How well could I expect this to work? How big are the diffs between 10A and 20A? * get them to provide win2k's riched20.dll * have them change their DLL to ask for RichEdit10A instead * implement riched20.dll in Wine. Sounds like a big job! Sound right? Any comments? Thanks a bunch... mo
No RichEdit20A window class
Hi.
My winelib application can't create a window of class RichEdit20A. It
looks like the class is not being registered, because the DLL is not
being loaded. Any clues why this might be?
Turning on trace+richedit shows that dlls/richedit/richedit.c's
RICHED32_Register and DllMain are not being called
My test app tries to create a RICHEDIT_CLASS window and then it tries a
TOOLTIP_CLASS window. Since both window classes are registered from
their respective DLLInit I thought they would make a good comparison.
The first fails; the other doesn't.
Neither riched32.dll nor commctrl.dll show up in the exe.spec.c file,
since winebuild finds none of their entry points in my code. But the
commctrl DLL is loaded, while the riched32 one is not.
Psuedo-code:
#include richedit.h
#include tooltips.h
winmain(...)
{
CreateWindow(RICHEDIT_CLASS, )
// Fails: I see err:win:CreateWindowExA bad class name RichEdit20A
// on the console
CreateWindow(TOOLTIP_CLASS, ...)
// no complaint
}
Any help would be appreciated... mo
===
Michael Ost, Software Architect
Muse Research, Inc.
[EMAIL PROTECTED]
JOB POSTING - VSTs and Wine
Our Menlo Park, CA based startup is looking for someone with strong Wine skills to help us support VST plugins in a Wine environment. Plugin compatibility issues need to be tracked down and solved, either by patching Wine or our hosting environment. Deep experience in Wine configuration and development are important. Strong Windows API skills are important too. An interest in digital music, soft synths and digital effects would be helpful. The position is available immediately. Telecommuting is available. The position would initially be on a contractor basis, but could lead to a full time position. The rate will be based on experience, and the terms are negotiable. If you are interested and qualified, please send an email to [EMAIL PROTECTED] with WINE CONTRACTOR in the subject line. Include your resume in the body of the email, and attach it as a separate file as well.
winedbg and loading symbols
Howdy, list. I can't figure out how to get winedbg (6/18/03 build) to load my application's symbol table. I am writing an ELF application which uses the wine libraries, and trying to debug it with winedbg. I can run that program fine, but when it loads the shared library built by winebuild (rm-host.exe.so) it says that there is no debug information in the ELF shared library. The file is built with -g, and 'nm' shows symbols galore. I tried using the 'symbolfile' command. The docs suggest that it would help, but I can't figure out what sort of 'path' argument it wants. Here's what I typed: Wine-dbgsymbolfile /home/most/src/rm-host/x86/rm-host.exe.so Parse error Wine-dbgsymbolfile F:\src\rm-host\x86\rm-host.exe.so Parse error Any suggestions? By the way has anyone got a GUI front end to winedbg in the works (ala kdbg for gdb)? I'd love to ge my hands on it. - mo PS: Sorry if this isn't the right forum, perhaps it's not a developer topic. But I can't find any other useful resources.
