From: Dongsheng S. <don...@gm...> - 2010-09-29 08:34:55
Attachments:
signature.asc
|
When I build libiconv NLS version, I can not run iconv.exe, which reference a non-exist symbol 'wcsnlen', from lib32\msvcrt.def, I can see this symbol after the following comments line: ; msvcr80.dll and later If we want to support Windows XP (SP3 or later), we should not include symbols which not belong to msvcrt.dll: File Version: 7.0.2600.5512 (xpsp.080413-2111) Product Version: 6.1.8638.5512 Regards, Dongsheng |
From: JonY <jo...@us...> - 2010-09-29 09:56:49
Attachments:
0xED74C077.asc
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/29/2010 16:34, Dongsheng Song wrote: > When I build libiconv NLS version, I can not run iconv.exe, which reference > a non-exist symbol 'wcsnlen', from lib32\msvcrt.def, I can see this symbol > after the following comments line: > > ; msvcr80.dll and later > > If we want to support Windows XP (SP3 or later), we should not include > symbols which not belong to msvcrt.dll: > > File Version: 7.0.2600.5512 (xpsp.080413-2111) > Product Version: 6.1.8638.5512 > > Regards, > Dongsheng > > Hello, As far as I know, this is not a bug. That comment means that it is available with Windows 7. Until its reimplemented in libmingwex, the proper fix would be not to call it if you expect your program to run on earlier versions of windows. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) iEYEARECAAYFAkyjDVMACgkQp56AKe10wHePnACgkdBty/rCtwSeesr0Ec0mHM+e 1O4An0uG/nzCXqwuFm4KW20PB+cspJNJ =/lfc -----END PGP SIGNATURE----- |
From: Dongsheng S. <don...@gm...> - 2010-09-29 13:39:57
|
On Wed, Sep 29, 2010 at 17:56, JonY <jo...@us...> wrote: > On 9/29/2010 16:34, Dongsheng Song wrote: > > When I build libiconv NLS version, I can not run iconv.exe, which reference > > a non-exist symbol 'wcsnlen', from lib32\msvcrt.def, I can see this symbol > > after the following comments line: > > > > ; msvcr80.dll and later > > > > If we want to support Windows XP (SP3 or later), we should not include > > symbols which not belong to msvcrt.dll: > > > > File Version: 7.0.2600.5512 (xpsp.080413-2111) > > Product Version: 6.1.8638.5512 > > As far as I know, this is not a bug. That comment means that it is > available with Windows 7. > > Until its reimplemented in libmingwex, the proper fix would be not to > call it if you expect your program to run on earlier versions of windows. But we can not ensure third party software DO NOT call those functions, so we must drop them or defined in guard blocks like this: /* Windows 7 */ #if _WIN32_WINNT >= 0x0601 #endif /* Windows Vista or Server 2008 */ #if _WIN32_WINNT >= 0x0600 #endif |
From: JonY <jo...@us...> - 2010-09-29 13:52:23
Attachments:
0xED74C077.asc
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/29/2010 21:39, Dongsheng Song wrote: > On Wed, Sep 29, 2010 at 17:56, JonY <jo...@us...> wrote: >> On 9/29/2010 16:34, Dongsheng Song wrote: >>> When I build libiconv NLS version, I can not run iconv.exe, which reference >>> a non-exist symbol 'wcsnlen', from lib32\msvcrt.def, I can see this symbol >>> after the following comments line: >>> >>> ; msvcr80.dll and later >>> >>> If we want to support Windows XP (SP3 or later), we should not include >>> symbols which not belong to msvcrt.dll: >>> >>> File Version: 7.0.2600.5512 (xpsp.080413-2111) >>> Product Version: 6.1.8638.5512 >> >> As far as I know, this is not a bug. That comment means that it is >> available with Windows 7. >> >> Until its reimplemented in libmingwex, the proper fix would be not to >> call it if you expect your program to run on earlier versions of windows. > > But we can not ensure third party software DO NOT call those functions, > so we must drop them or defined in guard blocks like this: > > /* Windows 7 */ > #if _WIN32_WINNT >= 0x0601 > #endif > > /* Windows Vista or Server 2008 */ > #if _WIN32_WINNT >= 0x0600 > #endif > Hi, hacking the headers will not work due to how link tests work, linking will still succeed even without the prototype declared. Dropping them is also out of the question if we want to support Vista/7 users. You will need to fix up the third party applications that use them. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) iEUEARECAAYFAkyjRIcACgkQp56AKe10wHfwDACePS6k5gEGUPrqrxhf4bNMN0PC Cf8AmOZLpZheCrmU8a2x9613laKX87Q= =fOWC -----END PGP SIGNATURE----- |
From: Xiaofan C. <xia...@gm...> - 2010-09-30 23:31:41
|
On Wed, Sep 29, 2010 at 9:52 PM, JonY <jo...@us...> wrote: > On 9/29/2010 21:39, Dongsheng Song wrote: >> But we can not ensure third party software DO NOT call those functions, >> so we must drop them or defined in guard blocks like this: >> >> /* Windows 7 */ >> #if _WIN32_WINNT >= 0x0601 >> #endif >> >> /* Windows Vista or Server 2008 */ >> #if _WIN32_WINNT >= 0x0600 >> #endif >> > hacking the headers will not work due to how link tests work, linking > will still succeed even without the prototype declared. But I feel this is still better than nothing. This depends how the other 3rd party project carries out the tests. If it is only linking test then it works. But if it is more than that (actually run it), then it will fail under XP. > Dropping them is also out of the question if we want to support Vista/7 > users. BTW, what is the supported OS for MinGW-w64 32bit and 64bit tool chain. Win2k onwards? Or XP onwards? I could not find this out from the Wiki. -- Xiaofan |
From: Xiaofan C. <xia...@gm...> - 2010-09-29 13:57:03
|
On Wed, Sep 29, 2010 at 5:56 PM, JonY <jo...@us...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 9/29/2010 16:34, Dongsheng Song wrote: >> When I build libiconv NLS version, I can not run iconv.exe, which reference >> a non-exist symbol 'wcsnlen', from lib32\msvcrt.def, I can see this symbol >> after the following comments line: >> >> ; msvcr80.dll and later >> >> If we want to support Windows XP (SP3 or later), we should not include >> symbols which not belong to msvcrt.dll: >> >> File Version: 7.0.2600.5512 (xpsp.080413-2111) >> Product Version: 6.1.8638.5512 >> > As far as I know, this is not a bug. That comment means that it is > available with Windows 7. Is this correct? http://msdn.microsoft.com/en-us/library/z50ty2zh%28VS.80%29.aspx So it can be available for many versions of Windows. -- Xiaofan |
From: Dongsheng S. <don...@gm...> - 2010-09-29 14:23:53
|
On Wed, Sep 29, 2010 at 21:56, Xiaofan Chen <xia...@gm...> wrote: > On Wed, Sep 29, 2010 at 5:56 PM, JonY <jo...@us...> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 9/29/2010 16:34, Dongsheng Song wrote: >>> When I build libiconv NLS version, I can not run iconv.exe, which reference >>> a non-exist symbol 'wcsnlen', from lib32\msvcrt.def, I can see this symbol >>> after the following comments line: >>> >>> ; msvcr80.dll and later >>> >>> If we want to support Windows XP (SP3 or later), we should not include >>> symbols which not belong to msvcrt.dll: >>> >>> File Version: 7.0.2600.5512 (xpsp.080413-2111) >>> Product Version: 6.1.8638.5512 >>> >> As far as I know, this is not a bug. That comment means that it is >> available with Windows 7. > > Is this correct? > http://msdn.microsoft.com/en-us/library/z50ty2zh%28VS.80%29.aspx > > So it can be available for many versions of Windows. > > -- > Xiaofan > No, the page is incorrect. I confirmed both XP and 2003 R2 no wcsnlen defined. |
From: JonY <jo...@us...> - 2010-09-29 14:24:39
Attachments:
0xED74C077.asc
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/29/2010 21:56, Xiaofan Chen wrote: > On Wed, Sep 29, 2010 at 5:56 PM, JonY <jo...@us...> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 9/29/2010 16:34, Dongsheng Song wrote: >>> When I build libiconv NLS version, I can not run iconv.exe, which reference >>> a non-exist symbol 'wcsnlen', from lib32\msvcrt.def, I can see this symbol >>> after the following comments line: >>> >>> ; msvcr80.dll and later >>> >>> If we want to support Windows XP (SP3 or later), we should not include >>> symbols which not belong to msvcrt.dll: >>> >>> File Version: 7.0.2600.5512 (xpsp.080413-2111) >>> Product Version: 6.1.8638.5512 >>> >> As far as I know, this is not a bug. That comment means that it is >> available with Windows 7. > > Is this correct? > http://msdn.microsoft.com/en-us/library/z50ty2zh%28VS.80%29.aspx > > So it can be available for many versions of Windows. > That page is specific to VS2005. As long as you are using VS2005, you'll be using MSVCR80.DLL, so this page doesn't describe what MSVCRT.DLL will provide unfortunately. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) iEYEARECAAYFAkyjR+AACgkQp56AKe10wHdhbgCfbQlCLGA4JKHTu6oNVPXEhDSq czYAn0ZwBLRMn3MGdOsF2T+BA1/wJhRN =cAg9 -----END PGP SIGNATURE----- |
From: Xiaofan C. <xia...@gm...> - 2010-09-29 14:30:50
|
On Wed, Sep 29, 2010 at 10:06 PM, JonY <jo...@us...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 9/29/2010 21:56, Xiaofan Chen wrote: >> On Wed, Sep 29, 2010 at 5:56 PM, JonY <jo...@us...> wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> On 9/29/2010 16:34, Dongsheng Song wrote: >>>> When I build libiconv NLS version, I can not run iconv.exe, which reference >>>> a non-exist symbol 'wcsnlen', from lib32\msvcrt.def, I can see this symbol >>>> after the following comments line: >>>> >>>> ; msvcr80.dll and later >>>> >>>> If we want to support Windows XP (SP3 or later), we should not include >>>> symbols which not belong to msvcrt.dll: >>>> >>>> File Version: 7.0.2600.5512 (xpsp.080413-2111) >>>> Product Version: 6.1.8638.5512 >>>> >>> As far as I know, this is not a bug. That comment means that it is >>> available with Windows 7. >> >> Is this correct? >> http://msdn.microsoft.com/en-us/library/z50ty2zh%28VS.80%29.aspx >> >> So it can be available for many versions of Windows. >> > > That page is specific to VS2005. As long as you are using VS2005, you'll > be using MSVCR80.DLL, so this page doesn't describe what MSVCRT.DLL will > provide unfortunately. Yes. The thing is that basically MSVCRT.dll is kind of fixed at Windows 2000 and Visual C++ 6.0. So those provided by the later VC++ runtime (VS2005/2008/2010) will not be provided by msvcrt.dll. And this is not specific to Windows version, but the C runtime library installed. -- Xiaofan |
From: Kai T. <kti...@go...> - 2010-09-29 14:34:00
|
2010/9/29 JonY <jo...@us...>: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 9/29/2010 21:56, Xiaofan Chen wrote: >> On Wed, Sep 29, 2010 at 5:56 PM, JonY <jo...@us...> wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> On 9/29/2010 16:34, Dongsheng Song wrote: >>>> When I build libiconv NLS version, I can not run iconv.exe, which reference >>>> a non-exist symbol 'wcsnlen', from lib32\msvcrt.def, I can see this symbol >>>> after the following comments line: >>>> >>>> ; msvcr80.dll and later >>>> >>>> If we want to support Windows XP (SP3 or later), we should not include >>>> symbols which not belong to msvcrt.dll: >>>> >>>> File Version: 7.0.2600.5512 (xpsp.080413-2111) >>>> Product Version: 6.1.8638.5512 >>>> >>> As far as I know, this is not a bug. That comment means that it is >>> available with Windows 7. >> >> Is this correct? >> http://msdn.microsoft.com/en-us/library/z50ty2zh%28VS.80%29.aspx >> >> So it can be available for many versions of Windows. >> > > That page is specific to VS2005. As long as you are using VS2005, you'll > be using MSVCR80.DLL, so this page doesn't describe what MSVCRT.DLL will > provide unfortunately. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.16 (MingW32) > > iEYEARECAAYFAkyjR+AACgkQp56AKe10wHdhbgCfbQlCLGA4JKHTu6oNVPXEhDSq > czYAn0ZwBLRMn3MGdOsF2T+BA1/wJhRN > =cAg9 > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Mingw-w64-public mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > The only general solution for this would be that someone contributes an implementation for this function. So we don't dependent here. The only issue I see here is that this wcstrnlen possibly depends on internal undocumented stuff. I'll do some research for this. Regards, Kai -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | (")_(") him gain world domination |
From: Dongsheng S. <don...@gm...> - 2010-09-30 01:44:06
Attachments:
signature.asc
|
On 2010-9-29 22:33, Kai Tietz wrote: >>>> On Wed, Sep 29, 2010 at 5:56 PM, JonY <jo...@us...> wrote: >>>>> As far as I know, this is not a bug. That comment means that it is >>>>> available with Windows 7. >>>>> >>>>> Until its reimplemented in libmingwex, the proper fix would be not to >>>>> call it if you expect your program to run on earlier versions of windows. >>>> No, this is not possible/acceptable. For example, the following code is very general: # if HAVE_WCSNLEN # define local_wcsnlen wcsnlen # else static size_t local_wcsnlen (const wchar_t *s, size_t maxlen) { const wchar_t *ptr; for (ptr = s; maxlen > 0 && *ptr != (wchar_t) 0; ptr++, maxlen--) ; return ptr - s; } # endif But since wcsnlen in both headers and libmsvrt.a, the autotools always report 'yes, your target platform have wcsnlen' !!! If we do not want to drop these symbols not in windows XP, we should declare: mingw-64 maybe generate invalid dll/exe files on target platform older than windows 7. Because these files maybe reference symbols only valid on windows 7, please check your dll/exe files carefully after build. > The only general solution for this would be that someone contributes > an implementation for this function. So we don't dependent here. The > only issue I see here is that this wcstrnlen possibly depends on > internal undocumented stuff. I'll do some research for this. Maybe there have another solution: S1: the intersection of XP and 2k3 symbols in msvcrt.dll S2: the intersection of VISTA and 2k8 symbols in msvcrt.dll S3: the Windows 7 symbols in msvcrt.dll libmsvcrt: S1 libvista: (S2 - S1) libwin7: (S3 - S1) or (S3 - S2) If user want to use symbols in VISTA/2K8, they should put libvista in additional library list. Then the generated files only valid on vista/2k8 or later is acceptable for these users. If user want to use symbols in Windows 7, they should put libwin7 in additional library list. Then the generated files only valid on Windows 7 or later is acceptable for these users. Regards, Dongsheng |
From: JonY <jo...@us...> - 2010-09-30 05:54:45
Attachments:
0xED74C077.asc
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/30/2010 09:43, Dongsheng Song wrote: > On 2010-9-29 22:33, Kai Tietz wrote: >>>>> On Wed, Sep 29, 2010 at 5:56 PM, JonY <jo...@us...> wrote: >>>>>> As far as I know, this is not a bug. That comment means that it is >>>>>> available with Windows 7. >>>>>> >>>>>> Until its reimplemented in libmingwex, the proper fix would be not to >>>>>> call it if you expect your program to run on earlier versions of windows. >>>>> > > No, this is not possible/acceptable. For example, the following code is very general: > > # if HAVE_WCSNLEN > # define local_wcsnlen wcsnlen > # else > static size_t > local_wcsnlen (const wchar_t *s, size_t maxlen) > { > const wchar_t *ptr; > > for (ptr = s; maxlen > 0 && *ptr != (wchar_t) 0; ptr++, maxlen--) > ; > return ptr - s; > } > # endif > Neither is your wcsnlen code acceptable, it does not verify if the unicode sequences are valid. > But since wcsnlen in both headers and libmsvrt.a, the autotools always > report 'yes, your target platform have wcsnlen' !!! > Please check how the tests are run, it is unlikely the headers are checked at all. Alternatively, you can check your config.status and edit it appropriately. > If we do not want to drop these symbols not in windows XP, we should declare: > > mingw-64 maybe generate invalid dll/exe files on target platform older than windows 7. > Because these files maybe reference symbols only valid on windows 7, please check your > dll/exe files carefully after build. > That is because you are calling functions that do not exists on your system, why would you expect it to work at all? >> The only general solution for this would be that someone contributes >> an implementation for this function. So we don't dependent here. The >> only issue I see here is that this wcstrnlen possibly depends on >> internal undocumented stuff. I'll do some research for this. > > Maybe there have another solution: > > S1: the intersection of XP and 2k3 symbols in msvcrt.dll > S2: the intersection of VISTA and 2k8 symbols in msvcrt.dll > S3: the Windows 7 symbols in msvcrt.dll > > libmsvcrt: S1 > libvista: (S2 - S1) > libwin7: (S3 - S1) or (S3 - S2) > > If user want to use symbols in VISTA/2K8, they should put libvista in additional library list. > Then the generated files only valid on vista/2k8 or later is acceptable for these users. > > If user want to use symbols in Windows 7, they should put libwin7 in additional library list. > Then the generated files only valid on Windows 7 or later is acceptable for these users. > > Regards, > Dongsheng > If you are willing to maintain it, then come and join #mingw-w64, we are always short of maintainers. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) iEYEARECAAYFAkykJhgACgkQp56AKe10wHf1vACbBY5J3Ldt33PAxuLZ4t83tzgj eeIAn2pdCaqTz1J4fxwlRD7Qpe6GIK24 =5mBF -----END PGP SIGNATURE----- |
From: JonY <jo...@us...> - 2010-09-30 06:09:40
Attachments:
0xED74C077.asc
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/30/2010 11:44, Xiaofan Chen wrote: > On Thu, Sep 30, 2010 at 9:43 AM, Dongsheng Song > <don...@gm...> wrote: >> Maybe there have another solution: >> >> S1: the intersection of XP and 2k3 symbols in msvcrt.dll >> S2: the intersection of VISTA and 2k8 symbols in msvcrt.dll >> S3: the Windows 7 symbols in msvcrt.dll >> >> libmsvcrt: S1 >> libvista: (S2 - S1) >> libwin7: (S3 - S1) or (S3 - S2) >> >> If user want to use symbols in VISTA/2K8, they should put libvista in additional library list. >> Then the generated files only valid on vista/2k8 or later is acceptable for these users. >> >> If user want to use symbols in Windows 7, they should put libwin7 in additional library list. >> Then the generated files only valid on Windows 7 or later is acceptable for these users. > > I tend to think this is not related to Windows versions. As mentioned > msvcrt.dll does not have this, no matter it is Windows 7 or Windows > Vista. They are in the run time for VS2003/2005/2008/2010 which > can be installed in XP/Vista/7. These runtime dlls are not named > msvcrt.dll. > It is available in Windows 7 msvcrt.dll, of course, that doesn't mean you should call it if you want your program to work on an older version of Windows. > But I agree with your subject "please get rid of symbols from > mingw-w64-crt\lib32\msvcrt.def which belong to msvcr70.dll > and msvcr80.dll". Since they are after all not belong to > msvcrt.dll but rather msvcr70.dll, msvcr80.dll or later. > The comments in the def files are not entirely accurate, msvcrt.dll has versions as well. XP has an equivalent to msvcr71.dll for msvcrt.dll. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) iEYEARECAAYFAkykKZcACgkQp56AKe10wHf0dgCgiUIYnOZmYTA++SCoEKYb/1Vo qFEAn1ZVWBxX4qbNGcbX9WOGuZ/bYSLC =PtfU -----END PGP SIGNATURE----- |
From: Xiaofan C. <xia...@gm...> - 2010-09-30 11:19:43
|
On Thu, Sep 30, 2010 at 2:09 PM, JonY <jo...@us...> wrote: > It is available in Windows 7 msvcrt.dll, of course, that doesn't mean > you should call it if you want your program to work on an older version > of Windows. > > The comments in the def files are not entirely accurate, msvcrt.dll has > versions as well. XP has an equivalent to msvcr71.dll for msvcrt.dll. You are right. I just checked using gendef on the Vista and Win7's msvcrt.dll, the results are quite similar and both seem to have wcsnlen. I do not have XP to check right now. BTW, the gendef output of the Vista and 7 msvcrt.dll are quite the same. -- Xiaofan |
From: JonY <jo...@us...> - 2010-10-01 00:02:53
Attachments:
0xED74C077.asc
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/1/2010 07:31, Xiaofan Chen wrote: > On Wed, Sep 29, 2010 at 9:52 PM, JonY <jo...@us...> wrote: >> On 9/29/2010 21:39, Dongsheng Song wrote: >>> But we can not ensure third party software DO NOT call those functions, >>> so we must drop them or defined in guard blocks like this: >>> >>> /* Windows 7 */ >>> #if _WIN32_WINNT >= 0x0601 >>> #endif >>> >>> /* Windows Vista or Server 2008 */ >>> #if _WIN32_WINNT >= 0x0600 >>> #endif >>> >> hacking the headers will not work due to how link tests work, linking >> will still succeed even without the prototype declared. > > But I feel this is still better than nothing. This depends how the other > 3rd party project carries out the tests. If it is only linking test then > it works. But if it is more than that (actually run it), then it will fail > under XP. > In the OP's situation, we can safely assume it is a linktime only test. Autotools sees wcsnlen and assumes it is usable on his system. >> Dropping them is also out of the question if we want to support Vista/7 >> users. > > BTW, what is the supported OS for MinGW-w64 32bit and 64bit > tool chain. Win2k onwards? Or XP onwards? I could not find this > out from the Wiki. > XP onwards, ymmv with Win2k. Kai is already working on a wcsnlen substitute. It is still lacking utf-16 verification routines. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) iEYEARECAAYFAkylIOYACgkQp56AKe10wHd75ACfZlQ0MMcG8YnqyJk0K+T3P7dt B44An3aOMUNctQsnxHAxsh3UYAmeXc4S =fC2I -----END PGP SIGNATURE----- |
From: Xiaofan C. <xia...@gm...> - 2010-10-01 02:08:38
|
On Fri, Oct 1, 2010 at 7:44 AM, JonY <jo...@us...> wrote: >> BTW, what is the supported OS for MinGW-w64 32bit and 64bit >> tool chain. Win2k onwards? Or XP onwards? I could not find this >> out from the Wiki. >> > > XP onwards, ymmv with Win2k. Thanks for the information. Maybe this should be put prominately in the project website. Win2k is quite old but there are still users of Win2k. For example we still have to support Win2k for the libusb-win32 project now so we have to use an older version of WDK. I myself do not really want to support Win2k since I do not have Win2k machine for testing. > Kai is already working on a wcsnlen > substitute. It is still lacking utf-16 verification routines. Will this be too much work if you want to rewrite every function available in Vista/7 msvcrt.dll and yet not available in XP's msvcrt.dll? Just wondering if it is possible to ask the users to install MSVC2005 run-time and link to that instead. Take note msvcrt.dll is a "known dll" and meant to be used by only system level components (like drivers). So WDK compiler will link to msvcrt.dll but not MSVC200x. ++++++++++++++++++ http://msdn.microsoft.com/en-us/library/abx4dbyh.aspx What is the difference between msvcrt.dll and msvcr100.dll? The msvcrt.dll is now a "known DLL," meaning that it is a system component owned and built by Windows. It is intended for future use only by system-level components. ++++++++++++++++++ Other reference: http://kobyk.wordpress.com/2007/07/20/dynamically-linking-with-msvcrtdll-using-visual-c-2005/ -- Xiaofan |
From: Xiaofan C. <xia...@gm...> - 2010-09-30 03:44:17
|
On Thu, Sep 30, 2010 at 9:43 AM, Dongsheng Song <don...@gm...> wrote: > Maybe there have another solution: > > S1: the intersection of XP and 2k3 symbols in msvcrt.dll > S2: the intersection of VISTA and 2k8 symbols in msvcrt.dll > S3: the Windows 7 symbols in msvcrt.dll > > libmsvcrt: S1 > libvista: (S2 - S1) > libwin7: (S3 - S1) or (S3 - S2) > > If user want to use symbols in VISTA/2K8, they should put libvista in additional library list. > Then the generated files only valid on vista/2k8 or later is acceptable for these users. > > If user want to use symbols in Windows 7, they should put libwin7 in additional library list. > Then the generated files only valid on Windows 7 or later is acceptable for these users. I tend to think this is not related to Windows versions. As mentioned msvcrt.dll does not have this, no matter it is Windows 7 or Windows Vista. They are in the run time for VS2003/2005/2008/2010 which can be installed in XP/Vista/7. These runtime dlls are not named msvcrt.dll. But I agree with your subject "please get rid of symbols from mingw-w64-crt\lib32\msvcrt.def which belong to msvcr70.dll and msvcr80.dll". Since they are after all not belong to msvcrt.dll but rather msvcr70.dll, msvcr80.dll or later. -- Xiaofan |