FileMaker and calling 64 bit apps via Send Event (Windows)

[Hijack]

Hello all,

 

Since FileMaker is a 32 bit app, when it makes a Send Event call on a 64 bit OS, the OS does its magic folder redirection and forces FM to see the 32 bit legacy system folder of C:WindowsSysWow64 as C:WindowsSystem32.  9 times out of 10 this isn't a problem.  The 32 bit system apps work fine.  But, some things like the 32 bit version of reg.exe for reading a remote registry on a server won't work properly when trying to query a remote 64 bit target server.

 

So, in these events, I need to force FM to call the native 64 bit sub-system when it makes a Send Event call to the OS.  This is easy enough to do by hard pathing a call to something like cmd.exe by the virtual path c:windowssysnativecmd.exe (and then building the command process steps after the main call).  On a 64 bit OS, this forces the native 64 bit components to be called even when done so by a 32 bit app.

 

For those buttons and functions in my system that require that FileMaker be running on a native 64 bit OS I'd like to put some logic in the background scripts and shield the 32 bit OS users from seeing a task spawn up only to result in a "Command not found" (since c:windowssysnative is not virtualized on 32 bit Windows OS'es).  I've double checked where I know to look but I can't find a Get function that will tell me the bit level of the client's OS.

 

Does anyone have a trick that can be incorporated in an FM script to determine the OS bit level to IF against to pretty-up the operation of scripts?

 

Thanks

[Wim Decorte]

Since you seem to be proficient with the registry, you can check that to see if the OS is 32 or 64 bit.  And there is a %PROCESSOR_ARCHITECTURE% environment variable.  So you can do a Send Event, make it output to a text file and import that text file to get your result.  Or you can store a VBscript or Powershell script in a global, use Export Field Contents to export it and Send Event to run it, if you need more power.  Note that FM has an ActiveX interface so you can avoid the "output to text file and import" by having your VBscript or Powershell run a script in the FM file.

[Hijack]

Thanks for the tip, Wim.  I adapted it a little bit and discovered that I can send the event "cmd.exe /c set | clip" to pull the system environment variables into the clipboard and once there working with the data in FM is simple.  Didn't realize the clip command wa available to do command line interaction with the clipboard.

 

FYI for anyone needing something similar, the PROCESSOR_ARCHITECTURE is funky and may not reflect the truth about the OS being 64 bit.  Microsoft documentation states that it is set to "x86" if the active process is a 32 bit app.  But, for me when I call cmd.exe from FileMaker (a 32 bit app) I would assume that would make the variable set to x86 which it was not.  It was set to AMD64.  So, hard to explain that based on what I read. 

 

You have to also look at the PROCESSOR_ARCHITEW6432 variable if the other is set to x86.  This evaluation worked for what I needed:

 

Case (

Position ( Global | Globals::Environment Variables ; "PROCESSOR_ARCHITECTURE=AMD64¶" ; 1 ; 1 ) > 0 ; 1 ;

Position ( Global | Globals::Environment Variables ; "PROCESSOR_ARCHITECTURE=x86¶" ; 1 ; 1 ) > 0 and Position ( Global | Globals::Environment Variables ; "PROCESSOR_ARCHITEW6432=AMD64¶" ; 1 ; 1 ) > 0 ; 1 ;

0 )

[Wim Decorte]

Thanks for the tip, Wim.  I adapted it a little bit and discovered that I can send the event "cmd.exe /c set | clip" to pull the system environment variables into the clipboard 

 

 

Thanks for posting back with what works for you!

 

I'm off two minds with the clipboard though since it may destroy what the user had already put on it and may expect it to survive.

 

Taking the long way around by outputting to a text file and importing into FM is more work but my ultimately be more user-friendly,