Folks, can 64 bit COM client talk to 32 bit COM server? What about the other way around? I believe the answer is "YES", but wanted to double check. THank you
As long as the server is out of process (an EXE and not a DLL), it is not a problem from 32 to 64 or from 64 to 32.
Related
I am trying to create an Excel file using SQL queries (64 bit) using a 32 bit driver. There are a lot of links/articles online that say this is only possible once I install the 64 bit version of the Access/Jet engine.
As I can't install the 64 bit version of the Access/Jet engine, is there any way to make the query run in a 32 bit runtime environment?
Currently I am using intellij idea 14.0.3(earlier I was using 12.1.4) on 64 bit windows 8.1.
When we install it, the installer creates the shortcut in start menu and other places which defaults to the 32 bit .exe file even on a 64 bit system.
I know that I can use the 64 bit executable to run idea in 64 bit mode as given in this SO answer.
But is there any significant performance difference between the two versions of the IDE?
And which executable is recommended for 64 bit systems? Shall I keep using 32 bit? or shall I switch to 64bit version?
The difference between running the 32 and 64 bits launcher is which Java will be used to start the IDE and what are the vmoptions parameters passed to it.
When starting the 32 bit one, IDEA uses it's own bundled 32 bit JRE. If there is no such one, IDEA tries to find 32 bit JRE in several places on specific order (%IDEA_HOME%, %JDK_HOME%, %JAVA_HOME%). The values in idea.exe.vmoptions are passed to it.
When starting the 64 bit one, it tries to find 64 bit JRE in several places on specific order. The values in idea64.exe.vmoptions are passed to it.
So if you want to allocate 2 GB RAM or more (with -xmx), this is not going to happen with 32 bit Java (resp. IDEA). And for large projects using less than 2GB causes the IDE to hang a lot. For smaller projects I don't think you'll feel any difference.
For reference this is the bug about this, so far they are not acting on it:
https://youtrack.jetbrains.com/issue/IDEA-146040
FSOpenFork(&fileRef, forkName.length, forkName.unicode, permissions, (FSIORefNum *)forkReference);
Is not working properly in 64 bit lion OSX, We can run same project in 32 bit and 64 bit. When we run in 32 bit FSOpenFork returns the data fork reference number, but when we run in 64 bit it does not returns, Anyone has any idea?
I have created an application in .NET. When I compile a 64bit version and a 32bit version of the same software, the 64bit executable is smaller.
However, when you run them both, the 64bit version uses more RAM.
I'm sure something is happening "under the hood", and was just interested why? (It's not a worry either way)
Thanks.
EDIT: C#.NET 4.0 if it matters.
In 32 bit applications, pointers are 32 bits i.e. 4 bytes, whereas they are 64 bits i.e. 8 bytes in 64 bit applications. So pointers (e.g. object reference) take up twice as much memory.
Also, in 32-bit applications objects have an overhead of 12 bytes per object, whereas in 64 applications they have an overhead of 24 bytes. Double again.
These affects will be noticed at runtime, not in the dll size.
Pointers are twice as big in 64bit mode. That could explain some (sometimes much) of the RAM usage difference.
I am not sure what is meant by 16-bit or 32-bit applications. Is that a 16-bit application is an application which would not require more than 2^16 bytes of memory space? Does this 16-bit refers to the max size of the application?
It means the application has been compiled for a processor that has 16 bits of memory addressing or 32 bit of memory addressing. Same goes for 64 bit applications.
The number refers to the maximum amount of memory that the application can address.
See wikipedia - 16-bit, 32-bit, 64-bit (and more).
A 32-bit application is software that runs in a 32-bit flat address space.
Answers to common questions
Will a 64 bit CPU run a standard (32-bit) program on a 64-bit version of an OS?
Yes it will. 64 bit systems are backward compatible with the 32 bit counterparts.
Will a 64-bit OS run a standard application on a 64 bit processor?
Again, it will. This is because of backward compatibility.
Can I run W2K and WXP on an 64 bit CPU, and use old software?
Yes, a 32 bit OS (W2K and WXP) will run on a 64 bit processor. Also, you should be able to run "old software" on a 64 bit OS.
The number(32 or 16 of the assembler directive of the addressmode (example "[use16]" and "[use32]")) does not refers to the maximum amount of memory that the application can address!
Because with the 80386+ it is also possible to use operandsize- and adresssize prefixes in combination with the 16 bit PM for to address up to 4 GB of ram.
(The maximum amount of memory that our application can be use is refering to the segment entries of the segmentsize inside of a GDT/LDT selector, or by the default size for a segment of 64 kb.)
The only one differnce between the 32 bit - and the 16 bit addressmode is the meaning and the usage of those operandsize- and addresssize prefixes.
[use16]
So if we want to use in the 16 bit addressmode 32 bit operands/addresses, then we have to add those prefixes to our opcode. Without those prefixes we can only use 16 bit.
[use32]
In the 32 bit addressmode we found a diametrical opposite situation, so if we want to use 32 bit operands/addresses, then we have to leave out those prefixes from our opcode and only if we want to use 16 operand/addresses, then we have to add those prefixes to our opcode.
If we use these size-directives above(or similar notation) carefully, then our assembler will do this job.
Operand size prefix in 16-bit mode
Dirk