OSDev.org

srg wrote: Windows NT/2000/XP are not based on DOS.

srg

they're not directly based upon it, they're only 99.99% compatible with it. Sounds an awful lot like basing it upon them.

PS: why does winxp format disks with the format string "MSDOS5.0"?

windows NT and family (2000/XP/2003) are not directly based on DOS or windows 95/98[me=proxy]family. NT stands for "New Technology" and that it is. It was a ground up rewrite of all the major portions of the code.[/me]

Windows NT unlike 95 and family implements true address space which are protected from each other (unlike 95 and family which can trample all over each other).

There are many other major architetual differnces but i forget at the moment.

Of course they are gonna reuse good code when they can, so it's not ALL written from scratch, but everything that's important to the basic architecture is pretty different under the hood.

the compatibilty is somthing that was done intentionally, when you have access to the original DOS/95/98[me=proxy]code it's pretty easy to port these thigns to your new product.[/me]

keep in mind the older versions of NT (3.x/4.x) dont have the greatest compatibility with DOS/Windows 95/98/ME...compatibility with these has been worked on over time. In my mind 2000 was the first version which was usable on the deskop as it introduced massively imnprioved compatibility over 4.0 (particularly with directx related apps)

proxy

All DOS compatibility is with the NTVDM, which is AFAIK a v86 monitor. Internally, Windows NT/2000/XP have *nothing* to do with DOS.

srg

srg wrote: All DOS compatibility is with the NTVDM, which is AFAIK a v86 monitor. Internally, Windows NT/2000/XP have *nothing* to do with DOS.

srg

I still retain my claim that the code in the ntvdm is partly or mostly DOS code.

And after you've installed it, so is DOSEMU on a Linux Box.

srg

Candy wrote: - Educate your users before allowing them to use the system. Even though it's very hard to push through, educating users (or at least allowing them to be educated without spending another load of cash) will increase the usability of your system, without people installing all sorts of weird software that only claims to protect you (consider the amount of people that install virus scanners, firewalls, privacy tools etc. only to think that they automatically are used and updated..).

While I generally can't fault anyone for recommending more education, in this case I find it misplaced. The current systems are so bad that users are already forced too much about them - far more than they need to about, say, their cars - just to use them on the most basic level. 'Computer literacy' is often just a code phrase for 'forcing them to do it a certain way', and in practice is an excuse for rotten system design.

- Do not publish your system unless you test it thoroughly. Disable compiling of programs using buggy functions (yes, you too posix/iso!) such as strcpy and strcat.

I can't disagree with this part.

Encourage use of a type-safe language (Java, VB).

Type-safety, in the usual sense of static typing, is considerably overrated as a debugging tool, and often requires decidely unsafe workarounds to accomplish certain goals. I would consider languages like Scheme, Smalltalk, or Python - all of which are dynamically typed, type being a property of the actual objects rather than the variables they are bound to - to be more secure than either VB or Java, for example.

Note that Smalltalk is type-safe in the sense of only allowing operations on objects that are specified in the class definition, even for polymorphic objects. Methods are bound to the objects at runtime, and only methods which are part of the object's actual class will run.

If not possible, encourage use of a language that allows a programmer to shield himself once after which s/he is permanently shielded (C++).

- Design your system according to a new design. Both the old traditional designs are provably bad (Windows because of the API, Linux because it still supports the same flaws that are in the stdlib for over 30 years now). Consider the implications any of your choices might have on any other function or use. Do not consider your OS designed when you've thought about it for 3 weeks or something similar. Your design isn't tested until you've tested your implementation and found it to be good.

The obvious counter-argument to that is that old designs are stable ones, and their strengths and weaknesses are well-known. A truly new OS design would have to be tested and analyzed from scratch. The weaknesses of this argument should be obvious, however: while the designs are old, the major implementations are all relatively young, and are undergoing constant modification.

- Design your OS on a good basis. Do not use a filesystem such as FAT or an operating base of BIOS functions, if only because they are very buggy, and you cannot be sure that it actually works correctly. Use only code that you can debug. Things you cannot debug can only cause you trouble.

Again, I have to agree wholeheartedly with this.

- You do want your OS to be widespread and available, but not as the "main" OS. Just keep normal competition levels (as soon as they're restored in this market segment) so all OSes get an equal share of users.

Actually, the pattern of a market dominated by one system, with a handful of less common ones, is one which reccurs in the computer field on all levels (i.e., almost all word-processing is with MS Word; nearly all C programming is done using either VC++ or gcc), and seems to be endemic to the market. It even appears among open-source users (how much of a market share do NetBSD and SkyOS have?). As ESR and others have said, market domination by Microsoft (and before them, IBM) is a symptom of the problem, not the problem itself.

Schol-R-LEA wrote: While I generally can't fault anyone for recommending more education, in this case I find it misplaced. The current systems are so bad that users are already forced too much about them - far more than they need to about, say, their cars - just to use them on the most basic level. 'Computer literacy' is often just a code phrase for 'forcing them to do it a certain way', and in practice is an excuse for rotten system design.

Can only agree with that. Still, if users want to use a new system they're going to have to be told about the way to use it without being so incredibly unsafe. They're now used to windows, so there's a good chance they'll expect delete (and rm) to use a trash can. Ouch.

Type-safety, in the usual sense of static typing, is considerably overrated as a debugging tool, and often requires decidely unsafe workarounds to accomplish certain goals. I would consider languages like Scheme, Smalltalk, or Python - all of which are dynamically typed, type being a property of the actual objects rather than the variables they are bound to - to be more secure than either VB or Java, for example.

Note that Smalltalk is type-safe in the sense of only allowing operations on objects that are specified in the class definition, even for polymorphic objects. Methods are bound to the objects at runtime, and only methods which are part of the object's actual class will run.

I see what your point is. With the type-safe I was kind of referring to buffer overflows because array sizes are not enforced, overflows in other variables where java & vb break their neck over the overflow etc. They might make the language slower but they also make it more stable.

The obvious counter-argument to that is that old designs are stable ones, and their strengths and weaknesses are well-known. A truly new OS design would have to be tested and analyzed from scratch. The weaknesses of this argument should be obvious, however: while the designs are old, the major implementations are all relatively young, and are undergoing constant modification.

I'm not saying you should forget it, but the idea is that it's already a bad design. Improving on a bad design is not going to make it a good design. The thing I was trying to convey is that you should not use those things verbatim, but use them heavily modified or if you can/dare, take what's wrong in there and think of structural improvements in the way of thinking.

Actually, the pattern of a market dominated by one system, with a handful of less common ones, is one which reccurs in the computer field on all levels (i.e., almost all word-processing is with MS Word; nearly all C programming is done using either VC++ or gcc), and seems to be endemic to the market. It even appears among open-source users (how much of a market share do NetBSD and SkyOS have?). As ESR and others have said, market domination by Microsoft (and before them, IBM) is a symptom of the problem, not the problem itself.

The market dominance is only because the applications are not as compatible as they should be. Someone using one application cannot switch to another without:

- getting used
- changing all old documents
- learning new quirks
- establishing compatibility with other applications of the same type

These things usually withhold other people from switching. The problem is that unless the last point is tackled, the users won't switch. The last point will thus be greatly upheld by whoever is in the market, blocking out all competition (think Microsoft being forced to release compatibility functions....).

PS: fix your post, the board nearly breaks on it

I think I'll comment on the latests comments a bit.

About types: there is two things that people relate with type-safety. One is static vs. dynamic, and another is weak vs. strong.

Static typing means that variables have types, and they are enforced on compile-time. Dynamic typing means that values (objects) have types, and they are enforced at runtime. C and C++, and Java would be well known examples of static typing, while Python, TCL and Lisp would be examples of dynamic typing. In statically typed object-oriented languages you can usually cheat a little by casting to a supertype. If you can also cast back to a subtype, then you have a form of dynamic typing.

In any case, weak vs. strong typing is another question. Strong typing means that an object of one type can never be interpreted as an object of another type, unless converted first. So since you can take an integer in C and use it as a pointer, C is weakly typed. Similarly you can freely cast between object types in C++. Java on the other hand is strongly typed, as it throws an InvalidCastException if an invalid cast is attempted.

Similarly, if you try to add to strings together in most Lisp dialects, you get a runtime error, so Lisp is definitely strongly typed even if you never actually need to specify the types (although usually you can if you want to help the compiler generate better code).

An example of dynamically and weakly typed language might be TCL, where everything is internally a string, so if you try to add two strings together and they happen to parse to numbers, then you get normal numeric addition.

So any strongly typed language, whether statically or dynamically typed, is type-safe in the sense that types can be never mis-interpreted (by definition of strong typing) and hence objects can only ever be accessed as intended. One could futher claim that such a language is "safe" as well, since strongly typing necessarily forbids direct memory access, at least to areas which hold typed objects.

Now, if we get to the security thingie, we find that most current security problems are related to typing problems. The reason stack-overflows happen, is because C does not enforce proper typing for arrays. An array type in C is really nothing more than a base-pointer and an index-increment size. "int x[]" says: let there be a pointer to some part of process address-space, with sizeof(int) used to scale the index.

Ok, what about SQL injection? We have a query in the form of string "SELECT * FROM atable WHERE astring = ?;" and since the query is simply a string, the programmer is required to enforce that any value inserted in place of the question-mark is actually something that parses to a proper string in the database. The problem here isn't type-safety of the language, but simply that type-safety isn't enforced between the language and the database. In some sense at least...

Various forms of priviledge escalation are also related: say that good old WM_TIMER trick in Windows happens, because the system doesn't enforce the function-pointer given as a callback to actually point to a function. Instead, it can point to anywhere, including a message box.

I don't know VBA macro viruses well enough, nor am I familiar with the problems of Outlook (honestly, I've paid little attention since I don't use Windows), but one COULD claim that the problem is still type-related: in most Outlook problems a document is expected, while the type is later found to be an executable, which is then run, since the to operations (of opening a document and running a program) happen to be "overloaded".

In the Word case the issue is a bit more tricky, but in a sense a script in a foreign document should be limited to the domain of the document itself.

My hypothesis is that given a fully strongly typed computer system, most security problems simply cannot exist. My other hypothesis is that such a typing-system would necessarily be (at least somewhat) dynamic to remain strong when new code is added to a system dynamically.

Now, what my POINT is, I do not really have a clue..