On Mon, 23 Dec 2002, Dimitrie O. Paun wrote:
That's what I have to do on my system.
Francois, does this seem OK to you? If the fix is right, what about the other _str* symbols?
According to the latest sdk I have (2000), _tcsdup is supposed to map to _strdup and _tcsicmp to _stricmp.
I think the catch is you are supposed to link with the msvcrt library since these symbols are only exported there.
Now, pointing _tcsdup to strdup should not make any difference. However I am not sure that _stricmp really behaves exactly like strcasecmp: you would need to check how each of these handles accentuated characters and locale.
Then the question is whether tchar.h should be considered to be a pure msvcrt thing, i.e. don't use it if you don't link to msvcrt, or whether we want to make is usable in Ansi mode with a regular C library. Currently we set the macros based on _MBCS and _UNICODE. Maybe we need to add a WINE_LIBC flag and add mappings to the native C library routines?
On December 23, 2002 10:52 pm, Francois Gouget wrote:
Then the question is whether tchar.h should be considered to be a pure msvcrt thing, i.e. don't use it if you don't link to msvcrt, or whether we want to make is usable in Ansi mode with a regular C library.
If using tchar.h forces you to link in msvcrt, it should be moved to include/msvcrt. Thing is that MinGW supports tchar.h it seems, so we can do one of two things: 1. Add conditionals in tchar.h as you suggested to do things differently depending on whether or not we link in msvcrt 2. Move the current tchar.h to include/msvcrt, and create a new one to support the MinGW/glibc case.
Alexandre?
On Tue, 24 Dec 2002, Dimitrie O. Paun wrote:
On December 23, 2002 10:52 pm, Francois Gouget wrote:
Then the question is whether tchar.h should be considered to be a pure msvcrt thing, i.e. don't use it if you don't link to msvcrt, or whether we want to make is usable in Ansi mode with a regular C library.
If using tchar.h forces you to link in msvcrt, it should be moved to include/msvcrt. Thing is that MinGW supports tchar.h it seems, so we can do one of two things:
- Add conditionals in tchar.h as you suggested to do things differently depending on whether or not we link in msvcrt
- Move the current tchar.h to include/msvcrt, and create a new one to support the MinGW/glibc case.
Solution 2 seems likely to cause directory include order headaches...
On December 24, 2002 03:43 pm, Francois Gouget wrote:
Solution 2 seems likely to cause directory include order headaches...
Not really. We should have another directory called include/cygwin, and you either use include/msvcrt or include/cygwin. They are mutually exclusive. Where is the problem?
"Dimitrie O. Paun" dpaun@rogers.com writes:
If using tchar.h forces you to link in msvcrt, it should be moved to include/msvcrt. Thing is that MinGW supports tchar.h it seems, so we can do one of two things:
- Add conditionals in tchar.h as you suggested to do things differently depending on whether or not we link in msvcrt
- Move the current tchar.h to include/msvcrt, and create a new one to support the MinGW/glibc case.
Alexandre?
tchar.h should not depend on msvcrt IMO, at least not in ASCII mode, so it should use the normal function names without underscores. It's not 100% compatible, but it should still do the right thing, both with and without msvcrt.
On January 2, 2003 12:38 pm, Alexandre Julliard wrote:
tchar.h should not depend on msvcrt IMO, at least not in ASCII mode, so it should use the normal function names without underscores. It's not 100% compatible, but it should still do the right thing, both with and without msvcrt.
Sounds good. But since we are on the subject, here's another thing that's been troubling me: we have 3 flavors of the crt to worry about: glibc, msvcrt, and cygwin libc (let's call it cygcrt). To be honest, I haven't looked in detail at cygcrt but I guess it's a derivative of glibc (as it is used to port Unix stuff). However, it has stuff such as io.h which is not present in Unix, and is reminiscent of msvcrt.
When compiling stuff on Windows with gcc (mingw), it links by default with cygcrt if available. If the -mno-cygwin option is used, or cygwin is not available, it links against crtdll. Of course, the appropriate headers are used automatically.
For winegcc, I mapped the -mno-cygwin option to use msvcrt, otherwise we use the native glibc. This is the closest mapping I could find, and it works fairly well, with a few caveats such as the missing io.h in glibc.
Anyhow, and ideas on how to deal with all this?
Wine,
Running a large VB app on 20021125, and I get this output:
fixme:ole:CoSetState (0x653c3f80),stub! fixme:ole:CoRegisterMessageFilter stub fixme:win32:PE_CreateModule Security directory ignored fixme:win32:GetCalendarInfoA (00000809,00000001,20000030,(nil),0,0x403ac1f4): quarter-stub fixme:win32:GetCalendarInfoW (00000809,00000001,20000030,(nil),0,0x403ac1f4): quarter-stub fixme:win32:PE_CreateModule Security directory ignored wine: Unhandled exception, starting debugger... fixme:ole:CoSetState ((nil)),stub!
Is there anything I can do to make my application run?
Ben
On January 3, 2003 01:43 am, Ben Clewett wrote:
Wine,
Running a large VB app on 20021125, and I get this output:
fixme:ole:CoSetState (0x653c3f80),stub! fixme:ole:CoRegisterMessageFilter stub fixme:win32:PE_CreateModule Security directory ignored fixme:win32:GetCalendarInfoA (00000809,00000001,20000030,(nil),0,0x403ac1f4): quarter-stub fixme:win32:GetCalendarInfoW (00000809,00000001,20000030,(nil),0,0x403ac1f4): quarter-stub fixme:win32:PE_CreateModule Security directory ignored wine: Unhandled exception, starting debugger... fixme:ole:CoSetState ((nil)),stub!
Is there anything I can do to make my application run?
Ben
That output probably has little to do with the application not running.
Did the debugger come up? If so were you able to get a stack trace?
Try running with --debugmsg +relay to see if the failure occurred during a wine function (but don't be surprised if it doesn't).
Is the VB App commercial or a one-off? Does it have a name? (You never know; someone else may have been working with it)
-
Alexandre Julliard -
Ben Clewett -
Bill Medland -
Dimitrie O. Paun -
Francois Gouget