Re: Header files that conflict with UNIX headers
Hi, David Elliott wrote: [...] > Are Winelib programs also supposed to use the wine CRTDLL? Yes and no. They need a C library (badly). Frankly I've never used 'crtdll.dll' and don't know it very well. All I know is that it seems very similar to a C library except I'm not sure who is supposed to use it. All the windows programs I've worked on/know of use the standard 'msvcrt.dll'. And all the 'C library' headers in the Windows directory are for 'msvcrt.dll'. > If so then it's > necessary to provide headers like stdlib.h and math.h to Winelib programs > and to link the winelib programs against the wine crtdll instead of the > native libc. Yes, we'll need 'our' C library headers for WineLib programs, one day. I've given some (_some_) thought on that. Here's a dump of how I see things currently. Keep in mind that it will need to be further discussed and refined. First we must put these headers 'out of the way' so that their use is optional. There are multiple reasons for that the most important being that we still need to be able to get access to the native (unix) headers for compiling Wine. The best seems to be a subdirectory of 'include'. Then I think we should have three different configurations: * native C library - Unix semantics This is what we currently have. The WineLib application compiles with the native (unix) headers, and links with the native C library. The semantics of all the C library functions is therefore the Unix semantics: fopen takes a Unix path, does not understand O_TEXT, etc. * MSVCRT C library - Windows semantics With this solution we provide C headers that are compatible with those of Microsoft. We provide them in 'include/msvcrt' and the user puts '-I$(WINE_ROOT)/msvcrt' in his include path. The WineLib application is linked with a library called 'libmsvcrt.so' in such a way that the he actually calls the C functions of this library rather than those of the native C library (playing with the link order and no-sys library options and such I guess). I say 'libmsvcrt.so' because that's what I know. Maybe 'libcrtdll.so' would work too. The semantics of the functions implemented by this library are the Windows semantics: fopen takes a dos path and recognises O_TEXT, we implement _beginthread and friends, etc. * 'Mixed' C library - Unix semantics This is an intermediate solution. The semantics is that of Unix like in the 'native C library' case. But we provide a specially designed set of headers to ease compilation: - macros map things like '_hypot' to 'hypot' - macros provide replacements for things like _itoa - macros fake support for 'O_TEXT' - maybe some macros would map an API to a CRTDLL_xxx function - provide additional headers like 'direct.h' - maybe approximate a little bit: map _flushall to sync - etc. The headers would be in 'include/mixedcrt' and a WineLib application would link with the native C library and possibly with crtdll if it uses APIs that have been remapped to one of the CRTDLL_xxx functions. The important thing here is: 'Unix semantics' plus some compatibility features. Notes: * Unicode We should provide the appropriate prototypes so that it works in the 'MSVCRT C library' case. For the other two solutions Unicode will not be supported (because of the 2 vs. 4 chars difference). * Thread safeness Again the MSVCRT solution should be thread safe because it is on Windows. For the other two it all depends on the native C library, i.e. it's most likely not thread safe. * This scheme leaves the door open for adding other C library implementations. If Borland has their own slightly different C library then we add the corresponding headers in 'include/bcrt' and provide another library. I have actually implemented some of the headers for the 'Mixed C library' solution. I attached a tarball containing the new files. -- Francois Gouget [EMAIL PROTECTED] mixedcrt.tar.gz
Re: Preferred way to get all 'recent' code
In message <[EMAIL PROTECTED]>, Andreas Mohr <[EMAIL PROTECTED]> writes >If you're an end-user, you might want to stick with normal releases. Why? >But even for end-users CVS is not too bad ;) > >Andreas Mohr I thought Alexandre's present policy was that there was no real difference between a dated release and a CVS snapshot? Bob > > -- robert w hall
wine & win4lin
I keep seeing occasional reports that 'wine does not run... on a win4lin-enabled kernel'. Though this is contrary to my experience and sounds like finger-trouble, I wonder if anyone has any better/hard info?. The one possibility for serious interaction would appear to be the dosmod/vm86 area? (which I don't personally use... sorry Ove! :-)) -- robert w hall
Re: Header files that conflict with UNIX headers
Francois Gouget wrote: >Hi, > > David Elliott wrote: > [...] > > Are Winelib programs also supposed to use the wine CRTDLL? > >Yes and no. They need a C library (badly). >Frankly I've never used 'crtdll.dll' and don't know it very well. All > I know is that it seems very similar to a C library except I'm not sure > who is supposed to use it. All the windows programs I've worked on/know > of use the standard 'msvcrt.dll'. And all the 'C library' headers in the > Windows directory are for 'msvcrt.dll'. > Yeah, and Wine doesn't even provide MSVCRT because "Applications will install it". However, newer versions of windows include it (at least it is in my 98SE cab files, and I think IE uses it). Although if one installed IE, then it would presumably install MSVCRT.DLL, and since IE is free for download, no one has yet done MSVCRT. At least that is my understanding of the situation. I have already looked at MSDN, and noticed that all new windows development seems to link against MSVCRT and not CRTDLL (like you mention). And yet CRTDLL is included in Wine because it came with Win95. This situation seems to be entirely bass ackwards for Winelib development. > > > If so then it's > > necessary to provide headers like stdlib.h and math.h to Winelib programs > > and to link the winelib programs against the wine crtdll instead of the > > native libc. > >Yes, we'll need 'our' C library headers for WineLib programs, one > day. I've given some (_some_) thought on that. Here's a dump of how I > see things currently. Keep in mind that it will need to be further > discussed and refined. > >First we must put these headers 'out of the way' so that their use is > optional. There are multiple reasons for that the most important being > that we still need to be able to get access to the native (unix) headers > for compiling Wine. The best seems to be a subdirectory of 'include'. > Yes, I agree. I like the names you are using too. >Then I think we should have three different configurations: > > * native C library - Unix semantics > >This is what we currently have. The WineLib application compiles with > the native (unix) headers, and links with the native C library. The > semantics of all the C library functions is therefore the Unix > semantics: fopen takes a Unix path, does not understand O_TEXT, etc. > Okay, that's what I thought. This is probably not very ideal for porting source seeing as how this is definitely going to require changes to the apps source. > > * MSVCRT C library - Windows semantics > >With this solution we provide C headers that are compatible with > those of Microsoft. We provide them in 'include/msvcrt' and the user > puts '-I$(WINE_ROOT)/msvcrt' in his include path. The WineLib > application is linked with a library called 'libmsvcrt.so' in such a way > that the he actually calls the C functions of this library rather than > those of the native C library (playing with the link order and no-sys > library options and such I guess). I say 'libmsvcrt.so' because that's > what I know. Maybe 'libcrtdll.so' would work too. The semantics of the > functions implemented by this library are the Windows semantics: fopen > takes a dos path and recognises O_TEXT, we implement _beginthread and > friends, etc. > We want to use libmsvcrt.so and implement MSVCRT. CRTDLL seems to be deprecated by Microsoft, and I have heard it is not very threadsafe, and I remember Alexandre saying that if a function is documented as not being threadsafe there shouldn't be additional overhead to make it threadsafe. However, supposedly CRTDLL is /supposed/ to be threadsafe, it's just that it isn't very much so in practice. At least that is what I gather from discussion on this list and from MSDN. It does export funtions like _beginthread. Personally I feel that sharing the CRTDLL implementation with MSVCRT would be better than specifically writing a non-threadsafe version of a function for CRTDLL. > > * 'Mixed' C library - Unix semantics > >This is an intermediate solution. The semantics is that of Unix like > in the 'native C library' case. But we provide a specially designed set > of headers to ease compilation: >- macros map things like '_hypot' to 'hypot' >- macros provide replacements for things like _itoa >- macros fake support for 'O_TEXT' >- maybe some macros would map an API to a CRTDLL_xxx function >- provide additional headers like 'direct.h' >- maybe approximate a little bit: map _flushall to sync >- etc. >The headers would be in 'include/mixedcrt' and a WineLib application > would link with the native C library and possibly with crtdll if it uses > APIs that have been remapped to one of the CRTDLL_xxx functions. >The important thing here is: 'Unix semantics' plus some compatibility > features. > So basically if it's implemented by the libc use it, but if it's not then use the MSVCRT implementation. > > Notes: > * Unicode >We s
Re: GetProcAddress
[EMAIL PROTECTED] writes: > Good day! > > I am trying to make a winelib rundll32, but I can not get GetProcAddress > to return anything but (nil). I must be doing something even stupider > than the stupid errors I have already fixed, but I can't see it. Maybe Hallo, in my understanding, winelib programs should stay within the scope of the win32 api. index() doesn't seems to be a win32 api: gauss:~/tmp/wine/compile/programs/rundll32> i386-mingw32-gcc rundll32.c rundll32.c: In function `WinMain': rundll32.c:21: warning: assignment makes pointer from integer without a cast rundll32.c:26: warning: assignment makes pointer from integer without a cast /tmp/cce1JxDZ.o(.text+0xaf):rundll32.c: undefined reference to `index' /tmp/cce1JxDZ.o(.text+0x153):rundll32.c: undefined reference to `index' strchr however is recognized by mingw. Bye Uwe Bonnes[EMAIL PROTECTED] Free Software: If you contribute nothing, expect nothing --
Re: wine & win4lin
robert w hall <[EMAIL PROTECTED]> writes: > I keep seeing occasional reports that 'wine does not run... on a > win4lin-enabled kernel'. Though this is contrary to my experience and > sounds like finger-trouble, I wonder if anyone has any better/hard > info?. I think the problem is that they changed the value of USER_CS and USER_DS (the selectors used when running in 32-bit mode). We use these to switch from 16 to 32-bit code, and their value is hardcoded in the relay code at compile-time. So it will work as long as you also compile on a win4lin-patched kernel. But if you compile when running a normal kernel and run on the patched one, or the other way around, it will break. -- Alexandre Julliard [EMAIL PROTECTED]
Re: wine & win4lin
Actually, it's a fascinating problem - I've been bit by it, badly. Wine works fine with a Win4lin kernel, so long as you build it from source. If you try to take a binary built on a non Win4lin kernel, you get an unhandled exception when your app starts to run, with a problem in the ThunkConnect32 area. Similarly, if you take a binary that you built on your Win4lin kernel, and give that binary to someone on a non Win4lin kernel, they see the exact same problem. So, it works with Win4lin, sorta. Jer robert w hall wrote: > I keep seeing occasional reports that 'wine does not run... on a > win4lin-enabled kernel'. Though this is contrary to my experience and > sounds like finger-trouble, I wonder if anyone has any better/hard > info?. > > The one possibility for serious interaction would appear to be the > dosmod/vm86 area? (which I don't personally use... sorry Ove! :-)) > > -- > robert w hall
[Q] Status of wine debugger
Hallo,
I am trying to debug some missfunction in a programm (avrstudio.exe)
that uses MFC. The missfunction are senseless top/left/width/height
values to CreateWindowExA and that CreateWindowExA is called from the
MFC library. As VC++ comes with PDB files and source for the MFC
library, I thought that windebg should read that pdb files and then
would give me a sensible stack backtrace at that invokation of
CreateWindowExA.
However doing so it looks like:
0x405cdf46 (CreateWindowExA+0x46 [win.c:1118])
1118 FIXME("BON:Setting up SysHeader32\n");
Wine-dbg>bt
Backtrace:
=>0 0x405cdf46 (CreateWindowExA+0x46(exStyle=0x0, className=0x5f4a5444,
windowName=0x0, style=0x4042, x=0x5f403903, y=0x5f4d1b60, width=0xa10af35d,
height=0xa0b2e4a0, parent=0x341c, menu=0x9c70, instance=0x40, data=0x0)
[win.c:1118]) (ebp=4083cde0)
1 0x5f407d8a (COccManager::SplitDialogTemplate+0x6(pTemplate=0x0,
ppOleDlgItems=0x5f4a5444) [occmgr.cpp:182]) (ebp=4083ce50)
2 0x5f409a6b (MFC42.DLL.2124+0x46) (ebp=4083ce8c)
3 0x5f456a10 (MFC42.DLL.2093+0x2d) (ebp=)
*** Invalid address 0x (SHLWAPI.DLL..reloc+0x4048dfff)
I wonder why the stack levels 2 and 3 don't get resolved in Function
names and looking at the MFC source for occmgr.cpp I think winedbg
doesn't get things right...
So my questions:
- Does winedbg do right here?
- Can I set a breakpoint in winedbg to
COccManager::SplitDialogTemplate and then single step line by
line. And how do I set the Breakpoint?
- Can I display variables in MFC? How do I do that.
Bye
Uwe Bonnes[EMAIL PROTECTED]
Free Software: If you contribute nothing, expect nothing
--
Re: Header files that conflict with UNIX headers (fwd)
Damn, I sent it to the wrong list! I shouldn't get up so early! David Elliott wrote: > > Francois Gouget wrote: > > >Hi, > > > > David Elliott wrote: > > [...] > > > Are Winelib programs also supposed to use the wine CRTDLL? > > > >Yes and no. They need a C library (badly). > >Frankly I've never used 'crtdll.dll' and don't know it very well. All > > I know is that it seems very similar to a C library except I'm not sure > > who is supposed to use it. All the windows programs I've worked on/know > > of use the standard 'msvcrt.dll'. And all the 'C library' headers in the > > Windows directory are for 'msvcrt.dll'. > > > > Yeah, and Wine doesn't even provide MSVCRT because "Applications will install > it". It is true that applications should install msvcrt themselves. And it is reasonable strategy not to implement it in Wine. But this strategy does not work with WineLib. The C library is too commonly used and too important. [...] > >Then I think we should have three different configurations: > > > > * native C library - Unix semantics [...] > > * MSVCRT C library - Windows semantics [...] > > * 'Mixed' C library - Unix semantics > > > >This is an intermediate solution. The semantics is that of Unix like > > in the 'native C library' case. But we provide a specially designed set > > of headers to ease compilation: > >- macros map things like '_hypot' to 'hypot' > >- macros provide replacements for things like _itoa > >- macros fake support for 'O_TEXT' > >- maybe some macros would map an API to a CRTDLL_xxx function > >- provide additional headers like 'direct.h' > >- maybe approximate a little bit: map _flushall to sync > >- etc. > >The headers would be in 'include/mixedcrt' and a WineLib application > > would link with the native C library and possibly with crtdll if it uses > > APIs that have been remapped to one of the CRTDLL_xxx functions. > >The important thing here is: 'Unix semantics' plus some compatibility > > features. > > > > So basically if it's implemented by the libc use it, but if it's not then use the > MSVCRT implementation. Just a slight adjustment. The operative word here is 'Unix semantics'. So eventhough 'sopen' is not implemented in the native C library we cannot take that of msvcrt because it would provide a Windows semantics: windows paths. So basically in such a case I would say: too bad, modify your source anyway (unless someone finds a creative solution). > > > > > Notes: > > * Unicode > >We should provide the appropriate prototypes so that it works in the > > 'MSVCRT C library' case. For the other two solutions Unicode will not be > > supported (because of the 2 vs. 4 chars difference). > > > > This answers the question I was about to ask. I assume if a function is > implemented by the native libc then we go with the native libc implementation > since it would be rather hard to include a UNIX header leaving out the parts that > would conflict. It would be possible to remove parts of the C library. It's not in my headers because I did not have this problem but it's all done so that you can have something before you include the native header :-) /* * Extinguish */ #define wcsdup do_not_call_wcsdup ... /* * Embrace */ ... include the native header here /* * Extinguish (again) */ #undef wcsdup ... /* * Extend */ #define wcsdup(a) ... > > * Thread safeness > >Again the MSVCRT solution should be thread safe because it is on > > Windows. For the other two it all depends on the native C library, i.e. > > it's most likely not thread safe. > > > > Aren't all the glibc's threadsafe? Especially with Wine exporting the pthreads > primitives? Is anyone still living in the darkages with non-threadsafe libc > 5??? I'm not entirely sure. The problem is with functions that return data in a static buffer, like h, ctime. In some Unix C libraries the regular function is not threadsafe and if you want something that is threadsafe then you should call xxx_r (different signature) instead. Of course maybe now they all rely on some form of TLS. [...] > It is my understanding that when compiling Winelib programs __WINE__ is not > supposed to be defined, but when compiling Wine itself, it is. Yes. And usually when compiling a WineLib application it is WINELIB that is defined. But in the headers it's better to entirely rely on __WINE__. > So the headers > could use that to determine whether they should name things with a MSVCRT_ prefix > (when compiling wine) or not (when compiling apps in MSVCRT mode). Yes. This should work. > I am not entirely sure how mixed mode should be handled. I originally thought of > simply straight-out using libc functions when available and using the > MSVCRT provided implementation when not. I was thinking of making the mixed-mode > headers actually #include "../msvcrt/h
Debugger problem
Hello. For quite some time I've been having problems attaching winedbg to a running process, for instance in the case of automatic invokation due to a crash. Direct invokation causes no problems and I also believe that my registry entries are all ok. My kernel is a standard 2.0.34 which otherwise has caused no problems and I use glibc 2.0.7 (yep, my system is oldish). I've traced the problem to this: debug_process() in server/debugger.c sets an error code which makes the debugger abort. To be more precise, this error code is set due to the call to get_thread_ip() ==> get_thread_context() which in turn calls: ptrace( PTRACE_GETREGS, pid, 0, ®s ) Now, this call fails for me with a EIO, so it seems like my system doesn't like PTRACE_GETREGS, at least according to the manpage? Did I miss anything, or can it really be the case? Are there any workarounds for this apart from just resetting the error code, which isn't very nice but gets the debugger going? How about a configure check or a error message for this? Should I prepare myself mentally for a system upgrade? ;-) Nicke -- -[ [EMAIL PROTECTED] ]- Seek simplicity, and distrust it. (A. Whitehead)
Re: wine & win4lin
Jeremy White wrote: > Actually, it's a fascinating problem - I've been bit by it, badly. > > Wine works fine with a Win4lin kernel, so long as you build > it from source. If you try to take a binary built on a non > Win4lin kernel, you get an unhandled exception when your > app starts to run, with a problem in the ThunkConnect32 area. > > Similarly, if you take a binary that you built on your Win4lin > kernel, and give that binary to someone on a non Win4lin kernel, > they see the exact same problem. > > So, it works with Win4lin, sorta. > > Jer > Ah, so that explains why I haven't seen this problem then, because I always build from source. Hmm, come to think of it, that'd make it kind of hard for me to make a wine package usable by anyone else. Do you happen to know WHY this problem shows up??? I don't believe it has anything to do with kernel headers, since I am using kernel headers from 2.4.0testXX (ala RedHat 7.0) even though I am running a customized version of 2.2.18pre17 (http://www.thecomputerbuilder.com/~dfe/linux/kernel_RPM/). So theoretically I should be hit really hard by the problem if it was the headers. In any case, a message by Richard Bass ([EMAIL PROTECTED]) says that they are fixing the problem. I just wish they'd go ahead and release a fixed kernel patch right now rather than wait for all the different kernels to build. I could have it in my kernel RPM in about 5 minutes then go worrk on Wine while I'm waiting for it to build. ;-) -Dave P.S. cced this back to the win4lin-beta list as this could be informative for people on that list.
[Fwd: Header files that conflict with UNIX headers]
Forwarding this to Wine-devel since I originally sent it to wine-patches because I just hit "Reply-All" and didn't bother to check. I agree with Francois, I really shouldn't get up before like 5 or so, 4 is too early ;-) (pm that is) -Dave Francois Gouget wrote: > David Elliott wrote: > > > > Francois Gouget wrote: > > > > >Hi, > > > > > > David Elliott wrote: [SNIP] > > > Yeah, and Wine doesn't even provide MSVCRT because "Applications will install > > it". > >It is true that applications should install msvcrt themselves. And it > is reasonable strategy not to implement it in Wine. But this strategy > does not work with WineLib. The C library is too commonly used and too > important. > Actually, that was the whole point, that not providing MSVCRT is a really bad thing for Winelib. [SNIP] > > > > > > * 'Mixed' C library - Unix semantics > > > [SNIP] > > > So basically if it's implemented by the libc use it, but if it's not then use the > > MSVCRT implementation. > >Just a slight adjustment. The operative word here is 'Unix > semantics'. So eventhough 'sopen' is not implemented in the native C > library we cannot take that of msvcrt because it would provide a Windows > semantics: windows paths. So basically in such a case I would say: too > bad, modify your source anyway (unless someone finds a creative > solution). > Right, I qualify this later on realizing that just using the MSVCRT implementation probably won't work for most functions. See below. [SNIP] > > This answers the question I was about to ask. I assume if a function is > > implemented by the native libc then we go with the native libc implementation > > since it would be rather hard to include a UNIX header leaving out the parts that > > would conflict. > >It would be possible to remove parts of the C library. It's not in my > headers because I did not have this problem but it's all done so that > you can have something before you include the native header :-) > [SNIP Extinguish, Embrace, Extinguish, Extend code] I am guessing that that is probably not very portable, but I haven't looked at other libc headers (other than glibc). [SNIP] > > Aren't all the glibc's threadsafe? Especially with Wine exporting the pthreads > > primitives? Is anyone still living in the darkages with non-threadsafe libc > > 5??? > >I'm not entirely sure. The problem is with functions that return data > in a static buffer, like h, ctime. In some Unix C libraries the > regular function is not threadsafe and if you want something that is > threadsafe then you should call xxx_r (different signature) instead. Of > course maybe now they all rely on some form of TLS. > That is an issue. I was reading MSDN and it appears that all these non-threadsafe functions use TLS in MSVCRT. But on UNIX IIRC they are still non-threadsafe because they have been replaced by the xxx_r versions. However it is fairly trivial to use the xxx_r function to provide the threadsafe implementation of the xxx function given some space on the TLS. > > > [...] > > It is my understanding that when compiling Winelib programs __WINE__ is not > > supposed to be defined, but when compiling Wine itself, it is. > >Yes. And usually when compiling a WineLib application it is WINELIB > that is defined. But in the headers it's better to entirely rely on > __WINE__. > > > So the headers > > could use that to determine whether they should name things with a MSVCRT_ prefix > > (when compiling wine) or not (when compiling apps in MSVCRT mode). > >Yes. This should work. > Okay, good, I liked the idea too. However, see below the stuff about obfuscating the names on purpose for easier linking. [SNIP] >Yes, for mixed mode I would prefer not to use msvcrt at all, although > it may be necessary to make an exception for some functions so that we > can take them from crtdll. The goal would be that in most cases you link > with the native C library and that's it. > Mixed mode should mostly provide syntactic sugar. > Perfect. I would go so far as to say you should have another smaller library, maybe libwinemsvcrt.so (or maybe even just a static libary) that would provide only the functions that we don't want to/can't get from the native libc. > > > I did think of one solution to the linking problem: If there was a library like > > libobfuscatedmsvcrt.so that imported the real names from msvcrt (that is, was > > linked against MSVCRT) and exported them with an MSVCRT_ prefix, then the headers > > could use things like #define malloc(x) MSVCRT_malloc(x) and prototype the > > functions with the MSVCRT_ prefix. Therefore the unresolved symbols all have the > > MSVCRT_ preifx. The app would then be linked against the > > libobfuscatedmsvcrt.so. > >I'm not sure about the details of the linking aspects. I think > there's persons more knowledgeable than me for this subject. Also we > should probably do some testing with a simple case to determine how >
Re: wine & win4lin
In message <[EMAIL PROTECTED]>, David Elliott <[EMAIL PROTECTED]> writes >Jeremy White wrote: >Ah, so that explains why I haven't seen this problem then, because I always >build from source. likewise > Hmm, come to think of it, that'd make it kind of hard >for me to make a wine package usable by anyone else. > >Do you happen to know WHY this problem shows up??? see AJ's post >I don't believe it has >anything to do with kernel headers, since I am using kernel headers from >2.4.0testXX (ala RedHat 7.0) even though I am running a customized version >of 2.2.18pre17 (http://www.thecomputerbuilder.com/~dfe/linux/kernel_RPM/). >So theoretically I should be hit really hard by the problem if it was the >headers. > well the mods are in include/asm/segment.h I think and the double whammy is that people loading stock win4lin kernels DON'T get that updated . So even if they build WINE from source (but not their kernel) they're scuppered. Bob In another context though, it may explain the loadlin/win4lin problem (since that uses KERNEL_CS, KERNEL_DS which are also mod'd I think?) >-Dave > >P.S. cced this back to the win4lin-beta list as this could be informative >for people on that list. > Thanks - I posted independently to both lists initially -- robert w hall
Re: wine & win4lin
robert w hall <[EMAIL PROTECTED]> writes: > well the mods are in include/asm/segment.h I think > > and the double whammy is that people loading stock win4lin kernels DON'T > get that updated . So even if they build WINE from source (but not their > kernel) they're scuppered. No, Wine gets the value directly from the %cs register at compile-time, so kernel headers don't matter, what is important is the kernel you are running on when you compile. Anyway it's not really hard to fix Wine to avoid this, I'm working on it. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [Q] Status of wine debugger
> However doing so it looks like:
>
>
> 0x405cdf46 (CreateWindowExA+0x46 [win.c:1118])
> 1118 FIXME("BON:Setting up SysHeader32\n");
> Wine-dbg>bt
> Backtrace:
> =>0 0x405cdf46 (CreateWindowExA+0x46(exStyle=0x0, className=0x5f4a5444,
>windowName=0x0, style=0x4042, x=0x5f403903, y=0x5f4d1b60, width=0xa10af35d,
>height=0xa0b2e4a0, parent=0x341c, menu=0x9c70, instance=0x40, data=0x0)
>[win.c:1118]) (ebp=4083cde0)
> 1 0x5f407d8a (COccManager::SplitDialogTemplate+0x6(pTemplate=0x0,
>ppOleDlgItems=0x5f4a5444) [occmgr.cpp:182]) (ebp=4083ce50)
> 2 0x5f409a6b (MFC42.DLL.2124+0x46) (ebp=4083ce8c)
> 3 0x5f456a10 (MFC42.DLL.2093+0x2d) (ebp=)
> *** Invalid address 0x (SHLWAPI.DLL..reloc+0x4048dfff)
>
> I wonder why the stack levels 2 and 3 don't get resolved in Function
> names and looking at the MFC source for occmgr.cpp I think winedbg
> doesn't get things right...
windbg can read pdb files if the debug information of the exe file is not stripped
and the exe file is pointing directly to the pdb file.
If the debuginformation is stripped to a dbg file and there is a record pointing
to the pdb file in the dbg file windgb is not able to load the filename.
I already implemented the missing functionallity but didn't post the code since
it resolves not all functions to the right adresses and i could not find the problem
yet.
A second problem is: the pdb file seems to have a different timestamp than the dbg file
so I had to disable the code what checks it. To me it looks like the pdb code gets a
invalid timestamp from pdb files mostly.
I think I'll post the patch tomorrow anyway. (Have do do some cleanup before and its
a bit late now)
With this patch it reads the pdb file regadless of the timestamp (prints a warning) but
it displays often wrong function names (some 1000 bytes beside the right name).
juergen
Re: Header files that conflict with UNIX headers
--- Francois Gouget <[EMAIL PROTECTED]> wrote: >Yes and no. They need a C library (badly). >Frankly I've never used 'crtdll.dll' and don't > know it very well. All > I know is that it seems very similar to a C library > except I'm not sure > who is supposed to use it. All the windows programs > I've worked on/know > of use the standard 'msvcrt.dll'. And all the 'C > library' headers in the > Windows directory are for 'msvcrt.dll'. This is probably just for your information, but as I understand it. crtdll.dll only came with the very first version of Windows 95, all subsequent version of Win95 (A, B, C, OSR2, OSR2a, etc) either didn't have it at all, or had msvcrt.dll Not sure what effect that has on how much support/non-support Wine/Winelib should have for crtdll.dll HTH, George __ Do You Yahoo!? Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free! http://photos.yahoo.com/
