WinNT is a derivative of VMS if you look at the kernel internals:
* Packet-driven I/O subsystem
* Delayed Procedure Calls
* Asynchronous Procedure Calls
* The security model at the lowest level
* The object manager (although it was somewhat non-formal in VMS)
I mean, if you've ever programmed both systems at the kernel level you would be pretty shocked how similar they are. I mean, WNT feels like a more modern VMS with some things new and some things removed (sadly, like the amazing VMS cluster support).
The kernel of NT really is very VMS-like. Its not a bad kernel at all, either. Just because the crap M$ piles on top of it is utter shit doesn't mean that the underlaying kernel isn't of very high quality.
Actually, I remember from my Bar-Mitzvah that I had to sing my parshah. Although I know how to read Hebrew I didn't know how to read the musical notes which most Torahs carry.
For those unfamiliar with semitic languages such as Hebrew, the vowels are somewhat optional and are not part of the normal string of consonants. Instead, they are little marks made in various locations around the consonants. For example, a dot to the left of a character in the middle is an "ewwww" sound. Move the dot to the top of the letter and its an "oh" sound.
In addition to these vowels are various musical notes which tell you how to sing that particular passage (as a canter would). If I understand the history correctly the vowels and musical notes are not part of the "characters" (consontnats) of the Torah.
Perhaps minor variations in the musical notes could be used to signify the Torah -- or would that invalidate it. I guess one other important thing to mention is that there is some built-in redundancy in the vowels and (if I remember correctly, it was almost 20 years ago) in the musical notes. For example, a bar under a letter is an "ah" sound but so is a T-shape under a letter (althoug there may be a subtle difference in pronounciation that I'm not aware of).
A bit like a stream of data can be encoded in the less-significant bits of an image.
Disclaimer: I wrote a mostly PC compatible BIOS for an embedded device.
Knowing quite a bit about what goes into a BIOS, why does having an open source BIOS matter? Aside from the technical issues, the BIOS in a standard PC isn't really used much beyond the booting of the machine. Things like ACPI and PnP are pretty well understood now in the open source world, but that is, in reality, a very small portion of the kind of code you find in a BIOS.
Just what kind of code do you find? Well, usually there is lots of stuff specific to the chipset, CPU, and bus. Adapting a BIOS to a particular piece of hardware means knowing exactly how the hardware is wired (PCI interrupt routing, memory configuration, etc). Its not quite as simple as compiling a BSD or Linux kernel.
But with the exception of DOS few operating systems make much use of the BIOS past booting.
While open hardware is a noble goal, having been in the world of the BIOS, I think it should remain closed for the sanity of everybody.
I'm all for an open source startup firmware, but how about something saner than the PC BIOS?
Since it seems that Canada will be filling up with people soon maybe us Americans should look towards Russia as a place to regain our freedoms and avoid the tyranny of Dubya.
Anybody who is a "collector" could be deemed an addict by their definition. In fact, I suspect many of us slashdot readers are addicted to computers.
I know I have a huge pile of old, wierd computers in my house. Sure they take up space, power, and generate heat (which costs more electricity to remove). So they do cost me; but I like keeping them around. I enjoy them!
Maybe the government will eventually make them illegal. I mean, I can view porn with them (well, some of them), I can copie movies, music and TV shows (if I wanted to), and I can write flaming stuff about how our current president sucks donkeyballs. So clearly I'm an evil man for posessing such dangerous tools. Maybe they should get me on a terrorist charge or something.
I predict a new addiction sweeping over America: Canada! I think lots of Americans are going to be addicted to Canada (or Europe or Australia).
I'm not sure about IA-64 but yeah some processors are better at context switching than others. Threads are faster to create and do tend to take up a bit less RAM for page tables as well. Thats a good thing when you have several thousand simultaneous requests going on.
The down-side to threads is, as some posters have pointed out that a few modules (PHP comes to mind) aren't thread safe. I don't really use PHP nor do I like the language enough to bother with it.
But of the things I do use they all seem to be very happy with threads. And for Win32 users the threading model is pretty much their only model.
Actually my.38 special rounds are more like 9mms. The cartridge seems to have quite a bit less powder than my AK-47 rounds.
I must say I don't plan on experimenting with my foot so for now we don't have conclusive data.
I guess I shouldn't use the AK-47 in a C++ analogy. While I use C++ it is a very complex and difficult to master language while the AK-47 is quite elegant and simple.
Because in the late 80's and early 90's (when NT was written) C++ was quite new and the toolchains didn't have stable ABI's (not that we have a stable ABI today). So things like virtual function tables and such had no standard.
Also, a C++ API is difficult to use if you are programming in C (or Pascal or FORTRAN, etc) where some languages don't have objects. Sure it can be faked, but thats exactly what the GDI API was, a front end for the C++ code underneath.
So even though the underlaying implementations of pens, regions, patterns and such is in C++ you still deal with them via handles. In fact, technical issues aside a C++ GDI API at the time made no sense for another reason: Windows (16-bit) compatability.
There was a big push by Microsoft to make the Win16 to Win32 converstion as much of a recompile as possible. Why else would we still have global and local memory? Such horrid things should have been dispatched to the land of the arcane years ago.
Apache 2 has quite a few good things going for it over Apache 1. First off, it handles multi-threading much better meaning that very heavy workloads require less CPU time[*]
Second, Apache 2 supports things like DAV which mean that to publish information on the web users need less access than with Apache 1 (such as shell accounts or worse FTP, since most ISP's don't think users should use SSH for some odd reason).
Lastly, Apache 2 can run Subversion. So not only can you use DAV to update information without shell access of any kind but you can version that information too.
[*] Why is multi-threading faster than the pre-fork model of Apache 1? Because there is less work to do when context-switching threads. A thread shares the same virtual address space with other threads in the process. Changing virtual address spaces is slow because it requires a TLB flush (as well as one or more extra registers to save). The TLB flush increases memory accesses.
The core of Windows is written mostly in C. The GDI was written in C++ and the chief Kernel architect of WinNT (David Cutler) continually jabbed the Graphics group on their choice of C++.
I don't suspect you will be finding C++ in NTOSKRNL any time soon. I think Cutler would beat up anybody who tried.
You're right. How do those crazy Apple developers debug their C++ device drivers[*] with only those few JTAG wires?
I mean, you would never have a tool that would do that for you, like a C++-aware debugger. I'm sure everybody clocks out JTAG transactions by hand... One morse key for the clock, one for data,...
[*] The device driver framework for Darwin is in C++, as is the eCos real-time kernel. I guess I just imagined those.
I'm an embedded developer. I've done some projects as C only and some as C++. With proper discipline C++ can actually generate smaller, more compact code than straight C. But getting the infrastructure done is a bit harder.
In fact, eCos, a very nice (GPL) embedded operating system has its kernel written in C++. eCos performs well and is cleaner than a competing straight C RTOS which has to build its object system by hand (VxWorks' WIND kernel).
The real difficulty in using C++ for embedded development comes from the toolchains themselvs. Frequently new processor architectures don't have very functional C++ back ends but C is somewhat stable.
In fact, I worked on porting some C++ TV middleware to a specialized "media DSP processor." The GCC back-end for C was rock solid but C++ constructs would give me constant ICEs.
C++ does fix some dumb things in C, but when it comes to shooting yourself in the foot, C++ is like an AK-47 while C is more like a.38 special.
I'm reading Slashdot instead right from not-so-sunny South Florida. With my worldly data backed up on several servers and burned to CD/DVD just to be sure.... You insensitive clods. Oh wait, the Hurricane made some Slashdot news. I guess you guys aren't so insensitive.
Digital tuning on traditional engines can increase MPG (as well as horsepower). Lots of companies make tools that allow you to re-flash the ECU and transmission controller of your current vehicle. In addition to added horsepower, configuration of your vehicle to more specific operating conditions (altitude, temperature, etc) can improve MPG.
For Ford and GM trucks Diablosport makes a tuning tool.
If you think Java applications are bad wait till you see how Java messes up embedded systems!
I'm an embedded guy. I've worked on lots of products from STB's to PBX's and now automotive electronics. The only time I heard of a group using Java it turned out to be a miserable failure both with software cost overruns and a hardware BOM cost spiraling out of control.
On a more personal note, I used to have a Nokie 5600 series cell phone. Its also my alarm clock. It never failed to wake me up. That phone died and I had to get some new Java-powered phone. Guess what. Its alarm clock feature occasionally doesn't go off. The new phone also crashes quite often (the old one never crashed).
My phone is too busy garbage collecting so it can display cute animations that I don't care for. I want it to be a phone, damn it! If I wanted something to run small Java applications I would rent time on a high-end 32-way z/Series.
Itanium 2 is certainly not x86. It has an x86 emulator but its native instruction set is more like RISC than CISC.
The Itanium 2 is based on what Intel calls the EPIC architecture: Explicit Parallel Instruction Computing. Basically the CPU fetches 128-bit 3-instruction bundles. The instructions themselvs are somewhat simple and all three are executed simultaneously by parallel execution units.
Like some RISC architectures the Itanium 2 instruction set includes predication, register windows (lots of them -- not necessarily the best thing for context switching though).
Because a machine like that isn't about running Apahce or serving files.
The purpose of that computer is to solve complex scientific problems such as weather simulations, high-energy particle simulations, protine folding, etc. Many of these simulations involve iterated systems of equations that can take decades to solve on the fastest CPU's we have today.
The only way to get meaningful results in a meaningful amount of time is to break the problem apart into smaller problems and solve them in parallel.
Some projects, such as Folding@Home and Find-A-Drug go the distributed computing route -- use many disconnected systems to solve the problem.
The downside to that approach is that not all problems can be easily broken apart -- and some classes of problems can exist without tight coupling but they loose efficiency. The impressive thing about this particular super computer is that it has a single, unified memory image.
This is very useful for some classes of simulation problems when the entire simulation must be present for each iteration.
Actually, Cutler himself admits to the VMS+1=WNT thing. In addition, NT originally stood for N-Ten, which was the codename of the i860 RISC processor from Intel. Back then it was dubbed a "Cray on a Chip"; that was NT's original target although Dave always intended to keep the system portable.
In the end, the i860 turned out to be not such a good idea and they moved NT to MIPS -- a chip preferred by Cutler -- as well as familiar to some of the ex-digital crew since I believe Cutler had managed the compiler group for the MIPS-Based DECStations.
And compiling with only GCC is a great way to get portable code?
Seriously. GCC allows many things that the standards forbid. And even if you are dilligent and stick to standards-only behavior you still can get code that is incorrect (by accident) but runs okay on GCC. Using a different compiler will help bring out portability bugs - indeed all bugs - in your code.
GCC and MSVC are just two. There is also Watcom C, lcc, TenDRA, and a few others.
If you want portable code, compile your code with all of them; test it with all of them. Diversity (with respect to compilers) usually only makes code better, not worse. Its like getting better coverage when testing.
Yes, the best way to describe what I do is that I eat software dicks at work.
That phrase started out between a friend of mine and I. He hated his job and said this job eats a big bag of dicks. At which point it was really funny (but I guess you had to be there).
Then it became a Costco* size bag of dicks. Then Ron Jeremy and Peter North were the chef's in the cafeteria. It just sorta snowballed from there.
* Costco is a chain that sells huge items, mostly for restraunts and businesses but lots of people buy groceries there. When you say Costco-sized anything you mean big!
Slashdot Mirror
WinNT is a derivative of VMS if you look at the kernel internals:
* Packet-driven I/O subsystem
* Delayed Procedure Calls
* Asynchronous Procedure Calls
* The security model at the lowest level
* The object manager (although it was somewhat non-formal in VMS)
I mean, if you've ever programmed both systems at the kernel level you would be pretty shocked how similar they are. I mean, WNT feels like a more modern VMS with some things new and some things removed (sadly, like the amazing VMS cluster support).
The kernel of NT really is very VMS-like. Its not a bad kernel at all, either. Just because the crap M$ piles on top of it is utter shit doesn't mean that the underlaying kernel isn't of very high quality.
Actually, I remember from my Bar-Mitzvah that I had to sing my parshah. Although I know how to read Hebrew I didn't know how to read the musical notes which most Torahs carry.
For those unfamiliar with semitic languages such as Hebrew, the vowels are somewhat optional and are not part of the normal string of consonants. Instead, they are little marks made in various locations around the consonants. For example, a dot to the left of a character in the middle is an "ewwww" sound. Move the dot to the top of the letter and its an "oh" sound.
In addition to these vowels are various musical notes which tell you how to sing that particular passage (as a canter would). If I understand the history correctly the vowels and musical notes are not part of the "characters" (consontnats) of the Torah.
Perhaps minor variations in the musical notes could be used to signify the Torah -- or would that invalidate it. I guess one other important thing to mention is that there is some built-in redundancy in the vowels and (if I remember correctly, it was almost 20 years ago) in the musical notes. For example, a bar under a letter is an "ah" sound but so is a T-shape under a letter (althoug there may be a subtle difference in pronounciation that I'm not aware of).
A bit like a stream of data can be encoded in the less-significant bits of an image.
And for anybody interested in the non-Roman alphabets, http://www.ancientscripts.com/ is a good place to start.
Sheesh. Some people.
Knowing quite a bit about what goes into a BIOS, why does having an open source BIOS matter? Aside from the technical issues, the BIOS in a standard PC isn't really used much beyond the booting of the machine. Things like ACPI and PnP are pretty well understood now in the open source world, but that is, in reality, a very small portion of the kind of code you find in a BIOS.
Just what kind of code do you find? Well, usually there is lots of stuff specific to the chipset, CPU, and bus. Adapting a BIOS to a particular piece of hardware means knowing exactly how the hardware is wired (PCI interrupt routing, memory configuration, etc). Its not quite as simple as compiling a BSD or Linux kernel.
But with the exception of DOS few operating systems make much use of the BIOS past booting.
While open hardware is a noble goal, having been in the world of the BIOS, I think it should remain closed for the sanity of everybody.
I'm all for an open source startup firmware, but how about something saner than the PC BIOS?
Canada here I come for many reasons!
Here Here!!!
Anybody who is a "collector" could be deemed an addict by their definition. In fact, I suspect many of us slashdot readers are addicted to computers.
I know I have a huge pile of old, wierd computers in my house. Sure they take up space, power, and generate heat (which costs more electricity to remove). So they do cost me; but I like keeping them around. I enjoy them!
Maybe the government will eventually make them illegal. I mean, I can view porn with them (well, some of them), I can copie movies, music and TV shows (if I wanted to), and I can write flaming stuff about how our current president sucks donkeyballs. So clearly I'm an evil man for posessing such dangerous tools. Maybe they should get me on a terrorist charge or something.
I predict a new addiction sweeping over America: Canada! I think lots of Americans are going to be addicted to Canada (or Europe or Australia).
If I had mod points, you would get em.
NTDETECT does a basic probe of some of the non-self-identifying (legacy) hardware and builds the dynamic registry entries for them.
The down-side to threads is, as some posters have pointed out that a few modules (PHP comes to mind) aren't thread safe. I don't really use PHP nor do I like the language enough to bother with it.
But of the things I do use they all seem to be very happy with threads. And for Win32 users the threading model is pretty much their only model.
I'm not 100% sure but I suspect it isn't really all that supported anymore.
I must say I don't plan on experimenting with my foot so for now we don't have conclusive data.
I guess I shouldn't use the AK-47 in a C++ analogy. While I use C++ it is a very complex and difficult to master language while the AK-47 is quite elegant and simple.
Also, a C++ API is difficult to use if you are programming in C (or Pascal or FORTRAN, etc) where some languages don't have objects. Sure it can be faked, but thats exactly what the GDI API was, a front end for the C++ code underneath.
So even though the underlaying implementations of pens, regions, patterns and such is in C++ you still deal with them via handles. In fact, technical issues aside a C++ GDI API at the time made no sense for another reason: Windows (16-bit) compatability.
There was a big push by Microsoft to make the Win16 to Win32 converstion as much of a recompile as possible. Why else would we still have global and local memory? Such horrid things should have been dispatched to the land of the arcane years ago.
Second, Apache 2 supports things like DAV which mean that to publish information on the web users need less access than with Apache 1 (such as shell accounts or worse FTP, since most ISP's don't think users should use SSH for some odd reason).
Lastly, Apache 2 can run Subversion. So not only can you use DAV to update information without shell access of any kind but you can version that information too.
[*] Why is multi-threading faster than the pre-fork model of Apache 1? Because there is less work to do when context-switching threads. A thread shares the same virtual address space with other threads in the process. Changing virtual address spaces is slow because it requires a TLB flush (as well as one or more extra registers to save). The TLB flush increases memory accesses.
The core of Windows is written mostly in C. The GDI was written in C++ and the chief Kernel architect of WinNT (David Cutler) continually jabbed the Graphics group on their choice of C++.
I don't suspect you will be finding C++ in NTOSKRNL any time soon. I think Cutler would beat up anybody who tried.
You're right. How do those crazy Apple developers debug their C++ device drivers[*] with only those few JTAG wires? I mean, you would never have a tool that would do that for you, like a C++-aware debugger. I'm sure everybody clocks out JTAG transactions by hand... One morse key for the clock, one for data,... [*] The device driver framework for Darwin is in C++, as is the eCos real-time kernel. I guess I just imagined those.
I'm an embedded developer. I've done some projects as C only and some as C++. With proper discipline C++ can actually generate smaller, more compact code than straight C. But getting the infrastructure done is a bit harder.
.38 special.
In fact, eCos, a very nice (GPL) embedded operating system has its kernel written in C++. eCos performs well and is cleaner than a competing straight C RTOS which has to build its object system by hand (VxWorks' WIND kernel).
The real difficulty in using C++ for embedded development comes from the toolchains themselvs. Frequently new processor architectures don't have very functional C++ back ends but C is somewhat stable.
In fact, I worked on porting some C++ TV middleware to a specialized "media DSP processor." The GCC back-end for C was rock solid but C++ constructs would give me constant ICEs.
C++ does fix some dumb things in C, but when it comes to shooting yourself in the foot, C++ is like an AK-47 while C is more like a
I'm reading Slashdot instead right from not-so-sunny South Florida. With my worldly data backed up on several servers and burned to CD/DVD just to be sure.... You insensitive clods. Oh wait, the Hurricane made some Slashdot news. I guess you guys aren't so insensitive.
For Ford and GM trucks Diablosport makes a tuning tool.
I'm an embedded guy. I've worked on lots of products from STB's to PBX's and now automotive electronics. The only time I heard of a group using Java it turned out to be a miserable failure both with software cost overruns and a hardware BOM cost spiraling out of control.
On a more personal note, I used to have a Nokie 5600 series cell phone. Its also my alarm clock. It never failed to wake me up. That phone died and I had to get some new Java-powered phone. Guess what. Its alarm clock feature occasionally doesn't go off. The new phone also crashes quite often (the old one never crashed).
My phone is too busy garbage collecting so it can display cute animations that I don't care for. I want it to be a phone, damn it! If I wanted something to run small Java applications I would rent time on a high-end 32-way z/Series.
The Itanium 2 is based on what Intel calls the EPIC architecture: Explicit Parallel Instruction Computing. Basically the CPU fetches 128-bit 3-instruction bundles. The instructions themselvs are somewhat simple and all three are executed simultaneously by parallel execution units.
Like some RISC architectures the Itanium 2 instruction set includes predication, register windows (lots of them -- not necessarily the best thing for context switching though).
All in all, its not a bad architecture at all.
The purpose of that computer is to solve complex scientific problems such as weather simulations, high-energy particle simulations, protine folding, etc. Many of these simulations involve iterated systems of equations that can take decades to solve on the fastest CPU's we have today.
The only way to get meaningful results in a meaningful amount of time is to break the problem apart into smaller problems and solve them in parallel.
Some projects, such as Folding@Home and Find-A-Drug go the distributed computing route -- use many disconnected systems to solve the problem.
The downside to that approach is that not all problems can be easily broken apart -- and some classes of problems can exist without tight coupling but they loose efficiency. The impressive thing about this particular super computer is that it has a single, unified memory image.
This is very useful for some classes of simulation problems when the entire simulation must be present for each iteration.
Actually, Cutler himself admits to the VMS+1=WNT thing. In addition, NT originally stood for N-Ten, which was the codename of the i860 RISC processor from Intel. Back then it was dubbed a "Cray on a Chip"; that was NT's original target although Dave always intended to keep the system portable.
In the end, the i860 turned out to be not such a good idea and they moved NT to MIPS -- a chip preferred by Cutler -- as well as familiar to some of the ex-digital crew since I believe Cutler had managed the compiler group for the MIPS-Based DECStations.
Seriously. GCC allows many things that the standards forbid. And even if you are dilligent and stick to standards-only behavior you still can get code that is incorrect (by accident) but runs okay on GCC. Using a different compiler will help bring out portability bugs - indeed all bugs - in your code.
GCC and MSVC are just two. There is also Watcom C, lcc, TenDRA, and a few others.
If you want portable code, compile your code with all of them; test it with all of them. Diversity (with respect to compilers) usually only makes code better, not worse. Its like getting better coverage when testing.
That phrase started out between a friend of mine and I. He hated his job and said this job eats a big bag of dicks. At which point it was really funny (but I guess you had to be there).
Then it became a Costco* size bag of dicks. Then Ron Jeremy and Peter North were the chef's in the cafeteria. It just sorta snowballed from there.
* Costco is a chain that sells huge items, mostly for restraunts and businesses but lots of people buy groceries there. When you say Costco-sized anything you mean big!