I worked hard on that retro feel! I also worked on portability and making it work on just about any system it has been on. The original MS-DOS edlin was written in 8086 assembler, and it seemed easy enough to rewrite in C and make it portable. But I didn't use any of Dan Peterson's code.
Having a portable version is in most cases a very good thing. But in this case it would have been better to write the program in assembler and to keep the memory requirement as small as possible. Because the first IBM PC was available in versions with only 16 KiB RAM. EDLIN from FreeDOS 1.3 already requires 32252 bytes on the storage medium, while EDLIN from MS-DOS 6.2 has a program size of only 12674 bytes and is even smaller in older MS-DOS versions. So while MS-DOS EDLIN will still run on the first IBM PC with only 16KiB, FreeDOS's EDLIN will not. And then you still need some storage space for the actual text you want to write with it. With new computers, of course, none of this matters, but the question is whether you want a free MS-DOS-compatible OS whose core components will still run on the first IBM PC with the smallest memory configuration. Fortunately, the first IBM PC can be upgraded to 256 KiB RAM.
@@gpietsch I know, that's what i said. No, thanks, i never used Edlin in DOS times. I would probably use Editor from DR-DOS for this job. Well, you need specific memory ICs and several of them to upgrade an IBM PC to a maximum memory expansion of 256 KiB. So you can't use just any memory ICs.
@@OpenGL4ever It doesn't need to be written in assembly to be tiny, it just needs to not be bloated and for 16-bit systems there's a lot of fat that needs trimming here. Although, I'd still rather see a simple vim clone.
@@anon_y_mousse The problem with this is that high-level language compilers don't do well with the segmented programming that is required when writing a real-mode program. And that is unfortunately still the case today, because the compilers only highly optimize from the 32-bit time in order to write fast or space-saving 32-bit code, but this does not cover segmented 16-bit code. Yes, you can choose 16 bit real mode as the target, but it will take up a lot of memory compared to a program written in assembler manually. In the 32-bit world, of course, things look different.
Doing my research recently on Digital Research, Gary Kildall and of course, Tim Paterson, Tim was quoted as saying that he was "horrified" that IBM chose to ship his quick and dirty text editor, Edlin, which he had made out of necessity to get a few hacks done. He did not expect it to be the default text editor for DOS until DOS5. I don't blame him for that! Working with Edlin, or Unix ed was a painful task to say the least!
@@OpenGL4ever indeed - Edlin was lifted from CP/M but it was a poor hack job that Paterson wrote in a couple of days to get the job done. Even he was not happy with it.
I worked hard on that retro feel! I also worked on portability and making it work on just about any system it has been on. The original MS-DOS edlin was written in 8086 assembler, and it seemed easy enough to rewrite in C and make it portable. But I didn't use any of Dan Peterson's code.
Having a portable version is in most cases a very good thing. But in this case it would have been better to write the program in assembler and to keep the memory requirement as small as possible. Because the first IBM PC was available in versions with only 16 KiB RAM.
EDLIN from FreeDOS 1.3 already requires 32252 bytes on the storage medium, while EDLIN from MS-DOS 6.2 has a program size of only 12674 bytes and is even smaller in older MS-DOS versions. So while MS-DOS EDLIN will still run on the first IBM PC with only 16KiB, FreeDOS's EDLIN will not.
And then you still need some storage space for the actual text you want to write with it.
With new computers, of course, none of this matters, but the question is whether you want a free MS-DOS-compatible OS whose core components will still run on the first IBM PC with the smallest memory configuration. Fortunately, the first IBM PC can be upgraded to 256 KiB RAM.
@@OpenGL4ever Then it wouldn't be portable. If you want to rewrite Edlin in assembler, do so. And memory's cheap now, so it's not a priority.
@@gpietsch I know, that's what i said.
No, thanks, i never used Edlin in DOS times. I would probably use Editor from DR-DOS for this job.
Well, you need specific memory ICs and several of them to upgrade an IBM PC to a maximum memory expansion of 256 KiB. So you can't use just any memory ICs.
@@OpenGL4ever It doesn't need to be written in assembly to be tiny, it just needs to not be bloated and for 16-bit systems there's a lot of fat that needs trimming here. Although, I'd still rather see a simple vim clone.
@@anon_y_mousse The problem with this is that high-level language compilers don't do well with the segmented programming that is required when writing a real-mode program.
And that is unfortunately still the case today, because the compilers only highly optimize from the 32-bit time in order to write fast or space-saving 32-bit code, but this does not cover segmented 16-bit code.
Yes, you can choose 16 bit real mode as the target, but it will take up a lot of memory compared to a program written in assembler manually.
In the 32-bit world, of course, things look different.
Doing my research recently on Digital Research, Gary Kildall and of course, Tim Paterson, Tim was quoted as saying that he was "horrified" that IBM chose to ship his quick and dirty text editor, Edlin, which he had made out of necessity to get a few hacks done. He did not expect it to be the default text editor for DOS until DOS5. I don't blame him for that! Working with Edlin, or Unix ed was a painful task to say the least!
Gary Kildall's DR-DOS had a much easier to use editor than EDLIN and was called just EDITOR.
@@OpenGL4ever indeed - Edlin was lifted from CP/M but it was a poor hack job that Paterson wrote in a couple of days to get the job done. Even he was not happy with it.
This is so cool. Great video, and amazing work!
Do you have any tips on recursive directory walking for file searching? Maybe a video idea if not? I seem to be really stuck on this one.
You can look at the code for TREE to see how to recurse across directories. In fact, TREE/F will also display filenames in each directory.
is there a word processor that support arabic in freedos?
I recall that WordPerfect had some support for this, but obviously I haven't tried it. Search for "arabic wordperfect dos" and you should find it.
@@freedosproject I'v tried it before. its just a windows app that emulates the dos aesthetics. its alright but not for me.
Back To the Old Days i use WordPerfect for Arabic
@@htechprogrammer really? I'd love to get my hands on it and use it in DosBox
@@scupd You need DOS wordperfect.
👍