January 06, 2007
Chris Nicholson-Sauls 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.
> 
> And why haven't you?  ;)  I'd just about guarantee some people would have a use for this.  (Client software that needs to be distributed throughout a multi-platform corporation environment, for example.  Would speed development, testing, and deployment time all at once.)
> 
> So, when you say "technically feasible" should I assume that implies "but an awful lot of work?"  Or just "but I haven't thought much on how to do it?"

It's just a fair project to get it to work. I don't see any technical obstacles, just resources. I worked out all the details about 5 years ago <g>.
January 06, 2007
Frits van Bommel wrote:
> How would you implement a garbage collector in an architecture-independent way?
> 
> Or are you talking about using version(arch_1) to version(arch_N)? [1]
> Because I'm pretty sure the garbage collector has to know some architecture-specific things. Start of stack, direction of stack, location of static data, threading API (if any), that sort of thing.
> So you'd need to perform at least _some_ porting to get it to run on a new architecture, if only to tell the GC what its properties are.

The runtime system would have to be ported, just like the Java VM has to be ported, before the code will run. The GC is part of the runtime system.
January 06, 2007
Sean Kelly wrote:
> For example, DMD/Linux appears to pad doubles differently than DMD/Win32,

It pads them to 12 on Linux (to match gcc on Linux).

> so how would the D user code know what to do re: pushing the values onto the stack?

It doesn't need to know.
January 06, 2007
Frits van Bommel wrote:
> I don't think there's currently any way to have it run directly on Windows and Linux simply because there's AFAIK no executable format that's supported by both OSs (ELF is supported on multiple OSs, but Windows doesn't support it). Furthermore, all executable formats I know of (except for plain binary, which AFAIK Linux doesn't support[1]) have some (unique) signature in the first few bytes, so a file can't be multiple of these formats at the same time.
> 
> So you'd need to either using some sort of custom loader binary for each OS or modify OSs to support a common binary format (i.e. a custom loader, but integrated into the OS).
> 
> 
> [1]: Windows "supports" these for programs that fit in 64k: .com files are plain binaries. They're not really useful for anything but backwards compatibility though.

Linux can support PEs (ie: .exe files); that's what Wine is for.

Aside: AFAIK, Mono (open source .NET implementation) is a bit more tricksy: its' compilers generate PEs using a Windows stub, but when you go to run said programs, it ignores the stub (it just looks for which .NET class to fire off and goes from there).

If Windows won't support it, you have to change everything else :3

	-- Daniel
January 06, 2007
John Reimer wrote:
> On Fri, 05 Jan 2007 11:54:09 -0800, 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.
> 
> 
> 
> Isn't this something that LLVM can be used for?
> 
> http://llvm.org/
> 
> -JJR

I once thought about grabbing LLVM and poking around, but the requirements just to compile the damn thing scared me off.  I've had so much pain from GCC (and the entire GNU toolchain) on Windows, I just can't be arsed anymore.

It's somewhat unfair that the OS I got stuck with is the only non-NIXish OS left. :P

	-- Daniel
January 06, 2007
Guest escribió:
> Carlos Santander Wrote:
> 
>> Guest escribió:
>>>
>>>
>>>
>>> Only real reason to use C# is for Win Vista apps since native apps run in a
>>> very suspicious box.
>>>
>> Would you care to explain that, please? I haven't used Vista so I don't know what you're talking about.
>>
>> -- 
>> Carlos Santander Bernal
> 
> Oh yeah. I forgot to tell you I don't have a Vista myself and would try to switch to linux before buying the junk.

LOL!
I'm just happy to have Mac and Linux.

-- 
Carlos Santander Bernal
January 06, 2007
Sean Kelly escribió:
> 
> If I remember correctly, .NET has a way of running native apps in a sandbox to apply its security features to the app.  During Microsoft's presentation,
>  my first thought was "so this is how they plan to get MS Office running
> under .NET."  In theory it's kind of a neat idea, but the code security
> features are so badly designed that I don't expect them to be very popular.
> The maintenance app in the control panel is ghastly, and in code I think it's
>  actually possible to override code security if it's too much of an obstacle.
>  I can't remember the details of this last feature so I may be remembering it
>  wrong, but at the time I was amazed that it was part of the design.
> 
> 
> Sean


Guest escribió:
> 
> 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 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
> 

Two very similar answers with different points of view. Thanks guys!

-- 
Carlos Santander Bernal
January 06, 2007
Sean Kelly wrote:
> Frits van Bommel 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.
>>
>> How would you implement a garbage collector in an architecture-independent way?
> 
> I don't think you would.  Rather, I think you'd have a separate runtime library for each platform that handled all the necessary back-end tasks, but which then called through to the same user-level D program.  This would allow you to deal with platform-specific startup requirements, memory allocation scheme, executable file layout, etc.  So long as the ABI or whatever were sufficiently strict regarding how exception handling occurs and a few other details, I think the compiled user code would be portable across OSes.  But I'm not sure how this would interact with things like calling C libraries built by other compilers.  For example, DMD/Linux appears to pad doubles differently than DMD/Win32, so how would the D user code know what to do re: pushing the values onto the stack?
> 
> 
> Sean

Or in other words, a D-"unique" stub exe format, and a dynamicly linked runtime library...  probably ran via a loader program.  Huh, its a bit like a JVM.  ;)  Although so long as it targeted a particular cpu (x86, PPC, blah) it wouldn't be using bytecodes.

-- Chris Nicholson-Sauls
January 06, 2007
Walter Bright wrote:
> It's just a fair project to get it to work. I don't see any technical obstacles, just resources. I worked out all the details about 5 years ago <g>.

Is that like "I have a truly marvelous proof of this proposition which this margin is too narrow to contain."?

This is meant in good humor, but seriously, why not put all your thoughts on the web somewhere?  It seems D could go much further via collaboration than one man doing all the work.  I was impressed by the benefits of open design while reading about lazy evaluation:

http://www.digitalmars.com/d/lazy-evaluation.html

-Jeff
January 06, 2007
Walter Bright wrote:
> Sean Kelly 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.
>>
>> This would still be limited to a specific architecture, wouldn't it?
> 
> Nope. But it would require one to code in a portable subset of D.
> 
>> ie. "This app runs on x86, regardless of OS."  Given that there are really very few architectures in the marketplace though, this is still a killer feature.
>>
>>
>> Sean

Are these trade secrets or can you elaborate?