LabVIEW
read the system memory
Accessing virtual memory is simply getting the pointer from somewhere inside your application. If you call a DLL, you simply get a pointer and need to configure your Call Library Node accordingly to match that pointer. You may also have to make sure to initialize such arrays beforehand, if the DLL is supposed to write information into it. You can't pass virtual memory addresses between processes as a virtual address only has a meaning in a specific process and will cause havoc if tried to access in a different process.
Physical memory access is a concept that is highly obsolete from application level in Windows 32 and newer. On such systems only device drivers residing in the kernel side of Windows are supposed to do that. There exists however an Open G Port IO library that also allows to access Physical memory access from application side. It uses a device driver that will open up your kernel IO space and Physical memory to any application that knows about this device driver interface, so it is definitely a security issue. Also it is 32 bit only and don't expect such support in Windows 64 bit. The according kernel APIs used in that device driver have been obsoleted by Microsoft a long time ago and some of them are simply not available in the 64 bit kernel of Windows.
Without a kernel device driver this is going to be a pain in the a** no matter what you do. We are in 2011 not 1975 where protected mode was not even known. The Visual C example uses technicques that were appropriate back in DOS and Windows 3.1 times, (though you usually had to write assembly anyhow to do such things at all), but in 2011 we have protected mode Winodws 32 and 64 bit, and Linux and Mac OS X. All these systems specifically abstract the hardware away from the application level and prevent an application actively from accessing hardware resources directly. You can circumvent these sometimes with the avove mentioned OpenG Port IO driver, which uses again a kernel mode driver to allow applications more or less generic access to some of these resources. But it is a hack and one that is not going to be portable in any way to 64 bits.
While I also don't believe that a DAQ driver requires 1GB of installer software, anyone selling hardware cards nowadays without a proper device driver installer simply has not done the most important part of his product. Ni's slogan "The software is the instrument" is more true nowadays than ever before.
But I think you are barking up the wrong tree here too. You say the DLL gives you the virtual address and the physical address. So I would assume that the DLL does the mapping already for you and should in fact have an API to which you can simply pass the heap pointer address in which you want the data to be written. In that case intialize a large enough array of data of the correct type in LabVIEW with Initialize Array and pass this as Array Data Pointer to the according DLL API. No fiddling with physical memory addresses.
If the card doesn't have such an API, send it back and request your money back! This is not from this century anymore!
No it won't help. The OpenG Port IO driver is a Windows kernel driver! While the NI ETS Realtime system (the one for x86 platforms, not the newer VxWorks based cRIO and other realtime controllers) does provide a subset of the Windows user space API, it's kernel is COMPLETELY different. It won't be able to distingiush the OpenG Port IO kernel driver component from your favorite JPG image or any other file on your system. For that kernel a Windows kernel driver looks simply like a bunch of useless binary data.
If you talk about the VxWorks based RT platforms, the kernel is again very different but for it the Windows kernel driver will make even less sense if that is possible at all.
The direction you are heading is most likely a dead end. You can't get into those kernels without optaining an expensive developer license of the respective tools, and even if you have that, you can't get your hands on the NI modifications for those kernels, and compiling your own kernel from the original sources will not allow them to run on the NI hardware as LabVIEW target.
There is a possibility that those RT kernels allow loading of dynamic drivers and that they even provide some access to direct memory through some kernel API. However if you don't synchronize that properly with the rest of the kernel then your system will be rather unstable, something an RT system is specifically not meant to be.
