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.

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

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.

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?

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/

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/

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/

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.

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?

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