Re: [Freedos-devel] New Old Timer reporting :-)

[Robert Riebisch]

Hi Ralf,

>>> Never heard about this one, so had only a brief look after downloading.
>>> The biggest hurdle for a start is that both the docs and the comments in
>>> the source code are in Japanese...
>> See it as a big puzzle. ;-)
> 
> Well,...
> 
> That might all depend on what else is going on in one's life... 😉

Yes, of course.

> I would much rather spend what ever time I have on the source code 
> itself, rather than spend endless hours trying to translate comments in 
> order to better understand the source code as is in the first place...

Feel free. :-)

Cheers,
Robert
-- 
  +++ BTTR Software +++
 Home page: https://www.bttr-software.de/
DOS ain't dead: https://www.bttr-software.de/forum/


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[Ralf Quint]

On 12/4/2020 1:40 PM, Robert Riebisch wrote:

Hi Ralf,


For a while I tinkered around with the Japanese Cabezon Pascal compiler:
https://wiki.bttr-software.de/Cabezon/HomePage

Didn't get very far, because I lost interest a little. Still have some
small examples on my disk only.

I already have some ideas, but time flies...

Never heard about this one, so had only a brief look after downloading.
The biggest hurdle for a start is that both the docs and the comments in
the source code are in Japanese...

See it as a big puzzle. ;-)


Well,...

That might all depend on what else is going on in one's life... 😉

I would much rather spend what ever time I have on the source code 
itself, rather than spend endless hours trying to translate comments in 
order to better understand the source code as is in the first place...


Ralf



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[Robert Riebisch]

Hi Ralf,

>> For a while I tinkered around with the Japanese Cabezon Pascal compiler:
>> https://wiki.bttr-software.de/Cabezon/HomePage
>>
>> Didn't get very far, because I lost interest a little. Still have some
>> small examples on my disk only.
>>
>> I already have some ideas, but time flies...
> 
> Never heard about this one, so had only a brief look after downloading. 
> The biggest hurdle for a start is that both the docs and the comments in 
> the source code are in Japanese...

See it as a big puzzle. ;-)

> And I have right now the same problem as you, so much interesting 
> projects/ideas but so little time... ;-)

Isn't that the problem of *all* people?

>>> Why is FreeDOS a toy in this case? I think it is pretty much en par with
>>> MS-DOS 6.x, for all practically purposes, just that less 3rd party
>>> support for drivers for devices like network cards/chips ad printers for
>>> example...
>> In what sense does FreeDOS have less support for drivers?
>>
> Maybe a bit bad wording on my part (after all, I wrote this a 06:00 in 
> the morning, with only one cup of coffee), what I mean is that in 
> general "DOS" has the problem of the lack of drivers for "modern" 
> hardware...

Okay.

Cheers,
Robert
-- 
  +++ BTTR Software +++
 Home page: https://www.bttr-software.de/
DOS ain't dead: https://www.bttr-software.de/forum/


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[Danilo Pecher]

I agree Jim,

If you go for effective, then the standard FreeDOS window is certainly not
the ideal solution, and perhaps I should have made it clearer that my
remark to Tom wasn't meant overly seriously.

The nice thing about FreeDOS is that you have choice these days, unlike in
the days of yore, so there's something for everybody. You even have choice
of compilers. Personally, I probably never really left the 90s, so I feel
right at home in an 80x25 world. I run CDE on my Linux and BSD Systems, so
my X11 looks still the same as it did on a 1997 Sparc Station, and my
Terminals always start in 80x25, black background, green text - because
that's what the screen looked like on my old A7150 in 1990, a haphazardly
cobbled together East German IBM PC clone. I'm just weird I guess ;)

Cheers, Danilo

On Thu, 3 Dec 2020 at 01:04, Jim Hall  wrote:

>
>
> On Wed, Dec 2, 2020 at 8:05 AM tom ehlert  wrote:
>
>> Danilo,
>> > Sorry, but I think you're too snippy here.
>>
>> > First of all, if the idea of an 80x25 single file editor frightens
>> > you, you're either a wimp or too young to have done any programming
>> > when that was the norm.
>>
>> my first 'editor' were punched cards.
>>
>> next came a single line editor (TECO on a PDP10), roughly comparable
>> to EDLIN. that was a HUGE improvement. I would never go back to
>> punched cards.
>>
>>
>> next came a full screen 25*80 editor; first VI on UNIX, with HJKL
>> cursor movement commands. that was a HUGE improvement. I would never go
>> back to
>> EDLIN.
>>
>> now it's two 28 inch monitors, with google search, RBIL, editor,
>> program output and debugger all living nicely side by side.
>> that was a HUGE improvement. I would never go back to
>> single screen 25x80. FOR DEVELOPEMENT!
>> [..]
>>
>
>
> I write code in FreeDOS and for FreeDOS, like when I recorded the "How to
> program in C" video series. I use the FED editor, which is probably my
> favorite programming editor under FreeDOS. The code syntax highlighting is
> a nice feature.
>
> But 80x25 is a very small "window" for effective coding. So I usually do
> not code on FreeDOS. I use a full screen editor on my Linux desktop system,
> and transfer the files to FreeDOS. This was a lot easier when I used DOSEmu
> to run FreeDOS - DOSEmu booted from a directory in your Linux home, so you
> could edit a file on Linux and it would appear immediately in your running
> DOSEmu session. But since DOSEmu hasn't been updated in a while (haven't
> checked DOSEmu2 lately) I do it another way with QEMU.
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[Jim Hall]

On Wed, Dec 2, 2020 at 8:05 AM tom ehlert  wrote:

> Danilo,
> > Sorry, but I think you're too snippy here.
>
> > First of all, if the idea of an 80x25 single file editor frightens
> > you, you're either a wimp or too young to have done any programming
> > when that was the norm.
>
> my first 'editor' were punched cards.
>
> next came a single line editor (TECO on a PDP10), roughly comparable
> to EDLIN. that was a HUGE improvement. I would never go back to
> punched cards.
>
>
> next came a full screen 25*80 editor; first VI on UNIX, with HJKL
> cursor movement commands. that was a HUGE improvement. I would never go
> back to
> EDLIN.
>
> now it's two 28 inch monitors, with google search, RBIL, editor,
> program output and debugger all living nicely side by side.
> that was a HUGE improvement. I would never go back to
> single screen 25x80. FOR DEVELOPEMENT!
> [..]
>


I write code in FreeDOS and for FreeDOS, like when I recorded the "How to
program in C" video series. I use the FED editor, which is probably my
favorite programming editor under FreeDOS. The code syntax highlighting is
a nice feature.

But 80x25 is a very small "window" for effective coding. So I usually do
not code on FreeDOS. I use a full screen editor on my Linux desktop system,
and transfer the files to FreeDOS. This was a lot easier when I used DOSEmu
to run FreeDOS - DOSEmu booted from a directory in your Linux home, so you
could edit a file on Linux and it would appear immediately in your running
DOSEmu session. But since DOSEmu hasn't been updated in a while (haven't
checked DOSEmu2 lately) I do it another way with QEMU.
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[Danilo Pecher]

Hi Tom,

Well, I guess we'll have to agree to disagree then, and maybe I'm just
weird. I'm the sort of guy that actually would look for spare parts on
horse back, because that's way more fun. Probably not for the horse though,
considering that, unlike 30 years ago, I weigh more than Belgium these
days.

As for using the best available tools - if that means using a completely
different OS, I think it sort of beats the purpose of the exercise. If I
wanted to do Dos programming on Linux, I could just as well use Dosbox. Of
course, with your 28 inch home cinema with all the bells and whistles,
you'll most likely beat the pants off me as far as productivity goes, but
that's where our idea of FreeDOS differs.

What you describe is programming for maximum efficiency. That's something I
use on my day job, but not when I'm programming for the fun of it. When I'm
programming for FreeDOS, I'm doing it IN FreeDOS. And on the whole I tend
to keep it as simple as possible in the first place. I've had people laugh
at me, because I do my C and C++ programming in vi (or vim, I've developed
a sense of luxury with age), but the thing is, no matter what sort of Unix
box you're tasked to work on, you'll always have vi. And you even have one
in FreeDOS, which is good, because it would drive me potty to use a
different editor, punching ESC everytime I want to save my file.

And that's not just crazed nostalgia even. I'm a freelance IT contractor. I
do everything from programming to database administration. In 2014, I
landed myself a sweet one-year contract as an Oracle dba with Volkswagen in
Wolfsburg. (I had nothing to do with the exhaust systems, just to make
sure). When it comes to Oracle administration you have a whole smorgasboard
of powerful tools, like TOAD, and knowing those is a nice thing, but had
those been my primary tools, I would have lasted exactly one day in that
contract, because they didn't allow access to the servers by anything than
ssh, and the servers were basically vanilla Solaris or HP-UX setups with an
Oracle server slapped on, so basically all you had at your disposal was vi
for text editing and sqlplus for running sql queries or scripts. People
came and went, sometimes the same week they arrived, because they didn't
have the experience to use the 'steam age tools'. It's nice know how to use
an electric drill, but you're three miles up the creek without a paddle in
a leaking canoe if the power is out and that's the only way you know of
drilling a hole.

Now that's of course an extreme example. I've worked at banks too and even
they weren't that restrictive. You obviously know your way around and if
you prefer the 28 inch option, all power to you. I'm the sort of guy who's
happy toiling about drilling holes using his hand-cranked drill, and only
uses the electric one if the hole-drilling is urgent.

Cheers, Danilo

PS: I'll take you up on the slide-show request. Any excuse to fiddle with
VGA registers is a welcome one. But since I'm one of the few lucky bastards
whose job has survived the lockdown, I'd like to ask you for waiting till
the weekend comes around.

On Wed, 2 Dec 2020 at 15:06, tom ehlert  wrote:

> Danilo,
> > Sorry, but I think you're too snippy here.
>
> > First of all, if the idea of an 80x25 single file editor frightens
> > you, you're either a wimp or too young to have done any programming
> > when that was the norm.
>
> my first 'editor' were punched cards.
>
> next came a single line editor (TECO on a PDP10), roughly comparable
> to EDLIN. that was a HUGE improvement. I would never go back to
> punched cards.
>
>
> next came a full screen 25*80 editor; first VI on UNIX, with HJKL
> cursor movement commands. that was a HUGE improvement. I would never go
> back to
> EDLIN.
>
> now it's two 28 inch monitors, with google search, RBIL, editor,
> program output and debugger all living nicely side by side.
> that was a HUGE improvement. I would never go back to
> single screen 25x80. FOR DEVELOPEMENT!
>
>
> > May I introduce you to Turbo Pascal 3.0? 80x25 text is the best there is.
> Turbo Pascal was really impressive. in 1990.
>
> > Programming 'something useful' is a subjective term. If you program
> > on FreeDOS, you are by definition programming for a fringe audience,
>
> you obviously don't understand the difference between 'programming on'
> and 'programming for'.
> and I simply want to have the best tools possible when programming for
> FreeDOS.
>
>
> even if your hoppy is a steam engine, you don't use steam age tools to
> take care of your steam engine. you use probably electric drills and
> go by car to find spare parts, not on horse back.
>
>
>
>
>
> > For me, FreeDos allows me to go back to the days when programming
> > was actually a testament to your skills, rather than just being able
> > to cobble a few lines of code together and nail a GUI on it by
> click-and-point.
>
> for a start: why don't you show us your slide show program for DOS,
> using any tools you like.
>
> talk i

Re: [Freedos-devel] New Old Timer reporting :-)

[tom ehlert]

Danilo,
> Sorry, but I think you're too snippy here. 

> First of all, if the idea of an 80x25 single file editor frightens
> you, you're either a wimp or too young to have done any programming
> when that was the norm.

my first 'editor' were punched cards.

next came a single line editor (TECO on a PDP10), roughly comparable
to EDLIN. that was a HUGE improvement. I would never go back to
punched cards.


next came a full screen 25*80 editor; first VI on UNIX, with HJKL
cursor movement commands. that was a HUGE improvement. I would never go back to
EDLIN.

now it's two 28 inch monitors, with google search, RBIL, editor,
program output and debugger all living nicely side by side.
that was a HUGE improvement. I would never go back to
single screen 25x80. FOR DEVELOPEMENT!


> May I introduce you to Turbo Pascal 3.0? 80x25 text is the best there is.
Turbo Pascal was really impressive. in 1990.

> Programming 'something useful' is a subjective term. If you program
> on FreeDOS, you are by definition programming for a fringe audience,

you obviously don't understand the difference between 'programming on'
and 'programming for'.
and I simply want to have the best tools possible when programming for
FreeDOS.


even if your hoppy is a steam engine, you don't use steam age tools to
take care of your steam engine. you use probably electric drills and
go by car to find spare parts, not on horse back.





> For me, FreeDos allows me to go back to the days when programming
> was actually a testament to your skills, rather than just being able
> to cobble a few lines of code together and nail a GUI on it by 
> click-and-point. 

for a start: why don't you show us your slide show program for DOS,
using any tools you like.

talk is cheap...

Tom



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[Steve Nickolas]

On Tue, 1 Dec 2020, Ralf Quint wrote:

I used to be able to speak and understand a little bit of Japanese, as 
learned while doing various martial arts, but this is now 40 years ago.


And of course, the kind of Japanese used in martial arts which you would 
have been familiar with, the kind of Japanese used in anime which I am 
familiar with, and the kind of Japanese used in the computing world are 
all different.


(My domain, buric.co, is actually a pun on a Japanese slang term.)

Of course, my Japanese ("aa, taihen desu!" - "oh, that's terrible!") is a 
cutesy animesque dialect. :P  (Hint: look up the term "burikko".)


But I never got a handle on the various ways of writing, something that 
Japanese had in common with Greek and Russian... 😉


At least Greek and Russian simply use alphabets.  Japanese, with 3 writing 
scripts, one semi-pictographic and two syllabaries, is a nightmare.


-uso.___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[Ralf Quint]

On 12/1/2020 7:33 PM, Steve Nickolas wrote:

On Tue, 1 Dec 2020, Ralf Quint wrote:

Yup, that one. But there is no proper, easy to install version of the 
ANSI style compiler and inclusion of things like the peephole 
optimizer. And there is no manual to cover the ANSI version, the last 
printed version only covers the 2.x K&R compiler. I have OCR'd the 
whole manual, but it is a lot of work to adjust everything to ANSI 
syntax and specially all the "screenshot" examples need to be redone 
from scratch. And to be more useful, it needs to have a lot of the 
Borland style libraries added...


I wonder if some of them could be ported from DJGPP? I know DJGPP has 
a Borland-compatible conio library (unlike Watcom).

You could even rewrite them from scratch. But it takes time, either way...


Never heard about this one, so had only a brief look after 
downloading. The biggest hurdle for a start is that both the docs and 
the comments in the source code are in Japanese...


あぁ、大変です！ (Sorry, couldn't resist.)

I'm going to guess it's too big for someone like me to attempt to 
trudge through all the comments, and my Japanese is rather mediocre 
(although I do speak the language a little bit and have done 
translation work, including semi-professionally, from Japanese to 
English).


Does help that most computer-related terminology in Japanese is 
borrowed from English (there's a joke in the movie "Perfect Blue" 
about this). 


I used to be able to speak and understand a little bit of Japanese, as 
learned while doing various martial arts, but this is now 40 years ago. 
But I never got a handle on the various ways of writing, something that 
Japanese had in common with Greek and Russian... 😉


On a more serious note, I have tried to use/participate in various Open 
Source projects that had their source and/or documentation in another 
language than English and it never went far. Not even when it was in my 
native language German rather than something more exotic (due to the 
non-Latin writing), like Japanese...


Ralf



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[Steve Nickolas]

On Tue, 1 Dec 2020, Ralf Quint wrote:

Yup, that one. But there is no proper, easy to install version of the 
ANSI style compiler and inclusion of things like the peephole optimizer. 
And there is no manual to cover the ANSI version, the last printed 
version only covers the 2.x K&R compiler. I have OCR'd the whole manual, 
but it is a lot of work to adjust everything to ANSI syntax and 
specially all the "screenshot" examples need to be redone from scratch. 
And to be more useful, it needs to have a lot of the Borland style 
libraries added...


I wonder if some of them could be ported from DJGPP? I know DJGPP has a 
Borland-compatible conio library (unlike Watcom).



For a while I tinkered around with the Japanese Cabezon Pascal compiler:
https://wiki.bttr-software.de/Cabezon/HomePage

Didn't get very far, because I lost interest a little. Still have some
small examples on my disk only.

I already have some ideas, but time flies...


Never heard about this one, so had only a brief look after downloading. 
The biggest hurdle for a start is that both the docs and the comments in 
the source code are in Japanese...


あぁ、大変です！ (Sorry, couldn't resist.)

I'm going to guess it's too big for someone like me to attempt to trudge 
through all the comments, and my Japanese is rather mediocre (although I 
do speak the language a little bit and have done translation work, 
including semi-professionally, from Japanese to English).


Does help that most computer-related terminology in Japanese is borrowed 
from English (there's a joke in the movie "Perfect Blue" about this).


And I have right now the same problem as you, so much interesting 
projects/ideas but so little time... ;-)


Ditto.

Maybe a bit bad wording on my part (after all, I wrote this a 06:00 in 
the morning, with only one cup of coffee), what I mean is that in 
general "DOS" has the problem of the lack of drivers for "modern" 
hardware...


Which I think has always been true at least since the 32-bit era.

-uso.___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[Steve Nickolas]

I got my PS/2 up with wifi on DOS (although I don't currently do so) using 
one of these:


https://www.amazon.com/gp/product/B00PMCJ17Y

(It's an Ethernet/Wifi bridge. Will need some setup using a modern Web 
browser first.)


-uso.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[Steve Nickolas]

On Tue, 1 Dec 2020, Eric Auer wrote:


Tom is neither, but you could argue that he could use more modern,
more advanced editors for DOS, with higher text mode resolutions.


Win9x's edit.com will run under unusual and unorthodox screen resolutions, 
and edits up to 9 files at a time.  When MS-DOS and Win32 were still my 
native platform, that was my editor of choice.



On the other hand, his impressive FreeDOS development track record
shows that cross-compiling from another system or using DOS in a
window while using another host operating system for the rest of
your activities does not keep you from being productive DOS-wise :-)


This.  And this is the advantage of Watcom C: you can compile to 16-bit 
DOS (or to Windows, or to OS/2) from Linux, and you can still compile to 
DOS from DOS.



I think it is an important point that ancient machines are no longer
widespread. There is little use in having a 640k, 16-bit scandisk
or defrag for FAT32, if nobody has managed to connect a large disk
to such ancient hardware. So it is fine for me that dosfsck needs
a 386 to check FAT32 partitions.


For what it's worth, when I want to get my retro on, I have a PS/2 Model 
30/286.  Because I was worried about the proprietary HD failing, I 
installed an XTCF and put a 2 GB CompactFlash card in line with the 
original drive (also, 20 MB just isn't enough).



People today seem to be more worried about the other end of the
spectrum: Why is DOS limiting them to 2 TB disk size or 3 GB of
RAM, running on only 1 of their 16 CPU cores? Not that I would
know ANY application for DOS which would need that kind of power,
I agree that people wonder whether DOS *may* use it, now that the
2020 PC on their desk has it anyway :-)


Although it would be nice to do a "DOS-64", and I've thought about ways to 
develop a DOS-like operating system for 64-bit PCs that no longer have 
BIOS, I think for a lot of these people, they may be served better by 
Linux.


-uso.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[Ralf Quint]

On 12/1/2020 8:10 AM, Robert Riebisch wrote:

Hi Ralf,


OpenWatcom at least requires a 386 and additional RAM, I don't think it
is running on a 640KB 808x machine anymore. But there is for years an
Open Source 16bit C compiler, though a bit of a quirky one, which got
pretty much forgotten since Turbo C came out in the mid '80s. I started
to get a proper, easy to use release, but RL just keeps getting in the
way of things, and things didn't get easier since COVID hit... 🙁

What's the name of the compiler?


http://www.desmet-c.com/ under GNU (L)GPL.
Yup, that one. But there is no proper, easy to install version of the 
ANSI style compiler and inclusion of things like the peephole optimizer. 
And there is no manual to cover the ANSI version, the last printed 
version only covers the 2.x K&R compiler. I have OCR'd the whole manual, 
but it is a lot of work to adjust everything to ANSI syntax and 
specially all the "screenshot" examples need to be redone from scratch. 
And to be more useful, it needs to have a lot of the Borland style 
libraries added...

For a while I tinkered around with the Japanese Cabezon Pascal compiler:
https://wiki.bttr-software.de/Cabezon/HomePage

Didn't get very far, because I lost interest a little. Still have some
small examples on my disk only.

I already have some ideas, but time flies...


Never heard about this one, so had only a brief look after downloading. 
The biggest hurdle for a start is that both the docs and the comments in 
the source code are in Japanese...


And I have right now the same problem as you, so much interesting 
projects/ideas but so little time... ;-)



Why is FreeDOS a toy in this case? I think it is pretty much en par with
MS-DOS 6.x, for all practically purposes, just that less 3rd party
support for drivers for devices like network cards/chips ad printers for
example...

In what sense does FreeDOS have less support for drivers?

Maybe a bit bad wording on my part (after all, I wrote this a 06:00 in 
the morning, with only one cup of coffee), what I mean is that in 
general "DOS" has the problem of the lack of drivers for "modern" 
hardware...


Ralf



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[Ralf Quint]

On 12/1/2020 7:52 AM, Steve Nickolas wrote:


I dunno, C and Pascal are almost identical in how they're structured. 


Sorry, but not even remotely. Pascal is in contrast to C

- not case sensitive

- strongly typed

- standard string type(s)

- range checks on by default

- strong error checking on file operations by default

- ever since UCSD Pascal, support for units, allowing for

    - separate testing

    - easier reusable code libraries

    - smart linking

    - data and code encapsulation

    - optional objects/object oriented features


Ralf



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[Chelson a]

I am working on these esp01/8266 with at commands from dos you can connect to a 
wifi in dos and other retro machines. This should be a viable option for 
freedos.

https://www.instructables.com/Getting-Started-With-the-ESP8266-ESP-01/ 


Thoughts?

> On 2 Dec 2020, at 9:26 am, Danilo Pecher  
> wrote:
> 
> wireless, I don't even go there, it's an iwi that need proprietary Intel 
> firmware - no sale. 
> 
> No, the machine is a geriatric Compaq Nx8220 and the NIC in question is a 
> Broadcom Ethernet card. BCM5751M.
> 
> On Wed, 2 Dec 2020 at 00:09, Eric Auer  > wrote:
> 
> Hi!
> 
> > laptop is 15 years old, and even that has hardware that is 'too new'
> 
> You mean wireless?
> 
> > I think you're asking two implicit questions here: a) Should we abandon
> > 16 bit hardware as nobody has any, which would mean FreeDOS goes 32bit.
> 
> No. Things which work well with 640k can AND should stay 16 bit :-)
> 
> Just relax that requirement for things which work BETTER in 32 bit.
> 
> > why FreeDOS?
> 
> Because you can :-) And because many DOS apps already exist.
> 
> > Not trying to get too philosophical here
> 
> Who knows ;-)
> 
> > FreeDos needs to find its main purpose and then adjust course
> 
> It already has a purpose - the question is what you want to change.
> 
> Regards, Eric
> 
> 
> 
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net 
> 
> https://lists.sourceforge.net/lists/listinfo/freedos-devel 
> 
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel

___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[Danilo Pecher]

wireless, I don't even go there, it's an iwi that need proprietary Intel
firmware - no sale.

No, the machine is a geriatric Compaq Nx8220 and the NIC in question is a
Broadcom Ethernet card. BCM5751M.

On Wed, 2 Dec 2020 at 00:09, Eric Auer  wrote:

>
> Hi!
>
> > laptop is 15 years old, and even that has hardware that is 'too new'
>
> You mean wireless?
>
> > I think you're asking two implicit questions here: a) Should we abandon
> > 16 bit hardware as nobody has any, which would mean FreeDOS goes 32bit.
>
> No. Things which work well with 640k can AND should stay 16 bit :-)
>
> Just relax that requirement for things which work BETTER in 32 bit.
>
> > why FreeDOS?
>
> Because you can :-) And because many DOS apps already exist.
>
> > Not trying to get too philosophical here
>
> Who knows ;-)
>
> > FreeDos needs to find its main purpose and then adjust course
>
> It already has a purpose - the question is what you want to change.
>
> Regards, Eric
>
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[Eric Auer]

Hi!

> laptop is 15 years old, and even that has hardware that is 'too new'

You mean wireless?

> I think you're asking two implicit questions here: a) Should we abandon
> 16 bit hardware as nobody has any, which would mean FreeDOS goes 32bit.

No. Things which work well with 640k can AND should stay 16 bit :-)

Just relax that requirement for things which work BETTER in 32 bit.

> why FreeDOS?

Because you can :-) And because many DOS apps already exist.

> Not trying to get too philosophical here

Who knows ;-)

> FreeDos needs to find its main purpose and then adjust course

It already has a purpose - the question is what you want to change.

Regards, Eric



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[Danilo Pecher]

Hi Eric,

Well, your argument is compelling, but I think it sort of misses the point.
FreeDOS is a system for legacy hardware - I mean - really legacy. My oldest
laptop is 15 years old, and even that has hardware that is 'too new' and
not supported by FreeDOS. I'm currently trying to nail a Packet driver
together for its Broadcom Nextreme NIC, but if that'll work is a matter of
'we'll see'.

I think you're asking two implicit questions here: a) Should we abandon 16
bit hardware as nobody has any, which would mean FreeDOS goes 32bit.

The second question is: What is it for? If you have 32bit hardware in the
first place, And except for a few stray early pentiums we're talking about
machines that can run dosbox at reasonable speeds, why FreeDOS? I mean, you
can run just about every DOS Software on a puny littleRaspberry Pi.

Not trying to get too philosophical here - I like FreeDos for he nostalgic
fuzzies - but that group is a rather small one.I think FreeDos needs to
find its main purpose and then adjust course accordingly.

sorry for the rambling, it's been a long day...

On Tue, 1 Dec 2020 at 23:30, Eric Auer  wrote:

>
> Danilo,
>
> > First of all, if the idea of an 80x25 single file editor frightens you,
> > you're either a wimp or too young to have done any programming when that
> > was the norm. May I introduce you to Turbo Pascal 3.0? 80x25 text is the
> > best there is.
>
> Tom is neither, but you could argue that he could use more modern,
> more advanced editors for DOS, with higher text mode resolutions.
>
> On the other hand, his impressive FreeDOS development track record
> shows that cross-compiling from another system or using DOS in a
> window while using another host operating system for the rest of
> your activities does not keep you from being productive DOS-wise :-)
>
> I think it is an important point that ancient machines are no longer
> widespread. There is little use in having a 640k, 16-bit scandisk
> or defrag for FAT32, if nobody has managed to connect a large disk
> to such ancient hardware. So it is fine for me that dosfsck needs
> a 386 to check FAT32 partitions.
>
> People today seem to be more worried about the other end of the
> spectrum: Why is DOS limiting them to 2 TB disk size or 3 GB of
> RAM, running on only 1 of their 16 CPU cores? Not that I would
> know ANY application for DOS which would need that kind of power,
> I agree that people wonder whether DOS *may* use it, now that the
> 2020 PC on their desk has it anyway :-)
>
> Cheers, Eric
>
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[Eric Auer]

Danilo,

> First of all, if the idea of an 80x25 single file editor frightens you,
> you're either a wimp or too young to have done any programming when that
> was the norm. May I introduce you to Turbo Pascal 3.0? 80x25 text is the
> best there is.

Tom is neither, but you could argue that he could use more modern,
more advanced editors for DOS, with higher text mode resolutions.

On the other hand, his impressive FreeDOS development track record
shows that cross-compiling from another system or using DOS in a
window while using another host operating system for the rest of
your activities does not keep you from being productive DOS-wise :-)

I think it is an important point that ancient machines are no longer
widespread. There is little use in having a 640k, 16-bit scandisk
or defrag for FAT32, if nobody has managed to connect a large disk
to such ancient hardware. So it is fine for me that dosfsck needs
a 386 to check FAT32 partitions.

People today seem to be more worried about the other end of the
spectrum: Why is DOS limiting them to 2 TB disk size or 3 GB of
RAM, running on only 1 of their 16 CPU cores? Not that I would
know ANY application for DOS which would need that kind of power,
I agree that people wonder whether DOS *may* use it, now that the
2020 PC on their desk has it anyway :-)

Cheers, Eric



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[Danilo Pecher]

Tom,

Sorry, but I think you're too snippy here.

First of all, if the idea of an 80x25 single file editor frightens you,
you're either a wimp or too young to have done any programming when that
was the norm. May I introduce you to Turbo Pascal 3.0? 80x25 text is the
best there is.

As for not finding a 486 machine that hasn't got a Pentium - that's not the
point - Dos was written for pre-386 processors and unless you want to chuck
that heritage overboard with FreeDOS, it should remain able to work on
those machines.

Programming 'something useful' is a subjective term. If you program on
FreeDOS, you are by definition programming for a fringe audience, unless we
can find a new market for FreeDOS (like the SBCs I mentioned earlier). The
legacy gamers are better off just slapping a dosbox on whatever system
they're using. Programming for FreeDOS is basically done because you like
it that way, a labour of love if you want, but you won't reach a huge
audience. Personally, if I was in charge, people at university would still
start programming on DOS to learn things like memory management, something
that modern languages hide behind ridiculously bloated runtimes. Sadly, I
am not in charge.

For me, FreeDos allows me to go back to the days when programming was
actually a testament to your skills, rather than just being able to cobble
a few lines of code together and nail a GUI on it by click-and-point.

Cheers, Danilo

On Tue, 1 Dec 2020 at 20:36, tom ehlert  wrote:

> P.S.:
>
> I have done a LOT of programming for FreeDOS.
> this includes Kernel, command, lba boot sector, himem, emm386, mkeyb,
> kitten, fdisk, and probably more.
>
> not a single edit or compile were done on DOS.
> just the idea of a single file, 25*80 editor frightens me.
>
> Tom
>
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[tom ehlert]

P.S.:

I have done a LOT of programming for FreeDOS.
this includes Kernel, command, lba boot sector, himem, emm386, mkeyb,
kitten, fdisk, and probably more.

not a single edit or compile were done on DOS.
just the idea of a single file, 25*80 editor frightens me.

Tom



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[tom ehlert]

Hi Ralf,

I simply don't get your point.

> OpenWatcom at least requires a 386 and additional RAM, I don't think it
> is running on a 640KB 808x machine anymore.

and you would probably be hard pressed to find a x86 machine that has
not a Pentium installed.
what's the point?

a recompiled TurboPascal program with a new, open source, 16 bit
compiler will do *exactly* the same as the old program.
(if sources were available and it compiles at all).

if it's a puzzle (like in a crossword), use EDLIN and MASM.
no C around. not even TinyC.

if it's about programming something useful, use all tools available,
including my favourite environment with multiple windows on multiple
high resolution monitors open, the debugger doesn't interfere with the
debugee, Google and RBIL only few a few mouse clicks away away.

if you are up to a challenge, use a hex editor to program. they don't
to much memory.

if you want to do something useful with your time, use all available tools.


Tom



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[Robert Riebisch]

Hi Ralf,

> OpenWatcom at least requires a 386 and additional RAM, I don't think it 
> is running on a 640KB 808x machine anymore. But there is for years an 
> Open Source 16bit C compiler, though a bit of a quirky one, which got 
> pretty much forgotten since Turbo C came out in the mid '80s. I started 
> to get a proper, easy to use release, but RL just keeps getting in the 
> way of things, and things didn't get easier since COVID hit... 🙁

What's the name of the compiler?

There are already:

https://github.com/ZaneDubya/Small-C
Enhancements by Zane Wagner:
- Replaced Quote[] with inline string literal.
- Consolidated Type recognition in dodeclare(), dofunction(), and
statement().
- C99 style comments are allowed (//)
- C89/C90 argument list types.
- Support for 'static' access modifier for functions and globals.
- Support for longer variable names.

http://www.desmet-c.com/ under GNU (L)GPL.

>> A 16-bit Pascal compiler would probably be the easier choice to start 
>> with as the language is better structured and easier to compile.
> Not writing from scratch, but getting an easier to use and set up 16bit 
> version of FreePascal. It pretty much exists, but is an over all an 
> afterthought by the general project maintainers these days. And requires 
> also a 386+ machine for the compiler itself, but it would at least help 
> to open up a vast amount of Turbo Pascal code that is still out there to 
> be utilized with FreeDOS. Working on this is also on my list, though for 
> me personally less of an issue, as I legally own Borland Pascal 7 (and 
> Borland C(++) 3.1 for that matter).

For a while I tinkered around with the Japanese Cabezon Pascal compiler:
https://wiki.bttr-software.de/Cabezon/HomePage

Didn't get very far, because I lost interest a little. Still have some
small examples on my disk only.

I already have some ideas, but time flies...

> Why is FreeDOS a toy in this case? I think it is pretty much en par with 
> MS-DOS 6.x, for all practically purposes, just that less 3rd party 
> support for drivers for devices like network cards/chips ad printers for 
> example...

In what sense does FreeDOS have less support for drivers?

Cheers,
Robert
-- 
  +++ BTTR Software +++
 Home page: https://www.bttr-software.de/
DOS ain't dead: https://www.bttr-software.de/forum/


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[Steve Nickolas]

On Tue, 1 Dec 2020, Danilo Pecher wrote:


I would agree with Ralf on most points.

As for the 16 bit C-Compiler, I think Turbo-C fits that bill but acquiring
it legally requires a registration with embarcadero, so not exactly optimal
and not everyone is an old hack like me, who started coding in 1989 and
still legally owns nearly every Borland Compiler ever released.
What is with the OpenWatcom compiler? Does that need an extender too? Else
we're looking at a completely new project, and as much as I feel tempted by
it, such work would only make sense if there was enough interest and at
least a small group of people volunteering to work on it.


It requires DOS/4GW to run the compiler because it's pretty heavy.


A 16-bit Pascal compiler would probably be the easier choice to start with
as the language is better structured and easier to compile.


I dunno, C and Pascal are almost identical in how they're structured.

-uso.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[Ralf Quint]

On 12/1/2020 4:55 AM, Danilo Pecher wrote:

I would agree with Ralf on most points.

As for the 16 bit C-Compiler, I think Turbo-C fits that bill but 
acquiring it legally requires a registration with embarcadero, so not 
exactly optimal and not everyone is an old hack like me, who started 
coding in 1989 and still legally owns nearly every Borland Compiler 
ever released.
What is with the OpenWatcom compiler? Does that need an extender too? 
Else we're looking at a completely new project, and as much as I feel 
tempted by it, such work would only make sense if there was enough 
interest and at least a small group of people volunteering to work on it.
OpenWatcom at least requires a 386 and additional RAM, I don't think it 
is running on a 640KB 808x machine anymore. But there is for years an 
Open Source 16bit C compiler, though a bit of a quirky one, which got 
pretty much forgotten since Turbo C came out in the mid '80s. I started 
to get a proper, easy to use release, but RL just keeps getting in the 
way of things, and things didn't get easier since COVID hit... 🙁


A 16-bit Pascal compiler would probably be the easier choice to start 
with as the language is better structured and easier to compile.
Not writing from scratch, but getting an easier to use and set up 16bit 
version of FreePascal. It pretty much exists, but is an over all an 
afterthought by the general project maintainers these days. And requires 
also a 386+ machine for the compiler itself, but it would at least help 
to open up a vast amount of Turbo Pascal code that is still out there to 
be utilized with FreeDOS. Working on this is also on my list, though for 
me personally less of an issue, as I legally own Borland Pascal 7 (and 
Borland C(++) 3.1 for that matter).


The biggest barrier in my view is that FreeDOS is still a bit of a toy 
for old hacks like me, who can't let go of the past when programmers 
had to actually code properly instead of relying of monstrous 
languages that come with garbage collectors and whatnot and leave you 
with memory-leaking megabyte-sized executables.
Why is FreeDOS a toy in this case? I think it is pretty much en par with 
MS-DOS 6.x, for all practically purposes, just that less 3rd party 
support for drivers for devices like network cards/chips ad printers for 
example...


So apart from the software I think FreeDOS needs to find a market for 
serious use other than retro afficionados, and cheap SBCs would be 
something that could work. Maybe we should port FreeDOS to the 
raspberry Pi ;) Just kidding...


Well, there is now the Pi-X (no relation to the Raspberry Pi Foundation 
though), with $100 the cheapest x86 board I know. Money is pretty tight 
these days but I still hope to get myself one as a Xmas present this 
year... 😉


Ralf



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[Danilo Pecher]

I would agree with Ralf on most points.

As for the 16 bit C-Compiler, I think Turbo-C fits that bill but acquiring
it legally requires a registration with embarcadero, so not exactly optimal
and not everyone is an old hack like me, who started coding in 1989 and
still legally owns nearly every Borland Compiler ever released.
What is with the OpenWatcom compiler? Does that need an extender too? Else
we're looking at a completely new project, and as much as I feel tempted by
it, such work would only make sense if there was enough interest and at
least a small group of people volunteering to work on it.

A 16-bit Pascal compiler would probably be the easier choice to start with
as the language is better structured and easier to compile.

The biggest barrier in my view is that FreeDOS is still a bit of a toy for
old hacks like me, who can't let go of the past when programmers had to
actually code properly instead of relying of monstrous languages that come
with garbage collectors and whatnot and leave you with memory-leaking
megabyte-sized executables. When I go into my local supermarket, they have
these large LCD-screens that usually display the latest discount deals, but
these days tell people to wear their mask and how far you need to stay away
from each other. Every other day the thing bombs out with a windows blue
screen and I thinks to myself - Why? Why run a windows system for what is
effectively a simple slide show? This would be a prime example for slapping
in a SBC with a small SD card and DOS in it. But it seems that nobody
builds such SBCs, even though considering DOS's modest requirements, you'd
think they could make such things dirt cheap.

So apart from the software I think FreeDOS needs to find a market for
serious use other than retro afficionados, and cheap SBCs would be
something that could work. Maybe we should port FreeDOS to the raspberry Pi
;) Just kidding...

Cheers, Danilo



On Tue, 1 Dec 2020 at 05:12, Ralf Quint  wrote:

> On 11/29/2020 6:17 AM, zz zz wrote:
> > I would much rather see some efforts in reviving some true DOS versions
> of programming languages, in a open source form. That also run on DOS, not
> require cross compiling on a multi-GB graphical OS.
> >Sounds interesting, but what exactly do you mean by "DOS versions" of
> such languages? As in previous versions of the C standard for example? or
> perhaps the borland "mannerisms"?
>
> A easily working 16bit version of FreePascal that can compile a large
> amount of old Turbo Pascal code, for example. And can run on DOS. Or a
> proper DOS version of (Open)COMAL, a nice structured interpreted
> programming language that to this day is still used to teach
> programming, kind of like a "better BASIC". Or a true 16bit C compiler,
> that runs on FreeDOS. Or a 16bit dBASE clone. Or Modula 2...
>
> In general, it would be nice to see some people really programming FOR
> DOS again, creating useful Open Source DOS application that people can
> actually use. Not just trying to recompile some behemoth Linux took that
> isn't really suited for DOS, and that to make things work require
> another behemoth development system ported from Linux, shoehorning both
> into the limitations of DOS.
>
> Ralf
>
>
> --
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[Steve Nickolas]

On Mon, 30 Nov 2020, Ralf Quint wrote:

In general, it would be nice to see some people really programming FOR DOS 
again, creating useful Open Source DOS application that people can actually 
use. Not just trying to recompile some behemoth Linux took that isn't really 
suited for DOS, and that to make things work require another behemoth 
development system ported from Linux, shoehorning both into the limitations 
of DOS.


This.

Hopefully GW-BASIC's open-sourcing will help a bit, although it was only a 
very early, 1.x version.  Back in the day I wrote tons upon tons upon tons 
of code, and all of it in GW-BASIC until I found QBASIC (and had a machine 
with more than 256K RAM), QuickBasic, and eventually Turbo C.


-uso.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[Ralf Quint]

On 11/29/2020 6:17 AM, zz zz wrote:

I would much rather see some efforts in reviving some true DOS versions of 
programming languages, in a open source form. That also run on DOS, not require 
cross compiling on a multi-GB graphical OS.
   Sounds interesting, but what exactly do you mean by "DOS versions" of such languages? 
As in previous versions of the C standard for example? or perhaps the borland 
"mannerisms"?


A easily working 16bit version of FreePascal that can compile a large 
amount of old Turbo Pascal code, for example. And can run on DOS. Or a 
proper DOS version of (Open)COMAL, a nice structured interpreted 
programming language that to this day is still used to teach 
programming, kind of like a "better BASIC". Or a true 16bit C compiler, 
that runs on FreeDOS. Or a 16bit dBASE clone. Or Modula 2...


In general, it would be nice to see some people really programming FOR 
DOS again, creating useful Open Source DOS application that people can 
actually use. Not just trying to recompile some behemoth Linux took that 
isn't really suited for DOS, and that to make things work require 
another behemoth development system ported from Linux, shoehorning both 
into the limitations of DOS.


Ralf


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[zz zz]

Sent: Sunday, November 29, 2020 at 3:32 AM
From: "Ralf Quint" 


> Well, the problem with that line of thinking is that DOS is a single-user, 
> single tasking OS, NOT a server. And not only that makes a server use for DOS 
> rather useless, you need to consider that DOS also by itself does not contain 
> any networking. Any ways to turn DOS into a server 
>

  I don't quite get your point, FreeDOS has networking and there is plenty of 
"server programs" (maybe this wording makes more sense?) for DOS, I'm told 
there are even more than what is listed on the FreeDOS downloads. Others have 
said elsewhere that being a single-user, single tasking OS can actually be a 
plus for, say, security. For small projects or simply experimentation this 
could be very useful and more RAM could allow those "servers" to be even more 
useful, meaning, doing more interesting things.
 

> Is there really a need for something like this? I am always curious when I 
> see people like you aiming  high up in the sky,

  I don't get this either, all I've mentioned already exists in FreeDOS. I 
don't see much difference from extending accessible RAM from 1MB to 64 compared 
to extending from 64 to 1GB. Except if the change would entail so much change 
to the architecture it would not be worth it, would you say 64MB then is such a 
hindrance?

> but nobody is able or even willing to contribute on some lower hanging 
> fruits...

Maybe if there are more people bumping against that limit, a small fraction 
could be willing to improve on it. We will never know until they *use* it up to 
that limit.
 
>> Also, glad to hear there is no interest in (even) more languages.
> Seriously, what programming languages that don't already exist in some form 
> or another for actual programing in DOS would be there?

  Totally agreed.

> Sorry, as mentioned before, I just don't see JavaScript as a viable option, 
> nor any of the other languages that came out after DOS officially died.  And 
> personally, I don't see a need for this either. 

 Like I said before, I saw other threads (maybe they were older threads) 
declaring such needs, therefore I'm happy effort needs not be spent in this 
regard.

> I would much rather see some efforts in reviving some true DOS versions of 
> programming languages, in a open source form. That also run on DOS, not 
> require cross compiling on a multi-GB graphical OS.

  Sounds interesting, but what exactly do you mean by "DOS versions" of such 
languages? As in previous versions of the C standard for example? or perhaps 
the borland "mannerisms"?

> Ralf
F.


 
[https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=icon]Virus-free.
 
www.avast.com[https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=link]___
 Freedos-devel mailing list Freedos-devel@lists.sourceforge.net 
https://lists.sourceforge.net/lists/listinfo/freedos-devel[https://lists.sourceforge.net/lists/listinfo/freedos-devel]


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[Mercury Thirteen via Freedos-devel]

Thanks! We would appreciate the help. :)


Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Friday, November 20, 2020 9:01 AM, tom ehlert  wrote:

> > But what has become a
> > slow but seemingly steady stream is that there are new people
> > showing up once in a while, with a whole plethora of grand ideas,
> > that very quickly end up nowhere. As it seems, mostly because the
> > vast majority of those doesn't understand what DOS is. And that
> > seems to be part of the overall trend, where people are coming up
> > with solutions for issues that people pretend to have  in order to
> > solve problems that nobody has...
>
> +1
>
> maybe we should redirect these DOSIX fans to the NightDOS project
> where they develop a multitasking, 32 Bit DOS clone
>
> /s
>
> Tom
>
> > Virus-free. www.avast.com
> >
>
> Virus-free. I personally checked this ;)
>
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[Jim Hall]

> The biggest problem that I see with/for FreeDOS is the number of
> people actually still interested in working with/for (Free)DOS. That
> number has always been limited, but has gotten even smaller over the
> years. Beside Jim, who started this, I might actually now be the
> longest surviving member here, being more or less active since late
> '95 or early '96. A lot of people from the early years have come and
> gone, for various reasons. But what has become a slow but seemingly
> steady stream is that there are new people showing up once in a
> while, with a whole plethora of grand ideas, that very quickly end
> up nowhere. As it seems, mostly because the vast majority of those
> doesn't understand what DOS is. And that seems to be part of the
> overall trend, where people are coming up with solutions for issues
> that people pretend to have  in order to solve problems that nobody
> has...



+1


In general, I like the idea of extending DOS. That's what FreeDOS is
about. But FreeDOS is still DOS, and that means all the limitations
that come with it.


Jim


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[tom ehlert]

> But what has become a
> slow but seemingly steady stream is that there are new people  
> showing up once in a while, with a whole plethora of grand ideas,   
> that very quickly end up nowhere. As it seems, mostly because the   
> vast majority of those doesn't understand what DOS is. And that 
> seems to be part of the overall trend, where people are coming up   
> with solutions for issues that people pretend to have  in order to
> solve problems that nobody has...

+1

maybe we should redirect these DOSIX fans to the NightDOS project
where they develop a multitasking, 32 Bit DOS clone

/s

Tom

> Virus-free. www.avast.com

Virus-free. I personally checked this ;)




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[Thomas Mueller]

> On 11/19/2020 3:36 AM, Harald Arnesen wrote:
> > I have no idea if such a thing exists (and that is not my point). You
> > were not aware of any standalone JS interpreters, I showed you that they
> > exist - although not for DOS.

> That is the whole point, after all we ARE talking (Free)DOS here...

> Ralf

Resending this message because I forgot to include the Subject: line :

Lack of Javascript support is one thing that makes serious web browsing 
near-impossible on any DOS.

There was years ago an attempt at DOSzilla.

I once downloaded and had a standalone Javascript interpreter for OS/2 Warp 4.

Since OS/2 Warp installation crashed the hard drive in April 2001 and could 
never again be booted, I was never again able to run any OS/2 software, and was 
not interested in eComStation and ArcaOS when Linux, FreeBSD and NetBSD were so 
much better.  I had many years of Internet with DR-DOS 7.03.

I did later manage to access the internet with FreeDOS,  but insufficiency of 
browser capabilities prevented me from going far in that direction.

Has anybody ever done onine banking from (Free or other)DOS? 

Tom



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[Thomas Mueller]

from zz zz:

--===6725751721200256742==
Content-Type: text/html; charset=UTF-8

hi

 

> DOS is based on 8086 architecture, with 1MB of RAM

 

  Wasn't protected mode supposed to extend that? Anyways, I'm 
running on a 48MB machine and even DSL and tinycore had problems with such a 
low amount, which is somewhat disturbing for the preservation of 
technology.

 

> and at times rather finicky ways to extended this amount for 
application running on top of DOS.

 

  what would be the maximum? 32 bits can address 4GB, 16 bits would 
be 64KB (which is definetely NOT enough for everyone :D) so it's already 
kind of a hack to have anything in between..

(snip)

First thing you need to do when asking such a question is make it more 
readable, not muddy with HTML codes.  Nasty to read!

Tom



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[Steve Nickolas]

On Thu, 19 Nov 2020, Ralf Quint wrote:

The biggest problem that I see with/for FreeDOS is the number of people 
actually still interested in working with/for (Free)DOS. That number has 
always been limited, but has gotten even smaller over the years. Beside Jim, 
who started this, I might actually now be the longest surviving member here, 
being more or less active since late '95 or early '96. A lot of people from 
the early years have come and gone, for various reasons. But what has become 
a slow but seemingly steady stream is that there are new people showing up 
once in a while, with a whole plethora of grand ideas, that very quickly end 
up nowhere. As it seems, mostly because the vast majority of those doesn't 
understand what DOS is. And that seems to be part of the overall trend, where 
people are coming up with solutions for issues that people pretend to have  
in order to solve problems that nobody has...


I've been in and out of lurk-mode here since the late 1990s.  More out, 
because I've taken a drink from the devil's firehose. ;)


Since I grew up on primitive home computers, and MS-DOS (or PC DOS) was my 
main OS for years, I probably understand DOS a bit more intuitively than 
these johnny-come-latelys who seem to want to turn DOS into Linux.


DOS did pick up a number of Unixisms.  That's why C is such a good 
language for it.  But it's not Unix, and never will be Unix.  It's DOS, 
and that's what I like about it.


-uso.___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[Ralf Quint]

On 11/19/2020 11:39 AM, zz zz wrote:

hi
> DOS is based on 8086 architecture, with 1MB of RAM
  Wasn't protected mode supposed to extend that? Anyways, I'm running 
on a 48MB machine and even DSL and tinycore had problems with such a 
low amount, which is somewhat disturbing for the preservation of 
technology.
But DOS at its core is a 16bit OS, designed to run on a very specific 
CPU with a 20bit address bus, hence a 1MB address limit. And for more 
than a decade, people were able to create excellent software just fine.
> and at times rather finicky ways to extended this amount for 
application running on top of DOS.
  what would be the maximum? 32 bits can address 4GB, 16 bits would be 
64KB (which is definetely NOT enough for everyone :D) so it's already 
kind of a hack to have anything in between..
DOS memory manager historically limit the amount of RAM via EMM/EMS to 
32 or 64MB of RAM. That ought to be enough for anyone really interested 
in programming for DOS.


>Sorry, I am programming for far too long, in a lot of different 
programming languages, as to be buying into this nonsense.

  Time can be a good OR a bad thing but, it does not address the argument.
> Well, I might actually have found a reasonably priced one and with a 
little bit of luck, I might have have one by Christmas.
  Cool! x86 is rather surprising (to me) for a SBC as ARMv8 and beyond 
will be all the rage going forward (got a little one here as well 
:)).. so the emulation route would probably be needed most of the time.
> Sorry, but there are enough programming languages around for use 
with DOS, there is no need to "even more", specially not any of those 
that have become self-serving solutions that only solve issues that 
nobody has...
  I agree with you here, which is why I've been (jokingly) writing 
"even" before the "more" ever since I suggested that. But skimming the 
mailing list I saw some people expressed that want, so my suggestion 
was a quick way to get them that without any additional work, like I 
said, C is probably a better target, it also has a bunch of those 
compilers and lower resistance of course.


Well,...

The biggest problem that I see with/for FreeDOS is the number of people 
actually still interested in working with/for (Free)DOS. That number has 
always been limited, but has gotten even smaller over the years. Beside 
Jim, who started this, I might actually now be the longest surviving 
member here, being more or less active since late '95 or early '96. A 
lot of people from the early years have come and gone, for various 
reasons. But what has become a slow but seemingly steady stream is that 
there are new people showing up once in a while, with a whole plethora 
of grand ideas, that very quickly end up nowhere. As it seems, mostly 
because the vast majority of those doesn't understand what DOS is. And 
that seems to be part of the overall trend, where people are coming up 
with solutions for issues that people pretend to have  in order to solve 
problems that nobody has...


Ralf




--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[zz zz]

hi

 

> DOS is based on 8086 architecture, with 1MB of RAM

 

  Wasn't protected mode supposed to extend that? Anyways, I'm running on a 48MB machine and even DSL and tinycore had problems with such a low amount, which is somewhat disturbing for the preservation of technology.

 

> and at times rather finicky ways to extended this amount for application running on top of DOS.

 

  what would be the maximum? 32 bits can address 4GB, 16 bits would be 64KB (which is definetely NOT enough for everyone :D) so it's already kind of a hack to have anything in between..

 

> Well, if not in a browser, how do you actually run _javascript_? You need the "engine" for that, and that is part of a browser. And I am not aware of a standalone _javascript_ interpreter, and even if there is, you can't really use it for DOS, as you have kind of a "chicken and egg" problem here...

 

  Why, I just told you, Ralf.. maybe you skimmed too quickly but there is a J in DOjS (doJs, clever huh?), and I discovered it only thanks to you guys, since it's in the FD pages ("what's included"). That's why I said you already got a canvas (HTML5 programmable video audio.. in js) WITH filesystem support.

 

  What is NOT in the pages but IS in the repositories for FD is an actual LISP implementation for DOS! It isn't there because, I'd assume, it's probably abandoned as the author's website is gone for years. It's usable though..

 

>Sorry, I am programming for far too long, in a lot of different programming languages, as to be buying into this nonsense.

 

  Time can be a good OR a bad thing but, it does not address the argument.

 

> Well, I might actually have found a reasonably priced one and with a little bit of luck, I might have have one by Christmas.

 

  Cool! x86 is rather surprising (to me) for a SBC as ARMv8 and beyond will be all the rage going forward (got a little one here as well :)).. so the emulation route would probably be needed most of the time.

 

> Sorry, but there are enough programming languages around for use with DOS, there is no need to "even more", specially not any of those that have become self-serving solutions that only solve issues that nobody has...

 

  I agree with you here, which is why I've been (jokingly) writing "even" before the "more" ever since I suggested that. But skimming the mailing list I saw some people expressed that want, so my suggestion was a quick way to get them that without any additional work, like I said, C is probably a better target, it also has a bunch of those compilers and lower resistance of course.

 

Cheers,

F.

 


Sent: Monday, November 16, 2020 at 11:47 PM
From: "Ralf Quint" 
To: freedos-devel@lists.sourceforge.net
Subject: Re: [Freedos-devel] New Old Timer reporting :-)


On 11/16/2020 11:26 AM, zz zz wrote:



hello,

 

> Seriously, _javascript_ has rather large memory requirements, so I am not sure that this is overall such a good fit for DOS.

 

 I plan to eventually get freeDos into 2GB RAM machines, at the least (probably 4GB eventually). Should be enough.


DOS is based on 8086 architecture, with 1MB of RAM and at times rather finicky ways to extended this amount for application running on top of DOS.



 

> Also the lack of support of _javascript_ in the existing DOS web browsers (Arachne, Dillo,..) might be another indicator for this.

 

  I wasn't talking about browsers -- nor the web for that matter -- at all. As I've pointed out, you already got a canvas going AND it has file/filesyestem support, with the package of DOjS. All the benefits I've listed, which has been at least discussed here before, stemmed from that simple realization: Higher level development, even more languages support with active maintenance (since it's not DOS specific), even threads (efficient simulated threads in a single process enviroment, which is what Ecmascript was designed for and excels at)


Well, if not in a browser, how do you actually run _javascript_? You need the "engine" for that, and that is part of a browser. And I am not aware of a standalone _javascript_ interpreter, and even if there is, you can't really use it for DOS, as you have kind of a "chicken and egg" problem here...



 

>Beside in general that _javascript_ has morphed into a rather awful behemoth these days...

 

  I'll again recommend reading "_javascript_ the good parts", the fact that it has been put together in a week and managed to morph into the most used behemoth these days -- running at nearly native assembly speed -- is testament to the underlying power at its core, even though you dislike lisp. In fact, one doesn't need to use anything that makes it a behemoth.


Sorry, I am programming for far too long, in a lot of different programming languages, as to be b

Re: [Freedos-devel] New Old Timer reporting :-)

[Ralf Quint]

On 11/19/2020 3:36 AM, Harald Arnesen wrote:

I have no idea if such a thing exists (and that is not my point). You
were not aware of any standalone JS interpreters, I showed you that they
exist - although not for DOS.


That is the whole point, after all we ARE talking (Free)DOS here...

Ralf



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[Harald Arnesen]

Ralf Quint [19.11.2020 01:16]:

> On 11/17/2020 2:25 AM, Harald Arnesen wrote:
>> Ralf Quint [17/11/2020 00.47]:
>>
>>> Well, if not in a browser, how do you actually run Javascript? You need
>>> the "engine" for that, and that is part of a browser. And I am not aware
>>> of a standalone Javascript interpreter, and even if there is, you can't
>>> really use it for DOS, as you have kind of a "chicken and egg" problem
>>> here...
>> 
> 
> Please provide me/us with an example working on (Free)DOS with 1MB of 
> RAM (or less)...

I have no idea if such a thing exists (and that is not my point). You
were not aware of any standalone JS interpreters, I showed you that they
exist - although not for DOS.
-- 
Hilsen Harald


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[Ralf Quint]

On 11/17/2020 2:25 AM, Harald Arnesen wrote:

Ralf Quint [17/11/2020 00.47]:


Well, if not in a browser, how do you actually run Javascript? You need
the "engine" for that, and that is part of a browser. And I am not aware
of a standalone Javascript interpreter, and even if there is, you can't
really use it for DOS, as you have kind of a "chicken and egg" problem
here...




Please provide me/us with an example working on (Free)DOS with 1MB of 
RAM (or less)...


Ralf


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[Harald Arnesen]

Ralf Quint [17/11/2020 00.47]:

>>   I wasn't talking about browsers -- nor the web for that matter -- at
>> all. As I've pointed out, you already got a canvas going AND it has
>> file/filesyestem support, with the package of DOjS. All the benefits
>> I've listed, which has been at least discussed here before, stemmed
>> from that simple realization: Higher level development, even more
>> languages support with active maintenance (since it's not DOS
>> specific), even threads (efficient simulated threads in a single
>> process enviroment, which is what Ecmascript was designed for and
>> excels at)

> Well, if not in a browser, how do you actually run Javascript? You need
> the "engine" for that, and that is part of a browser. And I am not aware
> of a standalone Javascript interpreter, and even if there is, you can't
> really use it for DOS, as you have kind of a "chicken and egg" problem
> here...


-- 
Hilsen Harald


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[Ralf Quint]

On 11/16/2020 11:26 AM, zz zz wrote:

hello,
> Seriously, JavaScript has rather large memory requirements, so I am 
not sure that this is overall such a good fit for DOS.
 I plan to eventually get freeDos into 2GB RAM machines, at the least 
(probably 4GB eventually). Should be enough.
DOS is based on 8086 architecture, with 1MB of RAM and at times rather 
finicky ways to extended this amount for application running on top of DOS.
> Also the lack of support of Javascript in the existing DOS web 
browsers (Arachne, Dillo,..) might be another indicator for this.
  I wasn't talking about browsers -- nor the web for that matter -- at 
all. As I've pointed out, you already got a canvas going AND it has 
file/filesyestem support, with the package of DOjS. All the benefits 
I've listed, which has been at least discussed here before, stemmed 
from that simple realization: Higher level development, even more 
languages support with active maintenance (since it's not DOS 
specific), even threads (efficient simulated threads in a single 
process enviroment, which is what Ecmascript was designed for and 
excels at)
Well, if not in a browser, how do you actually run Javascript? You need 
the "engine" for that, and that is part of a browser. And I am not aware 
of a standalone Javascript interpreter, and even if there is, you can't 
really use it for DOS, as you have kind of a "chicken and egg" problem 
here...
>Beside in general that JavaScript has morphed into a rather awful 
behemoth these days...
  I'll again recommend reading "javascript the good parts", the fact 
that it has been put together in a week and managed to morph into the 
most used behemoth these days -- running at nearly native assembly 
speed -- is testament to the underlying power at its core, even though 
you dislike lisp. In fact, one doesn't need to use anything that makes 
it a behemoth.
Sorry, I am programming for far too long, in a lot of different 
programming languages, as to be buying into this nonsense.
> Not sure if there are really that many x86 SBCs that do support 
UEFI, most certainly do not support a BIOS anymore.
  That's fair. On another thread there is discussion of running a DSL 
or TinyCore (I recommend) and autoboot into a QEMU running FreeDOS. I 
approve :)
Well, I might actually have found a reasonably priced one and with a 
little bit of luck, I might have have one by Christmas.
> To me that just all looks and sounds as just another attempt to make 
some behemoth out of DOS, like a second coming of Linux...
  Amen. :) J/K.. All this would be optional, of course. The context of 
my suggestion was to satisfy the expressed need of (even) more 
languages programmable within FD and, to boot, get current maintenance 
(the term I used was "piggyback", since it's not done with FD in mind 
but the web). But this could be done for other targets, probably C 
would be best.
Sorry, but there are enough programming languages around for use with 
DOS, there is no need to "even more", specially not any of those that 
have become self-serving solutions that only solve issues that nobody has...


Ralf




--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[zz zz]

hello,

 

> Seriously, _javascript_ has rather large memory requirements, so I am not sure that this is overall such a good fit for DOS.

 

 I plan to eventually get freeDos into 2GB RAM machines, at the least (probably 4GB eventually). Should be enough.

 

> Also the lack of support of _javascript_ in the existing DOS web browsers (Arachne, Dillo,..) might be another indicator for this.

 

  I wasn't talking about browsers -- nor the web for that matter -- at all. As I've pointed out, you already got a canvas going AND it has file/filesyestem support, with the package of DOjS. All the benefits I've listed, which has been at least discussed here before, stemmed from that simple realization: Higher level development, even more languages support with active maintenance (since it's not DOS specific), even threads (efficient simulated threads in a single process enviroment, which is what Ecmascript was designed for and excels at)

 

>Beside in general that _javascript_ has morphed into a rather awful behemoth these days...

 

  I'll again recommend reading "_javascript_ the good parts", the fact that it has been put together in a week and managed to morph into the most used behemoth these days -- running at nearly native assembly speed -- is testament to the underlying power at its core, even though you dislike lisp. In fact, one doesn't need to use anything that makes it a behemoth.


 

> Not sure if there are really that many x86 SBCs that do support UEFI, most certainly do not support a BIOS anymore.

 

  That's fair. On another thread there is discussion of running a DSL or TinyCore (I recommend) and autoboot into a QEMU running FreeDOS. I approve :)

 

> To me that just all looks and sounds as just another attempt to make some behemoth out of DOS, like a second coming of Linux...

 

  Amen. :) J/K.. All this would be optional, of course. The context of my suggestion was to satisfy the expressed need of (even) more languages programmable within FD and, to boot, get current maintenance (the term I used was "piggyback", since it's not done with FD in mind but the web). But this could be done for other targets, probably C would be best.

 

> not a gamer on DOS at all, so I skip that

 

  To your horror, some people are doing both! Emulation + _javascript_ .. DOS emulation, just to be ironic, in the browser. Check it out:

 

https://archive.org/details/softwarelibrary_msdos_games

 

> Well, that's in fact so crazy IMHO that I refrain at this point from further comments without my legal counsel present... 😉

 

  Another reply pointed out there is ALREADY something to that effect ;) the documentation says "if simple enough", though it even supports openGL AND DirectX! Indeed amazing.. should be enough for my humble needs.


 


> Not quite sure what you mean by "same hd installation". All you need to boot (Free)DOS is to get a basic kernel and command shell being loaded from a SYS'ed HD.

 

  I mean "same hd" BUT "different partition", which was unclear if it would work, since it was expressely 'forbidden" to do "same drive" installation, which is ambiguous but I managed to do that. Not sure why the installation can't sys the drive without formating it and preserving the copied contents from the CD to use as installation media, SPECIALLY since it's basically just a copy. But at least a "no format" option would have to be added to the Basic installer.

 

> Which is something relatively easy to do on a second system, if that is what you are referring to. Otherwise, there isn't much on "installation" beside copying folders/unzipping archives.

 

  assuming you can RUN sys at all? I don't have a windows machine, mostly linux here. So the 1st DOS installation would be nice to not need a 2nd system for anything besides precisely copying stuff. I did the diskette boot though.

 

Cheers!

F



Sent: Thursday, October 29, 2020 at 2:26 AM
From: "Ralf Quint" 
To: freedos-devel@lists.sourceforge.net
Subject: Re: [Freedos-devel] New Old Timer reporting :-)


On 10/27/2020 3:38 PM, zz zz wrote:


 
  So, here's some ideas: Checking the Dev apps, I see you got a DOS _javascript_ canvas! (you could also add to the description that it can handle files as well, since it's a very interesting feature, see below) This can help solve some of the 'problems'/requests/suggestions I've noticed here, while skimming the mailing list. For example:

 

    -- More programming language support: There have been a lot of effort over the last few years to compile next to every single language to JS. Check out asm.js / WebAssembly (though here is the perfect place to find actual asm programmers that will cringe to the nomenclature :-) those people never had to deal with the intricacies of x86 assem

Re: [Freedos-devel] New Old Timer reporting :-)

[zz zz]

 


hi

 

>Hi Flamengo, welcome :-)

 

Thanks!

> Can you give more details about the Wing game crash?

 

I thought it could be sound/music but disabling it did nothing. (Could still be, if they "disable" it by merely setting volume to zero but still calling the api)

the trigger could be explosion of some special enemy (some new enemy appearing?), the player or passing stage 1 or game over. Didn't play much. DOS screen gets a screen full of hexadecimals and mentions allegro (I think? or was it djgpp)



>As we already have some EMACS and EMACS has a thing with
>LISP, maybe we already have some LISP hidden in EMACS?

 

yes and no, emacs has eLisp (emacs lisp), which is not ideal to say the least. Mostly for making plugins and small editing related tasks.


 

> That would be called either HX RT (run simple Windows apps
in DOS) or REACTOS

 

I was aware of REACT, which wasn't yet ready at the time, but not HX RT. There is an ongoing thread here mentioning modifying the MM to support running windowsES (I thought win 3.1 wouldnt need anything special.. but win95 would be nice to be able to run).

It has my vote of support :)

 

Cheers,

F


Sent: Tuesday, October 27, 2020 at 10:58 PM
From: "Eric Auer" 
To: freedos-devel@lists.sourceforge.net
Subject: Re: [Freedos-devel] New Old Timer reporting :-)


Hi Flamengo, welcome :-)

Can you give more details about the Wing game crash?

As we already have some EMACS and EMACS has a thing with
LISP, maybe we already have some LISP hidden in EMACS?

I vaguely remember some thread topics exist in DOS forums,
but somebody else would have to provide links for you :-)

Regarding UEFI: You normally load a CSM to provide BIOS
interrupts which not only DOS itself but also DOS apps
need. There are some open source CSM, probably with a
somewhat limited hardware support, so you could learn
how this works (probably complex) and see whether you
can set your hardware to UEFI-only boot, use a Linux or
similar boot loader to load an open source CSM and then
load a standard DOS and see whether it actually works...

Regarding UEFI in a different sense: It would be cool to
have GPT support in our kernel. At the moment, only MBR
is supported, which limits DOS to 2 Terabyte disk size.

Regarding the web frameworks and high and low languages
etc. those can get quite complex even to just port, so
I am cautious to say anything about those suggestions.

> ... suggest is including an Amiga emulator... MAME too?

Do you know any for DOS, or any which seem port-friendly?
I guess more emulators at least on ibiblio would not hurt,
but is there an open source Amiga "BIOS" to use with such
an emulator, for example? To avoid license troubles here.
Same for Genesis, SMS, MEKA.

>  -- An even crazier idea: Porting WINE to DOS

That would be called either HX RT (run simple Windows apps
in DOS) or REACTOS (open source Windows clone, shares some
code with Wine for obvious reasons). There even is some DOS
port of DOSBOX which could be useful if the port has sound
drivers for modern hardware and the DOS inside DOSBOX can be
used for games which expect a soundblaster, simulated by it.

No comment on the installer, others know it better than me.

Cheers, Eric



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[zz zz]

Hi

 

>Hi Flamengo - and welcome to FreeDOS!


 

Thanks!

 

> Amiga emulator - Looks like there's a DOS version of an Amiga emulator already. DOSUAE is at http://uae.is.free.fr/

>However, I don't know if there's source code.

 

Yep, no mention there afaik, so I downloaded the zip and apparently there IS source inside, hard to tell if complete but I would assume so. Thanks for this btw.

 

>More generally, we recently started a thread to discuss "simplifying FreeDOS." 

 

hehe, yes, I've found that quite ironic when I went to send my message, as I typed it the day before, and a couple emails about it arrived. No problem, adding to the repo would be nice tho and that thread idea of having some sort of "package manager" to download stuff automatically is really cool.



 


>But some people like to have more control over how they install FreeDOS. For that, you can enter an "Advanced" mode of the setup process. 

 

oh nice, didn't see this anywhere, how does one enter that mode? Also, I'll watch the video you mentioned, should be enough. I was under the impression that you made things a bit more complex than the simple "sys c:" :-) and needed the installer to keep things structured or something. I see now it's basically copy/unzip etc, which is what I liked about DOS :)

 

>But it's not the mode we present by default, because most people will not use it.

 

yep, that's better.

 

> You have some experience in DOS. Are you also a programmer? 

 

a little rusty but, as you may have noticed I was bit by the lisp bug so I'll probably postpone it for the moment, although I really liked the idea someone posted about the game programming enciclopedia and I do have an old tutorial to do it in BASIC, I was curious about.. :)

 

Cheers,

F



Sent: Tuesday, October 27, 2020 at 10:52 PM
From: "Jim Hall" 
To: "Technical discussion and questions for FreeDOS developers." 
Subject: Re: [Freedos-devel] New Old Timer reporting :-)




 

 


On Tue, Oct 27, 2020 at 5:39 PM zz zz <flame...@gmx.com> wrote:




    Hello, everyone. Didn't see anything resembling posting guidelines so just posting here anyway, there are dev ideas below after all.
[..]



 

Hi Flamengo - and welcome to FreeDOS!

 

 

You have some interesting ideas. To respond to a few of them:

 

Amiga emulator - Looks like there's a DOS version of an Amiga emulator already. DOSUAE is at http://uae.is.free.fr/

 

However, I don't know if there's source code. The DOSUAE website is very hard for my eyes to read, but I didn't see a link to the source code. May not be available?

 

More generally, we recently started a thread to discuss "simplifying FreeDOS." As part of that thread, we're discussing removing the emulators from the distribution. They just aren't useful enough to many people.

 

You can find other emulators here: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.2/repos/pkg-html/group-emulator.html

 

 

You also suggested an "Advanced" method to install FreeDOS. My goal with FreeDOS 1.2 and later was to streamline the installation. Most people who install FreeDOS today are running it in a virtual machine of some kind. And these users don't care about fine-tuning their installation. So I wanted to make the installation process really simple - if all you want to do is "install FreeDOS" then it's just a few taps on the Enter key, and you're done.

 

But some people like to have more control over how they install FreeDOS. For that, you can enter an "Advanced" mode of the setup process. But it's not the mode we present by default, because most people will not use it.

 

 

You have some experience in DOS. Are you also a programmer? It would be great to have more folks working on FreeDOS stuff, fixing bugs, and adding features. If you need suggestions for what to work on, click the "How to Contribute" link on the front page: https://www.freedos.org/contribute/

 

 

Jim

 

 


___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[Ralf Quint]

On 10/27/2020 3:38 PM, zz zz wrote:
  So, here's some ideas: Checking the Dev apps, I see you got a DOS 
Javascript canvas! (you could also add to the description that it can 
handle files as well, since it's a very interesting feature, see 
below) This can help solve some of the 'problems'/requests/suggestions 
I've noticed here, while skimming the mailing list. For example:
    -- More programming language support: There have been a lot of 
effort over the last few years to compile next to every single 
language to JS. Check out asm.js / WebAssembly (though here is the 
perfect place to find actual asm programmers that will cringe to the 
nomenclature :-) those people never had to deal with the intricacies 
of x86 assembly! )
  Want FreeDos to support Common Lisp? Throw in some Parenscript, 
possibly with the Emacs modes to compile with the click of a button 
and you're good to go. Similar projects exists for most other languages.
  -- "Threads" : The more I thought about it, the more JS seemed like 
the perfect fit for DOS. It can handle all those heavy loaded web 
servers and yet it is single threaded, rather similar to DOS :-) I 
wonder if node.js could be ported over, perhaps having a dynamic web 
DOS server would improve our relevancy further; Maybe security would 
be a big plus, being single user, single threaded, etc..
I would consider this rather a fallacy! Seriously, JavaScript has rather 
large memory requirements, so I am not sure that this is overall such a 
good fit for DOS. Also the lack of support of Javascript in the existing 
DOS web browsers (Arachne, Dillo,..) might be another indicator for 
this. Beside in general that JavaScript has morphed into a rather awful 
behemoth these days...
  -- UEFI support : Suppose the above is true, now there is much more 
impetus to leverage FreeDOS appeal for embedded systems/application, 
considering all the new SBC's coming out and much more to come due to 
IoT. There would be interest in booting from the newer standard.
Not sure if there are really that many x86 SBCs that do support UEFI, 
most certainly do not support a BIOS anymore.
  -- High Level language for OS development: Check out Douglas 
Crockford's ideas on high level vs low level languages for OS dev, the 
apps above the OS should be programmed with the higher level language 
you could support, that way we can make more and higher quality 
applications. He's the author of "javascript the good parts", which is 
also relevant to this argument. As I mentioned, since DOjS support 
files and other OS calls, it is perfect for this, even as a 
compilation target.
  It may sound like all my ideas are based on JS but this could work 
with anything that already has translation support to something you 
already have. It just happens to have been a lot of effort in that 
front for JS ('cause the webs).. and if we could piggyback on that, 
all the better.
Sorry,  I just don't see this. To me that just all looks and sounds as 
just another attempt to make some behemoth out of DOS, like a second 
coming of Linux...
  -- Another idea I'd like to suggest is including an Amiga emulator, 
to "complete" the emulation support of all 8-bit classics. Perhaps 
some MAME too? FD can be installed on newer machines (with legacy BIOS 
support anyway) so power should not be a concern even for newer games. 
Speaking of "completing emulation", 16-bit consoles are lacking a 
Genesis emulator it seems, I don't think MEKA does it. (though SMS is 
the best of all, in any number of bits, so if you're not going for 
completion, at least scratch everything EXCEPT meka! ;)

not a gamer on DOS at all, so I skip that
 -- An even crazier idea: Porting WINE to DOS o.O` imagine running any 
software from windows one might need that is not yet on DOS! ON DOS! 
Not to mention some people seem to install FreeDos then turn around 
and slap a windows on it, I just find this somewhat distasteful :-D
Well, that's in fact so crazy IMHO that I refrain at this point from 
further comments without my legal counsel present... 😉
-- The installation process: I believe could be improved by having an 
"Advanced" tab where one could check and ideally select the target and 
source drives. One of the reasons I postponed trying FD out was that 
my old box doesn't have a CD drive (and I prefer not to have to burn 
them and have them lying around) and there was some uncertainty/trial 
and error into doing the "same hd" installation, the instructions were 
kinda hidden, I believe in the readme and not widely available (site? 
wiki? don't remember) and the FD installer is quite particular about 
installing itself on the C: drive, active partition, AND first IDE 
port even (in case you have more than one with hds plugged in).. 
perhaps a closer integration with fdisk could ease this process?
Not quite sure what you mean by "same hd installation". All you need to 
boot (Free)DOS is to get a basic kernel and command shell being loaded 
from a SYS'ed HD. W

Re: [Freedos-devel] New Old Timer reporting :-)

[Ralf Quint]

On 10/27/2020 3:52 PM, Jim Hall wrote:


Amiga emulator - Looks like there's a DOS version of an Amiga emulator 
already. DOSUAE is at http://uae.is.free.fr/ 


However, I don't know if there's source code. The DOSUAE website is 
very hard for my eyes to read, but I didn't see a link to the 
source code. May not be available?


Well, DOSUAE seems long abandoned, the last source code I find is from 
1999, to be found at https://www.zophar.net/amiga/uae.html


Ralf




--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[Steve Nickolas]

On Tue, 27 Oct 2020, Eric Auer wrote:

(Several snips)


Regarding UEFI: You normally load a CSM to provide BIOS
interrupts which not only DOS itself but also DOS apps
need. There are some open source CSM, probably with a
somewhat limited hardware support, so you could learn
how this works (probably complex) and see whether you
can set your hardware to UEFI-only boot, use a Linux or
similar boot loader to load an open source CSM and then
load a standard DOS and see whether it actually works...


Is SeaBIOS viable?

I've considered writing a PC emulator for UEFI, but I can't get enough 
access to the keyboard using gnu-efi (I wrote an Apple //e emulator for 
UEFI - and this is the biggest "breaker issue" preventing me from going 
further with it.)



Regarding UEFI in a different sense: It would be cool to
have GPT support in our kernel. At the moment, only MBR
is supported, which limits DOS to 2 Terabyte disk size.


Agreed.


Do you know any for DOS, or any which seem port-friendly?
I guess more emulators at least on ibiblio would not hurt,
but is there an open source Amiga "BIOS" to use with such
an emulator, for example? To avoid license troubles here.
Same for Genesis, SMS, MEKA.


A lot of older 8-bit and 16-bit systems don't need firmwares.  IIRC, the 
Genesis doesn't and I don't think the SMS does - although the systems do 
have boot firmwares used for lockout purposes.


I believe there's a free ROM for the Atari 800 (in Altirra, a 
Windows-based emulator).


-uso.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[Jim Hall]

>
> On Oct 27, 2020, at 6:38 PM, zz zz  wrote:
> [...]
>
> -- The installation process: I believe could be improved by having an
> "Advanced" tab where one could check and ideally select the target and
> source drives. One of the reasons I postponed trying FD out was that my old
> box doesn't have a CD drive (and I prefer not to have to burn them and have
> them lying around) and there was some uncertainty/trial and error into
> doing the "same hd" installation, the instructions were kinda hidden, I
> believe in the readme and not widely available (site? wiki? don't remember)
> and the FD installer is quite particular about installing itself on the C:
> drive, active partition, AND first IDE port even (in case you have more
> than one with hds plugged in).. perhaps a closer integration with fdisk
> could ease this process?
>
>
>

I'll also mention that you can also do a "manual" install, without the
FreeDOS installer. This is helpful for some folks who have hardware setups
that don't play well with the installer - or who want to do a manual
install for other reasons. I did a video about that recently for our
YouTube channel:

https://www.youtube.com/watch?v=krbYBZr2ISw


Jim
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[Jerome Shidel]

> On Oct 27, 2020, at 6:38 PM, zz zz  wrote:
> [...]

> -- The installation process: I believe could be improved by having an 
> "Advanced" tab where one could check and ideally select the target and source 
> drives. One of the reasons I postponed trying FD out was that my old box 
> doesn't have a CD drive (and I prefer not to have to burn them and have them 
> lying around) and there was some uncertainty/trial and error into doing the 
> "same hd" installation, the instructions were kinda hidden, I believe in the 
> readme and not widely available (site? wiki? don't remember) and the FD 
> installer is quite particular about installing itself on the C: drive, active 
> partition, AND first IDE port even (in case you have more than one with hds 
> plugged in).. perhaps a closer integration with fdisk could ease this process?

The Installer already has an advanced mode. That allows installing to different 
drives and many other options not present in the default mode. There are 
several ways to get to advanced mode. 1) quit and launch it using “setup adv” 
2) any time the installer is idle and waiting for user input, press Ctrl+C, a 
windows will prompt to quit, return or switch to/from advanced mode.

With one exception, all of the different install media, actively prevent 
installing to the same drive that the installer is located on.  This is for 
several reasons and probably won’t be changing anytime soon.

The exception is the Floppy Only edition (FD13-x86.zip). You can write its 
images to diskettes and install from those. Or, you can copy all the files 
inside those images to any drive and subdirectory you like. You must preserve 
the directory hierarchy and copy ALL files. But, it can install to a different 
or even the same drive. It contains only BASE packages without sources. 

___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[Jim Hall]

On Tue, Oct 27, 2020 at 5:59 PM Eric Auer  wrote:

>
> Hi Flamengo, welcome :-)
>
> Can you give more details about the Wing game crash?
>
> As we already have some EMACS and EMACS has a thing with
> LISP, maybe we already have some LISP hidden in EMACS?
>
> I vaguely remember some thread topics exist in DOS forums,
> but somebody else would have to provide links for you :-)
> [..]



Answering the Emacs question -

FreeDOS includes Freemacs, which tries to be very similar to GNU Emacs. But
it is a complete reimplementation, not a port of GNU Emacs to DOS. The
extension language in Freemacs is called MINT, which is based on the TRAC
string-based scripting language. (The name "MINT" is a recursive acronym
for "MINT Is Not TRAC.")

DJGPP has a version of GNU Emacs that runs on DOS. You can find it here:
http://www.delorie.com/pub/djgpp/current/v2gnu/


Jim
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[Eric Auer]

Hi Flamengo, welcome :-)

Can you give more details about the Wing game crash?

As we already have some EMACS and EMACS has a thing with
LISP, maybe we already have some LISP hidden in EMACS?

I vaguely remember some thread topics exist in DOS forums,
but somebody else would have to provide links for you :-)

Regarding UEFI: You normally load a CSM to provide BIOS
interrupts which not only DOS itself but also DOS apps
need. There are some open source CSM, probably with a
somewhat limited hardware support, so you could learn
how this works (probably complex) and see whether you
can set your hardware to UEFI-only boot, use a Linux or
similar boot loader to load an open source CSM and then
load a standard DOS and see whether it actually works...

Regarding UEFI in a different sense: It would be cool to
have GPT support in our kernel. At the moment, only MBR
is supported, which limits DOS to 2 Terabyte disk size.

Regarding the web frameworks and high and low languages
etc. those can get quite complex even to just port, so
I am cautious to say anything about those suggestions.

> ... suggest is including an Amiga emulator... MAME too?

Do you know any for DOS, or any which seem port-friendly?
I guess more emulators at least on ibiblio would not hurt,
but is there an open source Amiga "BIOS" to use with such
an emulator, for example? To avoid license troubles here.
Same for Genesis, SMS, MEKA.

>  -- An even crazier idea: Porting WINE to DOS

That would be called either HX RT (run simple Windows apps
in DOS) or REACTOS (open source Windows clone, shares some
code with Wine for obvious reasons). There even is some DOS
port of DOSBOX which could be useful if the port has sound
drivers for modern hardware and the DOS inside DOSBOX can be
used for games which expect a soundblaster, simulated by it.

No comment on the installer, others know it better than me.

Cheers, Eric



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Old Timer reporting :-)

[Jim Hall]

On Tue, Oct 27, 2020 at 5:39 PM zz zz  wrote:

> Hello, everyone. Didn't see anything resembling posting guidelines so
> just posting here anyway, there are dev ideas below after all.
> [..]
>

Hi Flamengo - and welcome to FreeDOS!


You have some interesting ideas. To respond to a few of them:

Amiga emulator - Looks like there's a DOS version of an Amiga emulator
already. DOSUAE is at http://uae.is.free.fr/

However, I don't know if there's source code. The DOSUAE website is very
hard for my eyes to read, but I didn't see a link to the source code. May
not be available?

More generally, we recently started a thread to discuss "simplifying
FreeDOS." As part of that thread, we're discussing removing the emulators
from the distribution. They just aren't useful enough to many people.

You can find other emulators here:
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.2/repos/pkg-html/group-emulator.html


You also suggested an "Advanced" method to install FreeDOS. My goal with
FreeDOS 1.2 and later was to streamline the installation. Most people who
install FreeDOS today are running it in a virtual machine of some kind. And
these users don't care about fine-tuning their installation. So I wanted to
make the installation process really simple - if all you want to do is
"install FreeDOS" then it's just a few taps on the Enter key, and you're
done.

But some people like to have more control over how they install FreeDOS.
For that, you can enter an "Advanced" mode of the setup process. But it's
not the mode we present by default, because most people will not use it.


You have some experience in DOS. Are you also a programmer? It would be
great to have more folks working on FreeDOS stuff, fixing bugs, and adding
features. If you need suggestions for what to work on, click the "How to
Contribute" link on the front page: https://www.freedos.org/contribute/


Jim
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] New Old Timer reporting :-)

[zz zz]

    Hello, everyone. Didn't see anything resembling posting guidelines so just posting here anyway, there are dev ideas below after all.

 

  I grew up with DOS and finally got around to installing FreeDos in my old Pentium I 200Mhz, 48MB RAM which now boots (much!) faster than any of the newest computers I use, at least 1000x more powerful (say 2Ghz, 4GB Ram). Delightful. :) Congrats for the great work.

 

  Managed to get TCP working! In DOS, how awesome is that? And everything up to this point was so quick and easy I was wondering why I've bothered going through LFS (Linux from Scratch) anyway? LOL! Even though I was curious as to whether FreeDOS OTB NIC drivers would work, I preferred to just test the system using the original disk for my card. (and now I'm 2 lazy to test that)

 

 Except for a crash in the game Wing (I followed the tutorial/book, very good!), which appears to be Allegro's fault, everything is going smooth.

 

  So, here's some ideas: Checking the Dev apps, I see you got a DOS _javascript_ canvas! (you could also add to the description that it can handle files as well, since it's a very interesting feature, see below) This can help solve some of the 'problems'/requests/suggestions I've noticed here, while skimming the mailing list. For example:

 

    -- More programming language support: There have been a lot of effort over the last few years to compile next to every single language to JS. Check out asm.js / WebAssembly (though here is the perfect place to find actual asm programmers that will cringe to the nomenclature :-) those people never had to deal with the intricacies of x86 assembly! )

  Want FreeDos to support Common Lisp? Throw in some Parenscript, possibly with the Emacs modes to compile with the click of a button and you're good to go. Similar projects exists for most other languages.

 

  -- "Threads" : The more I thought about it, the more JS seemed like the perfect fit for DOS. It can handle all those heavy loaded web servers and yet it is single threaded, rather similar to DOS :-) I wonder if node.js could be ported over, perhaps having a dynamic web DOS server would improve our relevancy further; Maybe security would be a big plus, being single user, single threaded, etc..

 

  -- UEFI support : Suppose the above is true, now there is much more impetus to leverage FreeDOS appeal for embedded systems/application, considering all the new SBC's coming out and much more to come due to IoT. There would be interest in booting from the newer standard.

 

  -- High Level language for OS development: Check out Douglas Crockford's ideas on high level vs low level languages for OS dev, the apps above the OS should be programmed with the higher level language you could support, that way we can make more and higher quality applications. He's the author of "_javascript_ the good parts", which is also relevant to this argument. As I mentioned, since DOjS support files and other OS calls, it is perfect for this, even as a compilation target.

 

  It may sound like all my ideas are based on JS but this could work with anything that already has translation support to something you already have. It just happens to have been a lot of effort in that front for JS ('cause the webs).. and if we could piggyback on that, all the better.

 

  -- Another idea I'd like to suggest is including an Amiga emulator, to "complete" the emulation support of all 8-bit classics. Perhaps some MAME too? FD can be installed on newer machines (with legacy BIOS support anyway) so power should not be a concern even for newer games. Speaking of "completing emulation", 16-bit consoles are lacking a Genesis emulator it seems, I don't think MEKA does it. (though SMS is the best of all, in any number of bits, so if you're not going for completion, at least scratch everything EXCEPT meka! ;)

 

 -- An even crazier idea: Porting WINE to DOS o.O` imagine running any software from windows one might need that is not yet on DOS! ON DOS! Not to mention some people seem to install FreeDos then turn around and slap a windows on it, I just find this somewhat distasteful :-D

 

-- The installation process: I believe could be improved by having an "Advanced" tab where one could check and ideally select the target and source drives. One of the reasons I postponed trying FD out was that my old box doesn't have a CD drive (and I prefer not to have to burn them and have them lying around) and there was some uncertainty/trial and error into doing the "same hd" installation, the instructions were kinda hidden, I believe in the readme and not widely available (site? wiki? don't remember) and the FD installer is quite particular about installing itself on the C: drive, active partition, AND first IDE port even (in case you have more than one with hds plugged in).. perhaps a closer integration with fdisk could ease this process?

 

  I realize some of these are long term or maybe not desirable/feasible? But hey, one can dre