Labview with Vista 64 bit native support

Question

I'm waiting day after day to see a new Labview release supporting Vista 64 bit (I mean running at 64bit natively and not in a 32bit emulation layer). I expected it last year... then I waited believing that of course... it'll come soon... but now I'm really panicking.
64bit CPUs and Vista x64 are now available from a long time ! What's going on ? 
Did I miss some release note ??? Maybe is already available and I don't know ? (I hope so!)
In the mean time Microsoft announced the discontinuation of Windows XP on June 2008 this year (3 moths from now)!!!
Does anyone knows when a full 64bit Labview version will be released ? And what about Vision libs ? (I also need full 64 bit Vision Libs for my applications...)
I have big memory allocation limits due to 32bit addressing (max 2GB)  that I cannot afford anymore... not in the 2008.
I write Vision acquisition software using Labview, IMAQ Hardware and Advanced IMAQ Vision Libs.
As everybody know, memory allocation is "generally" limited to 2GB by the 32bits OS (little more with some tricks) but max image allocation in Labview is anyway much smaller because of default memory fragmentation (Labview and Vision LIBs require allocating a "contiguous memory block" and generally no more then 3-500MB are really available for a single image even with 4GB of memory installed in your PC! This is caused by all DLLs and processes running in memory at different addresses and fragmenting the memory).
I spoke several time with NI concering this problem in the last years and I was told to wait... in the mean time I had to write a special "memory defragmentation" tool myself in order to free up to 1.2GB of RAM for imaging with Labview. Not enough for me and anyway not a clean solution.
Then after Microsoft announced Vista 64bit (a few years ago now) and all PC manufacturer starting building 64bit architecture I expected to solve all my problems soon because of the much larger usable memory addressability...
but this cannot be done yet if Labview and Vision LIBs run in 32bit emulation only !!!
Furthermore Vista 32bit is much slower then XP and uses much more memory !!! This is really a nightmare as I believe that for the first time I'm facing the possibility that soon I'll have to deliver a "newer" but worst product to my customers.
In fact I'll be forced soon to move from LV 7/8 to LV 8.5 (just in order to support Vista) but only to be slower and having the same memory limitations (or maybe more).
Maybe I'm wrong ?
Can anyone reassure me... LV 9 is just after the corner with full 64bit as requested ??? I'm really in panick !
Thanks...
I'm really a LV lover but cannot wait anymore...

Answer 1

Dear Matt,
I was aware of the /3GB and I tryed time ago with LV 7 and XP but without being able to allocate a larger image anyway...
I'll try again and for sure 4GB under Vista 64 is better then anything !!! Do you know if "Image Create.vi" (a VI included in the Vision package) is also able to allocate up to 4GB ?
Concerning Memory defrag I started using some tools available in the marlet (there are good ones for memory analyzing but no one is capable of defragging the memory really)... then a coupple of years ago I wrote a small application in Labview based on 2 free tools provided on the web (those are free tools for developpers provided from Microsoft)...
One is Listdlls.exe which is a command line capable of listing all running DLLs (associated with any running application) and it produces a memory map of the DLLs allocation in memory which allow you to understand how memory is fragmented.
The other one is also a command line tool named Rebase.exe which allow you to a DLL to a different address in memory.
In fact once rebased a DLL will generally load automatically starting at the new address instead of loading in the middle of the memory or at the original address... but not always as some rare system DLLs will anyway try to load always at the same position (as for Asian Language Pack on Chinese/Japanese OS). Furthermore some DLLs need to be loaded to a specific address.
I wrote a program in order to automatically create a memory map of all running DLLs (including system ones) using Listdlls.exe and automatically rebasing them after the first 128MB in memory. Rebasing system/running DLLs is generally more difficult (because of the required access policy and because you must plan a replacement only after next reboot) ... my software take care of this.
Furthermore rebasing running/system DLLs is also dangerous and can crash your system... after many test I limited the rebasing to the memory addresses included between 256MB and 1.6GB... I never have problems rebasing all DLLs in these range (including system ones) under XP 32bit SP2.
I also move DLLs to free space only (not on already occupyed space). Furthermore I never allocate DLLs in the first 128MB (as you'll crash your system probably). In this way I was capable of freing a lot of memory (generally about 15-20 DLLs are reallocated and memory between is free between 300 and 1.6)... something more can be done manually on the higher memory addresses but it take times and must be checked always. In automatic mode my software is capable of freing memory in 2 seconds (but you need a reboot).
Backing up original DLLs is also suggested in order to be able to restore them in case of any problem. I implemented an automatic backup and a restore option for this. A manual mode allow me to manually move DLLs in memory (but it's more dangerous and never allow my customer to do it).
Generally after rebased the memory stay defragmented until you install a new OS patch (which replace old DLLs).
Then you must be aware then in order to mantain the memory clean when running your application in Labview you should preallocate a large memory block when starting your application preventing labview from allocating resources in your free memory (it must use memory outside the 300-1600MB range). This is another problem... I found it hard to solve and my application is doing a good job but not perfect for this.
p.s. Labview and LV Runtimes are major cause of memory fragmentation as they load just in the middle of the system memory... these are the first DLLs ro be rebased !!!