I'm a long-time user of Cygwin. I'm running Win7/x64, but my Cygwin installation is 32-bit. At the time I installed it, 64-bit version was considered experimental. Now the Cygwin website lists 32-bit and 64-bit versions on their website without any special mentions or recommendations on which one to use.
As a programmer, my experience is: unless specifically designed for capabilities of 64-bit CPUs, very few applications can get any gains by being recompiled for a 64-bit CPU. They might use more memory, though, since each memory pointer now uses 8 bytes rather than 4.
So, my question is: is there any benefit to choose 64-bit Cygwin over 32-bit ones? Should I upgrade my 32-bit installation sooner or later?
Performance/memory benchmark results for common usage patterns (e.g. running common UNIX commands, particular shell scripts etc.) would be very welcome.
If you've upgraded your 32-bit Cygwin to 64-bit, please tell your story - was the upgrade worth it?
EDIT: I've been using 64-bit Cygwin for a while now, and haven't really noticed any differences - good or bad - from the 32-bit version.
After running 32-bit Cygwin at work for a number of years, I recently upgraded to 64-bit. It was quite painless as you can run the two installations side-by-side. For me, there was no noticeable difference in performance though I did not run any benchmarks. The biggest gain for me in upgrading was starting with a new fresh install without any of the cruft that built up over the last few years.
The one disadvantage that I had when running 32-bit Cygwin was that the WoW64 subsystem filesystem redirector silently redirects 32-bit applications. This has the result that running ls /cygdrive/c/Windows/System32/ in 32-bit Cygwin doesn’t actually display the contents of %WINDIR%\System32, but instead %WINDIR%\SysWOW64. Attempts to access files in the %WINDIR%\System32 directory, e.g., ls /cygdrive/c/Windows/System32/nbtstat.exe fail with the error message:
ls: cannot access /cygdrive/c/Windows/System32/nbtstat.exe: No such file or directory
This means that Windows commands installed in %WINDIR%\System32 such as nbtstat and dnscmd aren’t available without modifying the PATH. The work-around for accessing 64-bit Windows files was that the %SystemRoot%\sysnative pseudo-directory had to be used, e.g., to run the nbtstat command, use /cygdrive/c/Windows/Sysnative/nbtstat.
32-bit applications on 64-bit Windows
WoW64 (Windows 32-bit on Windows 64-bit) is a subsystem capable of running 32-bit applications. It is included on all 64-bit versions of Windows and creates a 32-bit environment to run unmodified 32-bit applications on a 64-bit system using DLLs to provide the necessary interfaces.
Windows uses the %SystemRoot%\system32 directory for its 64-bit library and executable files. This is done for backward compatibility reasons, as many legacy applications are hardcoded to use that path. When executing 32-bit applications, WoW64 transparently redirects 32-bit DLLs to SystemRoot%\SysWoW64, which contains 32-bit libraries and executables.
32-bit applications are generally not aware that they are running on a 64-bit operating system. 32-bit applications can access %SystemRoot%\System32 through the pseudo directory %SystemRoot%\sysnative.
For 64-bit applications (such as Windows Command Prompt, cmd.exe) there’s no filesystem redirection:
See also: File System Redirection
I ran one I/O heavy benchmark, but even for this the noticeable performance gain is well worth it.
On a cygwin bash shell on Windows 7, I ran a find of many patterns piped to grep and then redirected to a file on the same hard drive in 32 and 64 bit:
32 bit
real 1m58.57s 68% more time
user 0m11.95s 41% more time
sys 0m40.83s 23% more time
64 bit
real 1m10.36s
user 0m8.50s
sys 0m33.05s
Related
Hello Stackoverflow community,
I don't know if it's possible but I would like to have a portable linux Ubuntu OS on my USB stick:
wich I can lauch from any windows PC where I don't have administrator right
without having to "boot on it" but with launching it as an "application" in the windows OS (as MS excel for example and probably with virtualbox, vmware, or others)
without installing anything on the windows host PC
which keep the persistence (I want to work on this portable OS, install things, and find them again at the next start.)
Is that possible?
I'v found many things on the net but each time and for what I understood:
either you need the admistrator right (portable virtualbox)
or it cannot keep the persistence (live linux) so I have no choice to boot on the portable linux OS (wich I don't want)
or it's not portable so I have to install things on the PC I'm trying to work on
Any suggestion, idea, workaround would be strongly appreciated.
Thanks in advance,
Mat
I am aware that qemu does not require administrator rights. The problem is all virtualisation solutions require administrator rights either at installation time or in the case of portability beginning of runtime.
Qemu is not virtualisation, it is emulation so would be slower than virtualisation. It does run Linux, have persistance and is portable.
On the plus side, you can run amd64 on 32 bit machines (even slower), mips, arm and other architectures also.
I know about several projects for cross compiling between linux and Windows.
The Wine project is great for running windows application inside Linux.
andLinux is a linux running inside Windows.
My question is, can we compile a complete linux OS with a Windows compiler (like mingw32, visual studio , ...) in order to get a linux system which is fully compatible with the Windows PE executable format ?
As wine demonstrates, the PE format isn't really the problem with compatibility.
PE only defines how the program is pieced together at load time. Under windows, RUNDLL interprets it, loads all the program sections to memory, loads all the supporting dlls to memory and patches up the function pointers so that there is a program sitting in memory ready to go. (See http://msdn.microsoft.com/en-us/library/ms809762.aspx for more details. Its a good read!)
There is little stopping you writing a kernel module to do all of this. With the details in the page linked above it may not be to hard and someone may already have done it.
The real issue is the fundamentals of the operating system. Even if linux could load a PE, there would be problems around the fundamental difference in file names (\ or /) as well as the permissions model which is different and the windows registry which doesn't exist under linux. That's before you get into the different windowing model for GUIs.
Therefore the task of getting a windows program to run under linux is less about the program loader and much more about emulating all of the windows DLLs under Linux. As i understand it, this is the main heart of wine.
Although having a little experience, I am still confused with the question of whether it is necessary to install an application and/or build a C++ program or C++ library under Network File System shared by machines, which have different Linux version (e.g. CentOS release 4.7, Ubuntu 8.10), possibly different bit (e.g. 32-bit, 64-bit) and different versions of compiler (e.g. gcc/g++ 3.4.6 20060404 (Red Hat 3.4.6-10), gcc/g++ (Ubuntu 4.3.2-1ubuntu12) 4.3.2.), so that the executable or library files can be used under those different machines? What's the principles here?
For example, on a Network File System, I have an executable built from my C++ program under a machine with CentOS release 4.7, x86_64 ad gcc/g++ 3.4.6 20060404 (Red Hat 3.4.6-10). I surprisedly find that the executable can be used under another machine with Ubuntu 8.10, x86_64 and gcc/g++ (Ubuntu 4.3.2-1ubuntu12) 4.3.2. Also all the shared libraries I built on the first machine and used by my program do not complain error when the executable is running on the second machine. I am so worried if the running of the executable built on a different machine will give reliable results?
Another example, I remember a executable built on a 64-bit machine cannot run on a 32-bit machine. But how about the other way around, running on a 64-bit machine an executable built on 32-bit machine? How about C++ library files built and used across different bit machines?
If possible, could you point me to some reference, like some webpage, book,... that are related to my questions?
Thanks and regards!
You really need to test your program on each different configuration to be absolutely sure.
You can usually run 32 bit programs on 64 bit machines so you can probably get away with only a 32 bit version if you want.
You need to be a little careful about which version of gcc was used on each platform. Running a program built with gcc 4 on a machine whose OS and glibc were built with gcc 3 could cause you problems. So make sure that at least the major version numbers match.
Obviously, if you have different machine architectures, Sparc versus AMD64 for instance, you will need different versions. There are even some subtle differences between Intel and AMD so don't get over aggressive with the compiler optimizations and if you program uses SSE instructions (if you don't know what this is then you aren't using it), make sure the SSE set you use is supported by all the machines.
The key issues here are the machine architecture, the availability of the right libraries, and the "ABI" or Application Binary Interface. The ABI specifies how the OS should use machine registers and memory to pass information between different parts of the program, for example, how data is pushed onto the stack to pass arguments to a function. The ABI used by GCC has been known to change from time to time which is why using compatible versions is necessary.
I'm not aware of a book or web page that covers all these things. Start with the documentation for GCC and Binutils. And there is no substitute for good testing.
I am pricing a new software development machine and looking at the dell precision series.
When I get to this screen:
http://www.dell.com/content/topics/reftopic.aspx/pub/products/precn_kat?c=us&cs=555&l=en&s=biz&~section=T7400
The first choice is: Buy a Precision WorkStation T7400 32bit Now!
and the second choice is: Buy a Precision WorkStation T7400 64bit Now!
am I really at that point just deciding which software I want installed? or is there actually a different chipset depending on the choice.
I don't want to limit my options down the road by picking the wrong one - I can always upgrade the software - but I don't want to have to replace hardware.
BTW: This will be for SD of a Microsoft stack, asp.net, vs 2008, sql server etc and I would like to start using virtualization (probably from MS) with this machine purchase.
Both options give you the same choice of processors, they are all 64-bit capable. It's just a matter of whether a 32-bit or 64-bit version of the OS is preinstalled on it.
I would go with the 64-bit option simply because, in my experience, you can easily run both 32-bit and 64-bit VMs on a 64-bit platform, but are limited to 32-bit VMs on a 32-bit platform.
64-Bit, but just not XP64 (Which Dell offers as a downgrade). Driver situation is quite awful, and there are some incompatibilities in Software. If you need/want to stick to XP, go 32-Bit, if you want to use Vista or Windows Server 2008, 64-Bit is fine.
The only difference is the operating system anyway, so you can freely switch between installing 32 or 64 Bit Windows, you may just need to buy another License.
100% 64bit. RAM is cheap and you'll eventually want to use more than 4GB of it, especially if you've going to be running virtual machines.
64bit all the way. Vista64 is mature at this point, I haven't run into any issues. If you need 32bit for any older peripherals you might have, install XP32 as a VM.
As far as I know you can't really buy a 32-bit PC nowadays. I think the OS is the only different between the 32bit and 64bit version.
For .NET development it doesn't matter whether you're using a 64-bit OS or not. However 64-bit SQL Server maybe running faster.
And you'll also need more than 4GB RAM (especially if you run virtual machines), so I don't really see any reason to choose a 32-bit OS over a 64-bit one.
I would go for 64bit with 64bit Operating System. Only problem i encountered so far is that 32bit apps cannot access 64-dlls -> For example the context menu of TotalCommander won't show 64bit apps (e.g subversion) which might be inconvenient for development.
It can be difficult to get 64bit drivers for exotic or very new hardware, so if that's a concern for you, you might want to stick to the 32bit OS.
I have just installed a build server with a 64 bit windows server 2008 for continuous integration.
The reason I choose a 64 bit server was to have more than ~3Gb of RAM. I had hopes that this machine would provide blazing fast builds.
Unfortunately, the result are lacking greatly to say the least. My desktop provides faster builds than this server equipped with a Xeon quad core, 15k RPM SAS and 8 Gigs of RAM.
We use Visual C++ 2005 to compile our 32 bit application with Cygwin.
Could the WOW64 emulator be the bottleneck that is slowing down the build process?
Any pointers, comments would be greatly appreciated.
Regards,
We use Visual C++ 2005 to compile our
32 bit application with Cygwin.
I think that's the problem. I like Cygwin a lot, but it is really slow when it comes to file I/O. It helps a bit to deactivate the NTFS filesystem feature to keep track of the last file-access.
To get a better speed boost port your build-script / makefile to use the native command shell if pssible and only call cygwin-tools if there is really no replacement available.
If you use the gcc compiler try the mingw version. That one is a lot faster.
WOW64 is not an emulator on x64. The processor natively executes 32-bit x86 code. At the bottom of the user-mode stack, under kernel32 et al, are DLLs which map system calls to the 64-bit call interface.
See WOW64 Implementation Details.