OK. I think I get this and thank you for the learning. Just some clarification (I am a little dense):

Can a palm applet be written to watch for and do an action, like when there is a sound call from an application? This would be within GVM.
Does GVM access the n800's hardware wifi/bluetooth? Can it send and receive files? Any limitations on this? So send to the net, to my computer, to the n800? is this part stable? Can a GVM applet be written to accept incoming files and do a script on them? Place them, copy over existing file? Can GVM talk with n800 via wifi or bluetooth? Wifi and bluetooth are bi-directional? Sort of like they are both virtual machines within a shared hardware.

If GVM can be stable enough to do these things, which are the only things I really need for it to do, then we are golden! The PC part of the scripts ought be a walk in the park.

If GVM can't do these things then when it can it will be a good thing, until then, it is a successful and interesting proof of concept.

The next non-beta will be a great improvement too! Good work to those that worked on this! Hope GVM's development will continue.

In the mean time I need a DateBook level PIM.

Wow "Sungrove's" adventures with DBk is very cool. Recounted into the threadtitled: "Can't get GVM to work." DBk5 can sync (with a little help from friends)
Now sounds and stable enough to depend on!

Thanks so dubwise: Any ideas on how to write a little applet to listen for sound calls? From the GVM side and then access the WiFi?

I've been using GVM on a daily basis for several weeks now, and my experience is:
1. Palm apps running under GVM that try to make sounds are not just unsuccessful, they crash the GVM. However, I've done this several times and never had any serious data loss. I only had to restart the GVM.
2. There is very little access to hardware "outside" the GVM. So when you are working under the GVM you have no access to bluetooth, wifi or SD card. Getting things in or out of the GVM is accomplished from the top GVM window (before "launch", as it were). For data in and out you can do a network hotsync. For data in you can get files onto your memory or SD card (via connecting cable or bluetooth or however) and tell the GVM to "install" them. It will do that even for data files. Unfortunately, that option cannot be used for data out. This has impications for keeping backups. If you don't or can't use hotsync, then how do you back up your data? My choice is to use rsync daily on the Nokia to backup the /home/user/.gvm directory to my external SD card. That backs up the whole virtual machine. Not good for restoring individual data files, but if you had a disaster, you can restore your whole virtual machine after reinstalling the GVM software.

I hope Access fixes the sound bugs and continues the GVM after it's expiration date. I'll be using it!

I've had some success running PalmVNC over WiFi from within Garnet VM. It certainly connected to my Windows desktop at work and displayed my Windows session. After only a minute or two the connection dropped, but I didn't investigate why. It's likely I had the VNC server misconfigured in some way, as I don't normally use VNC. I had only installed it to check that Garnet VM could "see" my Windows desktop across subnets during my troubleshooting of the VM's network HotSync capability.

Regardless, networking from within Garnet VM over my N800's WiFi connection worked.

Networking works from GVM, via the Nokia's network stack. It doesn't have "direct" access to wi-fi or Bluetooth though, which is fine as far as tcp/ip networking is concerned - you can have your IT online via wi-fi, bluetooth, or presumably usb networking if you can get that working, and this is transparent to GVM - it just uses the "network" virtual interface.

However, it would be nice if GVM could use the non-networking part of BT directly (i.e. everything not BT DUN/PAN). And even more important, if it could just see the SD card.. as it is now it's a bit incommunicado, as been said already. Hopefully that's the first thing Access will fix in the hypothetical next release.

Agree completely. For backup purposes, and just general usability, you really need to be able to move data into and out of the SD card.