Writing your own file viewer 

That's very cool! I'm glad that FreeDOS helped get you into programming. As you said, FreeDOS (and any DOS) is a simple operating system, you can see all the moving parts and understand what they do - so it's a great operating system to learn on.

Good point! An easy way to update the program to do that is: if setting color mode doesn't work, set mono mode .. and use a global boolean variable to track 'color' or 'mono' so that the functions that use color can skip the "color" steps if it's supposed to be in mono mode.

You are welcome!

That's why we will need a tutorial for version 1.1. 😊

Yup, this has a few limitations because it was a quick demo. You're right that I should have set the input string to 81, so it would read 80 printable characters plus null. Rolling the cursor to the next line is okay here because the program always sets the correct output line before printing .. and because the prompt is on the last line, that takes care of line 24 rolling the cursor to the next line anyway. I think I mentioned in the video that a more robust way to write this - for example, I suggest one of two ways: 1. Read the input and "fill" an 80-column output line, one line at a time, while converting tabs to spaces. Then you can safely dump the text to the screen using _outtext 2. Read the whole file into memory, while converting tabs to spaces. That would allow you to use pgdn and pgup (or other keys) to jump backwards and forwards in the file. But this requires more memory and will not work for very large files (due to memory limitations). But for "everyday" files, it should be okay.

I might do an Assembly programming video, but I'm not really much of an Assembly programmer. Still, I might do something simple like "writing your first Assembly program" or "writing a PAUSE program in Assembly"

With file handle it is easy to load a text file into the memory.

Glad you liked it!

Thanks - that's exactly why I make these "intro to programming" videos! I want to show how new programmers can create programs like these. It's the first step to making more complicated programs (like a game or application). Once you get the basics, the rest should be easy.

Absolutely! I briefly mentioned something like that in the video .. if you read the whole file into memory, you could convert spaces to tabs, and use pgup and pgdn to navigate the file. Another method to support "forward only" is to read the input and "fill" an output line, one at a time, while converting tabs to spaces. That would minimize memory while working around the _outtext feature that displays literal tabs as circles (CP437).

@@freedosproject I maybe missed the place you mentioned that 🤦‍♂ Thanks once again, looking forward for more great videos like this one

@@ahmad-murery I mentioned it around 24:50 in the video, but it was very brief and didn't go into a lot of detail.

@@freedosproject Thanks for the clarification

@@freedosproject So instead of reading the whole file into memory, can't we just use fseek()

Glad you think so!

I just uploaded the view.c file to my GitHub project of the sample programs: github.com/freedosproject/demo1 The indenting is a little off because I didn't "reindent" the file before uploading, and FED's default 4-spaces makes it look off in GitHub. But this is a straight upload of the source file from my system. (See also cylon.c for last week's demo program.)

@@freedosproject thank you very much

I should have! ☺ In my head, I was going to print a filename in there, which would have been another fputs .. but I didn't need to print anything else, so I should have used on the first line instead.

How small did you want it? Seriously. printf being statically linked will always be bloated, similarly for other functions. (Most C linkers don't really smartlink away unused library code.) You have to use suitable replacements yourself (and not expect -os or even UPX to do everything for you). Check your linker map. Try using _dos_read and _dos_write for less overhead. Also, don't forget that FAT cluster size makes individual file size almost irrelevant. I'm sure you can get more direct help on the freedos-user mailing list.

when i compile a c program on Arch that does nothing at all besides stay in an infinite loop forever, the binary size is 16k

As Rugxulo pointed out, you need to write a program to do some real work - and if you need to use libraries, then that will add to the size. Just adding i/o will include some library code in there. If I write a program that just loops (no real work) it generates a 1.2k EXE program. Here's my "loop" program: int main() { while(1); } That compiles to 1,230 bytes with OpenWatcom: wcl -q -0 -os loop.c (that's a "zero" not a capital "O") Or a "nop" program that does nothing is still 1,230 bytes: int main() { return 0; } wcl -q -0 -os nop.c The same two programs compile (gcc -Os) to about 16k, same as shallex5744 said.

@@freedosproject header only libraries with static inline functions definitions do rule.