From: Timothy M. <ter...@gm...> - 2010-09-03 20:50:22
|
On 03.09.2010 12:05, Tor Lillqvist wrote: >> its popularity would then reach un-imaginable levels ... > > Sorry, I think you have unrealistic expectations and are > misunderstanding the purpose of MinGW. > >> 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? Ok, ok, I get it. I see people here are still annoyed by my attitude; I won't bother you with this any more ... :) >> 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. > >> 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? 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. [...] > >> 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. 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 |