Hi,

Thanks for the suggestions, which sounds good. I don't know what if any are the constraints (code size, multiple platform support, marketing/packaging etc?), but I'll pass this on to our product development group and get their take. I'll update you as soon as I get any input on the same, appreciate much.

-regards,
Kittur

Hi
One side is well , but if you use network sharing cifs or Xen machine or other same sharing ...
You put the fox in the hen house.
Can be extremely dangerous for two part systems
Now you have 20% 25% of charge machine used to guard system, to merge binaries can be resulting 50% or greater..
Best regards.

Yes, that's definitely one scenario which becomes a major constraint :-( Good point. The otherpoint that
I can think of is that it may not makesense to have code not compiled for a particular machine/arch consuming disk space, although the universal binary concept itself am sure sounds very appealing...
-Cheers

This could be implemented by using a DLL-like dispatch table. e.g. a generic system function call is made by way of the address of the routine stored in a dispatch table (similar to how DLL is done) excepting at program start (in one point of the code), O/S detection occures, and the appropriate table is loaded (or pointed to) and if/when necessary O/S specific auxiliary code loaded (again similar to DLL).

Note, I think if a program has what looks like a DOS .COM file pasted on the front that that portion of the program will load and start execution. This part would contain the O/S detection and prep the application for use.

For system calls that have no generic equivilent then the user code will have to have conditionalized section

switch(GetOS())
{
case isMAC:
{
...
break;
}
caseisVista:
{
...
break;
}
case isWinXP:
{
...
break;
}
...
...

Jim Dempsey