This is only a half-way programming question. First of all I have a PCI-Express card and 32/64 bit drivers. The target operating system has to be a Windows 64 bit system. I read that under Vista64 all drivers have to be certified 64 bit drivers. Is this a general restriction under 64 bit operating systems and does this also apply to "XP 64" or any Linux system?
So for simplicity let's say I use a 64 bit driver for my PCIe card under Vista64 and have a bunch of 64 bit DLLs to use the cards functionality. On the other side there's a large, legacy 32 bit exe program which needs to use the PCIe device. Converting the program to 64 bit would be a really huge effort.
So what can be done to bring that 32 bit program and the 64 bit driver together? I read that mixing 32/64 bit binaries and DLLs is not possible at all but this is hard to believe for me. I'm sure you can print out a document under Vista64 from within a 32 bit app and Windows will somehow wrap this around to a 64 bit printer driver.
64-bit certification is only required under Vista; there is no certifying authority for non-Windows platforms, and I don't believe that XP or Windows Server checks for certification (not sure though, and it may depend on which service pack you're on).
If you're using the driver via the Windows API, then there shouldn't be any problem; Windows will do the 32<->64-bit translations in the kernel. If you're trying to load the driver inside your own process, that probably won't be possible. As Dirk says you'll have to run it inside its own process and communicate through a COM server. I'm not sure what hoops you'll have to jump through if you have to run your driver in a higher-privilege execution level and want to make calls to it from user mode.
Hopefully your 64-bit DLLs offer a 32-bit API, or Windows offers a standard driver interface (if it's a common I/O device like a display or network card).
Does your 32-bit application directly call the driver? (I'm guessing a simulator for the driver!)
The only way to communicate between 32-bit and 64-bit dlls is to write a COM server that manages the communication (read: wrap EITHER the applications calls OR the 64-bit driver responses) in between.
One thing that came back to bite me: When I first wrote this COM server (yes, I too had to bear many sleepless nights before I came to know of this trick) I only built the 32-bit version of the (auto-generated) proxy/stub dll. Another bout of sleepless nights ensued before I came to know of the solution: Build the proxy/stub dll for both 32-bit and 64-bit. The 32-bit side deals with the 32-bit side (in your case the application) and the 64-bit with the 64-bit side (the driver). COM manages how the differnt versions of the proxy/stub talk to each other. And oh, do get the server registered on your system. Easy, right?
I think the whole point of a driver is to abstract away the actually workings of the hardware and present a common interface to the software. In this case, the PCIe driver needs to be 64-bit so that it can act as a go-between for Windows and the hardware, but I would think that a 32-bit application could then access the device without any troubles at all.
What's meant by that incompatibility you read about is that 32 and 64-bit assemblies can't be part of the same application - an application has to target either one or the other, though 32-bit application will generally run fine on Windows x64 using WoW64, which just acts as a translator.
Are you currently experiencing problems, or are you just asking hypothetically?
Related
How to call interrupt in assembly language using NASM on 32 bit architecture. I try many time but result not desired.
On Linux "core dump error" and on Windows nothing happens on CMD. I read some deep that in 32 bit user application are run under ring 3 level and kernel and driver are run in ring 1. How can I do that in user level?
I follow someone on YouTube he work very well on Visual Studio with C++ or C (with inline and external assembly file ) but when I call any interrupt in external file or inline, Visual Studio says memory location violation error.
Intel 32 bit architecture (Ring level).
You can't use BIOS (or DOS) interrupts under an OS like Linux or Windows. Use system calls (Linux) or WinAPI library calls (Windows).
There is no portable ABI for interacting with the system outside your own process in assembly that works under both Linux and Windows; MacOS is also incompatible.
To use a BIOS interrupt:
make sure the BIOS exists and all of the state it depends on hasn't been modified. If the computer booted with UEFI then BIOS doesn't exist. If an OS has started it's would've nuked the state (e.g. PIC chip config, PIT config, PCI configuration space, BIOS data area, IVT, ...) that the BIOS depends on.
make sure you're in real mode or similar. If your code is 32-bit then you need to switch back to real mode, or setup a virtual8086 task (and its monitor), or use some sort of emulator (e.g. to interpret the BIOS's code instead of executing it directly).
Note that there are some special cases (e.g. the old "Advanced Power Management" API that was superseded by ACPI, the VESA BIOS Extensions) where a protected mode interface is provided as an (sometimes optional) alternative. These are mostly painful (e.g. involve setting up special descriptors for "16-bit protected mode" and copying binary blobs into them) and almost never worth the hassle.
I remember hearing that for performance a development machine should be 32 bit, while servers should be 64 bit. I think it was Richard Campell on Dot Net Rocks! that mentioned this.
Why would 32-bit be faster than the 64-bit for a development box and vice versa for servers?
One major reason is the fact that 32-bit OSs can't address 4GB of RAM. 4-8GB can be crucial in a lot of development environments where virtual machines are involved, or even heavy lifting in general. This is why I always stick with 64-bit where possible, and all modern CPUs support it.
It depends in part on your tools - for example, Visual Studio is still a 32 bit app (but usable from x64 - just no huge gain).
However, if you are using your main OS to host VMs, then you can probably benefit from a ton of memory for your various virtuals - and then you can choose 32-bit and 64-bit VMs to suit your needs (it is harder to have a 64-bit guest VM in a 32-bit host).
Personally, I'm still on 32-bit for development. For most of what I do, it is fine.
I run 64-bit 2008 Server and see not performance issues whatsoever. In fact, it's much better than 32-bit XP. It performs generally faster. In a funny way, file operations are quicker on my laptop 5400rpm drive running 64-bit 2008 Server than on a office PC with a 7200rpm drive running 32-bit XP.
I can think of only one thing why you would want to run a 32-bit OS (XP being the latest): you get there IE6 to debug your sites.
The other thing is that a 32-bit OS is incapable of addressing RAM capacity over ~3,4 Gb. If your PC has 4+ Gb of RAM you only loose with a 32-bit OS. Recollecting that even consumer laptops are sold these days with 4, 6 and 8 Gb of RAM, one can safely say goodbye to a 32-bit OS.
If you are talking about non-Windows OS then my experience may not apply.
Having a lot of memory changes the way you work, sometimes dramatically. I run 8 virtual screens with 4 different development environments (1 trunk, 2 branches and a fourth environment for external projects). Just with 12GB mem and a 30" screen.
I don't think that 32 bit machines are faster then 64 machines for developers. It is true that your development environment on a 64 bit OS is running in an emulated 32 bit environment and that creates a slight overhead. On the other hand you will find that the 64 bit OS is slightly faster as the internal data paths are 64 bit enabling the OS to move twice as much data in a single operation. This makes the 64 bit OS slightly faster than a 32 bit OS. The downside of a 64 bit OS is that pointers are twice as big.
What really matters is that 64 bit OS'es are very stable, have access to much more physical memory, and can run both 64 bit and 32 bit applications and virtual machines without sacrificing performance. The 32 bit OS belongs to the past.
I have a 64-bit Ubuntu installed in my laptop. I use it for development and I have no performance issues at all. I have the feeling that computer resources are better used this way.
The only reason I can think of to choose 32-bit OS is that you know that what you develop will work on 32-bit and 64-bit machines. But VS let you choose your target machines...
His point was if you develop for 32bit you will have less than 4GB of ram to work with. And on a 64bit server you may have much more than 4GB of RAM. Basically tricking you into being more frugal with your memory requirements. It had more to do with memory usage than raw number crunching on the CPU.
Although I can't quantify it in numbers, I have noticed the same thing as 'new in town'. I used to run XP x86, and later vista x86 on my notebook. After I upgraded to Vista X64 it is a lot snappier. Don't know if it is a driver issue, the fact that I run SQL Server x64 etc, that it can use twice the amount of cpu registers, optimizations in 'internal' stuff in windows or what, but I can notice the difference...
I'd think the obvious suggestion would be to use whatever OS your code is going to be deployed on. If your development environment is as close as possible to the deployment environment, there's less chance of bugs showing up only in the deployment environment.
After a linux kernel upgrade, my VMWare server cannot start until using vmware-config.pl to do some re-config work (including build some kernel modules).
If I update my windows VMWare host with latest Windows Service Pack, I usually not need to do anything to run VMWare.
Why VMWare works differently between Linux and Windows? Does this re-compile action brings any benifits on Linux platform over Windows?
Go read The Linux Kernel Driver Interface.
This is being written to try to explain why Linux does not have a binary kernel interface, nor does it have a stable kernel interface. Please realize that this article describes the _in kernel_ interfaces, not the kernel to userspace interfaces. The kernel to userspace interface is the one that application programs use, the syscall interface. That interface is _very_ stable over time, and will not break. I have old programs that were built on a pre 0.9something kernel that still works just fine on the latest 2.6 kernel release. This interface is the one that users and application programmers can count on being stable.
It reflects the view of a large portion of Linux kernel developers:
the freedom to change in-kernel implementation details and APIs at any time allows them to develop much faster and better.
Without the promise of keeping in-kernel interfaces identical from release to release, there is no way for a binary kernel module like VMWare's to work reliably on multiple kernels.
As an example, if some structures change on a new kernel release (for better performance or more features or whatever other reason), a binary VMWare module may cause catastrophic damage using the old structure layout. Compiling the module again from source will capture the new structure layout, and thus stand a better chance of working -- though still not 100%, in case fields have been removed or renamed or given different purposes.
If a function changes its argument list, or is renamed or otherwise made no longer available, not even recompiling from the same source code will work. The module will have to adapt to the new kernel. Since everybody (should) have source and (can find somebody who) is able to modify it to fit. "Push work to the end-nodes" is a common idea in both networking and free software: since the resources [at the fringes]/[of the developers outside the Linux kernel] are larger than the limited resources [of the backbone]/[of the Linux developers], the trade-off to make the former do more of the work is accepted.
On the other hand, Microsoft has made the decision that they must preserve binary driver compatibility as much as possible -- they have no choice, as they are playing in a proprietary world. In a way, this makes it much easier for outside developers who no longer face a moving target, and for end-users who never have to change anything. On the downside, this forces Microsoft to maintain backwards-compatibility, which is (at best) time-consuming for Microsoft's developers and (at worst) is inefficient, causes bugs, and prevents forward progress.
Linux does not have a stable kernel ABI - things like the internal layout of datastructures, etc changes from version to version. VMWare needs to be rebuilt to use the ABI in the new kernel.
On the other hand, Windows has a very stable kernel ABI that does not change from service pack to service pack.
To add to bdonlan's answer, ABI compatibility is a mixed bag. On one hand, it allows you to distribute binary modules and drivers which will work with newer versions of the kernel. On the other hand, it forces kernel programmers to add a lot of glue code to retain backwards compatibility. Because Linux is open-source, and because kernel developers even whether they're even allowed, the ability to distribute binary modules isn't considered that important. On the upside, Linux kernel developers don't have to worry about ABI compatibility when altering datastructures to improve the kernel. In the long run, this results in cleaner kernel code.
It's a consequence of Linux and Windows being developed in different cultural environments and expectations: http://www.joelonsoftware.com/articles/Biculturalism.html. In short: Windows is designed to be suitable for users, whereas Linux evolves to be suitable for open source developers.
I have a small office, and I currently use a Visual Foxpro Application that I wrote to handle all the data.
It is time to buy a new server. It seems that there are problems with VFP and 64 bit operating system. Should I make the move to 64 bit and try to deal with the problems that arise, or buy a new server running the older 32 bit acrhitecture?
The latter would of course require that I use Exchange 2003 instead of 2007 or 2008. Probably no big deal?
Maybe you could use virtualisation products to set up an appropiate environment on the modern server which still is compatible to VFP.
That way you could run the conflicting applications in a virtual 32bit-environment on the new server and the modern applications outside on the real 64bit-environment.
The main reason to upgrade to 64-bit is to allow the OS to utilize more than 4 Gigabytes of RAM. In a 32-bit architecture, the CPU registers are only able to address 2^32 memory locations. In 64-bit processors, you get up to 2^64 memory locations. This is plenty for a long time to come.
Buy two cheap servers instead of a single one. :)
But in all seriousness, if there are issues, you might want to buy a 64 bit box, and then load a 32 bit OS on it.
Then when the issues are cleared up, or you can clear them up yourself, you can do the change over. That's just one idea though.
My other opinion though is to replace the Visual FoxPro Application with something a bit more modern and maintained. ;) You might be amazed how much more efficient some of the dev stacks are - especially for smaller offices.
...as Kosi2801 says about virtualization. That could be applied with my suggestion also. Buy a nice 64 bit box and use VMWare's ESX Server. It might even work out BETTER than actually trying to run all the services on a single box. The tools VMWare has out are VERY impressive these days.
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.