What is osdev? Rants from the screenshot thread.

[~]

No offense, but, isn't that kinda not OS development anymore? That is simply user mode application development.

Only a troll could say something like that.

Operating system development is really how programming was meant to be done. Doing things at that level is like being at the highest mountain (or maybe mountain range) possible and have all of the tools you need to see both the rest of the land and the sky with the most powerful telescopes in existence, and telecommunications equipment of all sorts. See how even a comparison ends up using the things that are used in reality.

If you do an OS from scratch all by yourself, then absolutely anything you do for it is OS related because you understand it all. From there you can port your programs simply to DOS, Widows, Linux/BSD, Java, JavaScript/kripken/Emscripten/HTML5 etc... that way of programming, from the actual OS and up, covers the whole extent of software development at the maximum extent of possibilities.

[cheapskate01]

If you do an OS from scratch all by yourself, then absolutely anything you do for it is OS related because you understand it all.

So if Microsoft pushes their web browser, Edge for example, and preinstalls it on windows, then the team that made edge would be OS developers because it was all made by Microsoft?

At a point, you stop working on the OS for a moment, and you start working on the apps for it. Thats just app development.

[heat]

If you do an OS from scratch all by yourself, then absolutely anything you do for it is OS related because you understand it all.

So if Microsoft pushes their web browser, Edge for example, and preinstalls it on windows, then the team that made edge would be OS developers because it was all made by Microsoft?

At a point, you stop working on the OS for a moment, and you start working on the apps for it. Thats just app development.

No, ~ is right, it's OS development. I'd consider Edge as a part of the OS since it's prepackaged and a first-party program. As Wikipedia says:

An operating system (OS) is system software that manages computer hardware and software resources and provides common services for computer programs.

I'd say a web browser is a common enough service to be a part of an OS.

[~]

In the beginning, in the 90's, it actually was OS development. There were fewer developers, all of them excellent. And I suspect that Windows 9x and Internet Explorer were largely done in Assembly. That's why it's a PC-specific OS and so fast compared to today's versions of the same programs. The development enthusiasm and clarity was felt simply by using a program, enthusiasm found only at the OS and old game level of development which is the same. The same developers must have done the whole set of programs original to Microsoft for example. That's why they were so well integrated between them. That was excellent integration, not monopoly, confused as many other technical things like protected mode; now what we have is real monopoly trapping even the newest open source code to unconditional .NET dependence.

Here at OSDev.org OSes are made by single persons or very small teams, so they all know how things work, whatever it is.

And if a program comes from a programmer who is normally an OS developer, and if that programmer uses OS development tricks to create applications, that's OS development too. You are just bringing good things from the highest mountains (OS areas) to other environments so that other people enjoy those products where they are (application level).

Originally programmers were much better in the 70's and 80's. They knew complex creative tricks for optimizations that not even compilers use now with that much efficiency. All of them were officially OS-level developers. Their applications didn't depend on any external facilities, so they really had to know what they were doing, what to do, even if it was a game, it was a masterpiece in all senses.

[~]

Probably you feel that thinking in OS development as being in a mountain is pointing to a place that is too far and isolated. But you can bring water and food there with a constant traffic of helicopters and other cargo planes. At least you can see many things form there than from any other place. But it feels exactly like OS development in its current state, difficult enough, far enough, but reachable and rewarding for different human technologies.

If you wanted to look an OS as a more varied and rich place, you would need to look at forest or other main environments that gives you the whole advantage of that kind of environment so as to understand the rest of similar places. Like a forest where most if not all species get together in the same area.

But then as you see, it would be like joining OS-level and application level in the same place, or looking at the different species of plants and animals in a forest, the ones that you consider important and the ones you really don't know what they are for. In any case you wouldn't want to look only at a part of that environment or mutilate/degrade it if you intend to create activities that can be sustained permanently without losing the system resources you and the other "components" will be needing. You won't want to separate applications from the OS when you are making it.

We simply end up looking at different platforms, or environments. If you don't want a platform, just go to another one, another environment for which you feel better adapted. That will also reward you. Just evaluate how things are if they were seen as different environments/ecosystems instead of ways to put an OS to good use.

[LtG]

If you do an OS from scratch all by yourself, then absolutely anything you do for it is OS related because you understand it all.

So if Microsoft pushes their web browser, Edge for example, and preinstalls it on windows, then the team that made edge would be OS developers because it was all made by Microsoft?

At a point, you stop working on the OS for a moment, and you start working on the apps for it. Thats just app development.

No, ~ is right, it's OS development. I'd consider Edge as a part of the OS since it's prepackaged and a first-party program. As Wikipedia says:

An operating system (OS) is system software that manages computer hardware and software resources and provides common services for computer programs.

I'd say a web browser is a common enough service to be a part of an OS.

I guess you didn't read your own Wikipedia quote carefully enough..

OS provides services to _computer programs_, Edge is a browser, it doesn't provide services to computer programs.

[LtG]

In the beginning, in the 90's, it actually was OS development.

Computing didn't begin in the 90's..

There were fewer developers, all of them excellent.

Seriously? All of them? Hardly, you have (based on other threads as well) an extremely romanticized view of the past.

And I suspect that Windows 9x and Internet Explorer were largely done in Assembly. That's why it's a PC-specific OS and so fast compared to today's versions of the same programs.

What "today's versions"? There aren't any. You're comparing apples to orangutans. Of course old software (that did almost nothing compared to today's software) is faster. Though from practical perspective, using old software on old hardware vs new software on new hardware I'd say it's generally speaking faster these days.

You have to realize that back in the 386 days I wouldn't have had a "real" browser, I wouldn't have 40 browser windows open, each with 10-40 tabs. So modern software is better, A LOT!


Couldn't be bothered with the rest.. sigh..

[zesterer]

And I suspect that Windows 9x and Internet Explorer were largely done in Assembly. That's why it's a PC-specific OS and so fast compared to today's versions of the same programs.

Performance-intensive routines, perhaps. But even back then, compilers were smarter than all but the best human programmers.

Also, this whole argument about "application programming" vs "OS development" is kind of silly. It's just programming. There is no rigid definition of either, and the terms have evolved as the industry has too. What is today considered systems programming would have been considered ordinary application programming only a decade or two ago. Software exists in a hierarchy of greyness, and arguing about arbitrary lines drawn in this greyness isn't really very useful.

A question for you all: You're writing a multi-platform OS. You've written your platform-specific low-level assembly routines that do the heavy work of interacting with hardware. You're now writing platform-independent C for your kernel. Is that still OS development? I mean... you're now only using a low-level API that you've built yourself.

Another question: Does driver module development count as OS development? After all, you're only using the existing kernel's API to interact with hardware.

And a final last question: You're writing a micro-kernel OS. The ramdisk filesystem you're developing sits in user-space and interacts with the kernel only through syscalls. You're not interacting with hardware in any meaningful way. Does this still count as OS development? Or is it now app development?

[mallard]

I suspect that Windows 9x and Internet Explorer were largely done in Assembly.

Windows 9x; yes, significant portions of its "kernel" were written in assembly, as the final evolution of the original Windows (1.0) codebase. Of course, while the original Windows 1.0 codebase was almost entirely assembly and even by Windows 3.x the idea of using compiled languages in the "kernel" was pretty new thinking, Windows 9x did have substantial amounts of kernel/system level code written in C/C++, especially new 32-bit code (much of which was "imported" from Windows NT).

Internet Explorer; no. Early versions of IE were basically a "fork" of NCSA Mosaic (via Spyglass), which was written in C. There's no evidence that Microsoft introduced any assembly code (although they did convert it to C++ pretty much immediately). Considering that IE, at it it's peak as a cross-platform browser in around 1998, ran on multiple operating systems (at least Windows, Mac, Solaris, HP-UX) and multiple CPU architectures (i386-16, i386-32, m68k, PowerPC, Alpha, SPARC, PA-RISC, and probably a few more, not including the extra architectures supported by the Windows CE port), having any significant portion of the code written in assembly would have been highly impractical.

[dseller]

No offense, but, isn't that kinda not OS development anymore? That is simply user mode application development.

Only a troll could say something like that.

<snip>

Whew, never thought I would be the subject of a rant thread.

Anyway, I wasn't stating anything. I am genuinely am curious about where the line between OS and application development is. As you can see from the responses in this thread, multiple people have multiple opinions about it, so it is worthy of discussion.

So no, I am not a troll. And personally I think that what you are doing is very rude.

[Brendan]

Hi,

Anyway, I wasn't stating anything. I am genuinely am curious about where the line between OS and application development is. As you can see from the responses in this thread, multiple people have multiple opinions about it, so it is worthy of discussion.

I'd say OS includes:

• Things that are needed by applications
• Tools/utilities that are needed by end users (to install, configure and maintain the OS)
• Things that are needed by things that are needed (e.g. if applications need a VFS; then VFS needs file systems and they need storage device drivers)

I'd also say that various OS providers misuse the OS as an excuse to force other software (that isn't part of an OS) onto end users (using "bundling"). This includes things like browsers, using Andriod as a way to make people more likely to use Google's services, using OS X as a way to make people more likely to use iTunes, etc.

Note that (in my opinion) this sort of thing is always "evil"; but (sadly) it's only illegal if it's done by a monopoly.


Cheers,

Brendan

[Kazinsal]

Interesting. I think bundling software is okay, as long as you don't lock the platform down or otherwise intentionally harm competition against said bundled software.

eg. my Windows 10 machine has Edge installed, but I'm more than free to (and in fact, do) install Chrome or Firefox or Vivaldi or whatever. It has a mail app, but I use a different one (though to be fair it's Outlook 2016, which is a separate product from the same software company as the OS). It has a video player, but I use a different one (VideoLAN/VLC).

The platform is open and you can freely distribute and install software for it. Because of that I think the OS coming with its own bundled software is fine. There's nothing locking you into that software (though I did notice recently after an in-place upgrade of a debug build my preferred mail client was reset, though it asked me which one I wanted to use so that's not a big deal). Contrast to, say, the Apple platforms, where the mobile phones have historically been incredibly locked down (there was no browser other than Safari for the longest time) and the desktop platform is slowly getting more and more locked down. That's a problem.

[~]

I suspect that Windows 9x and Internet Explorer were largely done in Assembly.

Windows 9x; yes, significant portions of its "kernel" were written in assembly, as the final evolution of the original Windows (1.0) codebase.

Internet Explorer; no. Early versions of IE were basically a "fork" of NCSA Mosaic (via Spyglass), which was written in C. There's no evidence that Microsoft introduced any assembly code (although they did convert it to C++ pretty much immediately).

Apparently the kernel and library optimizations positively impacted the other integrated applications a great deal considering that 9x could run all of that software in a 386DX onwards. It was optimized more than minimal, and integrated into the user kernel more than monopolic at that time (as in a kernel for the system and a kernel for the users, which interact together; that could be the answer of why treat with user applications and not just kernels here).

I wonder why don't programmers define functions like extensions to the instruction set and then implement everything by hand-optimized assembly for each platform. They would end up with very durable code. They would only need the full x86 implementation as a reference to derive assembly code for any other architecture if they define routines as instructions for the "machine" of a given task category. If they define so many "instructions", there would be a point where they would have so many clean assembly routines that it would be easy and portable to write the rest of the application in assembly, in low and high levels of the application.

With so many developers, it's possible, and it could only be a part of the team the one who did the generic instructions as the rest of the application would be trivial if it only uses them.

[Brendan]

Hi,

I wonder why don't programmers define functions like extensions to the instruction set and then implement everything by hand-optimized assembly for each platform. They would end up with very durable code.

They would end up spending a massive amount of extra time to create software that is less durable, less flexible and has worse performance.

To understand this you need to understand basic/common optimisations (like constant folding, function inlining, etc) that will be prevented by your approach.

For a simple example, imagine this code:

Code: Select all

uint32_t foo(uint32_t x, uint32_t y) {
    return (x + 1) * (y + 1);
}

uint32_t bar(uint32_t x) {
    return foo(x*4, 9);
}

If you wrote these functions as separate pieces of assembly; it's unlikely (excluding differences in calling conventions - what is/isn't preserved where) that you're going to get anything better than this:

Code: Select all

foo:
    push ebx
    push edx
    lea eax,[eax+1]
    lea ebx,[ebx+1]
    mul ebx
    pop edx
    pop ebx
    ret

bar:
    push ebx
    shl eax,2
    mov ebx,9
    call foo
    pop ebx
    ret

However, a compiler can inline the functions to get something like this:

Code: Select all

uint32_t bar(uint32_t x) {
    uint32_t y = 9;
    x *= 4;
    return (x + 1) * (y + 1);
}

And then it can do constant folding to get something like this:

Code: Select all

uint32_t bar(int x) {
    return x * 40 + 10;
}

And then convert it to something like this:

Code: Select all

bar:
    lea eax,[eax*4+eax]     ;eax = x * 4 + x = x * 5
    lea eax,[eax*8+10]      ;eax = (x * 5) * 8 + 10 = x * 40 + 10
    ret

For this example it's already obvious that the "hand written functions in assembly" approach is extremely bad for performance (and takes longer to write for one CPU, and takes significantly longer to write for many CPUs).


Cheers,

Brendan

[~]

I just feel that if a team out of all of those out there wanted to know how to implement things at the level of CPU technology, it would be worthwhile.

It just seems to me that if a team was to create a massive amount of hand-made assembly routines with a style that resembled the usage of other instructions, maybe even using opcode-like byte structure for the parameters, those routines could be very durable, as much as the rest of native instructions, taking their logic to concise, minimal, optimized bits per routine.

They would just need to be routinely optimized as much as the instructions themselves. But if there is a part of the team that only works at the low level optimizations also with the intention to gain CPU-implementing technology (for hardware projects of theirs), then the high-level team would simply make the rest of the program, and if they know that something is too slow, they could easily direct hand-optimized assembly only to the most critical parts of the program, not necessarily to everything, and it could become more understandable just because of being in the context of something that urges optimization.

It seems to me that if it was possible to design an optimizing CPU, then it's possible for a good team to create optimized code where it's really needed. Not many things truly require brutal optimization, only the most specialized algorithms. The rest can be gradually improved over time. It could be an interesting platform to re-explore.

At least x86 assembly has been proven to be able to have portable code for 16, 32 and 64-bit as much as if it was C, so the possibility is there.

And with the current bulk of software it would probably be beneficial to do this at least for making the machine execute a considerably shorter stream of code.

A compiler could be used to help them improve individual functions implementing additional software CPU instructions. Then they could document the optimizations back to assembly code. It could take as much as making a good emulator, but then the functions would be so clean that they could be reused as real instructions in other programs that use that same logic.

Probably the code that the compiler optimizes the most is the less optimal from the instructions point of view. So if there's code that cannot be reduced anymore, then it's optimal, it only needs to actually make sense for a program because the compiler could probably produce highly optimized code even for sources that make no sense at all.

By the way, for the assembly example it would probably be better not to use RET as a function, but just use those two instructions as normal code for a little more optimization. That and many other interesting code abbreviations are what I mean when I say that hand-optimized code would in the end always win over a compiler.

That's the sort of things that still make me wonder how programmers were so good to implement super-optimized games for the Atari 2600 like the 3D Tic-Tac-Toe. Nowadays, with all of the supercomputers (that's what they really are), optimizing compilers, high-level languages, nobody on the Internet has been able to reimplement another 3D Tic Tac Toe that is so hard to defeat as the original Atari 2600 game and in so little space, a perfect example of true optimization of the actual logic and its correctness and efficiency in less than 2 Kilobytes of 6507 and peripherals code. If it was done before, now it can more easily.

http://www.virtualatari.org/soft.php?soft=3D_TicTacToe

http://archive.org/download/3-D_Tic-Tac ... _Atari.pdf