Jump to content
Sign in to follow this  
tfabris

Please help with RUN command and 32-bit/64-bit, and NETSH command.

Recommended Posts

tfabris

I'm trying to write a script that gets back the results of the RUN command running NETSH, and then parses the results.

The command works on 32-bit win7, and I can parse the results, but, for some reason it doesn't work right when I run it on a 64-bit win7 system. It appears as though the 64-bit version of NETSH on win7 has different capabilities than the 32-bit version (both exist on the win7 system I'm running), and one will return me the results I want while the other one tells me an error that the command is not available. Funny thing is, I'm having trouble figuring out which one is which, and anyway, how to get the one that I want, to run.

Here's the code:

$OutputHandle = Run("netsh.exe mbn show readyinfo int=*", "", @SW_HIDE, $STDOUT_CHILD)
While 1
$RunResults = $RunResults & StdoutRead($OutputHandle)
If @error Then ExitLoop
WEnd

MsgBox (0, "Output", $RunResults)

Note: The code uses "MBN" which is a windows-7-and-later command only. It is looking for a Windows-Mobile-Broadband-enabled WWAN adapter, in my case, an AT&T card. If you have a similar adapter, it should return a set of statistics about the adapter, or, the words "The given interface is not present or not a Mobile Broadband interface" if you don't have one.

On a 32-bit system that works fine. I get the text back that I was expecting.

On a 64-bit system (running the 32-bit version of AutoIt), I get "The following command was not found: mbn show readyinfo int=*"

If I open up a command prompt on that computer, and type the command, it works fine and I get the text I expect.

If I open up a command prompt on that computer, and type the command but point it to the \Windows\SysWOW64\netsh.exe instead, I get the error "the following command was not found..." just like Autoit gets.

So clearly this is a 32/64 problem. But it's critical to me that I distribute a single 32-bit EXE for this program, not have to do 32 and 64 separate versions (there are other problems that prevent me from compiling a 64-bit version in other parts of the program).

So it appears as though AutoIt is doing the equivalent of running \Windows\SysWOW64\netsh.exe instead of the expected \Windows\System32\netsh.exe.

Okay, so I have tried the following:

- Running it shelled within @comspec /c ... Same undesired results, fails on 64 bit system.

- Running it from @SystemDir\Netsh.exe ... Same undesired results, fails on 64 bit system.

- Specifying \Windows\System32\Netsh.exe specifically ... Same undesired results, fails on 64 bit system.

- Just for the heck of it, calling \Windows\SysWOW64\netsh.exe directly ... Same undesired results, fails on 64 bit system.

- Running "netsh.exe ?" from the Autoit run command... it confirms my suspicion because the returned text does not contain the MBN command.

- If I run "\Windows\SysWOW64\netsh.exe ?" at a command prompt ... it confirms my suspicion because the returned text does not contain the MBN command.

The mapping between System32 and SysWOW64 confuzzles me anyway, and now I'm not even sure which of the two is the one that works, and which is the one that doesn't. Does anyone know how I can accomplish what I'm trying to do, but meet the following criteria?

- Must be compiled as a 32-bit Autoit executable only.

- Must run equally well on a 32-bit and 64-bit system.

- Must be able to get actual valid results of "netsh.exe mbn show readyinfo int=*" on both 32- and 64-bit systems when run.

- Must not ever return the bad error "The following command was not found" as a result of the command. (Returning "The given interface is not present" is a good result, meaning it's working)

Anyone? Please help!

Share this post


Link to post
Share on other sites
BrewManNH

Sounds to me that the 32 bit version doesn't support the mbn parameter if it doesn't even work from the command line.


If I posted any code, assume that code was written using the latest release version unless stated otherwise. Also, if it doesn't work on XP I can't help with that because I don't have access to XP, and I'm not going to.
Give a programmer the correct code and he can do his work for a day. Teach a programmer to debug and he can do his work for a lifetime - by Chirag Gude
How to ask questions the smart way!

I hereby grant any person the right to use any code I post, that I am the original author of, on the autoitscript.com forums, unless I've specifically stated otherwise in the code or the thread post. If you do use my code all I ask, as a courtesy, is to make note of where you got it from.

Back up and restore Windows user files _Array.au3 - Modified array functions that include support for 2D arrays.  -  ColorChooser - An add-on for SciTE that pops up a color dialog so you can select and paste a color code into a script.  -  Customizable Splashscreen GUI w/Progress Bar - Create a custom "splash screen" GUI with a progress bar and custom label.  -  _FileGetProperty - Retrieve the properties of a file  -  SciTE Toolbar - A toolbar demo for use with the SciTE editor  -  GUIRegisterMsg demo - Demo script to show how to use the Windows messages to interact with controls and your GUI.  -   Latin Square password generator

Share this post


Link to post
Share on other sites
tfabris

Sounds to me that the 32 bit version doesn't support the mbn parameter if it doesn't even work from the command line.

Exactly. The problem was that AutoIt is launching the 32 bit version, on the 64 bit system, because I'm running a 32-bit AutoIt executable (and must do so for other reasons).

Share this post


Link to post
Share on other sites
tfabris

Okay, I found a solution. The secret is that, a 32-bit executable running on a 64 bit system, can access the files in the 64-bit System32 folder via a special secret folder named "Sysnative".

Here's my code again, modified, this time it works in AutoIt on 32 and 64.

If @OSArch == "X64" Then
     $WindowsActualTrueSystemFolder = @WindowsDir & "sysnative"
Else
     $WindowsActualTrueSystemFolder = @SystemDir 
EndIf


$OutputHandle = Run($WindowsActualTrueSystemFolder & "" & "netsh.exe mbn show readyinfo int=*", "", @SW_HIDE, $STDOUT_CHILD)
While 1
      $RunResults = $RunResults & StdoutRead($OutputHandle)
      If @error Then ExitLoop
WEnd

MsgBox (0, "Output", $RunResults)
  • Like 1

Share this post


Link to post
Share on other sites
UEZ

I assume the problem is when you running x86 on a x64 system the path to the system folder is set different.

#AutoIt3Wrapper_UseX64=y
#include <Constants.au3>
Global $RunResults
$OutputHandle = Run(@ComSpec & " /c netsh.exe mbn show readyinfo int=*", @SystemDir, @SW_SHOW, $STDOUT_CHILD)

While 1
    $RunResults &= StdoutRead($OutputHandle)
    If @error Then ExitLoop
WEnd

MsgBox (0, "Output", $RunResults)

This produces the output but an em when running it in x86 mode but you found already a workaround by using sysnative. My workaround was to compile a x86 and x64 exe.

Br,

UEZ

Edited by UEZ

Please don't send me any personal message and ask for support! I will not reply!

Selection of finest graphical examples at Codepen.io

The own fart smells best!
Her 'sikim hıyar' diyene bir avuç tuz alıp koşma!
¯\_(ツ)_/¯  ٩(●̮̮̃•̃)۶ ٩(-̮̮̃-̃)۶ૐ

Share this post


Link to post
Share on other sites
tfabris

Right, I had a requirement of needing it to be a 32-bit EXE on both platforms, so compiling a 64-bit EXE was not an option for me. The Sysnative work around seems OK.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×