Might it make more sense to put 64-bit applications into "Program Files (x64)" and leave 32-bit applications to run in "Program Files"?
I have a batch file that need to run a Flex compiler. In x64, that program is in "Program Files (x86)". On Windows Vista 32-bit, it's in "Program Files" - environment variables? Check it:
ProgramFiles=C:\Program Files
ProgramFiles(x86)=C:\Program Files (x86)
What do I do?
set mxmlc="%ProgramFiles(x86)%\Adobe\Flex Builder 3\sdks\3.1.0\bin\mxmlc.exe"
if NOT EXIST %mxmlc% set mxmlc="%ProgramFiles%\Adobe\Flex Builder 3\sdks\3.1.0\bin\mxmlc.exe"
tnx
To make it portable:
SET ExecPath=%ProgramFiles(x86)%
IF "%ExecPath%"=="" SET ExecPath=%ProgramFiles%
That's nothing. Guess what \Windows\System32 contains? That's right, 64-bit DLL files. So where did they decide to put 32-bit legacy DLL files? \Windows\SysWOW64 of course.
The problem is, while there are built-in facilities for Windows applications to discover the location of system directories, many applications don't use them. And since Microsoft, above all else, is a slave to backwards compatibility we get stupid stuff like this.
x86 is commonly assumed to be 32-bit unless you specify x86-64. Why do they need their own program files directories anyway?
EDIT: I have a batch file that need to run FLEX compiler. in X64 that program is in "Program Files (x86)" on Vista 32 bit it's in "Program Files" .. environment variables ? .. check it:
Use the %ProgramFiles% environment variable and skip all this hassle.
Uh... I think x86 refers to the Intel processor architecture, e.g. 8086, 80286, 80386, 80486, and 80586.
80386 had the first 32-bit instruction set, see x86 (Wikipedia).
EDIT: Ah, the question was clarified.
See Stack Overflow question C# - How to get Program Files (x86) on Vista x64.
a.) Just because the default installation location changes doesn't mean you HAVE to install stuff there. A simple registry change will make your new installs go anywhere you want. Mine all go to a separate drive, into folders of my choosing. If an application can't even keep track of its installation path through the registry then it's probably not worth installing in the first place.
b.) I'm assuming they put 32-bit applications into an x86 folder because it's not a 32 bit OS, that is, old stuff goes here. You wouldn't buy a new house and let your dog sleep in it while you sleep in his old dog house, right? If 64 bit is a step forward then why would you put the legacy software in what will continue to be the standard installation folder?
Because Microsoft loves making things more complex for people. Rather than simplifying the transition to 64-bit, they made it divided and difficult.
Related
Is it possible to write a program (make executable) that runs on windows and linux without any interpreters?
Will it be able to take input and print output to console?
A program that runs directly on hardware, pure machine code as this should be possible in theory
edit:
Ok, file formats are different, system calls are different
But how hard or is it possible for kernel developers to introduce another executable format called raw for fun and science? Maybe raw program wont be able to report back but it should be able to inflict heavy load on cpu and raise its temperature as evidence of running for example
Is it possible to write a program (make executable) that runs on windows and linux without any interpreters?
in practice, no !
Levine's book Linkers and loaders explain why it is not possible in practice.
On recent Linux, an executable has the elf(5) format.
On Windows, it has some PE format.
The very first bytes of executables are different. And these two OSes have different system calls. The Linux ones are listed in syscalls(2).
And even on Linux, in practice, an executable is usually dynamically linked and depends on shared objects (and they are different from one distribution to the next one, so it is likely that an executable built for Debian/Testing won't run on Redhat). You could use the objdump(1), readelf(1), ldd(1) commands to inspect it, and strace(1) with gdb(1) to observe its runtime behavior.
Portability of software is often achieved by publishing it (in source form) with some open source license. The burden of recompilation is then on the shoulders of users.
In practice, real software (in particular those with a graphical user interface) depends on lots of OS specific and computer specific resources (e.g. fonts, screen size, colors) and user preferences.
A possible approach could be to have a small OS specific software base which generate machine code at runtime, like e.g. SBCL or LuaJit does. You could also consider using asmjit. Another approach is to generate opaque or obfuscated C or C++ code at runtime, compile it (with the system compiler), and load it -at runtime- as a plugin. On Linux, use dlopen(3) with dlsym(3).
Pitrat's book: Artificial Beings, the conscience of a conscious machine describes a software system (some artificial mathematician) which generates all of its C source code (half a million lines). Contact me by email to basile#starynkevitch.net for more.
The Wine emulator allows you to run some (but not all) simple Windows executables on Linux. The WSL layer is rumored to enable you to run some Linux executable on Windows.
PS. Even open source projects like RefPerSys or GCC or Qt may be (and often are) difficult to build.
No, mainly because executable formats are different, but...
With some care, you can use mostly the same code to create different executables, one for Linux and another one for windows. Depending on what you consider an interpreter Java also runs on both Windows and Linux (in a Java Virtual Machine though).
Also, it is possible to create scripts that can be interpreted both by PowerShell and by the Bash shell, such that running one of these scripts could launch a proper application compiled for the OS of the user.
You might require the windows user to run on WSL, which is maybe an ugly workaround but allows you to have the same executable for both Windows and Linux users.
I have a 32-bit .so binary-only library and I have to generate 64-bit program that uses it.
Is there a way to wrap or convert it, so it can be used with 64-bit program?
No. You can't directly link to 32bit code inside of a 64bit program.
The best option is to compile a 32bit (standalone) program that can run on your 64bit platform (using ia32), and then use a form of inter-process communication to communicate to it from your 64bit program.
For an example of using IPC to run 32-bit plugins from 64-bit code, look at the open source NSPluginWrapper.
It is possible, but not without some serious magic behind the scenes and you will not like the answer. Either emulate a 32 bit CPU (no I am not kidding) or switch the main process back to 32 bit. Emulating may be slow though.
This is a proof of concept of the technique.
Then keep a table of every memory access to and from the 32 bit library and keep them in sync. It is very hard to get to a theoretical completeness, but something workable should be pretty easy, but very tedious.
In most cases, I believe two processes and then IPC between the two may actually be easiest, as suggested othwerwise.
I'm writing a small utility that should run on both 16\32\64 bit systems.
My old utility ran both on 32 and 16 bit by compressing the 16bit version to the 32 bit and applying the /stub switch in visual studio 2008 (/STUB -MS-DOS Stub File Name ).
I'm looking for a way to do the same with my 64 bit executable.
The target 64bit system is Win PE 64bit and it doesn't have the WOW64 installed on it.
Is it possible?
The DOS stub of Windows executables uses the MZ section, whereas both 32-bit and 64-bit executables use the PE section. This allows the DOS stub to exist within either Windows executable, but causes a collision when trying to combine 32- and 64-bit executables.
You should pack your 32 and 64 bit util in resources of another exe, let's call it launcher 32 bit.
Then your launcher should detect on what system it is started from and then extract proper binary from it's resources and start it.
Windows 32-bit runs 16-bit applications by wowexec.exe, and Win64 runs 32-bit application by wow64. So without wow64 it's impossible for your program to create a universal launcher on Windows. (Note: Mac OSX supports multiple architecture in single binary anyway)
The best approach I can figure out is to create a single MSI installer package and put both 32/64 exes into it.
I'm currently in the process of learning assembly language.
I'm using Gas on Linux Mint (32-bit). Using this book:
Programming from the Ground Up.
The machine I'm using has an AMD Turion 64 bit processor, but I'm limited to 2 GB of RAM.
I'm thinking of upgrading my Linux installation to the 64-bit version of Linux Mint, but I'm worried that because the book is targeted at 32-bit x86 architecture that the code examples won't work.
So two questions:
Is there likely to be any problems with the code samples?
Has anyone here noticed any benefits in general in using 64-bit Linux over 32-bit (I've seen some threads on Stack Overflow about this but they are mostly related to Windows Vista vs. Windows XP.)
Your code examples should all still work. 64-bit processors and operating systems can still run 32-bit code in a sort of "compatability mode". Your assembly examples are no different. You may have to provide an extra line of assembly or two (such as .BITS 32) but that's all.
In general, using a 64-bit OS will be faster than using a 32-bit OS. x86_64 has more registers than i386. Since you're working on assembly, you already know what registers are used for... Having more of them means less stuff has to be moved on and off the stack (and other temporary memory) thus your program spends less time managing data and more time working on that data.
Edit: To compile 32-bit code on 64-bit linux using gas, you just use the commandline argument "--32", as noted in the GAS manual
Even if you run Linux 64bit, it is possible to compile and run 32bit binaries on it. I don't know how good Mint's support for that is, I assume you should check.
64bit assembler however is not fully compatible to 32bit, for example you have different (more) registers. There are some specific instructions not available on either platform.
I would say the move to 64bit is not a big deal. You can still write 32bit assembly and then perhaps try to get it also running as 64bit (shouldn't be too hard), as a source of even more programming/learning fun.
Usually 32-bits is plenty so only use 64-bits or more if you really NEED IT.
Best to decide prior to programming if you want to do it as a 32-bit app or
a 64-bit app and then stick to it as mixed mode debugging ca get tricky fast.
What are the guidelines for porting a 32-bit program to a 64-bit version?
Apart from the obvious issues with calling 32-bit libraries:
Don't assume a pointer is the same size as an integer.
Don't assume subtracting one pointer from another yields a value that fits in an integer.
See also http://msdn.microsoft.com/en-us/library/aa384190(VS.85).aspx
Don't use hard coded registry/file system paths as some are different on a 64-Bit machine. For example, 32 bit apps get installed in 'Program Files (x86)'.
If you are developing in Windows using .NET, make sure you are using the System or Microsoft.Win32 libraries to access resources.