Help on moving to Win64 bit system?

[Guest]

I'm thinking to move from WinXP 32bit to Windows 2003 Server 64 bit.
But first I have some unclear issues that would like to clarify in here
using your kind help:
(1) Can I take a driver (like the Coerce Frame Grabber Driver) that is used
for Windows XP 32 bit and use it on the 64 bit system?
(2) Assuming the answer to (1) is true - Can I use the 32 bit driver from
within a 64 bit application?
Do I need to write mixed code in my application, I mean; does my application
should be build from mixed components (DLL's), some of them 32bit, and some
of them 64 bit?
How will the mixed 32/64 components will interface with each other?
(3) On a 64bit system; How a 32bit executable should communicate with a
64bit executable? Does the C#/.NET remoting and TCP will work to communicate
between the two?
(4) What is the maximum continuous memory chunk limit per process in a Win64
bit system (with and without the linkage switch and Boot.ini switch)?
(5) What is different between WinXP 64bit and Windows 2003 Server 64 bit?

 

[Guest]

Sharon,
1) All drivers for Windows 2003 Server 64bit must be 64 bit drivers. I use
x64 version, and so far the only driver I haven't been able to find is the
bluetooth USB, but I suspect I could hack the one from the Windows XP 64 bit
x64 version.

2) No, you cannot use a 32 bit driver. A 32 bit application, yes.

3) Not sure how a 32 bit app might communicate with a 64 bit app.

4) for memory architecture, go here:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;q294418

5) difference between XP and Server 64 bit versions is virtually identical
to the differences between the associated 32 bit versions.

Peter

 

[Guest]

Thanks a lot for the info.

But I still couldn't find an answer to the thread question: What is the
maximum continuous memory chunk limit per process in a Win64
bit system (with and without the linkage switch and Boot.ini switch)?

The article you mentioned does not say what is the maximum continuous memory
chunk limit per process in a Win64 bit system.

 

[Willy Denoyette [MVP]]

| Thanks a lot for the info.
|
| But I still couldn't find an answer to the thread question: What is the
| maximum continuous memory chunk limit per process in a Win64
| bit system (with and without the linkage switch and Boot.ini switch)?
|
| The article you mentioned does not say what is the maximum continuous
memory
| chunk limit per process in a Win64 bit system.
|
|
| --
| Thanks
| Sharon

There is no such thing as "maximum contiguous memory chunk" defined at the
process level, there is only a maximum user virtual address space (VAS) per
process.
The maximum user VAS for X86 Windows is 2GB or 3GB (/4GT tuning), and ~8TB
for X64.
The size of the largest chunk of contiguous memory available in the VAS is
subject to the amount of fragmentation. This is true for both X86 and X64,
of course finding a contiguous chunk of 10GB on X64 won't be an issue with
such a huge VAS.


Willy.

 

[Kevin Yu [MSFT]]

Hi Sharon,

If you're working on a managed app, there is no problem using the remoting
or TCP.

theoretically speaking, a 64-bit process can use as much as 8TB memory. So
the maximum memeory chunk is 8TB. However, some spaces will be taken by the
code segment. Also, if some block has been assigned in the middle of the
chunk, you will note get 8TB continuous chunk.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

 

[Guest]

Thank you all for your prompt info.

Kevin - When you say "there is no problem using the remoting or TCP.", are
you referring to my third question regarding the communication between 32bit
process and a 64bit process?

Furthermore; Can a win32 DLL can communicate with win64 DLL and vice versa?

 

[Willy Denoyette [MVP]]

| Thank you all for your prompt info.
|
| Kevin - When you say "there is no problem using the remoting or TCP.", are
| you referring to my third question regarding the communication between
32bit
| process and a 64bit process?
|
| Furthermore; Can a win32 DLL can communicate with win64 DLL and vice
versa?
|
|
|
| --------
| Thanks
| Sharon

64 bit applications can only load 64 bit DLL's, 32 bit applications can only
load 32 bit (non COM) DLL's.
For inter-process communication, you can use any IPC mechanism available in
windows. That means you can use COM+, DCOM, RPC, and the lower level IPC
protocols like named pipes and sockets as IPC mechanism between 64 bit and
32 bit applications. As Kevin said, managed applications can use remoting as
interop channel between 64bit and 32 bit managed applications.


Willy.

 

[Guest]

If I'm using a 32bit machine (hardware: CPU, drivers etc.) as my development
PC; Can I use this PC (with installed VS2005) to compile code for 64bit to be
executed on another 64bit PC?
Or must I also compile the code on a 64 bit machine?

 

[Guest]

If I'm using a 32bit machine (hardware: CPU, drivers etc.) as my development
PC; Can I use this PC (with installed VS2005) to compile code for 64bit to be
executed on another 64bit PC?
Or must I also compile the code on a 64 bit machine?

 

[Willy Denoyette [MVP]]

| If I'm using a 32bit machine (hardware: CPU, drivers etc.) as my
development
| PC; Can I use this PC (with installed VS2005) to compile code for 64bit to
be
| executed on another 64bit PC?
| Or must I also compile the code on a 64 bit machine?
|
| ---------
| Thanks
| Sharon

VS 2005 PRO can be used to compile native C++ as 64 bit, but you need a 64
bit OS to run or debug.
Managed code JIT compiles to 32 bit code on 32 bit platforms and to 64 bit
code on 64 bit platforms (OS and Framework).


Willy.

 

[Kevin Yu [MSFT]]

Hi Sharon,

Yes, I was referring to your 3rd question. Willy has listed the common ways
to communicate between a 32bit process and 64bit process.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

 

[Guest]

Just to make sure I understand you correctly.
To generate a 64bit managed assemblies (from managed C++, Managed VB, C#
etc.) I must compile the code on the 64bit machine with Win64 OS and 64bit
Framework.
But unmanaged code can be compiled both on a 32bit machine and 64bit machine
using the VS2005 to generate 64 bit unmanaged assemblies.

Is that correct?

 

[Willy Denoyette [MVP]]

| Just to make sure I understand you correctly.
| To generate a 64bit managed assemblies (from managed C++, Managed VB, C#
| etc.) I must compile the code on the 64bit machine with Win64 OS and 64bit
| Framework.
| But unmanaged code can be compiled both on a 32bit machine and 64bit
machine
| using the VS2005 to generate 64 bit unmanaged assemblies.
|
| Is that correct?
|
| -------
| Thanks
| Sharon

No, managed code is compiled to "platform independant" IL by default[1], and
the IL is compiled to 32 bit or 64 bit code at run-time depending on the
platform is runs on.
That means that it will run as 32 bit code on X86 and as 64 bit code on X64.
If you want your code to run on a specific platform only, you can specify
the target by means of the /platform commandline swich (or a VS project
option).
For instance if you specify /platform:x86, your code bit run as 32 bit on
both 32bit and 64 bit windows.
If you specify /platform:x64, your code will only run on X64 (as 64 bit
code).
[1] The default /platform is anycpu.

Willy.

 

[Guest]

Hi again,

I sow this article http://support.microsoft.com/?kbid=283037 about how to
support a large memory in Windows Server 2003.

Maybe I can use this instead of moving to 64bit.

The info I'm missing is how much memory each process can have using this PAE?

 

[Willy Denoyette [MVP]]

| Hi again,
|
| I sow this article http://support.microsoft.com/?kbid=283037 about how to
| support a large memory in Windows Server 2003.
|
| Maybe I can use this instead of moving to 64bit.
|
| The info I'm missing is how much memory each process can have using this
PAE?
|
|
| -------
| Thanks
| Sharon

As I said before, the maximum memory a 32 bit process can access is 2GB (or
3GB using the /3GB boot.ini switch).
PAE is only meant to:
- let the CPU address RAM memory above the 4GB physical boundary.
- use AWE to dynamically map portions of physical memory to the process
working-set.
Note that the AWE API's are not exposed by the framework and this mapped
memory can only be used by unmanaged code (or unsafe constructs), the CLR
cannot take advantage of it at all, or otherwise stated - it's not an option
for managed applications.
Note also that you need at least the Enterprise edition of w2k3 for this and
a server that can accommodate more than 4GB of RAM.

Willy.

 

[Guest]

Ok. In that case, I understand that even if I use the PEA and AWI API with
unmanaged code I will have more then 2 or 3 GB per process, but still it will
not be possible to allocate single continuous memory chuck.
I'm I correct?