>>>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.
This is because they are mostly constrained by the companies they work.
Time is limited so using stuff that everyone does to create their programs
speeds up implementation time (maybe).
If you leave a developer free (I prefer the word "programmer" instead), I
would bet he would have gone towards the simplest way to solve his problem,
unless he has not got any knowledge about the hardware.
Thinking about real hardware no one could expect better performance from
the huge libraries. Yes, using these speeds up your work (or you get much
more time searching and finding what they do to use them), but what about
performance?
Simple is rugged, reliable and bugs can be easily corrected. Although
simple is sometimes a pain in the @$$ to write, like assembler based
software.
Konstantinos Giannopoulos (SV3ORA)
Computer and Telecommunications Engineer
Director of the Greek Microwave Group (www.microwave.gr)
2013/1/11 Rugxulo <rugx...@gmail.com>
> Hi,
>
> 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
> 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
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
------------------------------------------------------------------------------
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
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user