Menu
▾
▴
mingw-users
|
From: Keith M. <kei...@us...> - 2014-08-29 14:24:59
|
Folks, If you still use Windows versions pre-dating WinXP, you need to read this; we may not be able to offer you continuing support! Following my recent withdrawal of the Version 4.x MinGW runtime and w32api libraries from general release, (on account of the excessive number of unresolved regressions which they've introduced), I've been reviewing some of the related bug reports, with a view to backporting some solutions to an continuation of the version 3.x series. Three, which I'd like to address soonest, are: http://sourceforge.net/p/mingw/bugs/1621/ (aspect #2) http://sourceforge.net/p/mingw/bugs/2098/ http://sourceforge.net/p/mingw/bugs/2106/ Unfortunately, the last of these raises an issue, (which I suspect is already present with existing 3.x dirent.[hc] implementations), which makes it increasingly difficult for us to continue supporting users of Windows versions predating WinXP ... the _USE_32BIT_TIME_T insanity! The problem is that we *must* provide an implementation which is deterministically independent of the _USE_32BIT_TIME_T nonsense, so users are not constrained by what we choose when we build libmingwex.a; this precludes simple _findfirst()/_findnext() dependencies, and forces us to look to _findfirst64()/_findnext64() or similar, which behave completely independently of _USE_32BIT_TIME_T. As I've noted on ticket #2106, the _findfirst64()/_findnext64() combination *appears* to be the most widely acceptable; the MSDN reference, which I cite on the ticket, suggests that this pair of functions has been supported since Win98. However, my own research, (summarized at http://sourceforge.net/projects/keithmarshall.u/files/msvcrt-xref/msvcrt.exports.pdf/download), suggests otherwise. Now, the solution for bug #1621 will introduce dependencies on the dirent implementation into the mingwrt initialization code, so any application built with this in place will likely fail on any older version of Windows, which lacks _findfirst64()/_findnext64() support. So, if you are a user of such a system, and you care about continuing support from MinGW.org, you need to speak up now, (and you need to be prepared to pitch in, and help me to develop a solution which will continue to work for you; I have some ideas, but I cannot test their effectiveness on anything older than WinXP). -- Regards, Keith. |
|
From: Eli Z. <el...@gn...> - 2014-08-29 15:04:38
|
> Date: Fri, 29 Aug 2014 15:24:49 +0100 > From: Keith Marshall <kei...@us...> > > If you still use Windows versions pre-dating WinXP, you need to read > this; we may not be able to offer you continuing support! I hope I will change your mind on this. See below. > So, if you are a user of [Windows 9X], and you care about continuing > support from MinGW.org, you need to speak up now, (and you need to be > prepared to pitch in, and help me to develop a solution which will > continue to work for you; I have some ideas, but I cannot test their > effectiveness on anything older than WinXP). GNU Emacs for Windows nowadays builds almost exclusively with MinGW, and will most probably toss the MSVC support, now deprecated, at the next major release. Emacs still supports Windows 9X (through run-time tests and by loading unicows.dll for Unicode functions). There's a personal request by Richard Stallman to continue this support for the time being, the reason being that these systems are still widely used in the Third World. Dropping Windows 9X from MinGW will certainly mean that Emacs will be unable to comply with RMS's request. > Now, the solution for bug #1621 will introduce dependencies on the > dirent implementation into the mingwrt initialization code, so any > application built with this in place will likely fail on any older > version of Windows, which lacks _findfirst64()/_findnext64() support. My suggestion for breaking out of this conundrum is to reimplement these 2 functions (under slightly different names, if needed) in libmingwex. It cannot be too hard, as they still call FindFirstFile/FindNextFile, like the 32-bit functions did, right? I suggest to do the same with any other msvcrt functions that present a similar problem (if there are any). If this somehow fails to resolve the problem, please tell the details. Thanks. |
|
From: Keith M. <kei...@us...> - 2014-08-29 18:35:06
|
On 29/08/14 16:04, Eli Zaretskii wrote: >> Date: Fri, 29 Aug 2014 15:24:49 +0100 >> From: Keith Marshall <kei...@us...> >> >> If you still use Windows versions pre-dating WinXP, you need to read >> this; we may not be able to offer you continuing support! > > I hope I will change your mind on this. See below. It's not a matter of changing my mind -- I'd be delighted to be able to continue to support older Windows versions. It is, however, a matter of what I can reliably continue to support ... and reliably test. > Dropping Windows 9X from MinGW will certainly mean that Emacs will be > unable to comply with RMS's request [to continue supporting it]. > >> Now, the solution for bug #1621 will introduce dependencies on the >> dirent implementation into the mingwrt initialization code, so any >> application built with this in place will likely fail on any older >> version of Windows, which lacks _findfirst64()/_findnext64() support. > > My suggestion for breaking out of this conundrum is to reimplement > these 2 functions (under slightly different names, if needed) in > libmingwex. It cannot be too hard, as they still call > FindFirstFile/FindNextFile, like the 32-bit functions did, right? That may be a pragmatic solution ... even to the extent of just calling FindFirstFile()/FindNextFile() directly, within dirent.c itself. I say that it may be because MSDN tells us that the minimum supported client for this pair of functions, and their WIN32_FIND_DATA struct, is WinXP: http://msdn.microsoft.com/en-us/library/windows/desktop/aa364418(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/windows/desktop/aa365740(v=vs.85).aspx That's clearly a bogus claim, but how consistent is the layout of the WIN32_FIND_DATA struct, across all Windows versions? In particular, do its FILETIME members always provide resolution which is equivalent to __time64_t, and its nFileSize members always provide for resolution to a uint64_t file size? > I suggest to do the same with any other msvcrt functions that present > a similar problem (if there are any). I'm sure there are; _get_output_format() springs to mind. Our printf() implementation wants to call it, but it isn't always available. The mingwrt-3.x implementation worked around that by adding a stub to the import libraries for those MSVCRxx.DLL versions which were known not to provide it; 4.x regresses in this respect, compiling pformat.c, (which provides the core of the implementation for printf() and friends), as if _get_output_format() is *never* available. At the time when I wrote pformat.c, the 3.x approach was reasonable because no version of MSVCRT.DLL provided _get_output_format(). This is no longer true -- MSVCRT.DLL has provided it since Vista. I think we can do better that the 4.x regression though; I have a tentative implementation simulating the POSIX capability: dlsym( RTLD_DEFAULT, "_get_output_format" ) This would allow us to provide a replacement _mingw_get_output_format() -- tested and working on WinXP and Win7 -- which could delegate to _get_output_format() when available, or emulate it otherwise. -- Regards, Keith. |
|
From: Eli Z. <el...@gn...> - 2014-08-30 09:04:41
|
> Date: Sat, 30 Aug 2014 09:58:11 +0100 > From: Keith Marshall <kei...@us...> > > On 30/08/14 08:19, Eli Zaretskii wrote: > > Btw, one other complaint I have from Emacs users on Windows 9X is that > > the startup code of mingwrt-4.x uses some instruction(s) that crash > > with SIGILL on Windows 9X, presumably because those instructions > > require a newer CPU. So one other issue to keep an eye on is the GCC > > switches that define the target architecture: what mingwrt-3.x used up > > to 3.20 is OK, and should be kept, or at least not changed too > > drastically to drop older CPUs. > > Yes, but that's not so much an issue with mingwrt or w32api themselves, > but rather the configuration of the GCC used to build them. I stand corrected. > this issue should not arise when the runtime packages are built with > *my* GCC-4.8.2. Great, thanks. |
|
From: Riccardo M. <ric...@li...> - 2014-08-29 15:45:19
|
Hi, Keith Marshall wrote: > If you still use Windows versions pre-dating WinXP, you need to read > this; we may not be able to offer you continuing support! does this warning include Win2K (or maybe even NT4) or is it more specific to the 95/98/ME editions. Riccardo |
|
From: Keith M. <kei...@us...> - 2014-08-29 17:03:07
|
On 29/08/14 16:45, Riccardo Mottola wrote: > Keith Marshall wrote: >> If you still use Windows versions pre-dating WinXP, you need to read >> this; we may not be able to offer you continuing support! > > does this warning include Win2K (or maybe even NT4) or is it more > specific to the 95/98/ME editions. I don't know. I don't have access to MSVCRT.DLL from any Windows versions other than those I've listed in my summary document, to allow me to inspect the export tables. If you can help me out with that, I'll gladly update the document accordingly. -- Regards, Keith. |
|
From: <min...@sp...> - 2014-08-30 16:09:40
|
Keith Marshall wrote: > On 29/08/14 16:45, Riccardo Mottola wrote: >> Keith Marshall wrote: >>> If you still use Windows versions pre-dating WinXP, you need to read >>> this; we may not be able to offer you continuing support! >> >> does this warning include Win2K (or maybe even NT4) or is it more >> specific to the 95/98/ME editions. > > I don't know. I don't have access to MSVCRT.DLL from any Windows > versions other than those I've listed in my summary document, to allow > me to inspect the export tables. If you can help me out with that, I'll > gladly update the document accordingly. I have Windows 2000 SP4 installed in a virtual machine: - OS version : 5.00.2195 - MSVCRT.DLL version : 6.1.9844.0 Output from pexports is below. Is there anything else you need? Mark. C:\MinGW\bin>pexports PExports 0.46; Originally written 1998, Anders Norlander Updated 1999, Paul Sokolovsky, 2008, Tor Lillqvist, 2013, Keith Marshall ... C:\MinGW\bin>pexports c:\winnt\system32\msvcrt.dll LIBRARY MSVCRT.dll EXPORTS $I10_OUTPUT ??0__non_rtti_object@@QAE@ABV0@@Z ??0__non_rtti_object@@QAE@PBD@Z ??0bad_cast@@QAE@ABQBD@Z ??0bad_cast@@QAE@ABV0@@Z ??0bad_typeid@@QAE@ABV0@@Z ??0bad_typeid@@QAE@PBD@Z ??0exception@@QAE@ABQBD@Z ??0exception@@QAE@ABV0@@Z ??0exception@@QAE@XZ ??1__non_rtti_object@@UAE@XZ ??1bad_cast@@UAE@XZ ??1bad_typeid@@UAE@XZ ??1exception@@UAE@XZ ??1type_info@@UAE@XZ ??2@YAPAXI@Z ??3@YAXPAX@Z ??4__non_rtti_object@@QAEAAV0@ABV0@@Z ??4bad_cast@@QAEAAV0@ABV0@@Z ??4bad_typeid@@QAEAAV0@ABV0@@Z ??4exception@@QAEAAV0@ABV0@@Z ??8type_info@@QBEHABV0@@Z ??9type_info@@QBEHABV0@@Z ??_7__non_rtti_object@@6B@ DATA ??_7bad_cast@@6B@ DATA ??_7bad_typeid@@6B@ DATA ??_7exception@@6B@ DATA ??_E__non_rtti_object@@UAEPAXI@Z ??_Ebad_cast@@UAEPAXI@Z ??_Ebad_typeid@@UAEPAXI@Z ??_Eexception@@UAEPAXI@Z ??_G__non_rtti_object@@UAEPAXI@Z ??_Gbad_cast@@UAEPAXI@Z ??_Gbad_typeid@@UAEPAXI@Z ??_Gexception@@UAEPAXI@Z ??_U@YAPAXI@Z ??_V@YAXPAX@Z ?_query_new_handler@@YAP6AHI@ZXZ ?_query_new_mode@@YAHXZ ?_set_new_handler@@YAP6AHI@ZP6AHI@Z@Z ?_set_new_mode@@YAHH@Z ?_set_se_translator@@YAP6AXIPAU_EXCEPTION_POINTERS@@@ZP6AXI0@Z@Z ?before@type_info@@QBEHABV1@@Z ?name@type_info@@QBEPBDXZ ?raw_name@type_info@@QBEPBDXZ ?set_new_handler@@YAP6AXXZP6AXXZ@Z ?set_terminate@@YAP6AXXZP6AXXZ@Z ?set_unexpected@@YAP6AXXZP6AXXZ@Z ?terminate@@YAXXZ ?unexpected@@YAXXZ ?what@exception@@UBEPBDXZ _CIacos _CIasin _CIatan _CIatan2 _CIcos _CIcosh _CIexp _CIfmod _CIlog _CIlog10 _CIpow _CIsin _CIsinh _CIsqrt _CItan _CItanh _CxxThrowException _EH_prolog _Getdays _Getmonths _Gettnames _HUGE DATA _Strftime _XcptFilter __CxxFrameHandler __CxxLongjmpUnwind __RTCastToVoid __RTDynamicCast __RTtypeid __STRINGTOLD __argc DATA __argv DATA __badioinfo DATA __crtCompareStringA __crtGetLocaleInfoW __crtLCMapStringA __dllonexit __doserrno __fpecode __getmainargs __initenv DATA __isascii __iscsym __iscsymf __lc_codepage DATA __lc_collate_cp DATA __lc_handle DATA __lconv_init __mb_cur_max DATA __p___argc __p___argv __p___initenv __p___mb_cur_max __p___wargv __p___winitenv __p__acmdln __p__amblksiz __p__commode __p__daylight __p__dstbias __p__environ __p__fileinfo __p__fmode __p__iob __p__mbcasemap __p__mbctype __p__osver __p__pctype __p__pgmptr __p__pwctype __p__timezone __p__tzname __p__wcmdln __p__wenviron __p__winmajor __p__winminor __p__winver __p__wpgmptr __pioinfo DATA __pxcptinfoptrs __set_app_type __setlc_active DATA __setusermatherr __threadhandle __threadid __toascii __unDName __unDNameEx __unguarded_readlc_active DATA __wargv DATA __wgetmainargs __winitenv DATA _abnormal_termination _access _acmdln DATA _adj_fdiv_m16i _adj_fdiv_m32 _adj_fdiv_m32i _adj_fdiv_m64 _adj_fdiv_r _adj_fdivr_m16i _adj_fdivr_m32 _adj_fdivr_m32i _adj_fdivr_m64 _adj_fpatan _adj_fprem _adj_fprem1 _adj_fptan _adjust_fdiv DATA _aexit_rtn DATA _amsg_exit _assert _atodbl _atoi64 _atoldbl _beep _beginthread _beginthreadex _c_exit _cabs _callnewh _cexit _cgets _chdir _chdrive _chgsign _chkesp _chmod _chsize _clearfp _close _commit _commode DATA _control87 _controlfp _copysign _cprintf _cputs _creat _cscanf _ctime64 _ctype DATA _cwait _daylight DATA _dstbias DATA _dup _dup2 _ecvt _endthread _endthreadex _environ DATA _eof _errno _except_handler2 _except_handler3 _execl _execle _execlp _execlpe _execv _execve _execvp _execvpe _exit _expand _fcloseall _fcvt _fdopen _fgetchar _fgetwchar _filbuf _fileinfo DATA _filelength _filelengthi64 _fileno _findclose _findfirst _findfirst64 _findfirsti64 _findnext _findnext64 _findnexti64 _finite _flsbuf _flushall _fmode DATA _fpclass _fpieee_flt _fpreset _fputchar _fputwchar _fsopen _fstat _fstat64 _fstati64 _ftime _ftime64 _ftol _fullpath _futime _futime64 _gcvt _get_heap_handle _get_osfhandle _get_sbh_threshold _getch _getche _getcwd _getdcwd _getdiskfree _getdllprocaddr _getdrive _getdrives _getmaxstdio _getmbcp _getpid _getsystime _getw _getws _global_unwind2 _gmtime64 _heapadd _heapchk _heapmin _heapset _heapused _heapwalk _hypot _i64toa _i64tow _initterm _inp _inpd _inpw _iob DATA _isatty _isctype _ismbbalnum _ismbbalpha _ismbbgraph _ismbbkalnum _ismbbkana _ismbbkprint _ismbbkpunct _ismbblead _ismbbprint _ismbbpunct _ismbbtrail _ismbcalnum _ismbcalpha _ismbcdigit _ismbcgraph _ismbchira _ismbckata _ismbcl0 _ismbcl1 _ismbcl2 _ismbclegal _ismbclower _ismbcprint _ismbcpunct _ismbcspace _ismbcsymbol _ismbcupper _ismbslead _ismbstrail _isnan _itoa _itow _j0 _j1 _jn _kbhit _lfind _loaddll _local_unwind2 _localtime64 _lock _locking _logb _longjmpex _lrotl _lrotr _lsearch _lseek _lseeki64 _ltoa _ltow _makepath _mbbtombc _mbbtype _mbcasemap DATA _mbccpy _mbcjistojms _mbcjmstojis _mbclen _mbctohira _mbctokata _mbctolower _mbctombb _mbctoupper _mbctype DATA _mbsbtype _mbscat _mbschr _mbscmp _mbscoll _mbscpy _mbscspn _mbsdec _mbsdup _mbsicmp _mbsicoll _mbsinc _mbslen _mbslwr _mbsnbcat _mbsnbcmp _mbsnbcnt _mbsnbcoll _mbsnbcpy _mbsnbicmp _mbsnbicoll _mbsnbset _mbsncat _mbsnccnt _mbsncmp _mbsncoll _mbsncpy _mbsnextc _mbsnicmp _mbsnicoll _mbsninc _mbsnset _mbspbrk _mbsrchr _mbsrev _mbsset _mbsspn _mbsspnp _mbsstr _mbstok _mbstrlen _mbsupr _memccpy _memicmp _mkdir _mktemp _mktime64 _msize _nextafter _onexit _open _open_osfhandle _osplatform DATA _osver DATA _outp _outpd _outpw _pclose _pctype DATA _pgmptr DATA _pipe _popen _purecall _putch _putenv _putw _putws _pwctype DATA _read _rmdir _rmtmp _rotl _rotr _safe_fdiv _safe_fdivr _safe_fprem _safe_fprem1 _scalb _searchenv _seh_longjmp_unwind _set_error_mode _set_sbh_threshold _seterrormode _setjmp _setjmp3 _setmaxstdio _setmbcp _setmode _setsystime _sleep _snprintf _snwprintf _sopen _spawnl _spawnle _spawnlp _spawnlpe _spawnv _spawnve _spawnvp _spawnvpe _splitpath _stat _stat64 _stati64 _statusfp _strcmpi _strdate _strdup _strerror _stricmp _stricoll _strlwr _strncoll _strnicmp _strnicoll _strnset _strrev _strset _strtime _strupr _swab _sys_errlist DATA _sys_nerr DATA _tell _telli64 _tempnam _time64 _timezone DATA _tolower _toupper _tzname DATA _tzset _ui64toa _ui64tow _ultoa _ultow _umask _ungetch _unlink _unloaddll _unlock _utime _utime64 _vsnprintf _vsnwprintf _waccess _wasctime _wchdir _wchmod _wcmdln DATA _wcreat _wcsdup _wcsicmp _wcsicoll _wcslwr _wcsncoll _wcsnicmp _wcsnicoll _wcsnset _wcsrev _wcsset _wcsupr _wctime _wctime64 _wenviron DATA _wexecl _wexecle _wexeclp _wexeclpe _wexecv _wexecve _wexecvp _wexecvpe _wfdopen _wfindfirst _wfindfirst64 _wfindfirsti64 _wfindnext _wfindnext64 _wfindnexti64 _wfopen _wfreopen _wfsopen _wfullpath _wgetcwd _wgetdcwd _wgetenv _winmajor DATA _winminor DATA _winver DATA _wmakepath _wmkdir _wmktemp _wopen _wperror _wpgmptr DATA _wpopen _wputenv _wremove _wrename _write _wrmdir _wsearchenv _wsetlocale _wsopen _wspawnl _wspawnle _wspawnlp _wspawnlpe _wspawnv _wspawnve _wspawnvp _wspawnvpe _wsplitpath _wstat _wstat64 _wstati64 _wstrdate _wstrtime _wsystem _wtempnam _wtmpnam _wtoi _wtoi64 _wtol _wunlink _wutime _wutime64 _y0 _y1 _yn abort abs acos asctime asin atan atan2 atexit atof atoi atol bsearch calloc ceil clearerr clock cos cosh ctime difftime div exit exp fabs fclose feof ferror fflush fgetc fgetpos fgets fgetwc fgetws floor fmod fopen fprintf fputc fputs fputwc fputws fread free freopen frexp fscanf fseek fsetpos ftell fwprintf fwrite fwscanf getc getchar getenv gets getwc getwchar gmtime is_wctype isalnum isalpha iscntrl isdigit isgraph isleadbyte islower isprint ispunct isspace isupper iswalnum iswalpha iswascii iswcntrl iswctype iswdigit iswgraph iswlower iswprint iswpunct iswspace iswupper iswxdigit isxdigit labs ldexp ldiv localeconv localtime log log10 longjmp malloc mblen mbstowcs mbtowc memchr memcmp memcpy memmove memset mktime modf perror pow printf putc putchar puts putwc putwchar qsort raise rand realloc remove rename rewind scanf setbuf setlocale setvbuf signal sin sinh sprintf sqrt srand sscanf strcat strchr strcmp strcoll strcpy strcspn strerror strftime strlen strncat strncmp strncpy strpbrk strrchr strspn strstr strtod strtok strtol strtoul strxfrm swprintf swscanf system tan tanh time tmpfile tmpnam tolower toupper towlower towupper ungetc ungetwc vfprintf vfwprintf vprintf vsprintf vswprintf vwprintf wcscat wcschr wcscmp wcscoll wcscpy wcscspn wcsftime wcslen wcsncat wcsncmp wcsncpy wcspbrk wcsrchr wcsspn wcsstr wcstod wcstok wcstol wcstombs wcstoul wcsxfrm wctomb wprintf wscanf C:\MinGW\bin> |
|
From: Jan R. <tr...@mx...> - 2014-08-30 22:41:42
|
Keith Marshall wrote: > On 29/08/14 16:45, Riccardo Mottola wrote: >> Keith Marshall wrote: >>> If you still use Windows versions pre-dating WinXP, you need to read >>> this; we may not be able to offer you continuing support! >> >> does this warning include Win2K (or maybe even NT4) or is it more >> specific to the 95/98/ME editions. > > I don't know. I don't have access to MSVCRT.DLL from any Windows > versions other than those I've listed in my summary document, to allow > me to inspect the export tables. If you can help me out with that, I'll > gladly update the document accordingly. Hey everyone, let me chime in with my Windows NT4 virtual machine: - OS version: 4.0.1381 SP6a - MSVCRT.DLL version: 4.20.0.6201 Output from pexports: LIBRARY MSVCRT.dll EXPORTS $I10_OUTPUT ??0__non_rtti_object@@QAE@ABV0@@Z ??0__non_rtti_object@@QAE@PBD@Z ??0bad_cast@@QAE@ABQBD@Z ??0bad_cast@@QAE@ABV0@@Z ??0bad_typeid@@QAE@ABV0@@Z ??0bad_typeid@@QAE@PBD@Z ??0exception@@QAE@ABQBD@Z ??0exception@@QAE@ABV0@@Z ??0exception@@QAE@XZ ??1__non_rtti_object@@UAE@XZ ??1bad_cast@@UAE@XZ ??1bad_typeid@@UAE@XZ ??1exception@@UAE@XZ ??1type_info@@UAE@XZ ??2@YAPAXI@Z ??3@YAXPAX@Z ??4__non_rtti_object@@QAEAAV0@ABV0@@Z ??4bad_cast@@QAEAAV0@ABV0@@Z ??4bad_typeid@@QAEAAV0@ABV0@@Z ??4exception@@QAEAAV0@ABV0@@Z ??8type_info@@QBEHABV0@@Z ??9type_info@@QBEHABV0@@Z ??_7__non_rtti_object@@6B@ DATA ??_7bad_cast@@6B@ DATA ??_7bad_typeid@@6B@ DATA ??_7exception@@6B@ DATA ??_E__non_rtti_object@@UAEPAXI@Z ??_Ebad_cast@@UAEPAXI@Z ??_Ebad_typeid@@UAEPAXI@Z ??_Eexception@@UAEPAXI@Z ??_G__non_rtti_object@@UAEPAXI@Z ??_Gbad_cast@@UAEPAXI@Z ??_Gbad_typeid@@UAEPAXI@Z ??_Gexception@@UAEPAXI@Z ?_query_new_handler@@YAP6AHI@ZXZ ?_query_new_mode@@YAHXZ ?_set_new_handler@@YAP6AHI@ZP6AHI@Z@Z ?_set_new_mode@@YAHH@Z ?_set_se_translator@@YAP6AXIPAU_EXCEPTION_POINTERS@@@ZP6AXI0@Z@Z ?before@type_info@@QBEHABV1@@Z ?name@type_info@@QBEPBDXZ ?raw_name@type_info@@QBEPBDXZ ?set_new_handler@@YAP6AXXZP6AXXZ@Z ?set_terminate@@YAP6AXXZP6AXXZ@Z ?set_unexpected@@YAP6AXXZP6AXXZ@Z ?terminate@@YAXXZ ?unexpected@@YAXXZ ?what@exception@@UBEPBDXZ _CIacos _CIasin _CIatan _CIatan2 _CIcos _CIcosh _CIexp _CIfmod _CIlog _CIlog10 _CIpow _CIsin _CIsinh _CIsqrt _CItan _CItanh _CxxThrowException _EH_prolog _Getdays _Getmonths _Gettnames _HUGE DATA _Strftime _XcptFilter __CxxFrameHandler __CxxLongjmpUnwind __RTCastToVoid __RTDynamicCast __RTtypeid __STRINGTOLD __argc DATA __argv DATA __badioinfo DATA __crtCompareStringA __crtGetLocaleInfoW __crtLCMapStringA __dllonexit __doserrno __fpecode __getmainargs __initenv DATA __isascii __iscsym __iscsymf __lc_codepage DATA __lc_handle DATA __lconv_init __mb_cur_max DATA __p___argc __p___argv __p___initenv __p___mb_cur_max __p___wargv __p___winitenv __p__acmdln __p__amblksiz __p__commode __p__daylight __p__dstbias __p__environ __p__fileinfo __p__fmode __p__iob __p__mbctype __p__osver __p__pctype __p__pgmptr __p__pwctype __p__timezone __p__tzname __p__wcmdln __p__wenviron __p__winmajor __p__winminor __p__winver __p__wpgmptr __pioinfo DATA __pxcptinfoptrs __set_app_type __setlc_active DATA __setusermatherr __threadhandle __threadid __toascii __unDName __unguarded_readlc_active DATA __wargv DATA __wgetmainargs __winitenv DATA _abnormal_termination _access _acmdln DATA _adj_fdiv_m16i _adj_fdiv_m32 _adj_fdiv_m32i _adj_fdiv_m64 _adj_fdiv_r _adj_fdivr_m16i _adj_fdivr_m32 _adj_fdivr_m32i _adj_fdivr_m64 _adj_fpatan _adj_fprem _adj_fprem1 _adj_fptan _adjust_fdiv DATA _aexit_rtn DATA _amsg_exit _assert _atodbl _atoi64 _atoldbl _beep _beginthread _beginthreadex _c_exit _cabs _callnewh _cexit _cgets _chdir _chdrive _chgsign _chmod _chsize _clearfp _close _commit _commode DATA _control87 _controlfp _copysign _cprintf _cputs _creat _cscanf _ctype DATA _cwait _daylight DATA _dstbias DATA _dup _dup2 _ecvt _endthread _endthreadex _environ DATA _eof _errno _except_handler2 _except_handler3 _execl _execle _execlp _execlpe _execv _execve _execvp _execvpe _exit _expand _fcloseall _fcvt _fdopen _fgetchar _fgetwchar _filbuf _fileinfo DATA _filelength _filelengthi64 _fileno _findclose _findfirst _findfirsti64 _findnext _findnexti64 _finite _flsbuf _flushall _fmode DATA _fpclass _fpieee_flt _fpreset _fputchar _fputwchar _fsopen _fstat _fstati64 _ftime _ftol _fullpath _futime _gcvt _get_osfhandle _get_sbh_threshold _getch _getche _getcwd _getdcwd _getdiskfree _getdllprocaddr _getdrive _getdrives _getmaxstdio _getmbcp _getpid _getsystime _getw _getws _global_unwind2 _heapadd _heapchk _heapmin _heapset _heapused _heapwalk _hypot _i64toa _i64tow _initterm _inp _inpd _inpw _iob DATA _isatty _isctype _ismbbalnum _ismbbalpha _ismbbgraph _ismbbkalnum _ismbbkana _ismbbkprint _ismbbkpunct _ismbblead _ismbbprint _ismbbpunct _ismbbtrail _ismbcalnum _ismbcalpha _ismbcdigit _ismbcgraph _ismbchira _ismbckata _ismbcl0 _ismbcl1 _ismbcl2 _ismbclegal _ismbclower _ismbcprint _ismbcpunct _ismbcspace _ismbcsymbol _ismbcupper _ismbslead _ismbstrail _isnan _itoa _itow _j0 _j1 _jn _kbhit _lfind _loaddll _local_unwind2 _lock _locking _logb _longjmpex _lrotl _lrotr _lsearch _lseek _lseeki64 _ltoa _ltow _makepath _mbbtombc _mbbtype _mbccpy _mbcjistojms _mbcjmstojis _mbclen _mbctohira _mbctokata _mbctolower _mbctombb _mbctoupper _mbctype DATA _mbsbtype _mbscat _mbschr _mbscmp _mbscoll _mbscpy _mbscspn _mbsdec _mbsdup _mbsicmp _mbsicoll _mbsinc _mbslen _mbslwr _mbsnbcat _mbsnbcmp _mbsnbcnt _mbsnbcoll _mbsnbcpy _mbsnbicmp _mbsnbicoll _mbsnbset _mbsncat _mbsnccnt _mbsncmp _mbsncoll _mbsncpy _mbsnextc _mbsnicmp _mbsnicoll _mbsninc _mbsnset _mbspbrk _mbsrchr _mbsrev _mbsset _mbsspn _mbsspnp _mbsstr _mbstok _mbstrlen _mbsupr _memccpy _memicmp _mkdir _mktemp _msize _nextafter _onexit _open _open_osfhandle _osver DATA _outp _outpd _outpw _pclose _pctype DATA _pgmptr DATA _pipe _popen _purecall _putch _putenv _putw _putws _pwctype DATA _read _rmdir _rmtmp _rotl _rotr _safe_fdiv _safe_fdivr _safe_fprem _safe_fprem1 _scalb _searchenv _seh_longjmp_unwind _set_error_mode _set_sbh_threshold _seterrormode _setjmp _setjmp3 _setmaxstdio _setmbcp _setmode _setsystime _sleep _snprintf _snwprintf _sopen _spawnl _spawnle _spawnlp _spawnlpe _spawnv _spawnve _spawnvp _spawnvpe _splitpath _stat _stati64 _statusfp _strcmpi _strdate _strdup _strerror _stricmp _stricoll _strlwr _strncoll _strnicmp _strnicoll _strnset _strrev _strset _strtime _strupr _swab _sys_errlist DATA _sys_nerr DATA _tell _telli64 _tempnam _timezone DATA _tolower _toupper _tzname DATA _tzset _ui64toa _ui64tow _ultoa _ultow _umask _ungetch _unlink _unloaddll _unlock _utime _vsnprintf _vsnwprintf _waccess _wasctime _wchdir _wchmod _wcmdln DATA _wcreat _wcsdup _wcsicmp _wcsicoll _wcslwr _wcsncoll _wcsnicmp _wcsnicoll _wcsnset _wcsrev _wcsset _wcsupr _wctime _wenviron DATA _wexecl _wexecle _wexeclp _wexeclpe _wexecv _wexecve _wexecvp _wexecvpe _wfdopen _wfindfirst _wfindfirsti64 _wfindnext _wfindnexti64 _wfopen _wfreopen _wfsopen _wfullpath _wgetcwd _wgetdcwd _wgetenv _winmajor DATA _winminor DATA _winver DATA _wmakepath _wmkdir _wmktemp _wopen _wperror _wpgmptr DATA _wpopen _wputenv _wremove _wrename _write _wrmdir _wsearchenv _wsetlocale _wsopen _wspawnl _wspawnle _wspawnlp _wspawnlpe _wspawnv _wspawnve _wspawnvp _wspawnvpe _wsplitpath _wstat _wstati64 _wstrdate _wstrtime _wsystem _wtempnam _wtmpnam _wtoi _wtoi64 _wtol _wunlink _wutime _y0 _y1 _yn abort abs acos asctime asin atan atan2 atexit atof atoi atol bsearch calloc ceil clearerr clock cos cosh ctime difftime div exit exp fabs fclose feof ferror fflush fgetc fgetpos fgets fgetwc fgetws floor fmod fopen fprintf fputc fputs fputwc fputws fread free freopen frexp fscanf fseek fsetpos ftell fwprintf fwrite fwscanf getc getchar getenv gets getwc getwchar gmtime is_wctype isalnum isalpha iscntrl isdigit isgraph isleadbyte islower isprint ispunct isspace isupper iswalnum iswalpha iswascii iswcntrl iswctype iswdigit iswgraph iswlower iswprint iswpunct iswspace iswupper iswxdigit isxdigit labs ldexp ldiv localeconv localtime log log10 longjmp malloc mblen mbstowcs mbtowc memchr memcmp memcpy memmove memset mktime modf perror pow printf putc putchar puts putwc putwchar qsort raise rand realloc remove rename rewind scanf setbuf setlocale setvbuf signal sin sinh sprintf sqrt srand sscanf strcat strchr strcmp strcoll strcpy strcspn strerror strftime strlen strncat strncmp strncpy strpbrk strrchr strspn strstr strtod strtok strtol strtoul strxfrm swprintf swscanf system tan tanh time tmpfile tmpnam tolower toupper towlower towupper ungetc ungetwc vfprintf vfwprintf vprintf vsprintf vswprintf vwprintf wcscat wcschr wcscmp wcscoll wcscpy wcscspn wcsftime wcslen wcsncat wcsncmp wcsncpy wcspbrk wcsrchr wcsspn wcsstr wcstod wcstok wcstol wcstombs wcstoul wcsxfrm wctomb wprintf wscanf -- Jan |
|
From: Keith M. <kei...@us...> - 2014-08-31 04:55:24
|
On 30/08/14 17:09, min...@sp... wrote: > Keith Marshall wrote: >> On 29/08/14 16:45, Riccardo Mottola wrote: >>> Keith Marshall wrote: >>>> If you still use Windows versions pre-dating WinXP, you need to read >>>> this; we may not be able to offer you continuing support! >>> >>> does this warning include Win2K (or maybe even NT4) or is it more >>> specific to the 95/98/ME editions. >> >> I don't know. I don't have access to MSVCRT.DLL from any Windows >> versions other than those I've listed in my summary document, to allow >> me to inspect the export tables. If you can help me out with that, I'll >> gladly update the document accordingly. > > I have Windows 2000 SP4 installed in a virtual machine: > - OS version : 5.00.2195 > - MSVCRT.DLL version : 6.1.9844.0 > > Output from pexports is below. Is there anything else you need? > > [... snip ...] Excellent! Might have been slightly easier to extract, if provided as an attachment, but gives me all I need w.r.t. Win2K-SP4, as is. Thanks, Mark. On 30/08/14 17:10, min...@sp... wrote > Also found a Windows 98 first edition disc: > - OS version : 4.10.1998 > - MSVCRT.DLL version : 5.00.7128 > > pexports wouldn't run on Windows 98 - "The PEXPORTS.EXE file is > linked to missing export MSVCRT.DLL:_stat64" - but copying MSVCRT.DLL > to another machine and running pexports from there results in the > output below. > > [... snip ...] And again, thanks for this. On 30/08/14 23:26, Jan Ringoš wrote: > Hey everyone, let me chime in with my Windows NT4 virtual machine: > - OS version: 4.0.1381 SP6a > - MSVCRT.DLL version: 4.20.0.6201 > > Output from pexports: > > [... snip ...] And thanks also to you, Jan, for this. -- Regards, Keith. |
|
From: Keith M. <kei...@us...> - 2014-08-31 12:50:57
|
On 31/08/14 05:55, Keith Marshall wrote: > On 30/08/14 17:09, min...@sp... wrote: >> I have Windows 2000 SP4 installed in a virtual machine: >> - OS version : 5.00.2195 >> - MSVCRT.DLL version : 6.1.9844.0 > On 30/08/14 17:10, min...@sp... wrote >> Also found a Windows 98 first edition disc: >> - OS version : 4.10.1998 >> - MSVCRT.DLL version : 5.00.7128 > On 30/08/14 23:26, Jan Ringoš wrote: >> Hey everyone, let me chime in with my Windows NT4 virtual machine: >> - OS version: 4.0.1381 SP6a >> - MSVCRT.DLL version: 4.20.0.6201 Thanks again, guys. I've updated my document source, to incorporate the data from these. For completeness, can you please advise build dates for the respective versions of MSVCRT.DLL? Does anyone know what OS version of Vista provided MSVCRT.DLL version 7.0.6002.18005? I'd dumped the pexports listing from a machine at my former place of work, which I can no longer access, and I neglected to record the OS version. -- Regards, Keith. |
|
From: Raffaello D. Di N. <fas...@gm...> - 2014-08-31 13:33:08
|
2014-08-31 8:50 GMT-04:00 Keith Marshall < kei...@us...>: > Does anyone know what OS version of Vista provided MSVCRT.DLL version > 7.0.6002.18005? I'd dumped the pexports listing from a machine at my > former place of work, which I can no longer access, and I neglected to > record the OS version. > My 32-bit Vista SP2 (6.0.6002) has 7.0.6002.18551. -- Raf |
|
From: Raffaello D. Di N. <fas...@gm...> - 2014-08-31 13:36:48
|
(Resend - I accidentally sent HTML messages.) 2014-08-31 8:50 GMT-04:00 Keith Marshall <kei...@us...>: > Does anyone know what OS version of Vista provided MSVCRT.DLL version > 7.0.6002.18005? I'd dumped the pexports listing from a machine at my > former place of work, which I can no longer access, and I neglected to > record the OS version. My 32-bit Vista SP2 (6.0.6002) has 7.0.6002.18551. -- Raf |
|
From: <min...@sp...> - 2014-08-31 13:46:57
|
Keith Marshall wrote: > On 31/08/14 05:55, Keith Marshall wrote: >> On 30/08/14 17:09, min...@sp... wrote: >>> I have Windows 2000 SP4 installed in a virtual machine: >>> - OS version : 5.00.2195 >>> - MSVCRT.DLL version : 6.1.9844.0 - MSVCRT.DLL Modified : 2003-06-20 12:00:00 >> On 30/08/14 17:10, min...@sp... wrote >>> Also found a Windows 98 first edition disc: >>> - OS version : 4.10.1998 >>> - MSVCRT.DLL version : 5.00.7128 - MSVCRT.DLL Modified: 1998-05-11 19:01:00 >> On 30/08/14 23:26, Jan Ringoš wrote: >>> Hey everyone, let me chime in with my Windows NT4 virtual machine: >>> - OS version: 4.0.1381 SP6a >>> - MSVCRT.DLL version: 4.20.0.6201 > > Thanks again, guys. I've updated my document source, to incorporate the > data from these. > > For completeness, can you please advise build dates for the respective > versions of MSVCRT.DLL? I've added the modified timestamps for the Win98 and Win2k versions above. Presumably they correspond to the build dates. > Does anyone know what OS version of Vista provided MSVCRT.DLL version > 7.0.6002.18005? I'd dumped the pexports listing from a machine at my > former place of work, which I can no longer access, and I neglected to > record the OS version. Not sure about that one. I have Windows Vista SP2, 32-bit business edition, and that has: - OS version : 6.0.6002 - MSVCRT.DLL version : 7.0.6002.18551 - MSVCRT.DLL Modified : 2011-12-14 which appears to be a slightly newer version. I can supply the pexports output for that, if it would be helpful? Mark. |
|
From: Keith M. <kei...@us...> - 2014-08-31 14:01:53
|
On 31/08/14 14:46, min...@sp... wrote: >> For completeness, can you please advise build dates for the respective >> versions of MSVCRT.DLL? > > I've added the modified timestamps for the Win98 and Win2k versions > above. Presumably they correspond to the build dates. I think so, yes. Thanks. >> Does anyone know what OS version of Vista provided MSVCRT.DLL version >> 7.0.6002.18005? I'd dumped the pexports listing from a machine at my >> former place of work, which I can no longer access, and I neglected to >> record the OS version. > > Not sure about that one. I have Windows Vista SP2, 32-bit business > edition, and that has: > - OS version : 6.0.6002 > - MSVCRT.DLL version : 7.0.6002.18551 > - MSVCRT.DLL Modified : 2011-12-14 > which appears to be a slightly newer version. I can supply the pexports > output for that, if it would be helpful? Yes please. It may turn out to be the same as I have already, but a cross check is always worthwhile. (I guess that also matches what Raf has, on his Vista box, so may be a better source anyway). -- Regards, Keith. |
|
From: <min...@sp...> - 2014-08-31 21:35:35
Attachments:
msvcrt-WinVistaSP2-exports.txt
|
Keith Marshall wrote: > On 31/08/14 14:46, min...@sp... wrote: >>> Does anyone know what OS version of Vista provided MSVCRT.DLL version >>> 7.0.6002.18005? I'd dumped the pexports listing from a machine at my >>> former place of work, which I can no longer access, and I neglected to >>> record the OS version. >> >> Not sure about that one. I have Windows Vista SP2, 32-bit business >> edition, and that has: >> - OS version : 6.0.6002 >> - MSVCRT.DLL version : 7.0.6002.18551 >> - MSVCRT.DLL Modified : 2011-12-14 >> which appears to be a slightly newer version. I can supply the pexports >> output for that, if it would be helpful? > > Yes please. It may turn out to be the same as I have already, but a > cross check is always worthwhile. (I guess that also matches what Raf > has, on his Vista box, so may be a better source anyway). pexports output for MSVCRT 7.0.6002.18551 from Windows Vista SP2 is attached. Apologies for not attaching before; I had assumed the mailing list would strip attachments. Mark. |
|
From: Jan R. <tr...@mx...> - 2014-08-31 21:27:39
|
>> On 30/08/14 23:26, Jan Ringoš wrote: >>> Hey everyone, let me chime in with my Windows NT4 virtual machine: >>> - OS version: 4.0.1381 SP6a >>> - MSVCRT.DLL version: 4.20.0.6201 > > For completeness, can you please advise build dates for the respective > versions of MSVCRT.DLL? Sorry for responding a bit late, the file date is: 1996-10-14 -- Jan |
|
From: Raffaello D. Di N. <fas...@gm...> - 2014-08-31 13:26:44
|
I have functioning VirtualBox VMs with: - 95 (4.00.950) - 98 (4.10.1998, with IE4.0) - 98 SE (4.10.2222, with IE 5.0) - ME (4.90.3000 with IE 5.5) - NT 3.51 (3.51.1057) - NT 4.0 SP6a (4.00.1381, with IE 2.0) There are no programs or updates installed in any of them except NT 4 (which I keep for a different purpose), and the version of IE is the one that came with the OS (which is none for 95 and NT 3.51). Are you interested in the exports of msvcrt.dll from any of these? (In case you’re wondering, I also have 3.0, 3.1, WfW 3.11, XP, Vista, 7, and bunch of unices and Linux distros :) -- Raf |
|
From: <min...@sp...> - 2014-08-30 16:10:44
|
Keith Marshall wrote: > On 29/08/14 16:45, Riccardo Mottola wrote: >> Keith Marshall wrote: >>> If you still use Windows versions pre-dating WinXP, you need to read >>> this; we may not be able to offer you continuing support! >> >> does this warning include Win2K (or maybe even NT4) or is it more >> specific to the 95/98/ME editions. > > I don't know. I don't have access to MSVCRT.DLL from any Windows > versions other than those I've listed in my summary document, to allow > me to inspect the export tables. If you can help me out with that, I'll > gladly update the document accordingly. Also found a Windows 98 first edition disc: - OS version : 4.10.1998 - MSVCRT.DLL version : 5.00.7128 pexports wouldn't run on Windows 98 - "The PEXPORTS.EXE file is linked to missing export MSVCRT.DLL:_stat64" - but copying MSVCRT.DLL to another machine and running pexports from there results in the output below. C:\MinGW\bin>pexports PExports 0.46; Originally written 1998, Anders Norlander Updated 1999, Paul Sokolovsky, 2008, Tor Lillqvist, 2013, Keith Marshall ... C:\MinGW\bin>pexports Z:\Documents\aTemp\MSVCRT.DLL LIBRARY MSVCRT.dll EXPORTS $I10_OUTPUT ??0__non_rtti_object@@QAE@ABV0@@Z ??0__non_rtti_object@@QAE@PBD@Z ??0bad_cast@@QAE@ABQBD@Z ??0bad_cast@@QAE@ABV0@@Z ??0bad_typeid@@QAE@ABV0@@Z ??0bad_typeid@@QAE@PBD@Z ??0exception@@QAE@ABQBD@Z ??0exception@@QAE@ABV0@@Z ??0exception@@QAE@XZ ??1__non_rtti_object@@UAE@XZ ??1bad_cast@@UAE@XZ ??1bad_typeid@@UAE@XZ ??1exception@@UAE@XZ ??1type_info@@UAE@XZ ??2@YAPAXI@Z ??3@YAXPAX@Z ??4__non_rtti_object@@QAEAAV0@ABV0@@Z ??4bad_cast@@QAEAAV0@ABV0@@Z ??4bad_typeid@@QAEAAV0@ABV0@@Z ??4exception@@QAEAAV0@ABV0@@Z ??8type_info@@QBEHABV0@@Z ??9type_info@@QBEHABV0@@Z ??_7__non_rtti_object@@6B@ DATA ??_7bad_cast@@6B@ DATA ??_7bad_typeid@@6B@ DATA ??_7exception@@6B@ DATA ??_E__non_rtti_object@@UAEPAXI@Z ??_Ebad_cast@@UAEPAXI@Z ??_Ebad_typeid@@UAEPAXI@Z ??_Eexception@@UAEPAXI@Z ??_G__non_rtti_object@@UAEPAXI@Z ??_Gbad_cast@@UAEPAXI@Z ??_Gbad_typeid@@UAEPAXI@Z ??_Gexception@@UAEPAXI@Z ?_query_new_handler@@YAP6AHI@ZXZ ?_query_new_mode@@YAHXZ ?_set_new_handler@@YAP6AHI@ZP6AHI@Z@Z ?_set_new_mode@@YAHH@Z ?_set_se_translator@@YAP6AXIPAU_EXCEPTION_POINTERS@@@ZP6AXI0@Z@Z ?before@type_info@@QBEHABV1@@Z ?name@type_info@@QBEPBDXZ ?raw_name@type_info@@QBEPBDXZ ?set_new_handler@@YAP6AXXZP6AXXZ@Z ?set_terminate@@YAP6AXXZP6AXXZ@Z ?set_unexpected@@YAP6AXXZP6AXXZ@Z ?terminate@@YAXXZ ?unexpected@@YAXXZ ?what@exception@@UBEPBDXZ _CIacos _CIasin _CIatan _CIatan2 _CIcos _CIcosh _CIexp _CIfmod _CIlog _CIlog10 _CIpow _CIsin _CIsinh _CIsqrt _CItan _CItanh _CxxThrowException _EH_prolog _Getdays _Getmonths _Gettnames _HUGE DATA _Strftime _XcptFilter __CxxFrameHandler __CxxLongjmpUnwind __RTCastToVoid __RTDynamicCast __RTtypeid __STRINGTOLD __argc DATA __argv DATA __badioinfo DATA __crtCompareStringA __crtGetLocaleInfoW __crtLCMapStringA __dllonexit __doserrno __fpecode __getmainargs __initenv DATA __isascii __iscsym __iscsymf __lc_codepage DATA __lc_handle DATA __lconv_init __mb_cur_max DATA __p___argc __p___argv __p___initenv __p___mb_cur_max __p___wargv __p___winitenv __p__acmdln __p__amblksiz __p__commode __p__daylight __p__dstbias __p__environ __p__fileinfo __p__fmode __p__iob __p__mbcasemap __p__mbctype __p__osver __p__pctype __p__pgmptr __p__pwctype __p__timezone __p__tzname __p__wcmdln __p__wenviron __p__winmajor __p__winminor __p__winver __p__wpgmptr __pioinfo DATA __pxcptinfoptrs __set_app_type __setlc_active DATA __setusermatherr __threadhandle __threadid __toascii __unDName __unguarded_readlc_active DATA __wargv DATA __wgetmainargs __winitenv DATA _abnormal_termination _access _acmdln DATA _adj_fdiv_m16i _adj_fdiv_m32 _adj_fdiv_m32i _adj_fdiv_m64 _adj_fdiv_r _adj_fdivr_m16i _adj_fdivr_m32 _adj_fdivr_m32i _adj_fdivr_m64 _adj_fpatan _adj_fprem _adj_fprem1 _adj_fptan _adjust_fdiv DATA _aexit_rtn DATA _amsg_exit _assert _atodbl _atoi64 _atoldbl _beep _beginthread _beginthreadex _c_exit _cabs _callnewh _cexit _cgets _chdir _chdrive _chgsign _chmod _chsize _clearfp _close _commit _commode DATA _control87 _controlfp _copysign _cprintf _cputs _creat _cscanf _ctype DATA _cwait _daylight DATA _dstbias DATA _dup _dup2 _ecvt _endthread _endthreadex _environ DATA _eof _errno _except_handler2 _except_handler3 _execl _execle _execlp _execlpe _execv _execve _execvp _execvpe _exit _expand _fcloseall _fcvt _fdopen _fgetchar _fgetwchar _filbuf _fileinfo DATA _filelength _filelengthi64 _fileno _findclose _findfirst _findfirsti64 _findnext _findnexti64 _finite _flsbuf _flushall _fmode DATA _fpclass _fpieee_flt _fpreset _fputchar _fputwchar _fsopen _fstat _fstati64 _ftime _ftol _fullpath _futime _gcvt _get_osfhandle _get_sbh_threshold _getch _getche _getcwd _getdcwd _getdiskfree _getdllprocaddr _getdrive _getdrives _getmaxstdio _getmbcp _getpid _getsystime _getw _getws _global_unwind2 _heapadd _heapchk _heapmin _heapset _heapused _heapwalk _hypot _i64toa _i64tow _initterm _inp _inpd _inpw _iob DATA _isatty _isctype _ismbbalnum _ismbbalpha _ismbbgraph _ismbbkalnum _ismbbkana _ismbbkprint _ismbbkpunct _ismbblead _ismbbprint _ismbbpunct _ismbbtrail _ismbcalnum _ismbcalpha _ismbcdigit _ismbcgraph _ismbchira _ismbckata _ismbcl0 _ismbcl1 _ismbcl2 _ismbclegal _ismbclower _ismbcprint _ismbcpunct _ismbcspace _ismbcsymbol _ismbcupper _ismbslead _ismbstrail _isnan _itoa _itow _j0 _j1 _jn _kbhit _lfind _loaddll _local_unwind2 _lock _locking _logb _longjmpex _lrotl _lrotr _lsearch _lseek _lseeki64 _ltoa _ltow _makepath _mbbtombc _mbbtype _mbcasemap DATA _mbccpy _mbcjistojms _mbcjmstojis _mbclen _mbctohira _mbctokata _mbctolower _mbctombb _mbctoupper _mbctype DATA _mbsbtype _mbscat _mbschr _mbscmp _mbscoll _mbscpy _mbscspn _mbsdec _mbsdup _mbsicmp _mbsicoll _mbsinc _mbslen _mbslwr _mbsnbcat _mbsnbcmp _mbsnbcnt _mbsnbcoll _mbsnbcpy _mbsnbicmp _mbsnbicoll _mbsnbset _mbsncat _mbsnccnt _mbsncmp _mbsncoll _mbsncpy _mbsnextc _mbsnicmp _mbsnicoll _mbsninc _mbsnset _mbspbrk _mbsrchr _mbsrev _mbsset _mbsspn _mbsspnp _mbsstr _mbstok _mbstrlen _mbsupr _memccpy _memicmp _mkdir _mktemp _msize _nextafter _onexit _open _open_osfhandle _osver DATA _outp _outpd _outpw _pclose _pctype DATA _pgmptr DATA _pipe _popen _purecall _putch _putenv _putw _putws _pwctype DATA _read _rmdir _rmtmp _rotl _rotr _safe_fdiv _safe_fdivr _safe_fprem _safe_fprem1 _scalb _searchenv _seh_longjmp_unwind _set_error_mode _set_sbh_threshold _seterrormode _setjmp _setjmp3 _setmaxstdio _setmbcp _setmode _setsystime _sleep _snprintf _snwprintf _sopen _spawnl _spawnle _spawnlp _spawnlpe _spawnv _spawnve _spawnvp _spawnvpe _splitpath _stat _stati64 _statusfp _strcmpi _strdate _strdup _strerror _stricmp _stricoll _strlwr _strncoll _strnicmp _strnicoll _strnset _strrev _strset _strtime _strupr _swab _sys_errlist DATA _sys_nerr DATA _tell _telli64 _tempnam _timezone DATA _tolower _toupper _tzname DATA _tzset _ui64toa _ui64tow _ultoa _ultow _umask _ungetch _unlink _unloaddll _unlock _utime _vsnprintf _vsnwprintf _waccess _wasctime _wchdir _wchmod _wcmdln DATA _wcreat _wcsdup _wcsicmp _wcsicoll _wcslwr _wcsncoll _wcsnicmp _wcsnicoll _wcsnset _wcsrev _wcsset _wcsupr _wctime _wenviron DATA _wexecl _wexecle _wexeclp _wexeclpe _wexecv _wexecve _wexecvp _wexecvpe _wfdopen _wfindfirst _wfindfirsti64 _wfindnext _wfindnexti64 _wfopen _wfreopen _wfsopen _wfullpath _wgetcwd _wgetdcwd _wgetenv _winmajor DATA _winminor DATA _winver DATA _wmakepath _wmkdir _wmktemp _wopen _wperror _wpgmptr DATA _wpopen _wputenv _wremove _wrename _write _wrmdir _wsearchenv _wsetlocale _wsopen _wspawnl _wspawnle _wspawnlp _wspawnlpe _wspawnv _wspawnve _wspawnvp _wspawnvpe _wsplitpath _wstat _wstati64 _wstrdate _wstrtime _wsystem _wtempnam _wtmpnam _wtoi _wtoi64 _wtol _wunlink _wutime _y0 _y1 _yn abort abs acos asctime asin atan atan2 atexit atof atoi atol bsearch calloc ceil clearerr clock cos cosh ctime difftime div exit exp fabs fclose feof ferror fflush fgetc fgetpos fgets fgetwc fgetws floor fmod fopen fprintf fputc fputs fputwc fputws fread free freopen frexp fscanf fseek fsetpos ftell fwprintf fwrite fwscanf getc getchar getenv gets getwc getwchar gmtime is_wctype isalnum isalpha iscntrl isdigit isgraph isleadbyte islower isprint ispunct isspace isupper iswalnum iswalpha iswascii iswcntrl iswctype iswdigit iswgraph iswlower iswprint iswpunct iswspace iswupper iswxdigit isxdigit labs ldexp ldiv localeconv localtime log log10 longjmp malloc mblen mbstowcs mbtowc memchr memcmp memcpy memmove memset mktime modf perror pow printf putc putchar puts putwc putwchar qsort raise rand realloc remove rename rewind scanf setbuf setlocale setvbuf signal sin sinh sprintf sqrt srand sscanf strcat strchr strcmp strcoll strcpy strcspn strerror strftime strlen strncat strncmp strncpy strpbrk strrchr strspn strstr strtod strtok strtol strtoul strxfrm swprintf swscanf system tan tanh time tmpfile tmpnam tolower toupper towlower towupper ungetc ungetwc vfprintf vfwprintf vprintf vsprintf vswprintf vwprintf wcscat wcschr wcscmp wcscoll wcscpy wcscspn wcsftime wcslen wcsncat wcsncmp wcsncpy wcspbrk wcsrchr wcsspn wcsstr wcstod wcstok wcstol wcstombs wcstoul wcsxfrm wctomb wprintf wscanf C:\MinGW\bin> |
|
From: Raffaello D. Di N. <fas...@gm...> - 2014-08-31 13:35:25
|
(Resend - I accidentally sent HTML messages.) I have functioning VirtualBox VMs with: - 95 (4.00.950) - 98 (4.10.1998, with IE4.0) - 98 SE (4.10.2222, with IE 5.0) - ME (4.90.3000 with IE 5.5) - NT 3.51 (3.51.1057) - NT 4.0 SP6a (4.00.1381, with IE 2.0) There are no programs or updates installed in any of them except NT 4 (which I keep for a different purpose), and the version of IE is the one that came with the OS (which is none for 95 and NT 3.51). Are you interested in the exports of msvcrt.dll from any of these? (In case you’re wondering, I also have 3.0, 3.1, WfW 3.11, XP, Vista, 7, and bunch of unices and Linux distros :) -- Raf |
|
From: Eli Z. <el...@gn...> - 2014-08-31 15:32:28
|
> Date: Sun, 31 Aug 2014 13:50:50 +0100 > From: Keith Marshall <kei...@us...> > > Thanks again, guys. I've updated my document source, to incorporate the > data from these. If it's not too much of a bother, please tell when the updated PDF file is available for download. TIA |
|
From: Keith M. <kei...@us...> - 2014-08-31 17:07:30
|
On 31/08/14 16:32, Eli Zaretskii wrote: >> Thanks again, guys. I've updated my document source, to incorporate the >> data from these. > > If it's not too much of a bother, please tell when the updated PDF > file is available for download. Sure. I've posted a snapshot (without source for now) here: http://sourceforge.net/projects/keithmarshall.u/files/msvcrt-xref/snapshots/msvcrt.exports-20140831-1.pdf/download -- Regards, Keith. |
|
From: Raffaello D. Di N. <fas...@gm...> - 2014-08-31 19:26:53
Attachments:
msvcrt-exports.tar.xz
|
2014-08-31 10:09 GMT-04:00 Keith Marshall <kei...@us...>: > On 31/08/14 14:35, Raffaello D. Di Napoli wrote: >> I have functioning VirtualBox VMs with: >> - 95 (4.00.950) >> - 98 (4.10.1998, with IE4.0) >> - 98 SE (4.10.2222, with IE 5.0) >> - ME (4.90.3000, with IE 5.5) >> - NT 3.51 (3.51.1057) >> - NT 4.0 SP6a (4.00.1381, with IE 2.0) >> >> There are no programs or updates installed in any of them except NT 4 >> (which I keep for a different purpose), and the version of IE is the >> one that came with the OS (which is none for 95 and NT 3.51). >> >> Are you interested in the exports of msvcrt.dll from any of these? > > Definitely. Any that I don't already have, and which differ from those > which Mark and Jan have already provided, are worth a look. Instead of pexports I used dumpbin /exports since that’s what I have handy; the output is easily consumable with awk anyway. A few remarks: msvcrt.dll is not available in Windows 95 or NT 3.51, but crtdll.dll is, so for completeness I also dumped and attached the exports of crtdll.dll for all the Windows versions mentioned above. Also, all the crtdll.dll version 3.50.746.1 have the same exports (down to the symbols’ addresses), but a different overall file size. Strange. In the attachment, the format of each file name is: name.dll-dllver-winbrand-winver.exports . -- Raf |
|
From: <min...@sp...> - 2014-08-31 21:06:53
|
Raffaello D. Di Napoli wrote: > A few remarks: msvcrt.dll is not available in Windows 95 or NT 3.51, Related to that, I did come across the following unreferenced statement on Wikipedia: http://en.wikipedia.org/wiki/Microsoft_Windows_library_files "It [MSVCRT.DLL] has shipped with Windows versions since Windows 2000 for use by other Windows components. In older versions of Windows, programs which linked against MSVCRT.DLL were expected to install a compatible copy in the System32 folder..." Having said that, a fresh install of Windows98 (first edition) yesterday did include an MSVCRT.DLL. A couple of questions spring to mind... 1. Can presence of MSVCRT.DLL can be relied on for these older versions of Windows anyway? 2. Does MSVCRT.DLL fulfil the GPL's definition of a system library on those systems? Mark. |
|
From: Eli Z. <el...@gn...> - 2014-08-29 19:53:10
|
> Date: Fri, 29 Aug 2014 19:34:54 +0100 > From: Keith Marshall <kei...@us...> > > On 29/08/14 16:04, Eli Zaretskii wrote: > >> Date: Fri, 29 Aug 2014 15:24:49 +0100 > >> From: Keith Marshall <kei...@us...> > >> > >> If you still use Windows versions pre-dating WinXP, you need to read > >> this; we may not be able to offer you continuing support! > > > > I hope I will change your mind on this. See below. > > It's not a matter of changing my mind -- I'd be delighted to be able to > continue to support older Windows versions. That's very good to hear. > It is, however, a matter of > what I can reliably continue to support ... and reliably test. Yes, testing is a problem. But we can be pragmatic here as well: do our best effort in coding, and rely on Windows 9X users to report bugs, if any, and help us debug them. > > My suggestion for breaking out of this conundrum is to reimplement > > these 2 functions (under slightly different names, if needed) in > > libmingwex. It cannot be too hard, as they still call > > FindFirstFile/FindNextFile, like the 32-bit functions did, right? > > That may be a pragmatic solution ... even to the extent of just calling > FindFirstFile()/FindNextFile() directly, within dirent.c itself. Yes, that will also work. > I say that it may be because MSDN tells us that the minimum > supported client for this pair of functions, and their > WIN32_FIND_DATA struct, is WinXP: > http://msdn.microsoft.com/en-us/library/windows/desktop/aa364418(v=vs.85).aspx > http://msdn.microsoft.com/en-us/library/windows/desktop/aa365740(v=vs.85).aspx > > That's clearly a bogus claim Yes, that's a lie. MS consistently removed from MSDN any references to systems before XP, for reasons that have nothing to do with what is supported where. This is why I find this resource invaluable: http://winapi.freetechsecrets.com/win32/ This seems to be a copy of the old MSDN, which still describes what was available on Windows 9X (and even on Win32s). > how consistent is the layout of the WIN32_FIND_DATA struct, across > all Windows versions? It is entirely consistent and didn't change a bit. Emacs uses it extensively (it has its own implementation of dirent functions), and I have reports from Windows 9X users that this works for them. > In particular, do its FILETIME members always provide resolution > which is equivalent to __time64_t The time members are of the type FILETIME, which (as you know) are 64-bit values representing the number of 100-nanosecond intervals since January 1, 1601. So I see no problems here. > and its nFileSize members always provide for resolution to a > uint64_t file size? Yes, you get 2 32-bit values, for a total of 64 bits. > I think we can do better that the 4.x regression though; I have a > tentative implementation simulating the POSIX capability: > > dlsym( RTLD_DEFAULT, "_get_output_format" ) > > This would allow us to provide a replacement _mingw_get_output_format() > -- tested and working on WinXP and Win7 -- which could delegate to > _get_output_format() when available, or emulate it otherwise. Yes, this will surely work. Thanks. |
|
From: Keith M. <kei...@us...> - 2014-08-29 20:45:29
|
On 29/08/14 20:53, Eli Zaretskii wrote: >>>> If you still use Windows versions pre-dating WinXP, you need to read >>>> this; we may not be able to offer you continuing support! >>> >>> I hope I will change your mind on this. See below. >> >> It's not a matter of changing my mind -- I'd be delighted to be able to >> continue to support older Windows versions. > > That's very good to hear. > >> It is, however, a matter of >> what I can reliably continue to support ... and reliably test. > > Yes, testing is a problem. But we can be pragmatic here as well: do > our best effort in coding, and rely on Windows 9X users to report > bugs, if any, and help us debug them. Would that it were that easy. Sure, we can do our best, but often a bug report isn't followed up by effective feedback to aid debugging. >>> My suggestion for breaking out of this conundrum is to reimplement >>> these 2 functions (under slightly different names, if needed) in >>> libmingwex. It cannot be too hard, as they still call >>> FindFirstFile/FindNextFile, like the 32-bit functions did, right? >> >> That may be a pragmatic solution ... even to the extent of just calling >> FindFirstFile()/FindNextFile() directly, within dirent.c itself. > > Yes, that will also work. Yeah. Its the solution I intend to explore. > MS consistently removed from MSDN any references > to systems before XP, for reasons that have nothing to do with what is > supported where. This is why I find this resource invaluable: > > http://winapi.freetechsecrets.com/win32/ Thanks for this; I'll surely bookmark it. > It is entirely consistent and didn't change a bit. Emacs uses it > extensively (it has its own implementation of dirent functions), and I > have reports from Windows 9X users that this works for them. Good to know. Adds credibility to the proposed way forward. >> In particular, do its FILETIME members always provide resolution >> which is equivalent to __time64_t > > The time members are of the type FILETIME, which (as you know) are > 64-bit values representing the number of 100-nanosecond intervals > since January 1, 1601. So I see no problems here. So, not entirely consistent with __time64_t without adjustment, but does dirent really need to care? Probably not, since POSIX doesn't require, (nor even specify), that struct dirent should include *any* file time members; they're only present in our implementation to achieve alignment with an embedded _finddata_t, so any application relying on their content might be considered to be broken. >> and its nFileSize members always provide for resolution to a >> uint64_t file size? > > Yes, you get 2 32-bit values, for a total of 64 bits. I fully expected this, but once again, does dirent really care? I think not, because once again, POSIX doesn't specify it. >> I think we can do better that the 4.x regression though; I have a >> tentative implementation simulating the POSIX capability: >> >> dlsym( RTLD_DEFAULT, "_get_output_format" ) >> >> This would allow us to provide a replacement _mingw_get_output_format() >> -- tested and working on WinXP and Win7 -- which could delegate to >> _get_output_format() when available, or emulate it otherwise. > > Yes, this will surely work. Thanks for the vote of confidence. -- Regards, Keith. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X