DOS should have a stable, pudly Java VM

[Thomas Pfaff]

In response to both Joaqin and Dean's responses.

Yep there are plenty of TCP/IP stacks out there already for DOS.  They take
up a fair amount of space tho'... in mass-produced embedded systems it'd be
better to get the TCP/IP stacks out of the software/firmware space and into
a gate implementation (ideally on-chip with an 80186 core).  The gate
implementation of TCP/IP also has the advantage of being high speed and
low-power (100-baseT Ethernet based TCP/IP is no problem).

Threads would slow things down.  I think limiting the amount of threads that
are allowed in a system might be a good idea.  Or say you could as the
manufacturer of an embedded device allow a maximum number of threads to
exist.  On systems with megabytes of extended memory you could turn full
thread support on.  For many applications you might only want two threads.
One for the app that updates the functional app when the version changes and
another to run a particular application.  Granted more threads would be nice
for lotsa reasons (not just the ones I've stated here).

I wish I'd gotten the comp.lang.java.hardware group so we could talk more
about this and a myriad of other hardware-java issues.  Logically this
discussion should probably move to this non-existant place.  (sigh).  Can
anyone post the Network Control Message to make an alt.lang.java.hardware
group out there?  If so please keep me informed.

Did anyone see the Smartcard hype at the JavaOne conference?  It was pretty
lame except in the sense of evangelizing the VM on a smaller footprint.
These guys are using small 8 bit processors (like a 8051 core or something)
in a 20 millimeter dye on a smartcard.  They find they can implement a VM no
problem but have no space for a program!

With a 20 bit address space in a generic embedded system I think you could
quite a lot with a VM implementation that could:

(a) be capable of downloading and updating new software
(b) could support a group of Java applications smaller than the
applets/applications that we run today in larger 32 bit environments.
(c) could be scaled up or down for environments with different resource
parameters (i.e. RAM, ROM and I/O)

Thomas


At 04:19 PM 4/16/97 -0700, you wrote:
>> 
>> DOS would be great tho' you'd have to add support for TCP/IP to make it
>> useful.  It'd be great to have a DOS-based java-ready device so that
>
>DOS does have a TCP/IP implementation called WatTCP.  Many programs
>ranging from grapical web browsers to email readers use WatTCP stack.
>Check out www.fdisk.com for general info and further URLs.
>
>> [snip]
>> Granted AWT would introduce a big can of worms not because of graphics
>> support but more in the department of memory management.  Without AWT (i.e.
>
>That why one would use an 32bit extender.
>
>> [snip]
>> 
>> Anyone game for a 20-bit 80x86 VM implementation?
>> I think it should probably not have anything do with Kaffe, personally.
>> 
>
>Me neither, that why you would use a 32bit DOS extender to provide a flat
>memory model called DPMI or protected mode interface.  The DJGPP package
>offers a freeware extender and provides full gcc support.
>
>I do not think it is a matter of extra support except possibly in
>compilation targets.
>
>> [snip]
>
> - joaquin
>
>
>


---------------------------------------------------------
Without agents the World-Wide-Web is kind of like a blind man with one leg
trying to walk down a (crowded) street