How to detect OS type and version?
Roger Blum
running on Linux or Windows (and the version of the OS)?
Regards,
Roger
Martin Dowie
> Is there a way within Ada (GNAT 3.15p) to tell whether the application is
> running on Linux or Windows (and the version of the OS)?
There is no single standard why... yet!
I think that you will be able to do this with "package
Ada.Environment_Variables" come Ada200Y, e.g.
if Ada.Environment_Variables.Exists ("OS")
and Ada.Environment_Variables.Value ("OS") = "Windows_NT" then
...
elsif Ada.Environment_Variables.Exists ("OSTYPE")
and Ada.Environment_Variables.Value ("OSTYPE") = "linux-gnu" then
...
else
-- Unknown OS
...
end if;
I have a (partially tested) version of this package. If you (or anyone
else) would like it, please email me directly and I'll see what I can
do! :-)
Cheers
-- Martin
Stefan Bellon
> I think that you will be able to do this with "package
> Ada.Environment_Variables" come Ada200Y, e.g.
>
> if Ada.Environment_Variables.Exists ("OS")
> and Ada.Environment_Variables.Value ("OS") = "Windows_NT" then
> ...
> elsif Ada.Environment_Variables.Exists ("OSTYPE")
> and Ada.Environment_Variables.Value ("OSTYPE") = "linux-gnu"
> then ...
> else
> -- Unknown OS
> ...
> end if;
This approach has one problem: Those environment variables can be set
by the user, so that the user can fake the setting to select wrong OS
dependent code.
What we are doing is this: We configure our project for the target
operating system and during that configuration, a small file with
content similar to the following is generated:
separate (Bauhaus.OS)
function Get_OS return String is
begin
return "GNU/Linux";
end Get_OS;
This way, we have the OS type compiled in our executables and can
check wherever necessary without the fear that the user may change it.
It would be nice if this was available via some language defined
package, I agree.
--
Dipl.-Inf. Stefan Bellon
Bauhaus Software Technologies | TTI GmbH TGZ Softwareanalysen c/o ISTE
Tel.: +49 711 78 16 221 | Universitätsstraße 38
Fax.: +49 711 78 16 380 | 70569 Stuttgart
Martin Dowie
> This approach has one problem: Those environment variables can be set
> by the user, so that the user can fake the setting to select wrong OS
> dependent code.
Absolutely! Though I'm not sure exactly that would acheive as presumably
they would have to fake everything else that followed! :-)
I think this is what "System.Name" was probably orginally intended to
provide but it never quite worked out that way...
Rob Norris
One lazy dirty method is to inspect the path or directory separators.
Not very exact, but may be useful eg:
type os_type is (Unix, Windows, Unknown);
function What_OS return os_type is
if gnat.os_lib.directory_separator = '/' then
return Unix;
elsif gnat.os_lib.directory_separator = '\' then
return Windows;
else
return Unknown;
end if;
end What_OS;
Martin Dowie
Jeffrey R. Carter
>
> if Ada.Environment_Variables.Exists ("OS")
> and Ada.Environment_Variables.Value ("OS") = "Windows_NT" then
I'd think "and then" would be appropriate here.
--
Jeff Carter
"I fart in your general direction."
Monty Python & the Holy Grail
05
Jeffrey R. Carter
> What we are doing is this: We configure our project for the target
> operating system and during that configuration, a small file with
> content similar to the following is generated:
>
> separate (Bauhaus.OS)
> function Get_OS return String is
> begin
> return "GNU/Linux";
> end Get_OS;
Is there some reason you're using String rather than an enumerated type?
Stefan Bellon
> Stefan Bellon wrote:
>
> > What we are doing is this: We configure our project for the target
> > operating system and during that configuration, a small file with
> > content similar to the following is generated:
> >
> > separate (Bauhaus.OS)
> > function Get_OS return String is
> > begin
> > return "GNU/Linux";
> > end Get_OS;
>
> Is there some reason you're using String rather than an enumerated
> type?
Nothing more than historical reasons. In some files where OS specific
code resides, we have something like the following on package level:
Is_MSWindows : constant Boolean := Get_OS = "Windows";
We hope that GNAT can optimize enough to propagate the Boolean constant
and only include the active configuration in a case like
if Is_MSWindows then
Do_It_The_MSWindows_Way;
else
Do_It_The_UNIX_Way;
end if;
But yes, making it an enumeration is a neater solution (done now).
Simon Wright
> Roger Blum wrote:
>> Is there a way within Ada (GNAT 3.15p) to tell whether the
>> application is running on Linux or Windows (and the version of the
>> OS)?
>
> There is no single standard why... yet!
>
> I think that you will be able to do this with "package
> Ada.Environment_Variables" come Ada200Y, e.g.
We would like to distinguish the PowerPC VxWorks target from the Intel
Windows development environment!
At the moment we just test the endianness, not great but it works for
us.
One solution, similar to what we use in another context, is as
suggested by Stefan. We used a visible constant enumeration, eg
type environment_kind is (host, target);
environment : constant environment_kind := host;
and compiler path selection (via GNAT project file).
That way, GNAT (certainly at -O2) will generate no object code for the
'wrong' branch. OK, you get to recompile the world, but that was going
to happen anyway!
Bernd Specht
news:BJj3f.711$QM5...@tornado.socal.rr.com:
Determination of the os is relative simple, the os version of a linux also.
Windows is a bit more complicated.
Use "Text_IO" and try "Open" the file "/proc/sys/kernel/osrelease". On a
Windows system, you will get an exception (Name_Error ?), on a Linux system
you can read the file which contains the kernel version. You can use
"/proc/sys/kernel/version" to get the build (release?) date.
If you cannot determine a linux system as described above, then try to open
a file that is typically for windows (e.g. "c:\winnt\system32\command.com").
If you get _no_ exception, then you are on a windows system. To find the
version, look for the file "prodspec.ini" (in c:\winnt\system32 and in c:
\system32). You can find the Window type (2000, XP) and the build number.
But - not on all Windows systems :-( (Win98 do not have this file).
Hope this helps.
Regards,
Bernd
PS: Don't forget to close the files ;-)
Michael Bode
> If you cannot determine a linux system as described above, then try to open
> a file that is typically for windows (e.g. "c:\winnt\system32\command.com").
> If you get _no_ exception, then you are on a windows system. To find the
> version, look for the file "prodspec.ini" (in c:\winnt\system32 and in c:
> \system32). You can find the Window type (2000, XP) and the build number.
> But - not on all Windows systems :-( (Win98 do not have this file).
It has not to be "c:\winnt". The correct path is "%Systemroot%" and
for that you must read the environment variable.
--
Michael Bode
Bernd Specht
But as he doesn't know the os, he cannot read an environment variable.
Personally I've never seen a Windows system on a different drive (older
versions of Windows required C: which often gave problems with OS/2 on same
drive). Beside this you can try C:, D: ...
Stefan Bellon
> Personally I've never seen a Windows system on a different drive
> (older versions of Windows required C: which often gave problems with
> OS/2 on same drive). Beside this you can try C:, D: ...
And I have never seen a Windows installed inside a directory called
"winnt".
Michael Bode
> Roger Blum wrote:
>> Is there a way within Ada (GNAT 3.15p) to tell whether the
>> application is running on Linux or Windows (and the version of the
>> OS)?
>
> There is no single standard why... yet!
>
> I think that you will be able to do this with "package
> Ada.Environment_Variables" come Ada200Y, e.g.
>
> if Ada.Environment_Variables.Exists ("OS")
> and Ada.Environment_Variables.Value ("OS") = "Windows_NT" then
> ...
> elsif Ada.Environment_Variables.Exists ("OSTYPE")
He could use GNAT.Os_Lib.Getenv ("OSTYPE")
--
Michael Bode
Robert A Duff
> Nothing more than historical reasons. In some files where OS specific
> code resides, we have something like the following on package level:
>
> Is_MSWindows : constant Boolean := Get_OS = "Windows";
>
> We hope that GNAT can optimize enough to propagate the Boolean constant
> and only include the active configuration in a case like
>
> if Is_MSWindows then
> Do_It_The_MSWindows_Way;
> else
> Do_It_The_UNIX_Way;
> end if;
Compilers will probably not be able to optimize this unless Get_OS is
inlined. I believe GNAT refuses to inline functions that return String.
> But yes, making it an enumeration is a neater solution (done now).
... and add pragma Inline to the function.
By the way, a case statement would be better than an if statement,
because then you get the benefit of the full coverage rules. "Not
windows" might imply "unix" today, but what if you add a third
possible value?
- Bob
Stefan Bellon
> I believe GNAT refuses to inline functions that return String.
Oh, I didn't know that. Thanks for the hint.
Robert A Duff
> Robert A Duff wrote:
>
> > I believe GNAT refuses to inline functions that return String.
>
> Oh, I didn't know that. Thanks for the hint.
Well, don't believe me -- look at the generated code to make sure.
And/or, turn on the option that warns about ignored pragmas Inline.
- Bob
Randy Brukardt
news:434e4...@glkas0286.greenlnk.net...
> That way doesn't give the version of the OS.
But once you know that you're running on Windows, you can arrange to call
the Win32 Get_Version function to learn all of the details. (You'd have to
do that with a dynamic call to avoid statically linking part of the Windows
runtime.) I presume something similar is available in the Linux API.
Randy.
Randy Brukardt
news:20051013225...@pscube.informatik.uni-stuttgart.de...
Bernd Specht wrote:
>>But as he doesn't know the os, he cannot read an environment variable.
Why not? Use Ada.Environment_Variables (Ada 200Y) or the
implementation-defined version that comes with your compiler. (Pretty much
every Ada compiler I know of has one.)
>> Personally I've never seen a Windows system on a different drive
>> (older versions of Windows required C: which often gave problems with
>> OS/2 on same drive). Beside this you can try C:, D: ...
>And I have never seen a Windows installed inside a directory called
>"winnt".
That was the standard for Windows NT and at least some Windows 2000 systems.
All of the systems here are that way. (OTOH, none of them are on drive C:)
As I said before, once you figure out that you are running on Windows (some
version), then dynamically load the GetVersionEx API function and get all of
the version details.
Randy.
Steve
news:87mzldf...@code-hal.de...
In the implementation of GNAT.OS_Lib there is an interesting definition:
On_Windows : constant Boolean := Directory_Separator = '\';
Apparently that's how GNAT finds the OS.
Once you have the OS, you can use OS specific code to find the version.
Steve
(The Duck)
Roger Blum
find an acceptable solution!
Regards,
Roger
"Roger Blum" <roge...@hawaii.rr.com> schrieb im Newsbeitrag
news:BJj3f.711$QM5...@tornado.socal.rr.com...
Martin Dowie
Yep - and (GMGPL) Claw can provide this! :-)
Quick question for you Randy - was the original intent that "System.Name"
provide this?
Cheers
-- Martin
Rob Norris
<martin...@baesystems.com> wrote:
>That way doesn't give the version of the OS.
>
I tried to imply that with "Not very exact, but may be useful"...
Once you know the system is Unix like (including VMS??) they should
have the 'uname -a' shell command which could be called by some Ada
function that wraps around C pragma system call in stdlib.h.
For Windows systems the command is 'ver'.
Something like:
with Interfaces.C.Strings;
with Ada.Text_IO;
--
--
function C_System (Command : in Interfaces.C.Strings.chars_ptr)
return Integer;
pragma Import (C, C_System, "system");
--
--
function Shell_Command (Command : in String) return Integer is
C_Command : Interfaces.C.Strings.chars_ptr :=
Interfaces.C.Strings.New_String (Command);
begin
return C_System (C_Command);
end Shell_Command;
type os_type is (Unix, Windows, Unknown);
--
--
function What_OS return os_type is
begin
if gnat.os_lib.directory_separator = '/' then
if shell_Command ("uname -a") = -1 then
Ada.Text_IO.Put_Line ("OS version inspection failed");
end if;
return Unix;
elsif gnat.os_lib.directory_separator = '\' then
if shell_Command ("ver") = -1 then
Ada.Text_IO.Put_Line ("OS version inspection failed");
end if;
return Windows;
else
return Unknown;
end if;
end What_OS;
procedure main is
Ada.Text_IO.OS_Type'Image (what_os);
end main;
Randy Brukardt
...
> Quick question for you Randy - was the original intent that "System.Name"
> provide this?
I think so. But it's an enumeration type, and adding values everytime a new
version of an OS becomes available is annoying, so there never was much
support for this.
Ada 83 compounded the problem by implying that users could simply use a
pragma System_Name to change the target. The net effect was that nobody
provided more than one target in the type System.Name.
For Janus/Ada, we used to provide a number of literals, but somewhere along
the line that got dropped, perhaps for the reason above. The name of the
literal is a bit helpful ("Win32" or "Unix"), but hardly portable in any
way.
Randy.
Larry Kilgallen
> Ada 83 compounded the problem by implying that users could simply use a
> pragma System_Name to change the target.
If it describes the target, certainly that must be under the
control of the user, since compilation might be in a different
environment from execution.
Martin Dowie
If you are cross compiling then the version of package System for the
target would have a System.Name to reflect the target.
I'm not sure why this is a problem for any 'closed' compiler, as the
vendor must know the exact target (OS + processor + switches).
I can understand there is a problem for 'open' compilers, as anyone can
build for any OS+processor+switches and make the system name anything -
even erroneous!
Cheers
-- Martin
Bernd Specht
news:keWdnbiXWJM...@megapath.net:
Is loading os-specific api function possible in a system independent way?
How, I would like to know.
Bernd
Ray Blaak
> Stefan Bellon wrote:
> > return "GNU/Linux";
>
> Is there some reason you're using String rather than an enumerated type?
I submit that an enumerated type is the wrong thing to do. Operating systems
are not fixed, can have many sub-variants. (WinOS, Win2000, WinNT, etc.).
Simply adding a new OS to some central definition should not impact all
existing code. In practical terms people should have had an "unknown OS"
handler anyway.
It's akin to having some app that processes first names as enumerated values
instead of strings. It's a mistake because the set of values are open ended
and are not known in advance, and can change depending on where you execute.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
rAYb...@STRIPCAPStelus.net The Rhythm has my soul.
Robert A Duff
> "Jeffrey R. Carter" <sp...@spam.com> writes:
>
> > Stefan Bellon wrote:
> > > return "GNU/Linux";
> >
> > Is there some reason you're using String rather than an enumerated type?
>
> I submit that an enumerated type is the wrong thing to do. Operating systems
> are not fixed, can have many sub-variants. (WinOS, Win2000, WinNT, etc.).
Well, maybe, but...
> Simply adding a new OS to some central definition should not impact all
> existing code. In practical terms people should have had an "unknown OS"
> handler anyway.
What is the directory separator character on "unknown OS"? ;-)
The advantage of using an enumeration type, and _not_ having an
Unknown_OS value, is that the compiler will tell you about all
the places you might need to change when you add a new OS.
That might or might not be what you want.
In my current project, I have two levels of distinction -- OS (Unix
vs. Windows, for example) and OS_Flavor (Solaris vs. Linux, for
example). I've not needed to distinguish (for example) different
versions of Linux, and it's probably a good idea to avoid that fine
level of distinction if possible.
> It's akin to having some app that processes first names as enumerated values
> instead of strings. It's a mistake because the set of values are open ended
> and are not known in advance, and can change depending on where you execute.
You probably don't port to a new OS quite as often as you add names to
your database of telephone numbers or whatever. And you probably don't
use wildly different code based on first names, which needs updating
every time you add a new first name.
- Bob
Ray Blaak
> Ray Blaak <rAYb...@STRIPCAPStelus.net> writes:
> > Simply adding a new OS to some central definition should not impact all
> > existing code. In practical terms people should have had an "unknown OS"
> > handler anyway.
>
> What is the directory separator character on "unknown OS"? ;-)
I don't know, of course. The point is to have a plan for it. In the worst case
you exit with the appropriate error message "unknown OS!". In practice you
assume "Unix".
> The advantage of using an enumeration type, and _not_ having an
> Unknown_OS value, is that the compiler will tell you about all
> the places you might need to change when you add a new OS.
> That might or might not be what you want.
That is the inherent advantage of using an enumerated type, of course.
My point is that the nature of the information does not correspond to a known
fixed set.
> In my current project, I have two levels of distinction -- OS (Unix
> vs. Windows, for example) and OS_Flavor (Solaris vs. Linux, for
> example). I've not needed to distinguish (for example) different
> versions of Linux, and it's probably a good idea to avoid that fine
> level of distinction if possible.
That you need only a few levels of distinction is a property of your current
project, not a property of the set of known OS types. That should be separated.
What I would do in your case is to make my own project-specific enumerated
type and decide the appropriate current literal value at startup based on the
the string-based values returned from querying the OS.
If the reported OS value cannot be correlated to one of your assumed OS types,
then you must decide what to do, which is likely to either assume it's a
default known one (e.g. some sort of "generic" Unix) or else bail out.
> > It's akin to having some app that processes first names as enumerated values
> > instead of strings. It's a mistake because the set of values are open ended
> > and are not known in advance, and can change depending on where you execute.
>
> You probably don't port to a new OS quite as often as you add names to
> your database of telephone numbers or whatever. And you probably don't
> use wildly different code based on first names, which needs updating
> every time you add a new first name.
That is essentially true in practice, I admit.
I guess what I care about is that the built in OS query that would live
somewhere under the System or Ada hierarchy would not return an enumerated
type, but rather a string.
That is, the enumeration should not be built into the language, since it is
not at all a stable enough set of values for the long term. Imagine being able
to code to an updated set only every 10 years, which seems to be Ada's upgrade
cycle.
Larry Kilgallen
> Robert A Duff <bob...@shell01.TheWorld.com> writes:
>> Ray Blaak <rAYb...@STRIPCAPStelus.net> writes:
>> > Simply adding a new OS to some central definition should not impact all
>> > existing code. In practical terms people should have had an "unknown OS"
>> > handler anyway.
>>
>> What is the directory separator character on "unknown OS"? ;-)
>
> I don't know, of course. The point is to have a plan for it. In the worst
> case you exit with the appropriate error message "unknown OS!". In practice
> you assume "Unix".
I got to work on some Ada code that used this "directory separator"
approach. Perhaps it is ok if your only choices are Windows or Unix,
but on VMS the characters ":[", "." and "]" are all used, except when
that list is ":<", "." and ">". Needless to say, the "directory separator"
approach was totally inadequate.
Robert A Duff
Yes, I agree. What you want is a set of operations for pulling apart
pathnames and putting them together in various ways. Even that won't
work on some systems, but I suspect it's good enough in practise.
Ada 2005 has something along those lines, but I haven't looked at
it carefully.
So perhaps I should have said, "What is the algorithm for parsing file
names on `unknown OS'?" ;-)
- Bob
Robert A Duff
> What I would do in your case is to make my own project-specific enumerated
> type and decide the appropriate current literal value at startup based on the
> the string-based values returned from querying the OS.
In my case, we have an enumeration type, and we compile in the value.
(That is, we have a package spec with three versions, and the build
scripts pick the right one.) There's no need to query anything at run
time (in my project).
> I guess what I care about is that the built in OS query that would live
> somewhere under the System or Ada hierarchy would not return an enumerated
> type, but rather a string.
>
> That is, the enumeration should not be built into the language, since
> it is not at all a stable enough set of values for the long
> term. Imagine being able to code to an updated set only every 10
> years, which seems to be Ada's upgrade cycle.
I agree that an enum type would not work here, as a language feature.
But neither would a string or anything else -- there is no solution
at the language level. This issue has to be solved by each project,
I think.
- Bob
Pascal Obry
> I got to work on some Ada code that used this "directory separator"
> approach. Perhaps it is ok if your only choices are Windows or Unix,
> but on VMS the characters ":[", "." and "]" are all used, except when
> that list is ":<", "." and ">". Needless to say, the "directory separator"
> approach was totally inadequate.
Agreed, all this is a configuration management problem. It is far better
in my view to have some kind of script that configure the software
before compilation. This script will check the OS for example and use
the proper bodies for some of the OS specific packages. This is exactly
was the ./configure & make does on most software. I think it is wrong to
try doing that with the language itself. As pointed out there it can
work in some very simple case but it won't generally.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
Ray Blaak
> > it is not at all a stable enough set of values for the long
> > term. Imagine being able to code to an updated set only every 10
> > years, which seems to be Ada's upgrade cycle.
>
> I agree that an enum type would not work here, as a language feature.
> But neither would a string or anything else -- there is no solution
> at the language level. This issue has to be solved by each project,
> I think.
I don't see the problem with a string value. I use:
System.getProperty("os.name")
in Java all the time, and it works well in practice, at least to distinguish
between the OS's that I care about.
Ray Blaak
> Agreed, all this is a configuration management problem. It is far better
> in my view to have some kind of script that configure the software
> before compilation. This script will check the OS for example and use
> the proper bodies for some of the OS specific packages. This is exactly
> was the ./configure & make does on most software. I think it is wrong to
> try doing that with the language itself. As pointed out there it can
> work in some very simple case but it won't generally.
In languages like Ada that tend to need to be separately compiled for the
target OS, this is reasonable.
In languages that can portably run "anywhere", like Java in particular, some
sort of runtime query is needed, since the code is built once but executed in
multiple environments.
And then there is the case of ports of Ada to the JVM, so that Ada apps can in
fact run in multiple environments as well.