We have a windows service that uses dlls produced from a bunch of different .NET projects. One of those projects has a dependency on a dll that was compiled on 32 bit machine.
We have just moved the windows service to a 64 bit machine. By default .NET projects try to run as 64 bit assembly (because they are being run on a 64 bit machine). However, I can force individual projects to run as 32 bit assembly by specifying the Platform Target as 'x86' rather than 'Any CPU'.
My question is: do all the .NET projects need to be forced to run as a 32 bit assembly? Can 32 bit assembly and 64 bit assemblies be run together?
I think as long as you're not using native modules or anything, you're probably fine, though you can still have bugs in your code if you assume the size of a pointer, etc., anywhere.
"If you have 100% type safe managed code then you really can just copy it to the 64-bit platform and run it successfully under the 64-bit CLR."
http://www.hanselman.com/blog/CommentView.aspx?guid=4099df2d-ef01-4f70-a7f7-829eabc36afc
If there is no unsafe code and/or references on the unmanaged dlls you can safely compile everything with the target Any CPU.
The result of compilation is then CPU agnostic - the resulting IL is JIT - compiled by the CLR on the target machine, whatever the machine will be.
If the box is a 64 bit box it will be compiled to the by the 64 bit CLR to the 64 bit instruction set and will be happily run in the native 64 bit mode
Related
I just added the '64 bits platform' to my project and my Delphi (XE7) keeps generating a huge RSM file (which increases the compilation time). According to the Help this should not happen if the 'Include remote debug symbols' option is disabled.
And in my case it is disabled.
There is something else to be disabled?
from http://embarcadero.newsgroups.archived.at/public.delphi.ide/201203/12030416462.html
Delphi XE2 generates RSM files that are several MB in size. As I
understand it, these files are for remote debugging. Is there a way
to turn off the generation of these files?
Yes. In the Project Options look on the page "Delphi Compiler\Linking"
for "Include remote debug symbols" and turn it off if you do Win32
debugging. Note it is necessary for Win64 debugging.
and continuing on http://www.devsuperpage.com/search/Articles.aspx?G=2&ArtID=20168
The IDE is 32-bit, because that's the only way it can work on both 32
and 64 bit versions of Windows. (Win64 can run 32 bit apps, but Win32
can't run 64 bit apps.) That's why the remote debugger is used for 64
bit and cross-platform apps.
Jeff Overcash from TeamB
Is the reason that Delphi XE2 is not itself really 64-bit?
Sure, then it can't be run on 32 bit OS's. All third party components
won't work at all until a 64 bit version of it exists (a 64 bit IDE
would not be able to load a 32 bit bpl), this would be a major reason
for people not to upgrade too. Supporting both a 32 bit and 64 bit
IDE doubles the testing time for little to no benefit.
WoW64 makes it possible to run 32 bit applications on 64 bit Windows. If the conversion from 32 bit instructions to 64 bit instructions can be made at runtime, why can't we convert the executable itself to 64 bit?
That is because WoW64 doesn't convert 32bit instructions to 64bit.
Your 32bit executable is run in 32 bit mode by switching your CPU to compatibility mode. There are some conversions inlined for API/driver calls, but most of the code is not converted.
*This is only true for the x86-64 architecture. The IA-64 architecture doesn't support this, so WoW actually converts your code to 64bit, but with a significant performance penalty.
*.NET code compiled to MSIL is JITted to the correct architecture. Probably the same happens with other architectures with an Intermediate Language like Java, but i'm no expert there.
Yes, Wow64 lets you run 32-bit programs but they still run in 32-bit mode - no code alterations are performed. Such automatic translation would be impossible for a native application.
The number one problem is that native applications have no annotations explaining what the code does. Just one example: the compiler compiles pointer manipulation code and uses a 32-bit register to hold this pointer value on 32-bit platform and emits bare machine code for that - the runtime will have no idea that this was a pointer and it needs to be placed in 64-bit register on 64-bit platform.
Managed environments such as Java and .NET can deal with it - the compiler emits "intermediate language" code with necessary annotations that is then compiled for the target platform before the code is first run.
I am writing a program in Delphi, and including a library which contains some assembly code (Pipes.pas). I am getting an access violation when I run the code which makes a call to a function called StdWndProc. The process is an assembly function which contains assembly code.
A while back I updated this code (Pipes.pas) to include unicode support and other stuff, but I didn't figure out what this assembly was doing. Any ideas on what's going wrong here?
I'm running on a 64-bit machine, could it be that this assembly is 32-bit and isn't running correctly on a 64-bit processor (the project is targeted at 32-bit build).
A 32 bit process executes 32 bit code. It doesn't matter whether that code was compiled from assembler or Delphi or some other language.
It doesn't matter whether the machine is 64 bit or 32 bit, a 32 bit process runs 32 bit code. On a 64 bit machine, a 32 bit process runs in an emulated 32 bit machine called WOW64.
Conceptually what you are attempting is possible, so the conclusion is that your code has a bug.
As David Heffernan pointed out the cause of your problem can hardly be the OS architecture.
If your code runs with no errors on 32 bit machines, but it fails to run on 64 bit ones, it could be an OS issue however. It could be caused because of the use of 32 bit-exclusive directories (like SD:\Program Files which is called SD:\Program Files(x86) on 64 bit windows for 32 bit programs), registry reflection (which causes your program to store registry data under the Wow3264Node key), or even the use of old 16 bit DLL s (that can not run under wow3264), but that is a very rare case since it is 2013...
To be able to help I need further details of how your code does not run correctly.
(Please note, that the original question is already answered, I only wanted to provide some more useful help.)
As the title suggests!
I'm trying to get a 64bit dll
No.
Nope. Delphi 7 was released in 2002; the first AMD64 processor was released in 2003. No way Delphi 7 knows how to generate 64-bit code.
All released versions of Delphi following the 16 bit Delphi 1 emit 32 bit targets. At the moment your options are:
Wait until the upcoming 64 bit Delphi release. We anticipate this some time this year, but your port will be non-trivial.
Port to FreePascal. Again, a non-trivial port.
Port to a completely different language: even more work than porting to Free Pascal.
Carry on running 32 bit code.
Compiling a program means to translate your source files into CPU opcodes (and something more, it has to generate a executable image that can work on the OS it was designed for, respecting the OS ABI - Application Binary Interface). Each type of CPU has its own set of opcodes, and even if the Intel x86 architecture has many similarities among 16, 32 and 64 bit opcodes, there are enough differences and the ABI is anyway different.
Creating a 64 bit exe/dll means to generate 64 bit opcodes using also the new 64 bit ABI, and to do that a compiler must be written to "know" them, what a compiler can do is defined by how the compiler itself is written, not by the system it is run on. Delphi 7 compiler "doesn't know" about 64 bit CPUs and exe/dll ABI, and thereby can't generate it. This is true as well up to Delphi XE. The next version should be the first one to come with a 64 bit compiler, you can wait for it, or if you're in a hurry there are some partially compatible compilers like FPC.
I recently got a new laptop. Unfortunately, it came with Vista. It's been one big hassle getting it to work, and the comp has hardware components for which there are no XP drivers, so I can't "upgrade" to an OS that actually works. I've mostly gotten things working, but one particularly odd problem has me stumped.
I installed Delphi and tried to build a project. It compiled, but wouldn't run. "This application failed to start because sdl.dll was not found." Fair enough. So I grabbed SDL.dll and put it in the C:\windows\system32 folder. (Using Vista 64-bit Home Premium. This is a 32-bit dll, though, so I put it in the 32 folder instead of the 64 one.)
Hit Run again. Same problem. But why? That's where it goes, right? And C:\windows\system32 is in the system path. Anyone know why it can't link to the DLL?
(And yes, I know that I can work around the problem by putting the DLL in the same folder as the .exe. I'm currently doing that as a workaround. It's a bad idea in the long term, though, because I have a handful of different projects that all require SDL.)
That is not a Vista problem, but a 64 bit Windows problem: The name System32 is really confusing, but this is actually the folder where the systems (64 bit) DLLs reside.
So on any 64 bit version of Windows...
... all 64 bit system DLLs are located in C:\Windows\System32.
... all 32 bit system DLLs are located in C:\Windows\SysWOW64.
The name comes from Windows on Windows 64 (WOW64) which is the name of the translation layer allowing 32 bit applications to use the native 64 bit system resources.
Raymond Chen recently addressed the basic reason behind why 32-bit system directories are weird on 64-bit Windows. The first paragraph of the entry is really the key to understanding the reason behind segregated 32-bit directories:
On 64-bit Windows, 32-bit programs run
in an emulation layer...If a 32-bit
program tries to look at the system,
it will see a 32-bit system.
I think you'd have to have separate directories to keep these things all separate and working. The seemingly counter-intuitive name of SysWOW64 for the directory where the files reside is makes more sense when you consider that WOW64 means Windows On Windows 64-bit, which is what the emulater that's mentioned above is called.