Kazinsal wrote:No one in their right mind cares about DOS linkers and executables anymore. That technology is so old and obsolete Microsoft decided it wasn't worth supporting going forward on modern architectures eleven years ago.
I don't understand your obsession with trying to revive such ancient and dead technology. It was supplanted for a reason, and that reason is because it sucked like explosive decompression.
Even 64-bit Linux is capable of running Win16 and giving the impression that they are native. What's good about DOS is that if somebody writes a driver and if it runs in DOS, it will be tiny, easy to understand, the device will be well implemented and well oriented to final applications while keeping the intended power it should offer, and would run well in bigger OSes, and the same for existing applications, even the more modern web browser under DOS. A program can expand itself to 32 or 64-bit and with its own functions without having to get through Windows or Linux or having them monopolize the whole machine (bad for a machine intended for very heavy development at all levels where you need to switch from low to high-level development without delays to be efficient).
If Windows/Linux at least allowed to run the whole user space and programs in Ring 0, at least for a special user, it would become as easy to use and flexible as DOS: We could use a few library functions to initialize something totally or partially, and we could perform the rest of the execution on the raw hardware and our own functions, avoiding having to learn libraries for something we could do with our own knowledge and resources.
iansjack wrote:~ wrote:If the C language can be portable with all of its confusing syntax and nested expressions, then Assembly can perfectly be done.
The truth is that you are not talking about making assembler portable (an obviously impossible task because of the fundamental differences between different processors), but in creating a layer on top of assembler; a higher-level language. You are many years too late in doing this; languages such as BCPL and C were created many years ago and serve exactly the purpose that you are looking at. And the truth is that well written C libraries are likely to be far more efficient, and perform better, than an assembler programmer can manage (unless they are an extremely good assembler programmer). You can take it that, after many years of development, there are efficient libraries available.
You are trying to reinvent the wheel. Unfortunately, your concept of the wheel is a square one rather than the well rounded examples that already exist. By all means go and develop your ideas; but I think that they, and your rather quaint ideas about DOS, have little place in these forums - perhaps stick to the "General Programming" category if you really must, but they are only an unnecessary distraction in the forums aimed at operating system development.
It's not impossible. Think about porting an application that has been properly encapsulated and defined, which is intended to write on the screen, or functions to perform arithmetic operations for a calculator. If you think about how to compile x86 assembly to other native executable code, you will find that it's basically the same as compiling C, and we aren't using anything exotic, just clean x86 assembly well-defined to be cross-platform. If for example we are masters in using SSE and we want to use it in other architecture, it would be very useful if we already wrote an x86 application.
If it wasn't possible to compile one assembler into a different object code, then it wouldn't be possible to use PCI, accelerated 3D graphics cards, IEEE-754-compliant FPUs or USB in architectures other than x86 PCs either.
About DOS, I know that many companies have tried to simply erase it due to the fact that everything that is written for it is so tiny that it's very easy to disassemble and port to other architectures and OSes, specially drivers. But technically it's the second stage of the BIOS. It's just a shell for the BIOS that can take us, for example, to a portable LILO or GRUB, which doesn't require actually altering any installed hard disk, or start another OS from a subdirectory. We can either use DOS functions or implement our own (why not implement DOS-like services for 64-bit?).
As I said, given the current impossibility to run everything purely in Ring 0 under the current major OSes, it's good to learn what is in DOS.
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
Just think about the fact that if we turn the WinAPI, the Linux kernel components and other OSes' components into mere libraries to link applications against, and whether we run programs booting them directly or launched from DOS, and if we add programs like Firefox and a layer to load Win9x/XP/Win7/Linux drivers while any program loads, under DOS, then it would no longer look like DOS, but like a custom machine with a custom system which we can learn, run and configure as we like,
without having to use any particular OS at all, but DOS with SATA and other modern drivers, and maybe ported to pure 32 and 64-bit layers running in Ring 0, as well as the BIOS (BIOS32, BIOS64) is a good minimum, in practice more reasonable than booting every user program in place of an OS (although that's also a good test to know how little BIOS/OS services and libraries it needs to exist and run in memory all by itself).
If there are people from the 80's and 90's who can better understand how to achieve it (running everything with a minimum base as FreeDOS but without a particular OS to run programs), than with other OSes (used by uninteresting home and office tasks), then that's the best choice for them. It has good things to offer like simplifying code and expressing it in considerably lesser instructions; there are things to do and things to offer like happens with people from other OSes, UNIX or not.
In fact, remember how many old games were designed to run without OS at all (maybe they didn't want to pay for OS licenses to keep profits if any, and the profit of keeping an excellent concise programming level), and today they are still able to run directly as boot code, and use the minimum imaginable resources (like these 8086/8088 games and demos: Zaxxon, PacMan, JansFlame fire effect, 2DROT/3DROT... try to set up and boot old programs without OS... they all can run without OS and almost using no BIOS services).
That's the idea with DOS: Tilting to raw hardware or to existing OSes turned into libraries for any and every other OS so we can use whatever we want, not just traditionally-packed OS software.
