[Mingw-users] Can I use the MinGW runtime library in Visual Studio ?

Discussion:

Timothy Madden

2010-09-01 19:11:35 UTC

Hello

Can I include and use the MinGW runtime, as a library, in Visual Studio,
to get the POSIX functions available to my Visual Studio project ? But I
would still like to use the Visual Studio C Runtime library, if
possible. What I want to get are the POSIX functions.

Is that possible ?

Thank you,
Timothy Madden

Tor Lillqvist

2010-09-02 05:34:29 UTC

Permalink

Post by Timothy Madden
Can I include and use the MinGW runtime, as a library, in Visual Studio,
to get the POSIX functions available to my Visual Studio project ?

In general, the answer is no.

There is less "MinGW runtime" than you seem to think. MinGW-compiled
code uses the MSVCRT.DLL C (and C++) library, which is one of the
versions of the Microsoft C (and C++) library, the one that comes
bundled with the OS.

(Don't believe it if people call it "Visual C 6 runtime", that is not
really true. Visual C 6.0 was the last Microsoft "normal" compiler
product that used that runtime, sure, but MSVCRT.DLL is still present
in Windows 7, though, and also as a 64-bit variant on 64-bit Windows,
and used by most software that comes with Windows. If you use
Microsoft's less commonly known more system-oriented toolchains, you
use MSVCRT.DLL.)

In addition MinGW links to the mingwex library. But there is not
really much functionality that I would call specific to POSIX features
in it. It is more about providing more math functions and better C99
compatibiity for stdio, as far as I know.

Note that the Microsoft C libraries already do provide (and always
have provided) *some* of the more trivial POSIX functionality. I mean
functions like open(), read(), write(), dup().

Post by Timothy Madden
What I want to get are the POSIX functions.

What POSIX functions are you thinking of, exactly? Windows is not
POSIX. It is not possible to provide much of POSIX API and semantics
without going all the way and use a complete emulated OS environment,
like Cygwin or Microsoft's SUA, Subsystem for Unix Applications
(a.k.a. Interix). I mean functionality like fork(), wait(), poll() and
select() working on *all* types of file descriptors, various ioctl()
and fcntl() calls, pthread API, a single-root file system, etc.

--tml

Timothy Madden

2010-09-03 08:15:57 UTC

Permalink

Post by Tor Lillqvist

Post by Timothy Madden
Can I include and use the MinGW runtime, as a library, in Visual Studio,
to get the POSIX functions available to my Visual Studio project ?

In general, the answer is no.
There is less "MinGW runtime" than you seem to think. MinGW-compiled
code uses the MSVCRT.DLL C (and C++) library, which is one of the
versions of the Microsoft C (and C++) library, the one that comes
bundled with the OS.
(Don't believe it if people call it "Visual C 6 runtime", that is not
really true. Visual C 6.0 was the last Microsoft "normal" compiler
product that used that runtime, sure, but MSVCRT.DLL is still present
in Windows 7, though, and also as a 64-bit variant on 64-bit Windows,
and used by most software that comes with Windows. If you use
Microsoft's less commonly known more system-oriented toolchains, you
use MSVCRT.DLL.)
In addition MinGW links to the mingwex library. But there is not
really much functionality that I would call specific to POSIX features
in it. It is more about providing more math functions and better C99
compatibiity for stdio, as far as I know.
Note that the Microsoft C libraries already do provide (and always
have provided) *some* of the more trivial POSIX functionality. I mean
functions like open(), read(), write(), dup().

Post by Timothy Madden
What I want to get are the POSIX functions.

A few years ago I also posted a question about POSIX on some of these
mailing list and the people were so surprised and curious to know where
would I get the idea that MinGW would have something to do with POSIX ...

But despite their attitude then I still thought that MinGW would have
POSIX functions implemented or emulate because, as I said back then, it
tries to emulate Linux functions, which eventually are POSIX. Ok, I
guess I confuse GNU withe Linux !

I think if MinGW would actually try to provide the POSIX compatibility
that can reasonably be emulated under Windows, and get portable enough
to work with some commercial compilers (VC++, C++ Builder, Intel C++),
its popularity would then reach un-imaginable levels ...

Anyway, for my questions lets just say that I would like the POSIX
functions that can reasonably be implemented/emulated, without requiring
unrealistic efforts, like the ones now in MinGW ! :)

Microsoft has deprecated their CRT-provided POSIX functions since Visual
Studio 2005, for reasons that any non-standard symbols exported from the
CRT should begin with an undersocre, as stated by ISO C, so
fileno became _fileno. They still have a macro to disable the
deprecation, though.

And I hear that Windows kind of /is/ POSIX, in the sense that it
provides functionality like that described in POSIX, only it is far from
having the syntax and symbol names described POSIX headers. Also, I
think there are pthreads library implementations for Windows, and I am
also interested to know more about SUA

Thank you,
Timothy Madden

Tor Lillqvist

2010-09-03 09:05:39 UTC

Permalink

Post by Timothy Madden
its popularity would then reach un-imaginable levels ...

Sorry, I think you have unrealistic expectations and are
misunderstanding the purpose of MinGW.

Post by Timothy Madden
Anyway, for my questions lets just say that I would like the POSIX
functions that can reasonably be implemented/emulated, without requiring
unrealistic efforts, like the ones now in MinGW ! :)

Which ones, exactly? You do know that open(), read() etc are available
in all the Microsoft C libraries?

Post by Timothy Madden
Microsoft has deprecated their CRT-provided POSIX functions since Visual
Studio 2005,

Yeah, that "deprecation" is mostly a joke in my opinion, or motivated
by politics. Like they "deprecated" perfectly standard string
functions because they are "unsafe". When used incorrectly, sure, but
it is after all C we are talking about, it is supposed to be unsafe
when used incorrectly.

Post by Timothy Madden
for reasons that any non-standard symbols exported from the
CRT should begin with an undersocre, as stated by ISO C, so
fileno became _fileno.

That is so silly, because on the other hand, practically any sample
source code for Windows you see has no qualms at all in using
Microsoft-specific APIs, from <windows.h> or elsewhere.

These Microsoft APIs are not treated as non-standard "as stated by ISO
C" in the sense they would be prefixed with underscore... It's like
Animal Farm: "All non-ISO-C APIs are non-standard but some are more
non-standard than others"... One rule for non-C-standard POSIXish
functions, another rule for non-standard Microsoft functions?

Anyway, <windows.h> is really showing its age. It gladly stomps over
the whole namespace like an 800 kg gorilla, defining lots of very
generically named macros and identifiers that easily can clash with
those the poor unaware programmer has used in his own code.

Compare to the slightly newer (but still old fashioned) traditional
X11 headers for instance, which at least use consistent "namespaces".
Yes, I know C doesn't have namespaces in the C++ sense, I mean a small
set of consistently used prefixes in all the identifiers they declare
and macros they define, to make the risk of clashes smaller.

Post by Timothy Madden
And I hear that Windows kind of /is/ POSIX, in the sense that it
provides functionality like that described in POSIX,

Well, if you think that way, then sure, all operating systems are kind
of POSIX...

But POSIX is a standard for the *interface* to OS functionality, not a
standard for implementation details of the functionality as such.

Post by Timothy Madden
only it is far from having the syntax and symbol names described POSIX headers.

Well, the syntax and symbol names is what POSIX defines, so you are
essentially saying it is far from POSIX.

Post by Timothy Madden
Also, I think there are pthreads library implementations for Windows,

Yes, called pthreads-win32. But in most cases, I would recommend
people just use ifdefs, and use the Win32 thread API instead. It is
close enough in functionality for most uses, and it is clearer to have
one less layer in between your code and the OS.

Post by Timothy Madden
I am also interested to know more about SUA

Microsoft has more information. I don't remember now if it is a free
download, or a commercial product. Anyway, it's kinda like Cygwin, but
in Interix you are more isolated from the Win32 view of the machine
than in Cygwin.

--tml

Keith Marshall

2010-09-03 11:35:16 UTC

Permalink

[...snip...]

Post by Timothy Madden
for reasons that any non-standard symbols exported from the
CRT should begin with an undersocre, as stated by ISO C, so
fileno became _fileno.

That is so silly, ...

IMO, it's a lot worse than just silly...

because on the other hand, practically any sample
source code for Windows you see has no qualms at all in using
Microsoft-specific APIs, from <windows.h> or elsewhere.
These Microsoft APIs are not treated as non-standard "as stated by ISO
C" in the sense they would be prefixed with underscore... It's like
Animal Farm: "All non-ISO-C APIs are non-standard but some are more
non-standard than others"... One rule for non-C-standard POSIXish
functions, another rule for non-standard Microsoft functions?

They don't even apply it sensibly, or consistently, where it really would
be justified; it would be sensible to add this initial underscore in those
cases where their CRT provides an API which is similarly named to the ISO-C
or POSIX equivalent, but the functionality differs. For example, Microsoft's
implementation of the printf() family of functions is grossly incompatible
with the implementation requirements specified by ISO-C, (and mirrored by
POSIX); therefore this is a case where they *should* have prefixed their
function names with an underscore. Did they? Not a bit of it!

--
Regards,
Keith.

Timothy Madden

2010-09-03 20:49:54 UTC

Permalink

Post by Tor Lillqvist

Post by Timothy Madden
its popularity would then reach un-imaginable levels ...

Sorry, I think you have unrealistic expectations and are
misunderstanding the purpose of MinGW.

Which ones, exactly? You do know that open(), read() etc are available
in all the Microsoft C libraries?

Ok, ok, I get it. I see people here are still annoyed by my attitude; I
won't bother you with this any more ... :)

Post by Tor Lillqvist

Post by Timothy Madden
Microsoft has deprecated their CRT-provided POSIX functions since Visual
Studio 2005,

Post by Timothy Madden
for reasons that any non-standard symbols exported from the
CRT should begin with an undersocre, as stated by ISO C, so
fileno became _fileno.

Although I am not found of Microsoft either, I think there is an
explanation for those different rules. ISO C well allows third-party
libraries, which is what MFC and <windows.h> are, so the names defined
there can stay as third-party.

The mkdir, open, creat, fileno, ... functions, on the other hand are not
provided by a third party library, they are provided by the library that
comes with the compiler, which places them in the C run-time library
(CRT). You would normally think of them as provided by "the POSIX
implementation", but you will find that the Microsoft provided names are
not placed in their POSIX headers, they are provided by some Microsoft
specific headers (direct.h, io.h, ...). Actually the first
implementation to provide this headers might have been Borland, I am not
sure about that ... So this is one more reason showing the Microsoft
"open" and "mkdir" functions are provided by the CRT, not by the POSIX
implementation.

Now, with the mkdir function as part of the CRT, it is indeed legal for
them to prefix the name with an underscore. Of course this is still the
wrong solution to the problem, and I still suspect them of bad intent
against POSIX, as the right solution would have been to re-declare mkdir
in the POSIX header <sys/stat.h>, that VC++ provides anyway.

One would be surprised to find that stat() and fstat() functions, which
Microsoft has always provided in the POSIX header <sys/stat.h>, have as
such not been deprecated, but have anyway been undocumented (whereas
_stat and _fstat are documented).

And then there is also the question of deprecating the names that POSIX
places directly in the CRT headers (like fileno() from <stdio.h>), but
only if the feature test macro _POSIX_C_SOURCE is defined. I also think
Microsoft had no reason to deprecate these names.

[...]

Post by Tor Lillqvist

Post by Timothy Madden
Also, I think there are pthreads library implementations for Windows,

Hoyt, David

2010-09-03 20:59:39 UTC

Permalink

I'm not exactly sure what you need to abstract away, but you could look into something like glib which takes care of a lot of the platform-specific issues. You're not 100% isolated, but it does a pretty good job. Of course, it's a bit more overhead and could be way more than you need -- but it's worth considering.

-----Original Message-----
From: Timothy Madden [mailto:***@gmail.com]
Sent: Friday, September 03, 2010 1:50 PM
To: mingw-***@lists.sourceforge.net
Subject: Re: [Mingw-users] Can I use the MinGW runtime library in Visual Studio ?

Post by Tor Lillqvist

Post by Timothy Madden
its popularity would then reach un-imaginable levels ...

Sorry, I think you have unrealistic expectations and are
misunderstanding the purpose of MinGW.

Which ones, exactly? You do know that open(), read() etc are available
in all the Microsoft C libraries?

Ok, ok, I get it. I see people here are still annoyed by my attitude; I
won't bother you with this any more ... :)

Post by Tor Lillqvist

Post by Timothy Madden
Microsoft has deprecated their CRT-provided POSIX functions since Visual
Studio 2005,

Post by Timothy Madden
for reasons that any non-standard symbols exported from the
CRT should begin with an undersocre, as stated by ISO C, so
fileno became _fileno.

Post by Tor Lillqvist

Post by Timothy Madden
Also, I think there are pthreads library implementations for Windows,

I do not think I still follow you here. I would definitely use the POSIX
APIs in my application and just include the emulation layer when on
Windows. What if I have one more emulation layer ?

Thank you,
Timothy Madden

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://*p.sf.net/sfu/intel-thread-sfd
_______________________________________________
MinGW-users mailing list
MinGW-***@lists.sourceforge.net

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.sourceforge.net/lists/listinfo/mingw-users

Tor Lillqvist

2010-09-04 08:02:13 UTC

Permalink

Post by Timothy Madden

Post by Tor Lillqvist
Which ones, exactly? You do know that open(), read() etc are available
in all the Microsoft C libraries?

Ok, ok, I get it. I see people here are still annoyed by my attitude; I
won't bother you with this any more ... :)

Don't be so easily upset; I simply asked for a specific example?

Getting annoyed by the person you are arguing with is the essence of a
lively discussion, isn't it? What would be the point in a discussion
if one just said "oh, yes, you can say that too, and it also is
perfectly right" all the time?

Post by Timothy Madden
Although I am not found of Microsoft either, I think there is an
explanation for those different rules. ISO C well allows third-party
libraries, which is what MFC and <windows.h> are, so the names defined
there can stay as third-party.
The mkdir, open, creat, fileno, ... functions, on the other hand are not
provided by a third party library, they are provided by the library that
comes with the compiler, which places them in the C run-time library
(CRT).

Hmm, OK, I can following this reasoning yes, and it does make sense.
So I can take back my "Animal Farm" insinuation. One should apparently
think of it like this:

When writing a pure C89 program that includes only C89 headers and
links to no non-default libraries, one should be free to use any
identifier for one's own code without problems. So yeah, from that
point of view, it is correct to hide functions like open() and read(),
which after all a (naïve?) C programmer might use for his own code.
While a program that explicitly includes non-C89 headers and links
with additional libraries shouldn't be surprised then if those headers
declare stuff with random names.

Post by Timothy Madden
I do not think I still follow you here. I would definitely use the POSIX
APIs in my application and just include the emulation layer when on
Windows. What if I have one more emulation layer ?

One more thing you can not be entirely sure of? Too much complexity
involved if you need only the most basic thread functionality? (Read
the pthreads-win32 code, it has to do some complicated stuff to
support full pthread semantics. It's been a while, so I don't remember
the details.) But no big deal here, if it works fine for your code, by
all means use it.

--tml

Timothy Madden

2010-09-04 19:26:08 UTC

Permalink

Post by Tor Lillqvist

Post by Timothy Madden

Post by Tor Lillqvist
Which ones, exactly? You do know that open(), read() etc are available
in all the Microsoft C libraries?

Ok, ok, I get it. I see people here are still annoyed by my attitude; I
won't bother you with this any more ... :)

Don't be so easily upset; I simply asked for a specific example?

I do not have a specific problem to solve, it is just that when I write
code, I like to write it portable. That means not Windows-specific, but
rather POSIX. As such, I have always missed POSIX compatibility on
Windows ... :(

Recently for example, I got into a problem with directory_iterator in
boost so I can no longer iterate over directories, and until and if I
can find the cause, I naturally thought I would use opendir and readdir
functions, but then as always I do not have them on Windows. As another
example, I have previously run into strptime(); also, my application
needs to create a zip archive and I need open() and stat() to get the
file date and time, and content (actually to open the file I would like
something like wopen() but that is another problem). In general many
simple functions are what I want.

I also miss a reliable tmpfile() implementation for when I just need
some buffer space without an arbitrary size limit, because a temporary
file deleted automatically on close provides just that. But the
Microsoft implementation creates the temporary file in the root
directory and on Windows Vista fails for non-elevated processes.

Thank you,
Timothy Madden

Tor Lillqvist

2010-09-04 21:21:12 UTC

Permalink

Post by Timothy Madden
I naturally thought I would use opendir and readdir
functions, but then as always I do not have them on Windows.

Ah. Nice that you bring those up, because file system inspection and
manipulation is actually a prime example of why just having "POSIX
emulation" is not even necessarily fully possible on Windows for
superficially trivial things unless you accept some (IMHO) quite
serious shortcomings.

The fact just is that in Windows, the file system is in UTF-16, while
on POSIX file names are just byte strings with no implied codeset
interpretation or restriction.

But the "char" strings that all the "POSIXish" functions like open(),
or standard C ones like fopen() in the Microsoft libraries, or the
dirent functions of MinGW, take and return file names in the system
codepage.

I.e. there can well be file names on a Windows file system that you
can't name with a plain char string... (And no, UTF-8 is not a
possible system codepage.) Having files with names not expressible in
system codepage is perhaps very rare in most "Western" locales, but it
might be very common in some locales for some user groups, and you
want to write code to work in all possible situations, don't you?

Thus to actually be able to handle any possible file name, you need to
use the Windows-only "wchar_t" functions like _wopen(), _wfopen(), and
for dirent _wopendir() etc. (The Windows wchar_t is just 16 bits (so
you have to handle the possibility of surrogate pairs) while in most
"sane" POSIX systems these days (read: Linux at least) it is 32 bits
so it actually covers in one wchar_t element any possible Unicode code
point.)

That, or use a portability library that on Windows provides an UTF-8
view of the file system and its own API to handle it, like GLib. In
fact, what you write sounds like you definitely want to use something
like GLib. Or possibly Qt, as you seem to use C++, but I don't know if
it too provides a UTF-8 view of the system on Windows. (I am a plain C
guy myself.) Both GLib and Qt can be well used from code built with
Microsoft's compilers, too.

(You mention boost. I have absolutely no idea about that, sorry.)

So it seems that the answer to your question in the subject of this
thread should be: "No, but you can use other suitably licensed
cross-platform Open Source libraries from Visual Studio, too."

--tml

Andy Koppe

2010-09-05 06:18:30 UTC

Permalink

Post by Tor Lillqvist

Post by Timothy Madden
I naturally thought I would use opendir and readdir
functions, but then as always I do not have them on Windows.

Ah. Nice that you bring those up, because file system inspection and
manipulation is actually a prime example of why just having "POSIX
emulation" is not even necessarily fully possible on Windows for
superficially trivial things unless you accept some (IMHO) quite
serious shortcomings.
The fact just is that in Windows, the file system is in UTF-16, while
on POSIX file names are just byte strings with no implied codeset
interpretation or restriction.
But the "char" strings that all the "POSIXish" functions like open(),
or standard C ones like fopen() in the Microsoft libraries, or the
dirent functions of MinGW, take and return file names in the system
codepage.
I.e. there can well be file names on a Windows file system that you
can't name with a plain char string... (And no, UTF-8 is not a
possible system codepage.) Having files with names not expressible in
system codepage is perhaps very rare in most "Western" locales, but it
might be very common in some locales for some user groups, and you
want to write code to work in all possible situations, don't you?
Thus to actually be able to handle any possible file name, you need to
use the Windows-only "wchar_t" functions like _wopen(), _wfopen(), and
for dirent _wopendir() etc. (The Windows wchar_t is just 16 bits (so
you have to handle the possibility of surrogate pairs) while in most
"sane" POSIX systems these days (read: Linux at least) it is 32 bits
so it actually covers in one wchar_t element any possible Unicode code
point.)
That, or use a portability library that on Windows provides an UTF-8
view of the file system and its own API to handle it, like GLib.

Cygwin 1.7 presents a full POSIX view of the Windows filesystem,
including automatic filename translation between UTF-16 and UTF-8 (or
any other character set you might have configured). It even supports
filename characters such as ':' that aren't allowed in Windows
filenames.

Andy

Volker Grabsch

2010-09-05 12:57:04 UTC

Permalink

Post by Tor Lillqvist
Or possibly Qt, as you seem to use C++, but I don't know if
it too provides a UTF-8 view of the system on Windows.

Qt does quite a good job in that regard.

It provides a class QString which conceptually contains Unicode
characters, i.e. no hassle with encoding issues. [1]

The classes that handle filesystem stuff (QFile, QDir, QFileInfo, ...)
use consequently QString instances as arguments for filenames and
paths. [2]

Qt takes care of the file system API / encoding issues in the
background. You normally don't need to care. It does the "right
thing" on all platforms, including Windows. It even takes care
of the MacOS X specialities. [3]

Although I prefered Glib / GTK for a long time, mostly due to
Qt's former licencing issues, I currently prefer Qt because of
its excellent API.

Greets,
Volker

[1] Of course, strings are internally stored in some encoding,
but the API allows and forces you to operate on the level
of unicode characters. Also, there are of course methods
to convert a QString from and to a byte array, for which
you need to specify an encoding. It's very similar to
Python's "unicode" class.

[2] Also, all GUI components such as text fields, combo boxes
and labels use consequently QString.

[3] MacOS X deviates from the other Unix/POSIX systems in many
annoying ways. I've had more trouble with Mac portability
than I ever had with Win32 portability.

--
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR

Earnie

2010-09-03 11:41:22 UTC

Permalink

Post by Timothy Madden
A few years ago I also posted a question about POSIX on some of these
mailing list and the people were so surprised and curious to know where
would I get the idea that MinGW would have something to do with POSIX ...

And you still don't understand that MinGW only provides ANSI functions
as given by MSVCRT.DLL with a few C99 ANSI extensions. It isn't the
purpose of MinGW to provide POSIX, that is what Cygwin does.

Post by Timothy Madden
But despite their attitude then I still thought that MinGW would have
POSIX functions implemented or emulate because, as I said back then, it
tries to emulate Linux functions, which eventually are POSIX. Ok, I
guess I confuse GNU withe Linux !

If you think GNU is Linux then you are confused. GCC isn't Linux either
it is a compiler and compilers do not provide POSIX either unless the
compiler resides on a POSIX providing OS such as Linux. But even then
you can use a library of functions that provide the POSIXness you seek.

Post by Timothy Madden
I think if MinGW would actually try to provide the POSIX compatibility
that can reasonably be emulated under Windows, and get portable enough
to work with some commercial compilers (VC++, C++ Builder, Intel C++),
its popularity would then reach un-imaginable levels ...

Perhaps a different project could do this. Cygwin doesn't intermingle
and for that matter mixing C++ objects from different compilers doesn't
work at all due to the ABI produced by each compiler. It is a design
feature of C++ that causes the different ABI.

You should be able to find the ones you need in our headers and use them
for your own library to provide what you need. We will not provide you
with a working solution for that. You should be able to take our
libraries and compile and link them with MSVC. Good luck.

--
Earnie
-- http://www.for-my-kids.com

Timothy Madden

2010-09-03 20:56:43 UTC

Permalink

Post by Earnie

And you still don't understand that MinGW only provides ANSI functions
as given by MSVCRT.DLL with a few C99 ANSI extensions. It isn't the
purpose of MinGW to provide POSIX, that is what Cygwin does.

Yeah, sure, I know. The problem with Cygwin is that it is essentially a
commercial library. I do not work for free 8 hours a day every day, I
have to go to work. And to use cygwin in my project at work, I would
have to get my manager to buy it ...

[...]

Post by Earnie

Yeah, I have though about that