In Windows Vista, the wild-card character enclosed with the quart is progressed.
ex)
#include <stdio.h>
main(int argc, char *argv[])
{
int i;
for (i = 0; i < argc; i++) {
fprintf(stdout, "%d [%s]\n", i, argv[i]);
}
}
*** for Windows Vista ***
C:\> test.exe "*u*"
0 [test.exe]
1 [autoexec.bat]
2 [Documents and Settings]
3 [System Volume Information]
4 [Users]
*** for Windows XP, 2000, Me, etc... ***
C:\> test.exe "*u*"
0 [test.exe]
1 [*u*]
There seems to be a problem in MSVCRT __getmainargs() called in Mingw-runtime when a little
examining it.
ex2)
#include <stdio.h>
int _CRT_glob = -1;
typedef struct {
int newmode;
} _startupinfo;
_startupinfo start_info;
extern __getmainargs(int *, char ***, char ***, int, _startupinfo *);
main()
{
int i;
char **env;
start_info.newmode = 0;
__getmainargs(&argc, &argv, &env, _CRT_glob, &start_info);
for (i = 0; i < argc; i++) {
fprintf(stdout, "%d [%s]\n", i, argv[i]);
}
}
The operation of this test program seems is similarly amusing only Windows Vista.
Logged In: YES
user_id=15438
Originator: NO
Waiting on developers with Vista to fix.
Logged In: YES
user_id=1692229
Originator: YES
It solved it by linking libmsvcr71.a .
> cc test.c -o test -lmsvcr71
But,
> objdump -p test.exe | grep dll
DLL Name: KERNEL32.dll
DLL Name: msvcr71.dll
DLL Name: msvcrt.dll
It is anxious that both msvcrt.dll and msvcr71.dll are linked.
Logged In: YES
user_id=15438
Originator: NO
So the fix is to change the GCC spec file to add -lmsvcr71 if it exists. It is OK that both DLL are linked into the binary as differing libraries may need msvcrt.dll.
I'm assigning to Danny to see what he thinks.
Logged In: YES
user_id=11494
Originator: NO
From your description, this is a MSVCRT.dll/Vista WOW64 bug, not a mingw or gcc bug.
Please help me to reproduce by providing:
Build ID for Vista RC or beta.
Version of your msvcrt.dll (the one that is used up by WOW64 emulation layer).
I do not have a local Vista machine nor Vista documentation, so I am forced to remote testing. From what I have read, Vista RC still has significant problems. But, thanks for the report, nonetheless. I will look into it more seriously once I have fulltime Vista machine.
I do not think the msvcr71.dll specs workaround is good idea, generally, since this library is not system lib (nor are msvcr80.dll, etc) I understand that Vista supports symlinks. Would a local softlink of libmsvcrt.a to libmvscr**.a work?
Danny
Logged In: YES
user_id=1692229
Originator: YES
I am operating it on Virtual PC 2007 beta for the test of Windows Vista.
Microsoft Windows Vista Ultimate
Version 6.0.6000 build 6000
msvcrt.dll 7.0.6000.16386
> I do not think the msvcr71.dll specs workaround is good idea, generally,
> since this library is not system lib (nor are msvcr80.dll, etc) I
> understand that Vista supports symlinks. Would a local softlink of
> libmsvcrt.a to libmvscr**.a work?
It is not made to do a to our regret enough test yet.
Logged In: YES
user_id=1692229
Originator: YES
I am operating it on Virtual PC 2007 beta for the test of Windows Vista.
Microsoft Windows Vista Ultimate
Version 6.0.6000 build 6000
msvcrt.dll 7.0.6000.16386
> I do not think the msvcr71.dll specs workaround is good idea, generally,
> since this library is not system lib (nor are msvcr80.dll, etc) I
> understand that Vista supports symlinks. Would a local softlink of
> libmsvcrt.a to libmvscr**.a work?
It is not made to do a to our regret enough test yet.
Logged In: YES
user_id=1766271
Originator: NO
And using vista I can't download the files
I'm believing this to be covered by other issues involved with globbing.
I guess you mean the later bug report, where we identified that Microsoft have wilfully broken globbing in Vista (and later) MSVCRT.DLL? (And they've refused to correct the defect). If so, then yes, the new globbing code I've provided for libmingwex.a, and the accompanying modified start-up code, (which no longer calls _getmainargs() by default), should fix this.