Georg Wrede wrote:
> Walter Bright wrote:
>> TPJ wrote:
>>
>>> 1) In order to run a program written in D I have to compile it on the target OS.
>>
>> I haven't talked about this much, but it is technically feasible to create a D runtime that enables "compile once, run everywhere". It is not necessary to have a VM to do it.
> 
> 1. To run on any OS on one specific processor, either those OSes have to have different entry points to the "exe", or there has to be a way of probing the OS within "common" code, the result of which would cause a jump to an OS specific routine.
> 
> 2. To run on different processor architectures, (most probably with some of the same OSes), the worst case scenario would be that the same OS with the same jump target gets invocated on a different processor. This would mean that one (er, Walter) would have to invent a series of binary instructions that would not cause an (unwanted) exception on any of the processors, would not have any harmful side effects, and would eventually result in a jump to some processor specific version of the code.

> At first sight ("hearing" ?), it sounds too good to be true. Then one starts to suspect that either Walter has figured out a runtime gimmick that does it (thus rendering this (btw, patentable idea) independent of D), or it is some kind of result of the specific way D and its source code (more to the point, syntax domain) relate to the semantics of the source code, taken as a whole.

I've come up with one vague idea about how this could be done (which doesn't involve either 1 or 2), though it would involve an obscene hack, telling some serious lies to the OS. I can't think of a way it could be done for OSes with radically different file formats, though.

Don Clugston wrote:
> Guest wrote:
>> Carlos Santander Wrote:
>> I'm sorry for my long reply time.  I've read a couple of articles on running native apps in Vista and they have all said that it will be ran in a box that supplies imense security features to protect the user.  It will abort the app as soon as it starts looking suspicious.  That's the box I'm talking about.  So really you should use a .NET language on Vista because the .NET already has the security and won't be ran in a box.  I've also read the box will severely limit your programs access to resources (such as: files,hardware,etc.).
> 
> I find that a bit hard to believe. Consider what fraction of high-end PCs are used for games, which are almost exclusively native apps. Microsoft cannot afford to alienate that market.
> 
>> I wish I wrote the url's down of those web pages so I could directly link them to you and when I start reading up on vista again.  I will re reply with a list of url's you may visit.
>>
>> Guest
>>

It is mostly true. Vista has a new "feature" called User Account Protection (UAP) that can be defined as a sandbox since it prevents an application from executing certain operations that are considered "for administrators only".

Current versions of most programs won't work (Even .NET ones) directly and have to be modified and programs that use system devices will be specially affected. (Most burning programs and anti-virus will need to be updated, for example).

The performance hit isn't as bad as one can imagine as most safeguards are placed at operations that already are relatively slow... like disk access, changing video modes, opening ports, etc...

A famous WTF related with UAP is that Visual Studio 6 will run perfectly while Visual Studio 2002, 2003 and 2005 will present "some problems":

http://msdn2.microsoft.com/en-us/vstudio/aa964140.aspx

Still from the new Vista "features" the one I worry about it's the DRM integration for HD content because it will hurt us even if we only use Linux or MacOSX. For more information read:

http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt