System.Info.os is wrong, Was Re: HDBC-ODBC compile problem

Neil Mitchell ndmitchell at
Wed Jul 19 06:53:46 EDT 2006


> It's not a complete accident: we did envisage that making a distinction between
> a compiler that produces binaries via MinGW's gcc and a hypothetical compiler
> that produces binaries via MS's C compiler might be important, so we made
> System.Info.os include that distinction.

Unfortunately, even if the compiler is made with MS's C compiler (i.e.
WinHugs) it still returns mingw. Yhc binaries will also be MS C
produced. My worry is that unless we fix this quickly, these compilers
might need to return mingw32, so code like that which started this
discussion can continue to work.

> Nevertheless, you could persuade me that this is less than useful if you just
> want to know if the OS is Windows.  But then perhaps there should be some other
> System.Info entity with more information about the OS?

That seems a good idea.

The facts that are probably relevant about the OS are:

OS Type: Windows/Posix/Linux (an enumeration?)
What the os looks like if you were to abstract away the details, there
aren't that many OS's which are fundamentally different in terms of
how userspace should act with them. Any enumeration can have Other
String as the last element, but it stops matching against "magic
strings" for the most part.

OS Variant: Windows XP/Fedora Core (a simple string)
To get useful information for injecting into bug reports, or for
working around specific issues - i.e. oh, Windows XP requires this
super special behaviour, but do something else in every other case.

OS Environment: mingw/cygwin/64bit/32bit
Things that relate to how the binary was made, what features might
possibly be available etc. This seems more related to info.compiler
that info.os, but if it is useful can still be included.

For inspiration for the information that is returned, looking into
browser strings might be a good start.



More information about the Libraries mailing list