Qt-interest Archive, March 2002
How can I tell what OS I'm running on during application execution?
Message 1 in thread
My program that will be running on Windows needs to output a text file
that another Windows application can parse. This other application is
hard coded that when you are looking for one of these files, to have the
file open dialog box look in a specific directory for the text file. So
when my program is running under Windows, I want to save the file out to
that path.
However, I'm doing most of the development on Linux and that path
obviously doesn't exist on Linux (nor does the application to read this
text file), so if I compile and run the program on Linux, I'd just want
my program to output the text file in the current directory so I can
just double-check that the file is correct.
So what I'm looking for is something like:
QFile = file;
if (OS() == Windows)
{
file.open("C:\foo\bar\text.txt");
}
else if (OS () == Unix)
{
file.open("text.txt");
}
// do file stuff....
I can't seem to find any function that returns a value that tells me
what I'm running on. It seems there must be something because elsewhere
in my code I'm using QSettings objects and I've got the line:
settings.insertSearchPath( QSettings::Windows, "/MyCompany" );
And reading about QSettings it says that the above line of code will not
do anything if you aren't running on Windows. I've verified this to be
true since under Linux, my settings just show up in .qt/pilot_display,
but under Windows they show up under
HKEY_LOCAL_MACHINE\Software\MyCompany\Pilot_Display.
Are other people dealing with this? How did you solve it? It seems
like I could do some sort of compile time defines, but it seems like
this capability should already be in Qt somewhere... If not, is there a
reason why it isn't there?
Sean
Message 2 in thread
Sean Murphy wrote:
> My program that will be running on Windows needs to output a text file
> that another Windows application can parse. This other application is
> hard coded that when you are looking for one of these files, to have the
> file open dialog box look in a specific directory for the text file. So
> when my program is running under Windows, I want to save the file out to
> that path.
>
> However, I'm doing most of the development on Linux and that path
> obviously doesn't exist on Linux (nor does the application to read this
> text file), so if I compile and run the program on Linux, I'd just want
> my program to output the text file in the current directory so I can
> just double-check that the file is correct.
>
> So what I'm looking for is something like:
>
> QFile = file;
> if (OS() == Windows)
> {
> file.open("C:\foo\bar\text.txt");
> }
> else if (OS () == Unix)
> {
> file.open("text.txt");
> }
>
> // do file stuff....
>
> I can't seem to find any function that returns a value that tells me
> what I'm running on. It seems there must be something because elsewhere
> in my code I'm using QSettings objects and I've got the line:
> settings.insertSearchPath( QSettings::Windows, "/MyCompany" );
> And reading about QSettings it says that the above line of code will not
> do anything if you aren't running on Windows. I've verified this to be
> true since under Linux, my settings just show up in .qt/pilot_display,
> but under Windows they show up under
> HKEY_LOCAL_MACHINE\Software\MyCompany\Pilot_Display.
>
> Are other people dealing with this? How did you solve it? It seems
> like I could do some sort of compile time defines, but it seems like
> this capability should already be in Qt somewhere... If not, is there a
> reason why it isn't there?
>
> Sean
>
> --
> List archive and information: http://qt-interest.trolltech.com
>
>
>
As far as I know, preprocessor directives are all there
is:
Q_WS_X11 for X11
Q_WS_WIN for Windows
Q_WS_MACX for MacOS X
Q_WS_QWS for Embedded
--
[ signature omitted ]
Message 3 in thread
You might do the following:
Put to your project file something like
DEFINES += LINUX
and put to your code
#ifdef LINUX
... code
#elif ...
... code
#endif
If you have to differ between the couple of Windows
variants you must query their registry like:
error = RegOpenKeyEx(HKEY_CURRENT_USER, subkey, 0, KEY_READ, &phkey);
if (error == ERROR_SUCCESS)
{
error = RegQueryValueEx(phkey, "Version", NULL, NULL, (unsigned char *)login,
(unsigned long *)&data_size);
if (error == ERROR_SUCCESS)
{
if (!strcmp(login, "Windows 95"))
os_version = 95;
else
os_version = 98;
}
else
{
/* give error message */
}
Note: That code is not complete; I'd copied it somewhere out of mine.
Hope that helps a bit
Dietmar Kovar
Message 4 in thread
- Subject: Re: How can I tell what OS I'm running on during application execution?
- From: "Volker Hilsheimer" <vohi@xxxxxx>
- Date: Thu, 7 Mar 2002 18:30:55 +0100
- To: <qt-interest@xxxxxxxxxxxxx>
See qglobals.h - there are plenty of #defines to determine the platform
during compile time, which for all practical cases is the platform
during runtime.
The only exception is Windows; different Windows versions are provided
by qWinVersion().
--
[ signature omitted ]
Message 5 in thread
Ok, I figured there was a way to do it with defines.
One question things brings to mind that doesn't apply to me - it's more
of a big picture thing is:
What happens if someone runs a windows compiled program under something
like WINE? I don't even know if Windows Qt apps run under WINE, but
assuming they do, wouldn't using the #define method make the binary
think that it is running under Windows, but it is really running on
Linux, and then the path that it is looking for C:\foo\bar\ wouldn't
work?
I apologize if this isn't 100% correct in thought, I've never used WINE
before, I just know that it is out there and allows Windows binaries to
run on Linux. Maybe it takes care of faking out paths?
Sean
> -----Original Message-----
> From: Volker Hilsheimer [mailto:vohi@gmx.de]
> Sent: Thursday, March 07, 2002 12:31 PM
> To: qt-interest@trolltech.com
> Subject: Re: How can I tell what OS I'm running on during
> application execution?
>
>
> See qglobals.h - there are plenty of #defines to determine
> the platform during compile time, which for all practical
> cases is the platform during runtime. The only exception is
> Windows; different Windows versions are provided by qWinVersion().
>
> --
> Volker
>
> --
> List archive and information: http://qt-interest.trolltech.com
>
Message 6 in thread
- Subject: Re: How can I tell what OS I'm running on during application execution?
- From: "Volker Hilsheimer" <vohi@xxxxxx>
- Date: Thu, 7 Mar 2002 18:58:13 +0100
- To: <qt-interest@xxxxxxxxxxxxx>
> Ok, I figured there was a way to do it with defines.
>
> One question things brings to mind that doesn't apply to me - it's
more
> of a big picture thing is:
>
> What happens if someone runs a windows compiled program under
something
> like WINE? I don't even know if Windows Qt apps run under WINE, but
> assuming they do, wouldn't using the #define method make the binary
> think that it is running under Windows, but it is really running on
> Linux, and then the path that it is looking for C:\foo\bar\ wouldn't
> work?
>
> I apologize if this isn't 100% correct in thought, I've never used
WINE
> before, I just know that it is out there and allows Windows binaries
to
> run on Linux. Maybe it takes care of faking out paths?
>
> Sean
>
I would think any problem with Qt and WINE in that respect would be a
problem with any toolkit and WINE, and the problem you talk about is
actually also present when using Qt/X11 rather than WINE. C:\... will
never exist in a cross platform environment, so hardcoding values like
those doesn't make sense in cross platform applications. Qt provides
some means to find some standard directories (e.g. QDir::homeDirPath()
etc.).
--
[ signature omitted ]
Message 7 in thread
I think you may have misunderstood, I'd like to have something like this
in my code:
QFile = file;
if (QtOS() == QtOS::Windows)
{
// Running on Windows use this absolute path
file.open("C:\foo\bar\text.txt");
}
else if (QtOS () == QtOS::Unix)
{
// Running on Linux, just open file in current directory
file.open("text.txt");
}
Where Qt is some function that returns an enumeration equal to the OS I
am running on. From the previous replies, this obviously doesn't exist,
so you are saying to do this instead:
#ifdef (QT_OS_WIN32)
// Compiling on Windows use absolute path
file.open("C:\foo\bar\text.txt");
#else
// Compiling on Linux, use current directory
file.open("text.txt");
#endif
The problem is that this is a compile time solution, so if someone
compiles the application under windows, the open command will ALWAYS
look for C:\foo\bar\text.txt, even when run under WINE. But since C:\
never exists under Linux if someone runs this Windows binary under WINE,
the path isn't going to exist. Whereas the run-time version that I want
to do would tell the program "Hey, even though you were compiled for
Windows, you are running in Linux, so use the local directory, not the
absolute path". And unfortunately for my application on Windows, it
needs to look in an absolute path, not a path that QDir::homeDirPath()
is going to help find.
Does this make more sense?
> -----Original Message-----
> From: owner-qt-interest@trolltech.com
> [mailto:owner-qt-interest@trolltech.com] On Behalf Of Volker
> Hilsheimer
> Sent: Thursday, March 07, 2002 12:58 PM
> To: qt-interest@trolltech.com
> Subject: Re: How can I tell what OS I'm running on during
> application execution?
>
>
> > Ok, I figured there was a way to do it with defines.
> >
> > One question things brings to mind that doesn't apply to me - it's
> more
> > of a big picture thing is:
> >
> > What happens if someone runs a windows compiled program under
> something
> > like WINE? I don't even know if Windows Qt apps run under
> WINE, but
> > assuming they do, wouldn't using the #define method make the binary
> > think that it is running under Windows, but it is really running on
> > Linux, and then the path that it is looking for C:\foo\bar\
> wouldn't
> > work?
> >
> > I apologize if this isn't 100% correct in thought, I've never used
> WINE
> > before, I just know that it is out there and allows Windows binaries
> to
> > run on Linux. Maybe it takes care of faking out paths?
> >
> > Sean
> >
>
> I would think any problem with Qt and WINE in that respect
> would be a problem with any toolkit and WINE, and the problem
> you talk about is actually also present when using Qt/X11
> rather than WINE. C:\... will never exist in a cross platform
> environment, so hardcoding values like those doesn't make
> sense in cross platform applications. Qt provides some means
> to find some standard directories (e.g. QDir::homeDirPath() etc.).
>
> --
> Volker
>
> --
> List archive and information: http://qt-interest.trolltech.com
>
Message 8 in thread
What about using this?
os.h
-----
class OS
{
enum ostypes
{
WindowsOS,
LinuxOS,
NumberOfOS
};
#ifdef (QT_OS_WIN32)
static const int m_nOS = WindowsOS;
#else (QT_OS_LINUX)
static const int m_nOS = LinuxOS;
#endif
}
----- Original Message -----
From: "Sean Murphy" <sean.murphy@veridian.com>
To: <vohi@gmx.de>; <qt-interest@trolltech.com>
Sent: Thursday, March 07, 2002 1:50 PM
Subject: RE: How can I tell what OS I'm running on during application
execution?
> I think you may have misunderstood, I'd like to have something like this
> in my code:
>
> QFile = file;
> if (QtOS() == QtOS::Windows)
> {
> // Running on Windows use this absolute path
> file.open("C:\foo\bar\text.txt");
> }
> else if (QtOS () == QtOS::Unix)
> {
> // Running on Linux, just open file in current directory
> file.open("text.txt");
> }
>
> Where Qt is some function that returns an enumeration equal to the OS I
> am running on. From the previous replies, this obviously doesn't exist,
> so you are saying to do this instead:
>
> #ifdef (QT_OS_WIN32)
> // Compiling on Windows use absolute path
> file.open("C:\foo\bar\text.txt");
> #else
> // Compiling on Linux, use current directory
> file.open("text.txt");
> #endif
Message 9 in thread
Hello Maxime,
Thursday, March 07, 2002, 8:03:26 PM, you wrote:
MA> What about using this?
MA> os.h
MA> -----
MA> class OS
MA> {
MA> enum ostypes
MA> {
MA> WindowsOS,
MA> LinuxOS,
MA> NumberOfOS
MA> };
MA> #ifdef (QT_OS_WIN32)
MA> static const int m_nOS = WindowsOS;
MA> #else (QT_OS_LINUX)
MA> static const int m_nOS = LinuxOS;
MA> #endif
MA> }
... or, to stay independent of Qt,
class OS
{
enum ostypes ...
#ifdef _WIN32
static const int m_nOS = WindowsOS;
#else
static const int m_nOS = LinuxOS;
#endif
};
/eno
BTW: I'm pretty sure you meant
...
#elif defined (QT_OS_LINUX)
...
above.
Message 10 in thread
The point is that WINE is made to run programs that think they're running on
Windows. And one thing Windows programs often do is access files by their
absolute paths like "C:\blah\blah\blah". WINE *must* have some mechanism to
handle this already if it is at all successful at running Windows apps. So
it's WINE's job to map that C: path to some file on the actual OS's file
system. I don't know how WINE does it, but it must do it somehow.
So at least with the example you give, I think compile time decisions should
be perfectly fine.
--bb
Sean Murphy wrote:
> I think you may have misunderstood, I'd like to have something like this
> in my code:
>
> QFile = file;
> if (QtOS() == QtOS::Windows)
> {
> // Running on Windows use this absolute path
> file.open("C:\foo\bar\text.txt");
> }
> else if (QtOS () == QtOS::Unix)
> {
> // Running on Linux, just open file in current directory
> file.open("text.txt");
> }
>
> Where Qt is some function that returns an enumeration equal to the OS I
> am running on. From the previous replies, this obviously doesn't exist,
> so you are saying to do this instead:
>
> #ifdef (QT_OS_WIN32)
> // Compiling on Windows use absolute path
> file.open("C:\foo\bar\text.txt");
> #else
> // Compiling on Linux, use current directory
> file.open("text.txt");
> #endif
>
> The problem is that this is a compile time solution, so if someone
> compiles the application under windows, the open command will ALWAYS
> look for C:\foo\bar\text.txt, even when run under WINE. But since C:\
> never exists under Linux if someone runs this Windows binary under WINE,
> the path isn't going to exist. Whereas the run-time version that I want
> to do would tell the program "Hey, even though you were compiled for
> Windows, you are running in Linux, so use the local directory, not the
> absolute path". And unfortunately for my application on Windows, it
> needs to look in an absolute path, not a path that QDir::homeDirPath()
> is going to help find.
>
> Does this make more sense?
>
> > -----Original Message-----
> > From: owner-qt-interest@trolltech.com
> > [mailto:owner-qt-interest@trolltech.com] On Behalf Of Volker
> > Hilsheimer
> > Sent: Thursday, March 07, 2002 12:58 PM
> > To: qt-interest@trolltech.com
> > Subject: Re: How can I tell what OS I'm running on during
> > application execution?
> >
> >
> > > Ok, I figured there was a way to do it with defines.
> > >
> > > One question things brings to mind that doesn't apply to me - it's
> > more
> > > of a big picture thing is:
> > >
> > > What happens if someone runs a windows compiled program under
> > something
> > > like WINE? I don't even know if Windows Qt apps run under
> > WINE, but
> > > assuming they do, wouldn't using the #define method make the binary
> > > think that it is running under Windows, but it is really running on
> > > Linux, and then the path that it is looking for C:\foo\bar\
> > wouldn't
> > > work?
> > >
> > > I apologize if this isn't 100% correct in thought, I've never used
> > WINE
> > > before, I just know that it is out there and allows Windows binaries
> > to
> > > run on Linux. Maybe it takes care of faking out paths?
> > >
> > > Sean
> > >
> >
> > I would think any problem with Qt and WINE in that respect
> > would be a problem with any toolkit and WINE, and the problem
> > you talk about is actually also present when using Qt/X11
> > rather than WINE. C:\... will never exist in a cross platform
> > environment, so hardcoding values like those doesn't make
> > sense in cross platform applications. Qt provides some means
> > to find some standard directories (e.g. QDir::homeDirPath() etc.).
> >
> > --
> > Volker
> >
> > --
> > List archive and information: http://qt-interest.trolltech.com
> >
>
> --
> List archive and information: http://qt-interest.trolltech.com
Message 11 in thread
Am Donnerstag 07 März 2002 20:22:20 schrieb Bill Baxter:
> The point is that WINE is made to run programs that think they're running
> on Windows. And one thing Windows programs often do is access files by
> their absolute paths like "C:\blah\blah\blah". WINE *must* have some
> mechanism to handle this already if it is at all successful at running
> Windows apps. So it's WINE's job to map that C: path to some file on the
> actual OS's file system. I don't know how WINE does it, but it must do it
> somehow.
>
> So at least with the example you give, I think compile time decisions
> should be perfectly fine.
Exactly, you specify in either the global or the user's wine config file which
real path C:\, D:\ etc map to. This is not a Qt specific problem. Any
application compiled for Windows will "think" it's running on Windows when
run under WINE. That's the whole point of WINE - to emulate a Windows
environment. So, from anything run under WINE, you access files with Windows
paths. The only difference are winelib apps that can use both - Windows paths
via WinAPI and Linux paths via the standard C library.
--
[ signature omitted ]
Message 12 in thread
----- Original Message -----
From: "Volker Hilsheimer" <vohi@gmx.de>
To: <qt-interest@trolltech.com>
Sent: Thursday, March 07, 2002 11:30 AM
Subject: Re: How can I tell what OS I'm running on during application execution?
> See qglobals.h - there are plenty of #defines to determine the platform
> during compile time, which for all practical cases is the platform
> during runtime.
The OP's question was asked by another on Feb. 21 in the mailing list.
It's still not clear to me whether the #defines in qlobals.h are intended for
public use or are implementation details of Qt. In the absence of documentation
to the contrary, I would presume the latter.
If they're not intended for public use, Trolltech could change them between
versions. You could insulate your code from changes to Trolltech's macros by
using your own macros. At the very least, you could define your macros in terms
of Trolltech's, in exactly one place.
