On Thu, Jan 10, 2013 at 10:37 AM, dmccunney <dennis.mccun...@gmail.com> wrote:
> On Thu, Jan 10, 2013 at 8:29 AM, Rugxulo <rugx...@gmail.com> wrote:
>> On Thu, Jan 10, 2013 at 12:10 AM, dmccunney <dennis.mccun...@gmail.com> 
>> wrote:
> (DOS apps don't run at all under Win7, unless you use a VM, but I
> found a version that does of the only DOS app the SO used - a DOS port
> of the old Unix game Larn.)

I haven't really used Win7 32-bit at all, but I assume NTVDM still
(barely) works, last I heard. Though you can always run DOSBox
instead. Anyways, Larn can't be hard to find (or port or recompile)
since even NetBSD has it. Using OpenWatcom would maybe be best, IMHO,
but I haven't tried. (Or RSXNTDJ, if you're willing to dig up old
semi-bitrotted stuff, heh.)

>> Granted, perhaps DOS native binaries aren't the easiest or greatest
>> things to lug around for ages, but I don't know of a true "universal"
>> solution. Scripts? (Lua?) Bytecode? (Inferno?) We probably shouldn't
>> have separate binaries for every single x86 OS, but for some people,
>> source compatibility is "good enough". Too bad they make so many
>> horrible assumptions in the process.
> There's no such thing as a true universal solution.  (But then, how
> many folks *need* one?  Most folks either just run one platform, or
> don't *expect* to have the same programs available everywhere.  The
> folks most interested will be *developers* trying to target multiple
> platforms.)

Developers are fairly close-minded. They don't usually target anybody
outside of the big three, which usually means POSIX + Windows. And
these days they get more kicks out of having ten bazillion ports to
Linux (IA-32 or x64) than others. I'm just saying, if you want to run
it on any sane box, you're stuck with "modern" Windows (XP or newer,
usually automatic installers, which I hate) or building your own. For
any third party OS, it's much harder to get things running due to too
many requirements or bad assumptions. (Even OpenBSD is feeling some of
this pain, and they are much closer to the norm than we are.)

> The closest is a "Write once, run anywhere" solution like Java.  Code
> is compiled to a tokenized binary targeted at an arbitrary virtual
> machine implemented by the Java runtime.  If there *is* a Java runtime
> for what you have, the code will run on it.  Java runtimes exist for
> almost everything.  (You still have to be aware of various issues -
> it's possible to write non-portable code in Java.)

"Almost everything"? Not so much. Sure, I heard eCS (OS/2) updated
their Java a while back, but usually it seems Java doesn't run on most
OSes that aren't "top tier" (not counting very old or deprecated
versions which can't be found). In other words, it works where things
are big and popular and well-supported, not so much anywhere else.

In my opinion, Java has a few advantages that make it so popular
(though it's basically tied with C, which is more ubiquitous but has
less features):

* lots of features (objects, generics, exceptions, garbage collection,
threads, networking, GUI)
* semi-portable open source
* semi-portable byte code
* JIT for speeding up the bytecode

Now, lots of languages have bytecode, even languages that work well in
DOS, so that idea for portability isn't so far-fetched or unique to
Java. (And I think Java inherited the idea from the Pascal P-machine.)

Having a JIT is rarer, esp. for DOS. You could argue it's not needed,
esp. if only talking about speed, but who knows. Anyways, it's things
like this which make native compilation more popular than
interpreters. This is one of the reasons why Ruby 1.9.x is preferred
over (slower) 1.8.x. Also, this is probably? why Google spent time on
Go instead of Python (and they basically abandoned Unladen Swallow).
Python is popular but has a reputation for being slow.

Anyways, back to JIT, I don't know the answer. Lua-JIT exists, but
I've never tried in DOS. I know Lua "mostly" works, though, which is
good. (BTW, _PIL3_ was just published.) But like I said, there is no
standard, so it's slightly tricky (esp. since most people assume it
has add-ons, e.g. LuaPOSIX or LuaFS or whatever.)

> One interesting trend is wider use of scripting, because current
> hardware can run script languages fast enough to make them competitive
> with other languages.  I'm seeing an increasing amount of stuff
> written in Python, which is available for Windows, Linux, and OS/X,
> using widget libraries like Qt so it largely looks and acts the same
> on any supported platform.

Just to be clear, I am thinking of FreeDOS here, so this isn't all
meant to be totally off-topic. IMHO, FreeDOS 2.0 should have more
compilers and interpreters, and I've weakly tried over the past few
months to carefully add a few to iBiblio. Yes, interpreters are often
(but not always) slower, but they are easier to use, and many times
speed isn't relevant (unless done across heavy data or very

For interpreters, (in lieu of only using DEBUG + QBASIC clones) I
would suggest BWBasic, Lua, Regina REXX, AWK, or something similar for
"BASE" for FreeDOS 2.0. (Or maybe Pascal-S or P5, but I'm not sure how
well accepted those would be, maybe too limited.) Oh, and also maybe
something related to ever-popular C:  EiC, PicoC, CINT [not built yet
/ untested], etc. (Perl and Python are too big, but perhaps we can use
older Perl 5.005 or such.)

And I've gotten Ruby 1.8.7 to build, and now that it's an ISO
standard, maybe somebody would care, but dunno, who knows.   :-)

Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
much more. Get web development skills now with LearnDevNow -
350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only -- learn more at:
Freedos-user mailing list

Reply via email to