Brendan wrote:
Hi,
Combuster wrote:
There's no teachings without practice
I personally favor a DOS environment and writing .com files (I learnt in win9x, but dosbox should work too)
I did my fair share of DOS *.com files too, but DOS programs don't play nicely with modern OSs - the last OS that supported DOS programs directly was "Windows Me" (almost a decade old now), and if you're going to mess about running DOS (or FreeDOS) in an emulator (including the dodgy/minimal DOS emulator built into Windows XP) then it's much more tempting to forget DOS and go the "bare metal" route.
That's why I always say that it's illogical for somebody to think about advancing in an OS without having spare machines (they don't have to be old, they can be newly acquired for that specific purpose). I see that it's necessary to be able and having permission to remove the casing and disassemble that testbed machine as much as needed, and try several different peripherals and configurations.
You are of course right about the incompatibility with DOS/WinXP+. But there are things you can do with it if you put it in a bootable media. You can make a lot of snippets to inspect the most microscopic bits of hardware behavior without rebooting or having to make 1001 unusable kernels, but just make a small COM file that does nothing more than watching a single thing until really understanding it. Then when that little piece is working, debugged and watched carefuly to see if everything is OK in RAM even if it works OK (i.e., all code could be reading and writing structures at the same place but with the problem that that wasn't the intended place), it should be integrated in the kernel.
You can even make a set of miniprograms to "talk" about something with the machine and it shows you the results step by step, and so you can see what's really going on without re-writing code but only using different combinations of the different parts of an algorithm, all of them communicating through the state of variables at some high memory area that stays even when each of them terminates their 4 or 5-line task (maybe using Unreal Mode/A20 with care).
It's frustrating for anyone building a system several times from scratch, when a BIOS-like operating system like DOS could used as a testbed for the single "gears", instead of having to debug a new feature in a huge program.
Brendan wrote:
Let me put it this way - how long has it been since you've written a DOS program? For me, I wrote a simple 3D renderer (solid polygons without textures drawn onto a "320 * 200 * 256 colour" video mode; mostly as an excuse to get practice with FPU instructions) about 9 years ago.
I'm always in need of writing snippets under it. I DO NOT use DOS interrupts other than INT 21h and INT 20h. I made a very simple "file cutter" program 5 years ago in Turbo C++ 1.0 to split a file in several equally-sized pieces. It had an extremely basic graphical interface and a mouse pointer to click the icons, which could not move or react but were an actions menu to clicks. It was interesting using BGI graphics drivers and using registers through regs.x.ax, etc., which eventually brought more curiosity about assembly language.
Brendan wrote:
Now that DOS (and DOS programs) are virtually dead; I'd actually be tempted to say that (especially for people interested in OS development) writing your own boot code (and testing/debugging in something like Bochs) is one of the best ways to learn assembly language. I know this is exactly what I'd do if I had to learn assembly language in 2009 (and it's what I will do if/when I want to learn assembly language for a different CPU).
Yes, but I also see that it's necessary to have Bochs for being able to easily inspect memory and other things, and once everything seems right and in the correct place in RAM, then it's time to test it in several real machines to see if it really keeps working well across "standard" hardware built by different manufacturers.
I don't think DOS is dead for the low level x86 developers, if they wish to use it. You can use BIOS INT 19h if you want to warm-reboot the computer without going to POST again from DOS and cause the boot process (booting from a device) to start.
Brendan wrote:
Of course I'd also recommend learning a high level language first, but a lot of beginners have already done that and are ready for the next step.
Very true also, but for that who is curious, there should always be people around to encourage to learn more and more about hardware and assembly, even if those people don't personally know about those topics. Otherwise the person who is willing to learn might never actually take it into real consideration and forget it in some time.
Login
Register
FAQ
Search
