Re: libmsvcrt.a and _create_locale in win7

On 05/06/19 14:03, Andrei Voronin wrote:
>>> There is an issue that I hit a few days ago. Unfotuanally osdn.net
>>> can't register new accounts right now.
>>
>> In what way is it failing? I can access the account creation form,
>> and complete it, but I didn't go as far as submitting it, (because
>> I don't really want a second OSDN.net account).
> 
> After hitting submit I have got: "Due to technical reasons, the email
> address can not be used".

Well, that's an issue you should probably raise with OSDN.net technical
support.  I do note that your list postings are being flagged as SPAM,
and a skim of the headers indicates an authentication failure for your
protonmail.com service domain.

> With msvcrt-xref.pdf document, now I hope that I understand the
> difference between MSVCRT.DLL and MSVCR120.DLL.
> Shortly, as I get it:
> 
> - MSVCRT.DLL system dll with back compatibility to older windows
>   systems, always present in the system.

It's not so much a backward compatibility issue, as that MSVCRT.DLL is a
system component, and so we may link with it as if it were free; (in the
strict "copyleft" sense it isn't free, but it is usable).  It isn't
backwardly compatible, in the sense that newer Windows versions have
introduced new MSVCRT.DLL APIs, and if your code uses them, it will not
run on an earlier version.

> - MSVCR120.DLL part of Microsoft Visual C++ redistributable.

Yes, and AFAIK, it's only redistributable BY YOU, if you have bought a
(paid for) MSVC licence.

> I suppose that libmsvcrt.a use both MSVCRT.DLL and its MSVCRxxx.DLL 
> satellites.

No.  There are distinct import libraries for each distinct MSVCRxxx.DLL
variant; libmsvcrt.a maps symbols for MSVCRT.DLL _exclusively_, (but it
does include most of the symbols present in the Win7 version, with only
a few notable exceptions, which conflict with backward compatibility
hooks in libmingwex.a).

If you link with libmsvcrt.a, your application will depend on
MSVCRT.DLL; it _cannot_ also depend on any MSVCRxxx.DLL, without
introducing a serious risk of instability.

> And we have the same libmsvcrt.a on all windows distributions.

Yes, but it may over specify the available APIs, for Windows versions
prior to Win7.

> Seems like win10 machine have no trouble with _create_locale call
> because it has this function in MSVCRT.DLL,

Okay.  I don't have Win10, but it would appear that Microsoft may (at
last) have corrected ...

> but win7 don't have _create_locale in MSVCRT.DLL.

...this serious omission; for Vista, they introduced a number of new
APIs which cannot possibly be used without either "_create_locale()", or
"_get_current_locale()", but they completely ignored/overlooked this
requirement.

> MinGW project can't rely on MSVC redistributable because
> it's not always available, and it has its own licensing.

Exactly so.

> So it is not possible to just link libmsvcrt.a with MSVCRxxx.DLL.

No.  In fact, it is dangerous to try.

> But with the mechanism of GCC specs file, I can subset the other DLL
> instead MSVCRT.DLL in build, and at this point, I should know what
> I'm doing in terms of licensing and distribution.

Yes.

-- 
Regards,
Keith.

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

_______________________________________________
MinGW-Users mailing list
[email protected]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.osdn.me/mailman/listinfo/mingw-users
Also: mailto:[email protected]?subject=unsubscribe

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJc99SeAAoJEMCtNsY0flo/i6gP/2NY+h9NiP85lGHnl0cLyPK0
/oGvSoy6R06yAUwV7sti8wVZuDfQqIv830UERVGmOFB3FFLt7FvO3uem2rd9He0u
M80VQWsXREkYiRLDG33zkfQEkn7ULyFlAXMXu+cE8T3FXELQC99rnOU+fLRPfN6W
bSFIihH2jd3KNotbhFxqBbuqtr9SQWucuhd8jA18B1O71L9BIY1ZxC+uKwnco9UB
fbbudX25G6oGVJwr4xXXoJHbNc83NM+11Nw6SsF4ms9IxERc1b3a7NSWEf1QSaW7
3eFBln1CJjD7OgERPRudJVWyf2YrMbT4QnWZCJBsWLBZRBzNCm+0jnQkyI598zDc
cv315CRAoTOgyvT3icXR+eA+ZZjhN/Pg/bn8ym2kjdsSgfGnvmuXXjM+81GRfI2b
pvpXyQkEUBSW/RwpAlw0MipqSc3WZkf3fvKVFOaLoa2JxXt29WzXCbV+U6u6agvf
hLzCx+lPPCOLYRyjXRP62DbMVNDMax7vaFf/sllc66yOhRBYdXU9pXvqI8huaIjR
4krBwJjqySUQwDbSvZRdAIRBH2RhEQSP1qsqRR1aLo0Z9jqpOIuI3+aaWtVt2eTW
j7hRQ0+QeMQgAjT/yPmVXEeDXT54X64EJDsrmEDrYmjIk3pO8vcZHDQKVE+JqGmI
V/y4LwPUCITX7ISvVwn3
=JSpB
-----END PGP SIGNATURE-----