I'm compiling a program on my 64bit machine, but I'm not sure if it produces 32-bit or 64-bit output.. How can I check if a file is 32bit or 64bit on Windows?
You can use GNUfile for windows.
You can run the app thru PEID
Lastly (and preferred- less room for error)
With either Visual Studio C++ (at least express edition minimum) or the Platform SDK installed you can use dumpbin /headers to look at the PE header values.
The first value in the file header tells you the architecture: either 0x14C for x86 or 0x8664 for x64
Just run it and have a look at the Processes tab in Windows Task Manager. If there is a *32 suffix after the process name, it's 32-bit, otherwise it's 64-bit (provided you're on a 64-bit OS).
You could run the 'file' command from linux in a cygwin environment to test.
You could also place some debug statement like 'print sizeof(int)' (schematically) to check.
You may use EXE Explorer by MiTec, a small free tool. It also displays many other properites of the binary file it checks.
I had the same question as the original poster and the EXE Explorer works for me quite well.
http://ntinfo.biz/ - Detect It Easy.
Or just GNU Binutils objdump -f my.exe
Related
I installed both VS2013 and VS2015 Professional (full install), and both have a "armasm.exe" under the bin folder. I set the bin folder into "path" environment variable. When I tried "armasm /?" under cmd, it prompts out a dialog box with a red cross sign, saying that:
The application was unable to start correctly (0x000007b). Click OK to close the application.
I wonder if this program is for ARM CPU's assembly language. Does this program only run on ARM machine that installed VS?
How can I get it to run?
I assume you're talking about the armasm.exe file in the \VC\bin\x86_arm folder? If so, then no, that is an x86 binary, not an ARM binary. It will run on your machine.
It is actually an ARM cross-assembler for x86. That means it allows you to assemble ARM binaries on an x86 host. Think of it like the x64 cross-compiler for x86 (in the x86_amd64) folder. That can compile 64-bit binaries on a 32-bit x86 host.
The reason you can't get it to start is because the environment has not been set up correctly, and required dependencies cannot be located. When I try to start it, I get a more descriptive message than you do:
System Error:
The program can't start because msvcdis140.dll is missing from your computer. Try reinstalling the program to fix this problem.
You are meant to use the vcvarsx86_arm.bat batch file (in the same folder) to get your environment set up correctly, before trying to run any of the tools. Step-by-step:
Open a new Command Prompt.
Drag in vcvarsx86_arm.bat, and press Enter to run it. This sets up your environment to run the x86/ARM tools.
Drag in armasm.exe (or simply type armasm.exe into the prompt, unqualified). It will now run because the environment has been correctly set up (including the path, so that it can be found without requiring the full path to be entered).
There is also a \VC\bin\amd64_arm folder. This contains tools for ARM executables that run on x64 hosts. You use those in exactly the same way, except you launch the vcvarsamd64_arm.bat file in that folder first.
It is worth noting that I also see a \VC\bin\arm folder, but (at least in my install of VS 2015) that contains only one EXE: pgosweep.exe. Microsoft does not appear to provide an ARM assembler that runs on ARM platforms. Which makes sense—I don't think ARM is a supported host for development. Visual Studio certainly hasn't been ported to ARM. Just use the ARM tools on x86 or x64.
I am working on some legacy VB6 code and I am having my program break with this message:
and it then highlights this code:
I know that the specified locations exist per these screenshots:
I am running this Visual Studio 6.0 on a 64-bit Windows 7 machine. How can I make the program see shell?
command.com does not exist on 64 bit windows.
Try using C:\Windows\SysWOW64\cmd.exe instead. C:\Windows\SysWOW64 is a folder giving you backwards compatibility stuff for 32 bit.
But see the comment below (taken from Euro Micelli).
Really you should use %SYSTEMROOT\System32\cmd.exe instead. First, Windows is not always installed in C:\Windows; you should let the system figure that out. Second, using System32 is always correct for a 32-bit application: when running on Win32, it is the correct folder; when running on Win64, Windows will map %SYSTEMROOT%\System32 to %SYSTEMROOT%\SysWOW64
I use vb6 and windows 7.
I've done the same thing as you but I put the dos command in a bat file.
Login.bat
NET USE W: \\10.48.10.8\e$
Then in the code
Shell ("c:\login.bat")
The vb command is not correct for the OS that you are running. You need to check that that drive is not already mapped, and remove the command.com /c from the command that you are trying to execute.
I have to debug a problem with Windows DLLs, but I'm running Linux exclusively, so I was wondering whether there are (preferably command-line) tools to inspect Windows DLLs under Linux. What I'm looking for is mainly the list of exported symbols.
Use "winedump -j export file.dll"
winedump is part of Wine
Homepage:
https://www.winehq.org/docs/winedump
Have you checked if Dependency Walker will work under wine?
http://dependencywalker.com/
(just a WAG)
How to use it on the command line (Run it from the same directory as the DLL):
wine /full/path/to/depends.exe /c /of:output.txt dynamic-library.dll
https://github.com/knik0/peinfo
works nicely. Tested with several Windows DLLs 64 bits
I would like to install my USB device driver [.inf file] using PnPUtil.exe utility on both 32bit and 64bit systems for Windows Vista and Windows 7.
I tested on my machine [Windows 7 32bit] and everything was fine because PnpUtil.exe is located in: C:\Windows\System32\PnPUtil.exe.
But in 64bit Windows 7 the utility is not in this directory.
When I tried installing driver on different Windows 7 - 64bit machine I could found PnPUtil.exe in this location: C:\WIndows\winsxs\amd64_microsoft-windows-pnputil_31bf3856ad364e35_6.1.7600.16385_none_5958b438d6388d15\pnputil.exe
and the test was also fine.
So how can I exactly detect this directory on all platforms?
I noticed the path is dependent on built of Windows version - 6.1.7600.16385 - but how to detect the rest of path?
Or is the path always the same on all 64 bit platforms? And what about Vista?
The location of PnPUtil.exe seen from you installer application depends on the bitness of your installer:
32bit installer on 32bit Windows: %WinDir%\System32
64bit installer on 64bit Windows: %WinDir%\System32
32bit installer on 64bit Windows: %WinDir%\Sysnative (Windows Vista and up)
More info here:
http://www.samlogic.net/articles/sysnative-folder-64-bit-windows.htm
I recently came across this problem while trying to create an installer for ReplicatorG, which includes the Arduino drivers and some drivers specific to the Makerbot Replicator.
It seemed that there isn't any way to determine the location of PnPutil, and I instead had to acquire Microsoft's DIFx and use their redistributable DPinst.
There were a couple of strange things about DPinst that made it difficult to use. The first is that it didn't seem to run properly if it was located in a directory tree with spaces in the path. Who knows why. The second was that, because the Arduino drivers are unsigned, it needed to be run in legacy mode to keep from popping up a big, red dialog warning the user. To run it in legacy mode you use the /lm flag, but the flag must be lowercase. Again, it's unclear why.
In the end, I had the installer copy dpinst and each of the drivers to a folder in the temporary directory and then run dpinst. It pops up a nice little wizard and tells the user which drivers were installed.
From C:\WIndows\winsxs\
dir /s PnPUtil.*
will scan subdirectories
I am using Cygwin and have GCC (version 4.3.4 20090804 (release) 1 ) installed as Cygwin package.
When I built C code using GCC under Cygwin shell, the generated executable output file is a executable of type (PE32 executable for MS Windows (console) Intel 80386 32-bit) and it can only be executed/run under Cygwin shell, not as standalone .exe on Windows shell/command prompt. If I try to run it standalone on Windows command prompt it gives an error window saying "The program can't run because cygwin.dll is missing from your computer".
How can one make this .exe standalone, which can be executed on a command prompt of any other system or even in my own system?
I thought GCC under Cygwin would build a Linux executable (ELF 32-bit LSB executable), but it's not so. How can I use the gcc-cygwin combination to generate a *.out kind of Linux executable file?
Also, I cannot run a Linux executable generated on a Linux-gcc combination to execute under Cygwin.
Any pointers would be helpful.
Despite widespread rumours, Cygwin is not a Linux emulator, i.e. it doesn't produce or run Linux executables. For that you'll need a virtual machine or coLinux.
Instead, Cygwin is a compatibility layer, which aims to implement as much as possible of the POSIX and Linux APIs within Windows. This means that programs have to be compiled specifically for Cygwin, but it also means that it's better integrated with Windows, e.g. it lets you mix POSIX and Windows APIs in the same program.
It's the cygwin1.dll that provides that compatibility layer. If you build non-Cygwin executables using gcc-3's -mno-cygwin switch or one of the MinGW compilers, then of course you can't use any POSIX/Linux-specific APIs, and any such calls will need to be replaced with Windows equivalents.
Cygwin is an emulation layer. It allows UNIX code to run on Windows, if you compile it to use the emulation layer. To Windows it looks like any normal DLL and makes OS calls as normal. But when you compile against it, it shows the same functions as UNIX (well, POSIX technically, but UNIX it is)
1) When you build with cygwin, it automatically brings in this cygwin1.dll. This is the code that you need to make it look like UNIX. There are flags to make it not use this cygwin dll, meaning ignore the UNIX stuff and use native Windows calls. the -mno-cygwin flag will make the binary a native Windows binary, not using cygwin emulation. As others have said, you also need the -mwindows to make actual GUI apps using cygwin gcc.
2) To compile on one platform to run on another platform, you need what's called a cross compiler. You also need the libraries and headers for the other system. For what you want you'd need a cygwin-Linux cross compiler, Linux headers and libraries. It would probably be much easier to run Linux in a virtual machine than to set this up.
3) Remember that Cygwin just looks like UNIX to UNIX source code, not to Linux binaries. Once you compile things, the function calls are windows DLL calls. A cygwin program is still a Windows program (which is why you need a Windows style DLL to run it). Cygwin provides code for UNIX functions/system calls such as fork(), but even the method of calling them is now different. fork() now calls into a Windows DLL, not into a Linux kernel. It's still a very different system.
Not a complete answer, but I think I am able to give some pointers.
1) http://www.cygwin.com/cygwin-ug-net/programming.html says you should use -mswindows parameter. Take a look of MinGW.
2) You need a cross gcc to do this. By default cygwin gcc produces binaries linked against cygwin.dll.
3) That it because it is a linux binary. Easiest way is to recompile software in cygwin.
ad 1) There are currently three different mingw cross-compilers available for cygwin:
The old gcc3 -mno-cygwin is deprecated.
There are new mingw64 cross-compilers for 32 bit (mingw64-i686-gcc) and 64 bit windows targets (mingw64-x86_64-gcc).
There's no mingw-i686-gcc matching the official cygwin gcc4 compiler yet.
ad 2) There's no linux cross-compiler as cygwin package yet available. But people report success building such a cross-compiler by themselves.
ad 3) There's no cygwin cross-compiler as linux package available, but many mingw cross-compilers. Those mingw executables can also be executed under cygwin, though they cannot use cygwin features, just the simple windows runtime.
Correcting errors in others people posts:
-mswindows is not valid, -mwindows tells the linker to generate a GUI app without console.
-mno-cygwin is only valid for the old deprecated gcc3 compiler and is not supported anymore. Don't use it. With cygwin you should use ordinary host and target triples as with every other cross-compiler.
You need to have cygwin.dll in your path.
Or just use MinGW to compile native windows code without dependencies.