Hi, On Thu, Jan 10, 2013 at 10:37 AM, dmccunney <[email protected]> wrote: > On Thu, Jan 10, 2013 at 8:29 AM, Rugxulo <[email protected]> wrote: >> On Thu, Jan 10, 2013 at 12:10 AM, dmccunney <[email protected]> >> 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 frequently). 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: http://p.sf.net/sfu/learnmore_122812 _______________________________________________ Freedos-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-user
