Re: Investigating a crash at startup
Now with the correct patch...
- Filip
Filip Navara wrote:
Hi!
One insteresting thing is that OpenOffice does the same and was
reported to work under Wine. Anyway, an experimental patch is attached
(it's completely untested).
Regards,
Filip
Phil Krylov wrote:
Hello,
I have a program here (IBM Translation Manager v.6.0.4) which crashes
wine at startup. The program loads a DLL, and Wine starts importing
this DLL's imports from kernel32.dll. It crashes on the first import
in dlls/ntdll/loader.c:453, which says:
thunk_list->u1.Function = (PDWORD)find_named_export( imp_mod,
exports, exp_size,
pe_name->Name,
pe_name->Hint );
This causes an exception because thunk_list happens to be located in
.rdata section of the DLL, which is readonly.
Currently I have hacked this around by making all PE sections
read-write in map_image() in dlls/ntdll/virtual.c, and the program
works.
If a Wine guru would like to investigate this problem, I can give any
support (e.g., ssh access to my computer with the program).
If not - I will be using this hacked version of Wine.
--- dlls/ntdll/loader.c Tue Apr 20 00:36:30 2004
+++ dlls/ntdll/loader.c Sat Jun 12 16:23:34 2004
@@ -371,6 +371,9 @@
WCHAR buffer[32];
char *name = get_rva( module, descr->Name );
DWORD len = strlen(name) + 1;
+PVOID protect_base;
+DWORD protect_size = 0;
+DWORD protect_old;
thunk_list = get_rva( module, (DWORD)descr->FirstThunk );
if (descr->u.OriginalFirstThunk)
@@ -403,6 +406,20 @@
return NULL;
}
+/* unprotect the import address table since it can be located in
+ * readonly section */
+while (import_list[protect_size].u1.Ordinal)
+protect_size++;
+protect_base = thunk_list;
+protect_size *= sizeof(PVOID *);
+status = NtProtectVirtualMemory( GetCurrentProcess(), &protect_base,
+ &protect_size, PAGE_READWRITE, &protect_old );
+if (status)
+{
+ERR("Can't unprotect IAT for %s\n", name);
+return NULL;
+}
+
imp_mod = wmImp->ldr.BaseAddress;
exports = RtlImageDirectoryEntryToData( imp_mod, TRUE,
IMAGE_DIRECTORY_ENTRY_EXPORT, &exp_size );
@@ -427,6 +444,11 @@
import_list++;
thunk_list++;
}
+
+/* restore old protection of the import address table */
+NtProtectVirtualMemory( GetCurrentProcess(), &protect_base,
+&protect_size, protect_old, NULL );
+
return wmImp;
}
@@ -463,6 +485,11 @@
import_list++;
thunk_list++;
}
+
+/* restore old protection of the import address table */
+NtProtectVirtualMemory( GetCurrentProcess(), &protect_base,
+&protect_size, protect_old, NULL );
+
return wmImp;
}
--- dlls/ntdll/virtual.cTue Apr 6 23:13:48 2004
+++ dlls/ntdll/virtual.cSat Jun 12 17:10:06 2004
@@ -511,6 +511,10 @@
int delta, DWORD total_size )
{
IMAGE_BASE_RELOCATION *rel;
+NTSTATUS status;
+PVOID protect_base;
+DWORD protect_size = page_size;
+DWORD protect_old;
TRACE_(module)( "relocating from %p-%p to %p-%p\n",
base - delta, base - delta + total_size, base, base + total_size
);
@@ -537,6 +541,16 @@
TRACE_(module)("%ld relocations for page %lx\n", rel->SizeOfBlock,
rel->VirtualAddress);
+/* unprotect the page we're about to relocate */
+protect_base = page;
+status = NtProtectVirtualMemory( GetCurrentProcess(), &protect_base,
+ &protect_size, PAGE_READWRITE, &protect_old
);
+if (status)
+{
+ERR("Can't unprotect page during relocation\n");
+return 0;
+}
+
/* patching in reverse order */
for (i = 0 ; i < count; i++)
{
@@ -561,6 +575,10 @@
break;
}
}
+
+/* restore old protection */
+NtProtectVirtualMemory( GetCurrentProcess(), &protect_base,
+&protect_size, protect_old, NULL );
}
return 1;
}
Re: Versioning and internal APIs
>Mike Hearn <[EMAIL PROTECTED]> writes: > >> Paul Davis of Ardour has raised a good point: currently despite the fact >> that the symbols in libwine are versioned, we change them at will and >> don't change the symbol version, for instance in the patch that made >> environ passed through to wine_init from main to hack around the general >> suckage of MacOS X. >> >> Unless this versioning system is meant to be dormant until Wine 1.0 is out >> (and we should definitely document this if so), perhaps we should be >> changing the symbol versions? > >No, the interfaces are not considered frozen, they will be frozen in >1.0; until then it is possible that things will still need to >change. For the specific wine_init case, I suppose we could back out >the change if it causes trouble. well, the problem is that until the mono guys and us audio freaks came along, wine was a "self-contained" project. wine was the only thing that used the wine APIs. but now the situation has changed, even if only by the smallest amount. you've got at least 2 projects using wine API's outside of wine. in our case, the specific problem is the addition of the "environment" ptr arg in wine_init(). there appears to be no way to check on whether this needed, hence: >> Also, there is no easy way to find out the version of Wine you got from >> dlopen at runtime. Should we export a wine_version symbol? > >No, I don't think we should encourage this kind of version checks. how can anyone know which version of wine_init() to use, then? --p
Do we still need wineinstall?
Hi, I've been running without a config file for a while now, and have fixed various misc bugs related to that as I go - I'm sure there are some more in there, but as the config file is destined for eventual doom anyway I am wondering if we still need wineinstall at all? Currently, it's possible to use Wine quite succesfully just by doing a standard ./configure, make, make install. When you run wine for the first time wineprefixcreate will be used to setup ~/.wine, merge the registry, create the fake windows drive and so on. The only piece you don't get is the default config file, but that doesn't seem to make much difference any more. At least, the defaults should be in the code not the config file as people never upgrade that bit anyway :) So - do we still need it?
Re: [MSVCRT] Separate internal definitions from the public headers
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes: > Looking at the changes it seems to me: > 1. There aren't that many > 2. We can easily add a test file to check for consistency > with the public headers (ideally, this file would be > automatically generated by a script) > 3. We should be able to actually drop some of them, this > is just the first cut, and I've tried to keep the > number of changes to the source code to a minimum. > > Should I carry on? Sure, but I'd suggest writing the test as you go, I'd really want to see a working test before putting the patch in. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Versioning and internal APIs
Mike Hearn <[EMAIL PROTECTED]> writes: > The problem then is that the WINE_1.0 symbol means the 1.0 frozen > interfaces *and* any that were used before then. What is the point of > symbol versioning if the linker can't meet the guarantees it's supposed to > provide? Symbol versioning is enabled right now to make sure it works, and to make the transition easier since most symbols won't change before 1.0. Backwards compatibility will only be guaranteed after 1.0 is released. -- Alexandre Julliard [EMAIL PROTECTED]
Re: FindClose crash fix.
Mike Hearn <[EMAIL PROTECTED]> writes: >> BTW. I thought Crossover Office supports this application? > > It does (well, not the NL version specifically ...) so I checked and the > CrossOver version of FindClose is the same as the WineHQ version. I seem > to recall some talk of double closing find handles, but I guess either > we have a hack elsewhere, or for some reason the bug doesn't appear in > the builds we support? There is a hack in Crossover for that, it adds a magic number to the handle structure. I'll merge it in. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Versioning and internal APIs
On Sun, 13 Jun 2004 09:22:37 -0700, Alexandre Julliard wrote: > No, the interfaces are not considered frozen, they will be frozen in > 1.0; until then it is possible that things will still need to > change. For the specific wine_init case, I suppose we could back out > the change if it causes trouble. The problem then is that the WINE_1.0 symbol means the 1.0 frozen interfaces *and* any that were used before then. What is the point of symbol versioning if the linker can't meet the guarantees it's supposed to provide?
[MSVCRT] Separate internal definitions from the public headers
Hi Alexandre,
Welcome back! I did this last Friday, but I didn't want to continue
before running it by you. I'm sending here just the first cut of the
definitions I needed to duplicate in msvcrt.h, to compile the entire
msvcrt DLL without the MSVCRT() define in the public headers.
Looking at the changes it seems to me:
1. There aren't that many
2. We can easily add a test file to check for consistency
with the public headers (ideally, this file would be
automatically generated by a script)
3. We should be able to actually drop some of them, this
is just the first cut, and I've tried to keep the
number of changes to the source code to a minimum.
Should I carry on?
--
Dimi.
Index: dlls/msvcrt/msvcrt.h
===
RCS file: /var/cvs/wine/dlls/msvcrt/msvcrt.h,v
retrieving revision 1.25
diff -u -r1.25 msvcrt.h
--- dlls/msvcrt/msvcrt.h16 Mar 2004 19:17:11 - 1.25
+++ dlls/msvcrt/msvcrt.h4 Jun 2004 23:05:05 -
@@ -28,8 +28,27 @@
#include "winerror.h"
#include "winnls.h"
-#include "msvcrt/string.h"
-#include "msvcrt/eh.h"
+typedef unsigned short MSVCRT_wchar_t;
+typedef unsigned short MSVCRT_wint_t;
+typedef unsigned short MSVCRT_wctype_t;
+typedef unsigned short MSVCRT__ino_t;
+typedef unsigned long MSVCRT__fsize_t;
+typedef unsigned int MSVCRT_size_t;
+typedef unsigned int MSVCRT__dev_t;
+typedef int MSVCRT__off_t;
+typedef long MSVCRT_clock_t;
+typedef long MSVCRT_time_t;
+typedef long MSVCRT_fpos_t;
+
+typedef void (*terminate_handler)();
+typedef void (*terminate_function)();
+typedef void (*unexpected_handler)();
+typedef void (*unexpected_function)();
+typedef void (*_se_translator_function)(unsigned int code, struct _EXCEPTION_POINTERS
*info);
+typedef void (*_beginthread_start_routine_t)(void *);
+typedef unsigned int (__stdcall *_beginthreadex_start_routine_t)(void *);
+typedef int (*MSVCRT__onexit_t)(void);
+
/* TLS data */
extern DWORD MSVCRT_tls_index;
@@ -123,4 +142,363 @@
#define _RT_CRNL252
#define _RT_BANNER 255
+struct MSVCRT_tm {
+int tm_sec;
+int tm_min;
+int tm_hour;
+int tm_mday;
+int tm_mon;
+int tm_year;
+int tm_wday;
+int tm_yday;
+int tm_isdst;
+};
+
+struct _timeb
+{
+MSVCRT_time_t time;
+unsigned short millitm;
+short timezone;
+short dstflag;
+};
+
+typedef struct MSVCRT_iobuf
+{
+ char* _ptr;
+ int _cnt;
+ char* _base;
+ int _flag;
+ int _file;
+ int _charbuf;
+ int _bufsiz;
+ char* _tmpfname;
+} MSVCRT_FILE;
+
+struct MSVCRT_lconv
+{
+char* decimal_point;
+char* thousands_sep;
+char* grouping;
+char* int_curr_symbol;
+char* currency_symbol;
+char* mon_decimal_point;
+char* mon_thousands_sep;
+char* mon_grouping;
+char* positive_sign;
+char* negative_sign;
+char int_frac_digits;
+char frac_digits;
+char p_cs_precedes;
+char p_sep_by_space;
+char n_cs_precedes;
+char n_sep_by_space;
+char p_sign_posn;
+char n_sign_posn;
+};
+
+struct MSVCRT__exception
+{
+ int type;
+ char*name;
+ double arg1;
+ double arg2;
+ double retval;
+};
+
+struct MSVCRT__complex
+{
+ double x; /* Real part */
+ double y; /* Imaginary part */
+};
+
+typedef struct _heapinfo
+{
+ int* _pentry;
+ MSVCRT_size_t _size;
+ int_useflag;
+} _HEAPINFO;
+
+#ifdef __i386__
+typedef struct __JUMP_BUFFER
+{
+unsigned long Ebp;
+unsigned long Ebx;
+unsigned long Edi;
+unsigned long Esi;
+unsigned long Esp;
+unsigned long Eip;
+unsigned long Registration;
+unsigned long TryLevel;
+/* Start of new struct members */
+unsigned long Cookie;
+unsigned long UnwindFunc;
+unsigned long UnwindData[6];
+} _JUMP_BUFFER;
+#endif /* __i386__ */
+
+struct MSVCRT__diskfree_t {
+ unsigned int total_clusters;
+ unsigned int avail_clusters;
+ unsigned int sectors_per_cluster;
+ unsigned int bytes_per_sector;
+};
+
+struct MSVCRT__finddata_t
+{
+ unsigned attrib;
+ MSVCRT_time_t time_create;
+ MSVCRT_time_t time_access;
+ MSVCRT_time_t time_write;
+ MSVCRT__fsize_t size;
+ charname[260];
+};
+
+struct MSVCRT__finddatai64_t
+{
+ unsigned attrib;
+ MSVCRT_time_t time_create;
+ MSVCRT_time_t time_access;
+ MSVCRT_time_t time_write;
+ __int64size;
+ char name[260];
+};
+
+struct MSVCRT__wfinddata_t {
+ unsigned attrib;
+ MSVCRT_time_t time_create;
+ MSVCRT_time_t time_access;
+ MSVCRT_time_t time_write;
+ MSVCRT__fsize_t size;
+ MSVCRT_wchar_t name[260];
+};
+
+struct MSVCRT__wfinddatai64_t {
+ unsigned attrib;
+ MSVCRT_time_t time_create;
+ MSVCRT_time_t time_access;
+ MSVCRT_time_t time_write;
+ __int64 size;
+ MSVCRT_wchar_t name[260];
+};
+
+struct _utimbuf
+{
+MSVCRT_time_t actime;
+MSVCRT_time_t modtime;
+};
+
+/* for FreeBSD */
+#undef st_
Re: Versioning and internal APIs
Mike Hearn <[EMAIL PROTECTED]> writes: > Paul Davis of Ardour has raised a good point: currently despite the fact > that the symbols in libwine are versioned, we change them at will and > don't change the symbol version, for instance in the patch that made > environ passed through to wine_init from main to hack around the general > suckage of MacOS X. > > Unless this versioning system is meant to be dormant until Wine 1.0 is out > (and we should definitely document this if so), perhaps we should be > changing the symbol versions? No, the interfaces are not considered frozen, they will be frozen in 1.0; until then it is possible that things will still need to change. For the specific wine_init case, I suppose we could back out the change if it causes trouble. > Also, there is no easy way to find out the version of Wine you got from > dlopen at runtime. Should we export a wine_version symbol? No, I don't think we should encourage this kind of version checks. -- Alexandre Julliard [EMAIL PROTECTED]
Re: (Still) problem on AMD64 with wine CVS
On Thu, 3 Jun 2004 15:37:19 +0200, Maurizio Monge wrote: > Hello, i have retried to compile wine CVS on amd64 (gcc 3.4 with -m32, etc + > kernel 2.6.4-rc2), where i was thinking the 0xc000 problem was solved. > but i get: Hmm, wine 20040505 works on my AMD64 system (using a biarch 2.6.6 kernel, Debian woody for the 32-bit stuff and the Debian AMD64 port in a chroot environment for the 64-bit stuff). So I guess, either your kernel is outdated (there have been lots of improvements in the 32-bit emulation layer in recent kernels), or there is some problem with your 32-bit compiler setup or libraries. bye, Christof -- http://cmeerw.org JID: [EMAIL PROTECTED] mailto cmeerw at web.de
Re: Investigating a crash at startup
Hi! In ReactOS we are unprotecting the IAT (Import Address Table) before every modification and restoring the previous access rights after all the modifications are done using NtProtectVirtualMemory. I'll try to write a patch for Wine tommorow if no one will do it earlier, but I can't test it... Regards, Filip Phil Krylov wrote: Hello, I have a program here (IBM Translation Manager v.6.0.4) which crashes wine at startup. The program loads a DLL, and Wine starts importing this DLL's imports from kernel32.dll. It crashes on the first import in dlls/ntdll/loader.c:453, which says: thunk_list->u1.Function = (PDWORD)find_named_export( imp_mod, exports, exp_size, pe_name->Name, pe_name->Hint ); This causes an exception because thunk_list happens to be located in .rdata section of the DLL, which is readonly. Currently I have hacked this around by making all PE sections read-write in map_image() in dlls/ntdll/virtual.c, and the program works. If a Wine guru would like to investigate this problem, I can give any support (e.g., ssh access to my computer with the program). If not - I will be using this hacked version of Wine.
Re: Investigating a crash at startup
--- Begin Message --- Hi! In ReactOS we are unprotecting the IAT (Import Address Table) before every modification and restoring the previous access rights after all the modifications are done using NtProtectVirtualMemory. I'll try to write a patch for Wine tommorow if no one will do it earlier, but I can't test it... Regards, Filip Phil Krylov wrote: Hello, I have a program here (IBM Translation Manager v.6.0.4) which crashes wine at startup. The program loads a DLL, and Wine starts importing this DLL's imports from kernel32.dll. It crashes on the first import in dlls/ntdll/loader.c:453, which says: thunk_list->u1.Function = (PDWORD)find_named_export( imp_mod, exports, exp_size, pe_name->Name, pe_name->Hint ); This causes an exception because thunk_list happens to be located in .rdata section of the DLL, which is readonly. Currently I have hacked this around by making all PE sections read-write in map_image() in dlls/ntdll/virtual.c, and the program works. If a Wine guru would like to investigate this problem, I can give any support (e.g., ssh access to my computer with the program). If not - I will be using this hacked version of Wine. --- End Message ---
Re: wingcc and -Wb option
Hi, > But maybe we can introduce a '-i' options instead: > winebuild: --ignore=x,y,z => -ix -iy -iz I just checked this, and it actually works already, as multiple -i's are cumulative on winebuilds command line. Good thought! Cheers, Jon = "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live [EMAIL PROTECTED] __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/
Re: Investigating a crash at startup
Hi!
One insteresting thing is that OpenOffice does the same and was reported
to work under Wine. Anyway, an experimental patch is attached (it's
completely untested).
Regards,
Filip
Phil Krylov wrote:
Hello,
I have a program here (IBM Translation Manager v.6.0.4) which crashes
wine at startup. The program loads a DLL, and Wine starts importing
this DLL's imports from kernel32.dll. It crashes on the first import
in dlls/ntdll/loader.c:453, which says:
thunk_list->u1.Function = (PDWORD)find_named_export( imp_mod, exports, exp_size,
pe_name->Name, pe_name->Hint );
This causes an exception because thunk_list happens to be located in
.rdata section of the DLL, which is readonly.
Currently I have hacked this around by making all PE sections
read-write in map_image() in dlls/ntdll/virtual.c, and the program
works.
If a Wine guru would like to investigate this problem, I can give any
support (e.g., ssh access to my computer with the program).
If not - I will be using this hacked version of Wine.
--- dlls/ntdll/loader.c Tue Apr 20 00:36:30 2004
+++ dlls/ntdll/loader.c Sat Jun 12 16:23:34 2004
@@ -371,6 +371,9 @@
WCHAR buffer[32];
char *name = get_rva( module, descr->Name );
DWORD len = strlen(name) + 1;
+PVOID protect_base;
+DWORD protect_size = 0;
+DWORD protect_old;
thunk_list = get_rva( module, (DWORD)descr->FirstThunk );
if (descr->u.OriginalFirstThunk)
@@ -403,6 +406,20 @@
return NULL;
}
+/* unprotect the import address table since it can be located in
+ * readonly section */
+while (import_list[protect_size].u1.Ordinal)
+protect_size++;
+protect_base = import_list;
+protect_size *= sizeof(PVOID *);
+status = NtProtectVirtualMemory( GetCurrentProcess(), &protect_base,
+ &protect_size, PAGE_READWRITE, &protect_old );
+if (status)
+{
+ERR("Can't unprotect IAT for %s\n", name);
+return NULL;
+}
+
imp_mod = wmImp->ldr.BaseAddress;
exports = RtlImageDirectoryEntryToData( imp_mod, TRUE,
IMAGE_DIRECTORY_ENTRY_EXPORT, &exp_size );
@@ -427,6 +444,11 @@
import_list++;
thunk_list++;
}
+
+/* restore old protection of the import address table */
+NtProtectVirtualMemory( GetCurrentProcess(), &protect_base,
+&protect_size, protect_old, NULL );
+
return wmImp;
}
@@ -463,6 +485,11 @@
import_list++;
thunk_list++;
}
+
+/* restore old protection of the import address table */
+NtProtectVirtualMemory( GetCurrentProcess(), &protect_base,
+&protect_size, protect_old, NULL );
+
return wmImp;
}
--- dlls/ntdll/virtual.cTue Apr 6 23:13:48 2004
+++ dlls/ntdll/virtual.cSat Jun 12 17:10:06 2004
@@ -511,6 +511,10 @@
int delta, DWORD total_size )
{
IMAGE_BASE_RELOCATION *rel;
+NTSTATUS status;
+PVOID protect_base;
+DWORD protect_size = page_size;
+DWORD protect_old;
TRACE_(module)( "relocating from %p-%p to %p-%p\n",
base - delta, base - delta + total_size, base, base + total_size
);
@@ -537,6 +541,16 @@
TRACE_(module)("%ld relocations for page %lx\n", rel->SizeOfBlock,
rel->VirtualAddress);
+/* unprotect the page we're about to relocate */
+protect_base = page;
+status = NtProtectVirtualMemory( GetCurrentProcess(), &protect_base,
+ &protect_size, PAGE_READWRITE, &protect_old
);
+if (status)
+{
+ERR("Can't unprotect page during relocation\n");
+return 0;
+}
+
/* patching in reverse order */
for (i = 0 ; i < count; i++)
{
@@ -561,6 +575,10 @@
break;
}
}
+
+/* restore old protection */
+NtProtectVirtualMemory( GetCurrentProcess(), &protect_base,
+&protect_size, protect_old, NULL );
}
return 1;
}
Re: Windows are unmaxmized when closing other window
On Sun, 13 Jun 2004 22:34:22 +0900, you wrote: > "Rein Klazes" <[EMAIL PROTECTED]> wrote: > > > Agent has fallen victim to the MDI changes since the beginning of this > > year. Here is a previous comment on this breakage: > > > > http://www.winehq.org/hypermail/wine-devel/2004/01/0890.html > > Did you try with my recent (still not commited MDI patch) entitled > "Various MDI children activation fixes"? Yes, it did nothing visible for the maximized/restored problem. However, Agent 1.93 (still used a lot, Agent 2.0 is a paid upgrade) has stopped crashing in some code related to menu handling. So if your patch needs a vote, it gets mine. Rein. -- Rein Klazes [EMAIL PROTECTED]
Re: Windows are unmaxmized when closing other window
"Rein Klazes" <[EMAIL PROTECTED]> wrote: > Agent has fallen victim to the MDI changes since the beginning of this > year. Here is a previous comment on this breakage: > > http://www.winehq.org/hypermail/wine-devel/2004/01/0890.html Did you try with my recent (still not commited MDI patch) entitled "Various MDI children activation fixes"? -- Dmitry.
Re: Windows are unmaxmized when closing other window
On Sun, 13 Jun 2004 10:17:03 +0200, you wrote: > Some time ago I noticed a strange behviour in Agent. When the windows are > maxmized and you close any other window (doesn't matter if it is a dialog or > any other normal window) the remaining windows are unmaximized. They arr not > minimized, but they are getting smaller. Don't know if this is the same for > all types but it seems at least for multiple document windows it is true. > > I just downloaded the current CVS version and there this behaviour is also. Agent has fallen victim to the MDI changes since the beginning of this year. Here is a previous comment on this breakage: http://www.winehq.org/hypermail/wine-devel/2004/01/0890.html Rein. -- Rein Klazes [EMAIL PROTECTED]
Re: [REGRESSION] Photoshop 7.0 works before wine-cvs-20040130 16:??:?? CST (bug #2017)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Rein, on 06/12/2004 05:55 PM, Rein Klazes wrote: > OK, I managed to get a copy of Photoshop and fixed the problem here. It > is a Dutch version, please verify that it works with what you have. I made two tests with your patch on my machine (Debian unstable): 1) latest CVS: Photoshop 7.0 (English) works 2) wine-20040505: as above, Photoshop 7.0 (English) works! In both cases, the output is the following: = [EMAIL PROTECTED]:~/cvs/wine$ ./wine /home/luca/.wine/fake_windows/Program\ Files/Adobe/Photoshop\ 7.0/Photoshop.exe fixme:sync:SetCriticalSectionSpinCount critsection=0x40e348e0: spincount=20 not supported fixme:sync:SetCriticalSectionSpinCount critsection=0x40e34fa4: spincount=500 not supported fixme:sync:SetCriticalSectionSpinCount critsection=0x40e34aa4: spincount=500 not supported fixme:sync:SetCriticalSectionSpinCount critsection=0x40e34ca4: spincount=500 not supported fixme:sync:SetCriticalSectionSpinCount critsection=0x40e35028: spincount=500 not supported fixme:sync:SetCriticalSectionSpinCount critsection=0x40e3514c: spincount=500 not supported fixme:sync:SetCriticalSectionSpinCount critsection=0x40e351c8: spincount=50 not supported fixme:actctx:QueryActCtxW stub! fixme:wintab32:X11DRV_WTInfoA Return proper size fixme:commdlg:PRINTDLG_OpenDefaultPrinter Could not open printer SCIII-4036A.HP-LJ-4200n?! fixme:commdlg:PRINTDLG_OpenDefaultPrinter Could not open printer SCIII-4036A.HP-LJ-4200n?! err:psdrv:PSDRV_FindPrinterInfo OpenPrinterA failed with code 1801 fixme:font:WineEngRemoveFontResourceEx :stub fixme:wintab32:X11DRV_WTInfoA Return proper size err:win:WIN_FindWndPtr window 0x100de belongs to other process err:ddeml:DdeConnect Done with INITIATE, but no Server window available err:ntdll:RtlpWaitForCriticalSection section 0x12538c0 "?" wait timed out in thread 000b, blocked by 0009, retrying (60 sec) fixme:font:WineEngRemoveFontResourceEx :stub fixme:font:WineEngRemoveFontResourceEx :stub [EMAIL PROTECTED]:~/cvs/wine$ = Finally, Rein, thank you very much for your support! Thx, bye, Gismo / Luca -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQFAzBYEVAp7Xm10JmkRAo2UAJkBIsxvXDJPH8BAm8afEBoKkSEYBgCeMUxL sGAK60BiQEg8WBK8C92oFXg= =OaIu -END PGP SIGNATURE-
Windows are unmaxmized when closing other window
Some time ago I noticed a strange behviour in Agent. When the windows are maxmized and you close any other window (doesn't matter if it is a dialog or any other normal window) the remaining windows are unmaximized. They arr not minimized, but they are getting smaller. Don't know if this is the same for all types but it seems at least for multiple document windows it is true. I just downloaded the current CVS version and there this behaviour is also. -- Gerhard Gruber Maintainer of SoftICE for Linux - http://pice.sourceforge.net/ Fast application launcher - http://sourceforge.net/projects/launchmenu
