www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - how to detect OS =?UTF-8?Q?architecture=3F?=

reply Hugo Florentino <hugo acdam.cu> writes:
Hi,

I am writing a launcher to make a Windows application portable, but 
since this application supports both x86 and x86_64, I would like to 
detect the architecture of the OS my launcher is being run on, in order 
to launch the proper executable.

How can I do this?

Regards, Hugo
Dec 16 2013
next sibling parent reply "Jeroen Bollen" <jbinero gmail.com> writes:
On Monday, 16 December 2013 at 10:54:15 UTC, Hugo Florentino
wrote:
 Hi,

 I am writing a launcher to make a Windows application portable, 
 but since this application supports both x86 and x86_64, I 
 would like to detect the architecture of the OS my launcher is 
 being run on, in order to launch the proper executable.

 How can I do this?

 Regards, Hugo
version(Windows) { // Windows code goes here } else { // Other OS code goes here } More here: http://dlang.org/version.html
Dec 16 2013
parent reply "MrSmith" <mrsmith33 yandex.ru> writes:
 version(Windows) {
       // Windows code goes here
 } else {
      // Other OS code goes here
 }

 More here: http://dlang.org/version.html
I think he wants determine at runtime what architecture x86 or x64 processor supprots and launch appropriate executable. I think this is what he want http://dlang.org/phobos/core_cpuid.html#.isX86_64
Dec 16 2013
parent reply Hugo Florentino <hugo acdam.cu> writes:
On Mon, 16 Dec 2013 12:40:17 +0100, MrSmith wrote:
 version(Windows) {
       // Windows code goes here
 } else {
      // Other OS code goes here
 }

 More here: http://dlang.org/version.html
I think he wants determine at runtime what architecture x86 or x64 processor supprots and launch appropriate executable. I think this is what he want http://dlang.org/phobos/core_cpuid.html#.isX86_64
Thanks, that's precisely what I needed :)
Dec 16 2013
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Monday, 16 December 2013 at 11:56:07 UTC, Hugo Florentino 
wrote:
 On Mon, 16 Dec 2013 12:40:17 +0100, MrSmith wrote:
 version(Windows) {
      // Windows code goes here
 } else {
     // Other OS code goes here
 }

 More here: http://dlang.org/version.html
I think he wants determine at runtime what architecture x86 or x64 processor supprots and launch appropriate executable. I think this is what he want http://dlang.org/phobos/core_cpuid.html#.isX86_64
Thanks, that's precisely what I needed :)
Are you sure? This will tell you about the processor, but not necessarily about what the OS supports. I don't know, but you may find that when using windows 32bit on an x64 machine, cpuid will tell you the cpu is 64bit, but the OS won't let you run any 64bit code.
Dec 16 2013
next sibling parent reply Hugo Florentino <hugo acdam.cu> writes:
On Mon, 16 Dec 2013 12:59:52 +0100, John Colvin wrote:
 On Monday, 16 December 2013 at 11:56:07 UTC, Hugo Florentino wrote:
 On Mon, 16 Dec 2013 12:40:17 +0100, MrSmith wrote:
 I think this is what he want
 http://dlang.org/phobos/core_cpuid.html#.isX86_64
Thanks, that's precisely what I needed :)
Are you sure? This will tell you about the processor, but not necessarily about what the OS supports. I don't know, but you may find that when using windows 32bit on an x64 machine, cpuid will tell you the cpu is 64bit, but the OS won't let you run any 64bit code.
You are right. I realized that this function was not quite what I needed when running this code on a 32 bit system: import std.stdio, core.cpuid; int main() { immutable auto appname = "myapp"; auto appversion = !isX86_64() ? appname ~ "32" : appname ~ "64") ~ ".exe"; scope(failure) return -1; writeln(appversion); return 0; } I was expecting "myapp32.exe" but got "myapp64.exe". Apparently what isX86_64() detects is the capability of the processor, not the arquitecture of the OS. So currently D has no specific function for detecting the OS architecture at runtime? I had not expected this. I will try using the other options though. Thanks
Dec 16 2013
next sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Mon, 16 Dec 2013 08:19:40 -0500
schrieb Hugo Florentino <hugo acdam.cu>:

 So currently D has no specific function for detecting the OS=20
 architecture at runtime? I had not expected this.
You are the first to raise this question. I guess most of us just install either a 32-bit version or a 64-bit version and never found a need to ask from inside the running program if it is actually the correct architecture. Your launcher use-case stands out. But there is really more to it than 32 or 64. There is also x32, which is a mix of 32-bit pointers with 64-bit CPU features, giving the best overall performance. Also, while dmd only emits x86 code, the language and the standard library strive to be architecture independent except for some minimal requirements for data types or thread local storage. And a function like that should probably return an array of supported ABIs, like [amd64, x32, x86] with the "main" or most feature rich architecture in index 0. Just my 2=C2=A2 --=20 Marco
Dec 16 2013
prev sibling parent reply "Gary Willoughby" <dev nomad.so> writes:
On Monday, 16 December 2013 at 13:19:52 UTC, Hugo Florentino 
wrote:
 On Mon, 16 Dec 2013 12:59:52 +0100, John Colvin wrote:
 On Monday, 16 December 2013 at 11:56:07 UTC, Hugo Florentino 
 wrote:
 On Mon, 16 Dec 2013 12:40:17 +0100, MrSmith wrote:
 I think this is what he want
 http://dlang.org/phobos/core_cpuid.html#.isX86_64
Thanks, that's precisely what I needed :)
Are you sure? This will tell you about the processor, but not necessarily about what the OS supports. I don't know, but you may find that when using windows 32bit on an x64 machine, cpuid will tell you the cpu is 64bit, but the OS won't let you run any 64bit code.
You are right. I realized that this function was not quite what I needed when running this code on a 32 bit system: import std.stdio, core.cpuid; int main() { immutable auto appname = "myapp"; auto appversion = !isX86_64() ? appname ~ "32" : appname ~ "64") ~ ".exe"; scope(failure) return -1; writeln(appversion); return 0; } I was expecting "myapp32.exe" but got "myapp64.exe". Apparently what isX86_64() detects is the capability of the processor, not the arquitecture of the OS. So currently D has no specific function for detecting the OS architecture at runtime? I had not expected this. I will try using the other options though. Thanks
Try building the launcher as a 32bit executable then use the following code: import std.stdio; import core.sys.windows.windows; enum AMD64 = 9; enum IA64 = 6; enum X86 = 0; enum UNKNOWN = 0xFFFF; void main() { SYSTEM_INFO executableEnvironment; SYSTEM_INFO outerEnvironment; GetSystemInfo(&executableEnvironment); GetNativeSystemInfo(&outerEnvironment); // See the above enums for values. writefln("Executable: %s", executableEnvironment.wProcessorArchitecture); writefln("Outer: %s", outerEnvironment.wProcessorArchitecture); } If the launcher is running under Wow64 (the 32bit emulation layer on a 64bit processor) the results will be different for executableEnvironment and outerEnvironment. GetSystemInfo gets the environment the executable is running under, GetNativeSystemInfo gets the 'real' environment. I guess it's a place to start?
Dec 16 2013
parent reply Hugo Florentino <hugo acdam.cu> writes:
GetNativeSystemInfo worked. Thanks!

The code ended being like this (it seems to be working both in x86 and 
x86_64):

import std.file: exists, getcwd;
import std.path: buildPath, dirName;
import std.string: format, toStringz;
import core.sys.windows.windows;

enum X86   = 0;
enum AMD64 = 9;
immutable static auto appname = "myapp";

extern(Windows) HANDLE ShellExecuteA(HWND, LPCSTR, LPCSTR, LPCSTR, 
LPCSTR, int);
extern(Windows) int MessageBoxA(HWND, LPCSTR, LPCSTR, UINT);

int main() {
   auto appath = getcwd();
   string appexe;
   SYSTEM_INFO env;
   GetNativeSystemInfo(&env);
   switch(env.wProcessorArchitecture) {
     case X86: appexe = buildPath(appath, appname ~ "32.exe"); break;
     case AMD64: appexe = buildPath(appath, appname ~ "64.exe"); break;
     default:
       MessageBoxA(null, "System architecture is not supported.", 
"Error", MB_ICONHAND + MB_OK);
       return -1;
   }
   if (exists(appexe)) {
     auto param = format(`/ini="%s"`, buildPath(appath, appname ~ 
".ini"));
     ShellExecuteA(null, "", toStringz(appexe), toStringz(param), "", 
SW_SHOWMAXIMIZED);
     scope(failure) return -2;
   }
   return 0;
}
Dec 16 2013
parent reply "Gary Willoughby" <dev nomad.so> writes:
On Monday, 16 December 2013 at 21:23:11 UTC, Hugo Florentino
wrote:
 GetNativeSystemInfo worked. Thanks!

 The code ended being like this (it seems to be working both in 
 x86 and x86_64):

 import std.file: exists, getcwd;
 import std.path: buildPath, dirName;
 import std.string: format, toStringz;
 import core.sys.windows.windows;

 enum X86   = 0;
 enum AMD64 = 9;
 immutable static auto appname = "myapp";

 extern(Windows) HANDLE ShellExecuteA(HWND, LPCSTR, LPCSTR, 
 LPCSTR, LPCSTR, int);
 extern(Windows) int MessageBoxA(HWND, LPCSTR, LPCSTR, UINT);

 int main() {
   auto appath = getcwd();
   string appexe;
   SYSTEM_INFO env;
   GetNativeSystemInfo(&env);
   switch(env.wProcessorArchitecture) {
     case X86: appexe = buildPath(appath, appname ~ "32.exe"); 
 break;
     case AMD64: appexe = buildPath(appath, appname ~ "64.exe"); 
 break;
     default:
       MessageBoxA(null, "System architecture is not 
 supported.", "Error", MB_ICONHAND + MB_OK);
       return -1;
   }
   if (exists(appexe)) {
     auto param = format(`/ini="%s"`, buildPath(appath, appname 
 ~ ".ini"));
     ShellExecuteA(null, "", toStringz(appexe), 
 toStringz(param), "", SW_SHOWMAXIMIZED);
     scope(failure) return -2;
   }
   return 0;
 }
Make sure you handle if users have a 32bit OS installed on a 64bit PC.
Dec 17 2013
parent reply Hugo Florentino <hugo acdam.cu> writes:
On Tue, 17 Dec 2013 15:13:18 +0100, Gary Willoughby wrote:
 Make sure you handle if users have a 32bit OS installed on a
 64bit PC.
As a matter of fact that was the actual configuration in the system I wrote the app. I am now with a friend with the same configuration, and it also seems to be working. At work I use Windows 7 x86_64 and it also works.
Dec 17 2013
parent reply "Regan Heath" <regan netmail.co.nz> writes:
On Wed, 18 Dec 2013 04:22:23 -0000, Hugo Florentino <hugo acdam.cu> wrote:

 On Tue, 17 Dec 2013 15:13:18 +0100, Gary Willoughby wrote:
 Make sure you handle if users have a 32bit OS installed on a
 64bit PC.
As a matter of fact that was the actual configuration in the system I wrote the app. I am now with a friend with the same configuration, and it also seems to be working. At work I use Windows 7 x86_64 and it also works.
It works because the SYSTEM_INFO member "wProcessorArchitecture" is defined to be "The processor architecture of the installed operating system" .. note, *installed operating system*, not processor architecture. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Dec 18 2013
parent reply Hugo Florentino <hugo acdam.cu> writes:
On Wed, 18 Dec 2013 13:20:45 -0000, Regan Heath wrote:
 On Wed, 18 Dec 2013 04:22:23 -0000, Hugo Florentino <hugo acdam.cu> 
 wrote:

 On Tue, 17 Dec 2013 15:13:18 +0100, Gary Willoughby wrote:
 Make sure you handle if users have a 32bit OS installed on a
 64bit PC.
As a matter of fact that was the actual configuration in the system I wrote the app. I am now with a friend with the same configuration, and it also seems to be working. At work I use Windows 7 x86_64 and it also works.
It works because the SYSTEM_INFO member "wProcessorArchitecture" is defined to be "The processor architecture of the installed operating system" .. note, *installed operating system*, not processor architecture.
Well, isn't that what I needed to begin with? That's why I said OS architecture instead of CPU architecture. Unless you are refering to something else.
Dec 18 2013
parent "Regan Heath" <regan netmail.co.nz> writes:
On Wed, 18 Dec 2013 13:43:44 -0000, Hugo Florentino <hugo acdam.cu> wrote:

 On Wed, 18 Dec 2013 13:20:45 -0000, Regan Heath wrote:
 On Wed, 18 Dec 2013 04:22:23 -0000, Hugo Florentino <hugo acdam.cu>  
 wrote:

 On Tue, 17 Dec 2013 15:13:18 +0100, Gary Willoughby wrote:
 Make sure you handle if users have a 32bit OS installed on a
 64bit PC.
As a matter of fact that was the actual configuration in the system I wrote the app. I am now with a friend with the same configuration, and it also seems to be working. At work I use Windows 7 x86_64 and it also works.
It works because the SYSTEM_INFO member "wProcessorArchitecture" is defined to be "The processor architecture of the installed operating system" .. note, *installed operating system*, not processor architecture.
Well, isn't that what I needed to begin with?
Yes, I was just explaining 'why' it works :)
 That's why I said OS architecture instead of CPU architecture.
 Unless you are refering to something else.
I was just explaining for posterity/future readers. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Dec 20 2013
prev sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Mon, 16 Dec 2013 12:59:52 +0100
schrieb "John Colvin" <john.loughran.colvin gmail.com>:

 On Monday, 16 December 2013 at 11:56:07 UTC, Hugo Florentino 
 wrote:
 On Mon, 16 Dec 2013 12:40:17 +0100, MrSmith wrote:
 version(Windows) {
      // Windows code goes here
 } else {
     // Other OS code goes here
 }

 More here: http://dlang.org/version.html
I think he wants determine at runtime what architecture x86 or x64 processor supprots and launch appropriate executable. I think this is what he want http://dlang.org/phobos/core_cpuid.html#.isX86_64
Thanks, that's precisely what I needed :)
Are you sure? This will tell you about the processor, but not necessarily about what the OS supports. I don't know, but you may find that when using windows 32bit on an x64 machine, cpuid will tell you the cpu is 64bit, but the OS won't let you run any 64bit code.
...and your launcher would in turn fail to work on my Vista Home Premium 32-bit, which came pre-installed on a 64-bit system. -- Marco
Dec 16 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Monday, 16 December 2013 at 10:54:15 UTC, Hugo Florentino 
wrote:
 Hi,

 I am writing a launcher to make a Windows application portable, 
 but since this application supports both x86 and x86_64, I 
 would like to detect the architecture of the OS my launcher is 
 being run on, in order to launch the proper executable.

 How can I do this?

 Regards, Hugo
http://stackoverflow.com/questions/601089/detect-whether-current-windows-version-is-32-bit-or-64-bit http://support.microsoft.com/kb/556009 To detect environment variables you can use std.process.environment.get
Dec 16 2013
prev sibling next sibling parent reply "Gary Willoughby" <dev nomad.so> writes:
On Monday, 16 December 2013 at 10:54:15 UTC, Hugo Florentino 
wrote:
 Hi,

 I am writing a launcher to make a Windows application portable, 
 but since this application supports both x86 and x86_64, I 
 would like to detect the architecture of the OS my launcher is 
 being run on, in order to launch the proper executable.

 How can I do this?

 Regards, Hugo
version (Windows) { version (X86_64) { // 64bit code. } version (X86) { 32bit code. } }
Dec 16 2013
parent Mike Parker <aldacron gmail.com> writes:
On 12/16/2013 9:26 PM, Gary Willoughby wrote:
 On Monday, 16 December 2013 at 10:54:15 UTC, Hugo Florentino wrote:
 Hi,

 I am writing a launcher to make a Windows application portable, but
 since this application supports both x86 and x86_64, I would like to
 detect the architecture of the OS my launcher is being run on, in
 order to launch the proper executable.

 How can I do this?

 Regards, Hugo
version (Windows) { version (X86_64) { // 64bit code. } version (X86) { 32bit code. } }
That will tell him the version of Windows the executable was compiled on, but won't help him much when running a 32-bit executable on a 64-bit OS. He wants to detect the run-time architecture.
Dec 16 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-12-16 11:53, Hugo Florentino wrote:
 Hi,

 I am writing a launcher to make a Windows application portable, but
 since this application supports both x86 and x86_64, I would like to
 detect the architecture of the OS my launcher is being run on, in order
 to launch the proper executable.
The easiest would be: if you launcher is built for 64bit, pick the 64bit application, otherwise pick the 32bit application. -- /Jacob Carlborg
Dec 16 2013
parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Mon, 16 Dec 2013 16:04:07 +0100
schrieb Jacob Carlborg <doob me.com>:

 On 2013-12-16 11:53, Hugo Florentino wrote:
 Hi,

 I am writing a launcher to make a Windows application portable, but
 since this application supports both x86 and x86_64, I would like to
 detect the architecture of the OS my launcher is being run on, in order
 to launch the proper executable.
The easiest would be: if you launcher is built for 64bit, pick the 64bit application, otherwise pick the 32bit application.
Hehe, I guess the whole purpose of the launcher is to run in 32-bit and detect at runtime if the 64-bit main executable can be run or the 32-bit version must be used. -- Marco
Dec 16 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-12-16 17:46, Marco Leise wrote:

 Hehe, I guess the whole purpose of the launcher is to run in
 32-bit and detect at runtime if the 64-bit main executable can
 be run or the 32-bit version must be used.
The only advantage of that is that only a 32bit launcher needs to be distributed. Perhaps that's the whole idea. -- /Jacob Carlborg
Dec 16 2013
parent reply Hugo Florentino <hugo acdam.cu> writes:
On Mon, 16 Dec 2013 20:23:00 +0100, Jacob Carlborg wrote:
 On 2013-12-16 17:46, Marco Leise wrote:

 Hehe, I guess the whole purpose of the launcher is to run in
 32-bit and detect at runtime if the 64-bit main executable can
 be run or the 32-bit version must be used.
The only advantage of that is that only a 32bit launcher needs to be distributed. Perhaps that's the whole idea.
It is. :)
Dec 16 2013
parent reply "Regan Heath" <regan netmail.co.nz> writes:
On Mon, 16 Dec 2013 21:27:13 -0000, Hugo Florentino <hugo acdam.cu> wrote:

 On Mon, 16 Dec 2013 20:23:00 +0100, Jacob Carlborg wrote:
 On 2013-12-16 17:46, Marco Leise wrote:

 Hehe, I guess the whole purpose of the launcher is to run in
 32-bit and detect at runtime if the 64-bit main executable can
 be run or the 32-bit version must be used.
The only advantage of that is that only a 32bit launcher needs to be distributed. Perhaps that's the whole idea.
It is. :)
"Process Explorer" by sysinternals, now distributed by M$ does something similar. http://technet.microsoft.com/en-gb/sysinternals/bb896653.aspx It is a 32 bit exe, which detects the OS bit width and if it's 64 bit extracts a 64 exe from within itself to run. When you quit that 64 bit exe, it deletes the file it extracted from disk. It's quite a neat solution. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Dec 17 2013
parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Tue, 17 Dec 2013 13:30:25 -0000
schrieb "Regan Heath" <regan netmail.co.nz>:

 On Mon, 16 Dec 2013 21:27:13 -0000, Hugo Florentino <hugo acdam.cu> wrote:
 
 On Mon, 16 Dec 2013 20:23:00 +0100, Jacob Carlborg wrote:
 On 2013-12-16 17:46, Marco Leise wrote:

 Hehe, I guess the whole purpose of the launcher is to run in
 32-bit and detect at runtime if the 64-bit main executable can
 be run or the 32-bit version must be used.
The only advantage of that is that only a 32bit launcher needs to be distributed. Perhaps that's the whole idea.
It is. :)
"Process Explorer" by sysinternals, now distributed by M$ does something similar. http://technet.microsoft.com/en-gb/sysinternals/bb896653.aspx It is a 32 bit exe, which detects the OS bit width and if it's 64 bit extracts a 64 exe from within itself to run. When you quit that 64 bit exe, it deletes the file it extracted from disk. It's quite a neat solution. R
Only if your executable is self-contained. If you already have external DLLs or assets you can as well have a launcher and 2 actual binaries. -- Marco
Dec 17 2013
parent reply "Regan Heath" <regan netmail.co.nz> writes:
On Tue, 17 Dec 2013 15:13:20 -0000, Marco Leise <Marco.Leise gmx.de> wrote:

 Am Tue, 17 Dec 2013 13:30:25 -0000
 schrieb "Regan Heath" <regan netmail.co.nz>:

 On Mon, 16 Dec 2013 21:27:13 -0000, Hugo Florentino <hugo acdam.cu>  
 wrote:

 On Mon, 16 Dec 2013 20:23:00 +0100, Jacob Carlborg wrote:
 On 2013-12-16 17:46, Marco Leise wrote:

 Hehe, I guess the whole purpose of the launcher is to run in
 32-bit and detect at runtime if the 64-bit main executable can
 be run or the 32-bit version must be used.
The only advantage of that is that only a 32bit launcher needs to be distributed. Perhaps that's the whole idea.
It is. :)
"Process Explorer" by sysinternals, now distributed by M$ does something similar. http://technet.microsoft.com/en-gb/sysinternals/bb896653.aspx It is a 32 bit exe, which detects the OS bit width and if it's 64 bit extracts a 64 exe from within itself to run. When you quit that 64 bit exe, it deletes the file it extracted from disk. It's quite a neat solution. R
Only if your executable is self-contained. If you already have external DLLs or assets you can as well have a launcher and 2 actual binaries.
I don't see why that changes things? Sure, you cannot extract your *static* dependent dlls (those linked at compile time with libs), those have to exist before you can execute your 32 bit launcher. But, if you really wanted to, you could extract and runtime load dlls no problem. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Dec 18 2013
parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Wed, 18 Dec 2013 13:19:09 -0000
schrieb "Regan Heath" <regan netmail.co.nz>:

 On Tue, 17 Dec 2013 15:13:20 -0000, Marco Leise <Marco.Leise gmx.de> wrote:
 
 Am Tue, 17 Dec 2013 13:30:25 -0000
 schrieb "Regan Heath" <regan netmail.co.nz>:

 On Mon, 16 Dec 2013 21:27:13 -0000, Hugo Florentino <hugo acdam.cu>  
 wrote:

 On Mon, 16 Dec 2013 20:23:00 +0100, Jacob Carlborg wrote:
 On 2013-12-16 17:46, Marco Leise wrote:

 Hehe, I guess the whole purpose of the launcher is to run in
 32-bit and detect at runtime if the 64-bit main executable can
 be run or the 32-bit version must be used.
The only advantage of that is that only a 32bit launcher needs to be distributed. Perhaps that's the whole idea.
It is. :)
"Process Explorer" by sysinternals, now distributed by M$ does something similar. http://technet.microsoft.com/en-gb/sysinternals/bb896653.aspx It is a 32 bit exe, which detects the OS bit width and if it's 64 bit extracts a 64 exe from within itself to run. When you quit that 64 bit exe, it deletes the file it extracted from disk. It's quite a neat solution. R
Only if your executable is self-contained. If you already have external DLLs or assets you can as well have a launcher and 2 actual binaries.
I don't see why that changes things? Sure, you cannot extract your *static* dependent dlls (those linked at compile time with libs), those have to exist before you can execute your 32 bit launcher. But, if you really wanted to, you could extract and runtime load dlls no problem. R
That's my point. If you really wanted, you could do that but you can as well have a launcher and 2 application binaries and avoid this repeated file extraction/deletion and save yourself some troubles at the end of the day. -- Marco
Dec 19 2013
parent "Regan Heath" <regan netmail.co.nz> writes:
On Thu, 19 Dec 2013 09:41:26 -0000, Marco Leise <Marco.Leise gmx.de> wrote:

 Am Wed, 18 Dec 2013 13:19:09 -0000
 schrieb "Regan Heath" <regan netmail.co.nz>:

 On Tue, 17 Dec 2013 15:13:20 -0000, Marco Leise <Marco.Leise gmx.de>  
 wrote:

 Am Tue, 17 Dec 2013 13:30:25 -0000
 schrieb "Regan Heath" <regan netmail.co.nz>:

 On Mon, 16 Dec 2013 21:27:13 -0000, Hugo Florentino <hugo acdam.cu>
 wrote:

 On Mon, 16 Dec 2013 20:23:00 +0100, Jacob Carlborg wrote:
 On 2013-12-16 17:46, Marco Leise wrote:

 Hehe, I guess the whole purpose of the launcher is to run in
 32-bit and detect at runtime if the 64-bit main executable can
 be run or the 32-bit version must be used.
The only advantage of that is that only a 32bit launcher needs to
be
 distributed. Perhaps that's the whole idea.
It is. :)
"Process Explorer" by sysinternals, now distributed by M$ does
something
 similar.
 http://technet.microsoft.com/en-gb/sysinternals/bb896653.aspx

 It is a 32 bit exe, which detects the OS bit width and if it's 64 bit
 extracts a 64 exe from within itself to run.  When you quit that 64  
bit
 exe, it deletes the file it extracted from disk.  It's quite a neat
 solution.

 R
Only if your executable is self-contained. If you already have external DLLs or assets you can as well have a launcher and 2 actual binaries.
I don't see why that changes things? Sure, you cannot extract your *static* dependent dlls (those linked at compile time with libs), those have to exist before you can execute your 32 bit launcher. But, if you really wanted to, you could extract and runtime load dlls no problem. R
That's my point. If you really wanted, you could do that but you can as well have a launcher and 2 application binaries and avoid this repeated file extraction/deletion and save yourself some troubles at the end of the day.
Sure, but having a self contained exe is useful and *cool* :) R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Dec 20 2013
prev sibling parent reply "Regan Heath" <regan netmail.co.nz> writes:
On Mon, 16 Dec 2013 10:53:45 -0000, Hugo Florentino <hugo acdam.cu> wrote:
 I am writing a launcher to make a Windows application portable, but  
 since this application supports both x86 and x86_64, I would like to  
 detect the architecture of the OS my launcher is being run on, in order  
 to launch the proper executable.

 How can I do this?
Compile the launcher as 32bit, and use this global boolean "isWow64": import std.stdio; import std.internal.windows.advapi32; void main(string[] args) { writefln(isWow64 ? "yes" : "no"); } You can thank Kenji for this one :) Someone document this somewhere please :p The code from advapi32 for those interested.. immutable bool isWow64; shared static this() { // WOW64 is the x86 emulator that allows 32-bit Windows-based applications to run seamlessly on 64-bit Windows // IsWow64Process Function - Minimum supported client - Windows Vista, Windows XP with SP2 alias extern(Windows) BOOL function(HANDLE, PBOOL) fptr_t; auto hKernel = GetModuleHandleA("kernel32"); auto IsWow64Process = cast(fptr_t) GetProcAddress(hKernel, "IsWow64Process"); BOOL bIsWow64; isWow64 = IsWow64Process && IsWow64Process(GetCurrentProcess(), &bIsWow64) && bIsWow64; } Basically, your 32 bit launcher process has to, at runtime, ask Kernel32 for a function "IsWow64Process" which only exists on 64 bit windows. So, if it doesn't find it, it's 32 bit. If it finds it, it calls it with the current PID to find out of the current process is a 32 bit app running inside WOW64 (the emulator layer) and that gives you the answer. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Dec 16 2013
parent reply Hugo Florentino <hugo acdam.cu> writes:
On Mon, 16 Dec 2013 17:04:18 -0000, Regan Heath wrote:
 ...
 Compile the launcher as 32bit, and use this global boolean "isWow64":
 ...
Thanks, it's nice to have another option. What do you guys think are the possible advantages/disadvantages of either solution?
Dec 16 2013
parent reply "Regan Heath" <regan netmail.co.nz> writes:
On Mon, 16 Dec 2013 21:26:31 -0000, Hugo Florentino <hugo acdam.cu> wrote:

 On Mon, 16 Dec 2013 17:04:18 -0000, Regan Heath wrote:
 ...
 Compile the launcher as 32bit, and use this global boolean "isWow64":
 ...
Thanks, it's nice to have another option. What do you guys think are the possible advantages/disadvantages of either solution?
Is GetNativeSystemInfo your other solution? On the MSDN page for GetNativeSystemInfo it recommends using IsWow64Process to detect if you're running under WOW64, at which point you would then call GetNativeSystemInfo. I am not sure what GetNativeSystemInfo does if called from a 32 bit exe on a 32 bit OS.. I /know/ that the code in std.internal.windows.advapi32 which dynamically loads and calls IsWow64Process will work, because we use it here at work for this very purpose. It's also the simplest most direct way to answer this specific question and it's already present, tested and working in phobos .. so I would be inclined to use it, in preference over GetNativeSystemInfo. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Dec 17 2013
parent reply Hugo Florentino <hugo acdam.cu> writes:
On Tue, 17 Dec 2013 13:21:30 -0000, Regan Heath wrote:
 Is GetNativeSystemInfo your other solution?  On the MSDN page for
 GetNativeSystemInfo it recommends using IsWow64Process to detect if
 you're  running under WOW64, at which point you would then call
 GetNativeSystemInfo.

 I am not sure what GetNativeSystemInfo does if called from a 32 bit
 exe on  a 32 bit OS..
It seems to work. After all it makes sense, the native system is actually 32 bits.
 I /know/ that the code in std.internal.windows.advapi32 which
 dynamically  loads and calls IsWow64Process will work, because we use
 it here at work  for this very purpose.  It's also the simplest most
 direct way to answer  this specific question and it's already 
 present,
 tested and working in  phobos .. so I would be inclined to use it, in
 preference over  GetNativeSystemInfo.

 R
If after using IsWOW64Process a GetNativeSystemInfo must still be issued like you mentioned earlier, I don't see the advantage over calling that function directly in the first place. Or am I missing something?
Dec 17 2013
parent reply "Regan Heath" <regan netmail.co.nz> writes:
On Wed, 18 Dec 2013 04:28:57 -0000, Hugo Florentino <hugo acdam.cu> wrote:

 On Tue, 17 Dec 2013 13:21:30 -0000, Regan Heath wrote:
 Is GetNativeSystemInfo your other solution?  On the MSDN page for
 GetNativeSystemInfo it recommends using IsWow64Process to detect if
 you're  running under WOW64, at which point you would then call
 GetNativeSystemInfo.

 I am not sure what GetNativeSystemInfo does if called from a 32 bit
 exe on  a 32 bit OS..
It seems to work. After all it makes sense, the native system is actually 32 bits.
Cool. The reason I was unsure and the reason I do not agree that it "makes sense" that it works, is the first paragraph on the MSDN page: "Retrieves information about the current system to an application **running under WOW64**. If the function is called from **a 64-bit application**, it is equivalent to the GetSystemInfo function." **emphasis mine** It doesn't actually address the situation of calling it from a 32 bit application NOT running under WOW64. GetSystemInfo is callable from both 32 and 64 bit so I assume now, that given that it works for you, that it is doing what it mentions above for a 64 bit application, and actually just calling GetSystemInfo. You will probably find that calling GetSystemInfo works just as well as what you're already doing.
 I /know/ that the code in std.internal.windows.advapi32 which
 dynamically  loads and calls IsWow64Process will work, because we use
 it here at work  for this very purpose.  It's also the simplest most
 direct way to answer  this specific question and it's already present,
 tested and working in  phobos .. so I would be inclined to use it, in
 preference over  GetNativeSystemInfo.

 R
If after using IsWOW64Process a GetNativeSystemInfo must still be issued like you mentioned earlier, I don't see the advantage over calling that function directly in the first place. Or am I missing something?
Yes, you're missing something :) http://msdn.microsoft.com/en-us/library/windows/desktop/ms684139(v=vs.85).aspx IsWow64Process returns (in the output parameter) if the 32 bit application is running in WOW64. WOW64 *only* exists on a 64 bit OS. So, if true this tells you you're on a 64 bit OS. You don't need an additional call to GetNativeSystemInfo at all. Further, the code is already in phobos so all you actually need to do is check the isWow64 global boolean defined by "std.internal.windows.advapi32". So, your code is as simple as: import std.stdio; import std.internal.windows.advapi32; void main(string[] args) { writefln(isWow64 ? "yes" : "no"); } R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Dec 18 2013
parent reply Hugo Florentino <hugo acdam.cu> writes:
On Wed, 18 Dec 2013 13:16:35 -0000, Regan Heath wrote:
 IsWow64Process returns (in the output parameter) if the 32 bit
 application  is running in WOW64.  WOW64 *only* exists on a 64 bit 
 OS.
 So, if true  this tells you you're on a 64 bit OS.  You don't need an
 additional call  to GetNativeSystemInfo at all.
Cool, thanks for clarifying. BTW, how could I benchmark the performance of both solutions (lets say for a few thousand runs) to see if one is more efficient than the other?
Dec 18 2013
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 12/18/2013 05:50 AM, Hugo Florentino wrote:

 BTW, how could I benchmark the performance of both solutions (lets say
 for a few thousand runs) to see if one is more efficient than the other?
There is std.datetime.benchmark: http://dlang.org/phobos/std_datetime.html#.benchmark Ali
Dec 19 2013
parent Hugo Florentino <hugo acdam.cu> writes:
On Thu, 19 Dec 2013 10:53:12 -0800, Ali Çehreli wrote:
 On 12/18/2013 05:50 AM, Hugo Florentino wrote:

 BTW, how could I benchmark the performance of both solutions (lets 
 say
 for a few thousand runs) to see if one is more efficient than the 
 other?
There is std.datetime.benchmark: http://dlang.org/phobos/std_datetime.html#.benchmark Ali
Thanks. I don't know why I missed that.
Dec 19 2013