Quantcast

MSVCRT.DLL is no longer stated as the "Known DLL"

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

MSVCRT.DLL is no longer stated as the "Known DLL"

Earnie Boyd
The read for MSVC 2015 removes the "Knwon DLL" wording.  Compare the
pages at
https://msdn.microsoft.com/en-us/library/abx4dbyh(v=vs.140).aspx and
https://msdn.microsoft.com/en-us/library/abx4dbyh(v=vs.120).aspx

Just wanted to give a heads up to the changes in documentation.
--
Earnie

------------------------------------------------------------------------------
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: MSVCRT.DLL is no longer stated as the "Known DLL"

Keith Marshall-3
On 03/01/16 19:47, Earnie wrote:
> The read for MSVC 2015 removes the "Knwon DLL" wording.  Compare the
> pages at
> https://msdn.microsoft.com/en-us/library/abx4dbyh(v=vs.140).aspx and
> https://msdn.microsoft.com/en-us/library/abx4dbyh(v=vs.120).aspx
>
> Just wanted to give a heads up to the changes in documentation.

Unless MSVCRT.DLL no longer ships with Win10[*], I don't see how this is
in any way relevant for us.  As a system DLL, use of MSVCRT.DLL is free
to the extent of being GPL compatible; the other MSVCRxxx.DLL variants
are not, and we prefer not to depend on them.

The vs.140 reference suggests that the C runtime, formerly provided by
MSVCRT.DLL, will henceforth be factored into UCRT.DLL, (which will be
provided as a system DLL from Win10 onward), and VCRUNTIME<version>.DLL,
(which will be a non-free MSVC component).  Thus, while MSVCRT.DLL
remains available as a system DLL, it should remain as our preferred
linking choice.

[*] I don't have Win10, and have no intention of acquiring it, since I
no longer work for a company which forces me to use any version of
Windows; I am unable to personally confirm or deny the continued
existence of MSVCRT.DLL, in any Windows version later than Win7.

--
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F


------------------------------------------------------------------------------

_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: MSVCRT.DLL is no longer stated as the "Known DLL"

Yongwei Wu
On 4 January 2016 at 05:31, Keith Marshall
<[hidden email]> wrote:

>
> On 03/01/16 19:47, Earnie wrote:
> > The read for MSVC 2015 removes the "Knwon DLL" wording.  Compare the
> > pages at
> > https://msdn.microsoft.com/en-us/library/abx4dbyh(v=vs.140).aspx and
> > https://msdn.microsoft.com/en-us/library/abx4dbyh(v=vs.120).aspx
> >
> > Just wanted to give a heads up to the changes in documentation.
>
> Unless MSVCRT.DLL no longer ships with Win10[*], I don't see how this is
> in any way relevant for us.  As a system DLL, use of MSVCRT.DLL is free
> to the extent of being GPL compatible; the other MSVCRxxx.DLL variants
> are not, and we prefer not to depend on them.
>
> The vs.140 reference suggests that the C runtime, formerly provided by
> MSVCRT.DLL, will henceforth be factored into UCRT.DLL, (which will be
> provided as a system DLL from Win10 onward), and VCRUNTIME<version>.DLL,
> (which will be a non-free MSVC component).  Thus, while MSVCRT.DLL
> remains available as a system DLL, it should remain as our preferred
> linking choice.
>
> [*] I don't have Win10, and have no intention of acquiring it, since I
> no longer work for a company which forces me to use any version of
> Windows; I am unable to personally confirm or deny the continued
> existence of MSVCRT.DLL, in any Windows version later than Win7.
>
> --
> Regards,
> Keith.

>From the page quoted, I do not see any implication that MSVCRT.DLL
will be removed from Windows 10. I think Microsoft just wants to
discourage the use of MSVCRT.DLL, which is really obsolete.

In the blog "Introducing the Universal CRT"
<URL:http://blogs.msdn.com/b/vcblog/archive/2015/03/03/introducing-the-universal-crt.aspx?PageIndex=2#comments>,
people actually commented:

  This is a good occasion for MinGW to switch from the horror of
msvcrt.dll to ucrtbase.dll

As MSVCRT has been broken regarding non-English support since Windows
Vista, I tend to agree. The new runtime seems to support older version
of Windows too. The gotcha is that some functions like memcpy is not
in ucrtbase.dll.

Best regards,

Yongwei

--
Wu Yongwei
URL: http://wyw.dcweb.cn/

------------------------------------------------------------------------------
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: MSVCRT.DLL is no longer stated as the "Known DLL"

Earnie Boyd
On 1/4/2016 7:08 AM, Yongwei Wu wrote:

> On 4 January 2016 at 05:31, Keith Marshall wrote:
>>
>> On 03/01/16 19:47, Earnie wrote:
>>> The read for MSVC 2015 removes the "Knwon DLL" wording.  Compare the
>>> pages at
>>> https://msdn.microsoft.com/en-us/library/abx4dbyh(v=vs.140).aspx and
>>> https://msdn.microsoft.com/en-us/library/abx4dbyh(v=vs.120).aspx
>>>
>>> Just wanted to give a heads up to the changes in documentation.
>>
>> Unless MSVCRT.DLL no longer ships with Win10[*], I don't see how this is
>> in any way relevant for us.  As a system DLL, use of MSVCRT.DLL is free
>> to the extent of being GPL compatible; the other MSVCRxxx.DLL variants
>> are not, and we prefer not to depend on them.
>>

As I said I wanted to give a heads up on the change in documentation.  I
do not know the full details on why the change but reading the blog
Younwei pointed to seems to infer that the change is trying to move away
from needing to provide the runtime DLL with each application.

>> The vs.140 reference suggests that the C runtime, formerly provided by
>> MSVCRT.DLL, will henceforth be factored into UCRT.DLL, (which will be
>> provided as a system DLL from Win10 onward), and VCRUNTIME<version>.DLL,
>> (which will be a non-free MSVC component).  Thus, while MSVCRT.DLL
>> remains available as a system DLL, it should remain as our preferred
>> linking choice.
>>

So MSVCRT.DLL may just disappear in the future but I agree that it
should remain as long as it is available.  UCRT.DLL is likely to be its
replacement.  But someone could end up having an issue with memory
management because of varying runtime dll.  This might be a cause for
concerns.

>> [*] I don't have Win10, and have no intention of acquiring it, since I
>> no longer work for a company which forces me to use any version of
>> Windows; I am unable to personally confirm or deny the continued
>> existence of MSVCRT.DLL, in any Windows version later than Win7.
>>

You should be able to apply the automated update from Vista if you still
have a VM of it.  Or perhaps we could use our donated funds for to buy
you a copy.

>> --
>> Regards,
>> Keith.
>
>>From the page quoted, I do not see any implication that MSVCRT.DLL
> will be removed from Windows 10. I think Microsoft just wants to
> discourage the use of MSVCRT.DLL, which is really obsolete.
>

Perhaps but it does still exist.  To really discourage it they would
need to remove it from the disks.

> In the blog "Introducing the Universal CRT"
> <URL:http://blogs.msdn.com/b/vcblog/archive/2015/03/03/introducing-the-universal-crt.aspx?PageIndex=2#comments>,
> people actually commented:
>

Thanks for the pointer to the blog.

>   This is a good occasion for MinGW to switch from the horror of
> msvcrt.dll to ucrtbase.dll
>

And comments such as this is the reason for the heads up.

> As MSVCRT has been broken regarding non-English support since Windows
> Vista, I tend to agree. The new runtime seems to support older version
> of Windows too. The gotcha is that some functions like memcpy is not
> in ucrtbase.dll.
>

Based on the original link I provided, the msvcrt.dll is still used for
the initialization process.  This would be the reason for leaving memory
management there.  See the cross dll boundary warning on the document I
pointed to.


--
Earnie

------------------------------------------------------------------------------
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Loading...