Re: Fix SERIOUS bug in winecfg

2005-10-25 Thread Mike Hearn 
On Tue, 2005-10-25 at 01:33 +, James Hawkins wrote:
> Couldn't we check that Z points to / already before we swap the
> drives?  If Z already points to /, then we would drop the current
> letter we're adding; otherwise, wouldn't we have two drive letters
> mapping to /?  Besides that point, it looks good to me.

Yes, good point. Though I think this one missed the boat so we may as
well fix the underlying problem, which I guess Michael correctly
identified. I thought it was the unixfs as some of the debug output was
related to that, but there was quite a lot (cascading failures I guess).
The desktop shell folder still having references to Z: in the registry
sounds much more likely.

Re: Fix SERIOUS bug in winecfg

2005-10-25 Thread Michael Jung 
Hi Mike,

On Monday 24 October 2005 22:17, Mike Hearn wrote:
> The unixfs module apparently can't cope with the Z: drive being anything
> other than / or being non-existant. A fresh .wine has this set up OK, but
> clicking the drive autodetect button in winecfg will currently set it up
> so D: is the root drive. Oops!

Unixfs should'nt depend on the Z: drive beeing mapped to '/'. It even 
should'nt depend on '/' beeing mapped anywhere. I guess the problem you are 
seeing depends on the setting for the Desktop directory, which is generated 
automatically (There are a couple more registry entries, which depend on z:):

[Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders] 
1130228151
"Desktop"="z:\\home\\mjung\\Desktop"

If you remove or remap the 'Z:' drive afterwards without adjusting these 
registry settings, the desktop shellfolder object won't initialize any 
longer, which is why the file dialogs won't work.

Bye,
-- 
Michael Jung
[EMAIL PROTECTED]

Re: Fix SERIOUS bug in winecfg

2005-10-24 Thread James Hawkins 
On 10/24/05, Mike Hearn <[EMAIL PROTECTED]> wrote:
> +
> +if ('A' + i != 'Z')
> +{
> +struct drive swapbuf;
> +
> +/* the root drive must be letter Z for now, the unixfs seems 
> to expect it */
> +WINE_TRACE("attempting to remap / to drive Z:\n");
> +
> +/* if Z is already used, we need to swap Z and this drive 
> around */
> +if (drives['Z' - 'A'].in_use)
> +{
> +swapbuf = drives['Z' - 'A'];
> +drives['Z' - 'A'] = drives[i];
> +drives[i] = swapbuf;
> +}
> +else
> +{
> +drives['Z' - 'A'] = drives[i];
> +drives[i].in_use = FALSE;
> +}
> +}

Couldn't we check that Z points to / already before we swap the
drives?  If Z already points to /, then we would drop the current
letter we're adding; otherwise, wouldn't we have two drive letters
mapping to /?  Besides that point, it looks good to me.

--
James Hawkins

Re: Serious Bug

2003-10-29 Thread Boaz Harrosh 
I'm Just exactly now fighting same problems.
See my last post: "Help with shared library make files"
Note 2 things
A. Initialization order is opposite of msvc++ Last object on the linker 
gets to run first. (msvc first on the command line first to initialize)

B. Hard, in gdb (kdevelop), to set a break point on pre-main code. use 
below file to do that. Put it as last object linked and after any 
library. In effect it is an "int 0x03" instruction to hard code a break 
point.

C. All DLLs linked to the MyApp.dll.so should also link to MyApp.exe.so 
see my wine post: "wine msvcrt on Library initialization". These are the 
ones that get linked through winebuild.



#include "windows.h"

#define _CrtDbgBreak()  __asm__ ("\tint $0x3\n")

class TestStaticClass
{
public:
TestStaticClass() ;
~TestStaticClass() ;
} ;
TestStaticClass::TestStaticClass()
{
   MessageBox(NULL ,"Constructor" ,"Cpp_Globs_stop" ,MB_OK) ;
   _CrtDbgBreak();
}
TestStaticClass::~TestStaticClass()
{
   MessageBox(NULL ,"Destructor" ,"Cpp_Globs_stop" ,MB_OK) ;
}
TestStaticClass g_StaticClass ;


$(mfctest_dll_MODULE).so:  $(mfctest_dll_MODULE).spec.o 
$(mfctest_dll_OBJS) Cpp_Globs_stop.o
   $(LDXXSHARED) $(LDDLLFLAGS) -o $@ \
   $(mfctest_dll_MODULE).spec.o \
   $(mfctest_dll_OBJS) \
   $(mfctest_dll_LIBRARY_PATH) \
   $(mfctest_dll_LIBRARIES:%=-l%) \
   $(ALL_LIBRARIES) \
   Cpp_Globs_stop.o \



Now you can single step the initialization chain.

flyker wrote:

Boaz Harrosh wrote:

use --wrap in winemaker. Read about this option in the documentation

Thanks. It is work :)

Re: Serious Bug

2003-10-29 Thread flyker 
Boaz Harrosh wrote:

use --wrap in winemaker. Read about this option in the documentation

Thanks. It is work :)

Re: Serious Bug

2003-10-29 Thread flyker 
Vincent Béron wrote:

Huh?
Works fine here cross-compiled with mingw.
Even added 2 printf (one to the constructor, the other in WinMain), and
the constructor one is called first (as it should be).
Vincent

RedHat 9.0,  gcc and winelib.
Of course constructor first.

Re: Serious Bug

2003-10-29 Thread Vincent Béron 
Le mer 29/10/2003 à 09:02, flyker a écrit :
> 
> The simple test crashes wine.
> And i think many other commands in constructor A() may crash wine.

Huh?
Works fine here cross-compiled with mingw.
Even added 2 printf (one to the constructor, the other in WinMain), and
the constructor one is called first (as it should be).

Vincent

Serious Bug

2003-10-29 Thread flyker 
The simple test crashes wine.
And i think many other commands in constructor A() may crash wine.
test.cpp:

#include 
#include 
class A
{
public:
 A();
};
A::A()
{
 LoadLibrary("user32.dll"); // all ok user32.dll is present
}
A a;

int WinMain(HINSTANCE hInst, HINSTANCE, LPSTR szCmdLine, int nCmdShow)
{
 return 0;
}