The Intel i810 chipset provides a random number generator based on this principle. There was a discussion on the linux-kernel mailing list about whether or not the data it produced could be considered truly random. IIRC, it was decided to add data from the chipset to the entropy pool, but not to increment the estimate of entropy in the pool. (Which wouldn't hurt and might even help the randomness of the entropy pool.)
---
The Hotmail addres is my decoy account. I read it approximately once per year.
I actually put some effort into trying to learn how Microsoft's extensions to the Kerberos protocol operate. The URLs that you have linked to contain no useful information (they mostly consist of "Windows 2000 works with Unix. Yay!"). The one and only document that actually contains usable information (usable meaning it documents what all of the relevant bytes mean) is marked by a click-wrap NDA as being an "Internal Microsoft Trade Secret" and it is illegal for anyone who reads it to tell anyone about the information it contains. (Never mind the fact that anyone can download the document for free...) So, they have effectively prevented any opensource Kerberos implementation that is compatible with their KDC (or rather, they have effectively prevented anyone from basing their implementation on the documents they have provided).
Most of the above documents that the URLs refer to also claim that their proprietary extensions are RFC1510 compliant, which is deliberately misleading. There is a portion of the Kerberos protocol that can be used for vendor extensions, but Microsoft's proprietary extensions are still secret.
---
The Hotmail addres is my decoy account. I read it approximately once per year.
Computers are very predictable devices. Hence it is extremely hard
to produce truly random numbers on a computer --- as opposed to
pseudo-random numbers, which can easily generated by using a
algorithm. Unfortunately, it is very easy for attackers to guess
the sequence of pseudo-random number generators, and for some
applications this is not acceptable. So instead, we must try to
gather "environmental noise" from the computer's environment, which
must be hard for outside attackers to observe, and use that to
enerate random numbers. In a Unix environment, this is best done
from inside the kernel.
Sources of randomness from the environment include inter-keyboard
timings, inter-interrupt timings from some interrupts, and other
events which are both (a) non-deterministic and (b) hard for an
outside observer to measure. Randomness from these sources are
added to an "entropy pool", which is mixed using a CRC-like function.
This is not cryptographically strong, but it is adequate assuming
the randomness is not chosen maliciously, and it is fast enough that
the overhead of doing it on every interrupt is very reasonable.
As random bytes are mixed into the entropy pool, the routines keep
an estimate of how many bits of randomness have been stored into
the random number generator's internal state.
When random bytes are desired, they are obtained by taking the SHA
hash of the contents of the "entropy pool". The SHA hash avoids
exposing the internal state of the entropy pool. It is believed to
be computationally infeasible to derive any useful information
about the input of SHA from its output. Even if it is possible to
analyze SHA in some clever way, as long as the amount of data
returned from the generator is less than the inherent entropy in
the pool, the output data is totally unpredictable. For this
reason, the routine decreases its internal estimate of how many
bits of "true randomness" are contained in the entropy pool as it
outputs random numbers.
If this estimate goes to zero, the routine can still generate
random numbers; however, an attacker may (at least in theory) be
able to infer the future output of the generator from prior
outputs. This requires successful cryptanalysis of SHA, which is
not believed to be feasible, but there is a remote possibility.
Nonetheless, these numbers should be useful for the vast majority
of purposes.
So, yes, I have RTFM (RTFS?) in this case (and before this article was ever posted, which should give me bonus points).
The time between the interrupts caused by my keypresses and mouse movements is random. PGP for DOS used this fact directly, however modern operating systems provide their own sources of random bits based on the same principle.
Note that devices that measure radioactive decay can be easily hooked up to the Linux random number generator.:-)
---
The Hotmail addres is my decoy account. I read it approximately once per year.
I think you may have missed the point of your CS teacher's argument.
Yes, it is impossible to generate a truly random number using a simple mathematical formula. That's why these are all referred to as "pseudo-random number generators." The numbers they produce look random, but if you continue to generate numbers using the same function, it will eventually repeat itself.
However, it is possible to design random number generators that can actually generate random numbers./dev/random on Linux is an example of this. It samples the times of the user's keypress and mouse movements (actually the time specific interrupts occured, but its basicly the same thing) along with other random sources to produce real random numbers. There is also specialized hardware that will listen to atmospheric noise and background radiation to producte random numbers as well.
Now, back to the point of this topic: TCP sequence number prediction. As someone else has already pointed out, this vulnerablity has been known about (and fixed) since 1996. The above mentioned/dev/random device has been used internally by the TCP/IP stack in Linux to generate cryptographically secure random initial sequence numbers for some time now.
---
The Hotmail addres is my decoy account. I read it approximately once per year.
Prior art must be 1 year in advance of the filing date of the patent.
Interesting.
So I can see a product in the marketplace, run off to the good old USPTO and apply for a patent for an idea that is used in that product, and then sue the maker of that product and there is nothing they can do about it?
The US patent system is even more screwed up than I previously thought...
---
The Hotmail addres is my decoy account. I read it approximately once per year.
gtk-themes beat them out by at least two months. If you look at the GNOME CVS log for gtkthemes.c, you'll see that it was first checked in in March of 1998, which is before that May of 1998 application date for Apple's patent.
Of course, Enlightenment also beat the Apple patent (by an even larger margin), however, IIRC, Enlightenment use pixmaps and scripts to do its work, while gtkthemes uses plugins (one of which can load arbitrary pixmap themese, but others, like Notif and Redmond95 are full-blown shared objects).
---
The Hotmail addres is my decoy account. I read it approximately once per year.
That isn't proof. WinSock is the Windows Socket interface, which is based on the Berkeley Socket interface. The WinSock DLLs convert the mostly standardized socket API into the native Windows's networking interface.
This does not indicate in any way that the Windows TCP/IP stack is derived from BSD code. (Although, I wouldn't be surprised if it was. nmap misidentifying Win2k as BSD is a bit suspicious.)
---
The Hotmail addres is my decoy account. I read it approximately once per year.
But there's one thing that you can't reasonably accomplish outside of the kernel: speed. Or, perhaps I should say, blindingly fast, beat-ther-crap-outta-NT speed. So, there are (obviously) tradeoffs. However, ther Linux kernel is usually well tested, and there are a lot of smart people working on the kernel. Someone would probably notice it, especially because it is a security sensitive area of the kernel.
BTW, TUX isn't equivalent to running Apache as a kernel thread. TUX has limited abilities. It only does the fast/easy stuff. Anything harder gets handed to a user-space process, whether it be a webserver or TUX client program. So the amount of functionality in TUX that is actually in-kernel is much smaller that Apache.
---
The Hotmail addres is my decoy account. I read it approximately once per year.
Its interesting how many of these media access control architectures that the various large corporations are pushing are built around software.
What these big corporations are forgetting is that software is just a bunch of bits stored on some magnetic media somewhere. These bits can be looked at, pondered over, duplicated and modified.
Yes, your operating system may verify that your software is special in some way. Perhaps your programs must be signed by one of these corporation's master keys before the program can even begin play with the imprisoned audio and video. But your operating system itself is just a bunch of bits, and bits can be changed. How can an operating verify it has not been altered or even verify that it verified itself?
Of course, there is always hardware. Sure, your hardware may insist that your software meets some specific, magical criteria before the software gets the privilege of looking at that imprisoned song, book or movie, but the hardware still depends upon the software. And software is just a bunch of bits. And bits can be learned from or changed. And hardware can be deceived.
And then there is the hardware itself. The opaque, unchanging, mysterious hardware. Or is it? Opaque? No, hardware can be studied as well. Logic analyzers, in-circuit emulators, oscilliscopes and other toys allow for the exploration of the depths of the machines. Unchanging? Also wrong. Flash memory, EPROMs, and soldering irons abound. Nothing is immutable. Mysterious? No as well. Someone designed it. Somewhere out there exists the source code to the firmware and the VHDL for the chips themselves. Nothing can go undiscovered forever.
So where does this leave us?
No matter what obstacles are thrown at us by those who espouse the ideal that absolutely no action should go uncharged, they will be overcome. There will always be a Jon Johansen or a Julien Stern and Julien Boeuf that step out of the corner and say "Hey wait, your system isn't so special at all."
Then those big corporations will start all over again. They will come up with their Next Great Thing, their New Magic Bullet, their Unbreakable Secure System. Their marketing departments and PR flaks will crow about how wonderfully great their new system is. Until someone else steps out of the depths...
Information is unstoppable.
---
The Hotmail addres is my decoy account. I read it approximately once per year.
Because two of these can run at the same time (one per CPU), the data doesn't have to be
written to the disk between stages.
The data doesn't have to be written do disk anyway -- that the entire point of the -pipe option in gcc. All data is written to stdin of the child processes, resulting in faster compiles because nothing ever hits the disk until to assembler outputs the object file.
Multi-processor builds are faster because make (with the -j option) compiles several files in parallel (idealy, one per processor), not because data is piped from stage to stage in the compiler.
The reason they use make -j3 on a two-processor is to take advantage of the fact that compiling programs is both a compute-bound and I/O-bound operation. While one instance of the compiler is waiting for data to be read, another instance is busy generating code. Both processors are always in use, even when one of the instances of gcc is stalled waiting for an I/O operation to complete.
---
The Hotmail addres is my decoy account. I read it approximately once per year.
Yeah, but a buffer overflow in knfsd, smbfs, ncpfs, nfs or any of the device drivers would also lead to a total system compromise. I fail to see your point. ---
The Hotmail addres is my decoy account. I read it approximately once per year.
Linux does support hot-swapable hardware
on
Linux Is Going Down
·
· Score: 1
In case you were wondering, 2.4.0 supports hot-swapable hardware -- USB, PCMCIA, CardBus (which isn't much more than funny shaped PCI cards), IEEE-1394 (experimental), and generic PCI as well.
---
The Hotmail addres is my decoy account. I read it approximately once per year.
The author of the article that started this all has also interviewed Linus.
It's rather interesting in that Linus contradicts many of the comments that have been posted here -- that Linux will never support NUMA or big iron servers, and things like that.
Definitely worth the read...
---
The Hotmail addres is my decoy account. I read it approximately once per year.
Re:linux-2.4.0 & gcc-2.95?
on
2.2 vs 2.4
·
· Score: 1
Linus talked about this recently. Basically, it should work, but it isn't guaranteed to work and he would like to know about what breaks so it can be fixed. (There was a post on linux-kernel about this, but I can't find a link to it...) ---
The Hotmail addres is my decoy account. I read it approximately once per year.
Re:The real 'end' for 2.0.38?
on
2.2 vs 2.4
·
· Score: 1
Are you kidding? 2.0.38 is already dead. 2.0.39 was released in early January.:-) ---
The Hotmail addres is my decoy account. I read it approximately once per year.
How does being in-kernel make a web server (or any type of server, for that matter) make it insecure?
Lot's of things are already in the kernel. Their presence doesn't hurt security, so why should a web-server?
Oh, btw. TUX isn't exactly a webserver. It's more of a kernel-side object cache that can be extened by modules or user-space apps to speak various protocols.
---
The Hotmail addres is my decoy account. I read it approximately once per year.
Most likely because *BSD doesn't have major corporate sponsorship like Linux does.
(However, TUX still beats the crap out of *BSD (and damn near anything else) at web-serving any day...:-) ---
The Hotmail addres is my decoy account. I read it approximately once per year.
Credit card companies are very paranoid about card usage, and do all sorts of stuff to prevent criminals from getting away with too much.
For example, when my family went to Europe on vacation a couple years ago, MasterCard locked out our accout due to "suspicious activity."
When we got home a week later, we discovered a message on our answering machine asking us about our card usage, recorded on the afternoon that the card was disabled. ("Hello, this is MasterCard. We were calling you at your home in the US to ask you if you are in Europe right now...")
Moral of this story: call your credit card company before you go on vacation. And don't fly British Airways (en route to Heathrow, we were diverted to Montreal because the primary power generator on the plane died and the pilot didn't want to risk flying over the ocean in such a state. Which was good, because the lighting, toilets and air conditioning wasn't working. Didn't even get frequent flyer miles out of it... )
---
The Hotmail addres is my decoy account. I read it approximately once per year.
OK, there was going to be a bastard-variant-of-C++ code excerpt here, but... (Dammit Taco, the lameness filter sucks...)
Anyway, the example I linked to above uses three proprietary extensions that Microsoft has introduced to the C++ language.
#using <mscorlib.dll>
Programmers can now directly include.NET DLL's into their program. (God forbid they have to run some external tool that generates a C++ header file from an DLL or IDL description and then include that, I mean, think of all the extra typing they would have to do...)
__gc public class StringComponent
So you want to declare a.NET managed (created and garbage collected by the runtime) class. As everyone knows, you have to introduce a new keyword to do this. There is absolutely no way you can make this class be derived from the NetManagedObject base class, that would (once again) require way too much typing if you were to require that the developers do it that way...
__property int get_Count()
Once again, a new keyword was absolutely necessary to allow developers to declare properties in their classes. An external file that says that StringComponent::get_Count() is the get method for a read-only property called Count would be an incredible burden on the developers. (As would a/* %NET property Count(get_Count,NULL)% */ comment next the the declaration of get_Count(), and then running the source file through a preprocessor..)
---
The Hotmail addres is my decoy account. I read it approximately once per year.
Now here's where the REAL fun begins: Microsoft has to not only convince consumers to use.NET software, but it's got to convince programmers to write.NET software - which has its own programming language.
That isn't entirely true. Yes, they have developed a new programming language (C#) for their.NET thingy, but you can use any language that their compiler supports to generate.NET components.
Note that I said their compiler - instead of doing something simple, like using the framework of C++ to adapt it to.NET (i.e. Every.NET compatible object is derived from the DotNET class, or something like that), they have introduced new keywords (__gc comes to mind) which triggers some internal magic in the compiler that produces.NET compatible objects. This guarantees that code written in C++ for.NET will not be easily ported to other compilers without heavy modification (either to the compiler or to the program).
---
The Hotmail addres is my decoy account. I read it approximately once per year.
Software AG ported DCOM to Linux and, IIRC, several other Unixen some years ago. I haven't heard anything else about this, so I don't think it took off (why use DCOM when you can use CORBA?).
DCOM wasn't that hard for them to port, however not much would actually work using it because many COM interfaces use Windows APIs internally to do graphics or networking or whatever. So, yes, DCOM runs on other platforms, but it is basically useless because almost none of the COM components run on other platforms or ever will be able to run on other platforms without some one porting the entire Win32 API to those platforms. (Which is what Wine is doing, but it isn't finished yet...)
---
The Hotmail addres is my decoy account. I read it approximately once per year.
For instance the exam could cover recursion, file systems, memory allocation, etc.
The exam does cover recursion, memory allocation and (to a limited extent) the file system.
---
The Hotmail addres is my decoy account. I read it approximately once per year.
Slashdot Mirror
The Intel i810 chipset provides a random number generator based on this principle. There was a discussion on the linux-kernel mailing list about whether or not the data it produced could be considered truly random. IIRC, it was decided to add data from the chipset to the entropy pool, but not to increment the estimate of entropy in the pool. (Which wouldn't hurt and might even help the randomness of the entropy pool.)
---
The Hotmail addres is my decoy account. I read it approximately once per year.
I actually put some effort into trying to learn how Microsoft's extensions to the Kerberos protocol operate. The URLs that you have linked to contain no useful information (they mostly consist of "Windows 2000 works with Unix. Yay!"). The one and only document that actually contains usable information (usable meaning it documents what all of the relevant bytes mean) is marked by a click-wrap NDA as being an "Internal Microsoft Trade Secret" and it is illegal for anyone who reads it to tell anyone about the information it contains. (Never mind the fact that anyone can download the document for free...) So, they have effectively prevented any opensource Kerberos implementation that is compatible with their KDC (or rather, they have effectively prevented anyone from basing their implementation on the documents they have provided).
Most of the above documents that the URLs refer to also claim that their proprietary extensions are RFC1510 compliant, which is deliberately misleading. There is a portion of the Kerberos protocol that can be used for vendor extensions, but Microsoft's proprietary extensions are still secret.
---
The Hotmail addres is my decoy account. I read it approximately once per year.
So, yes, I have RTFM (RTFS?) in this case (and before this article was ever posted, which should give me bonus points).
The time between the interrupts caused by my keypresses and mouse movements is random. PGP for DOS used this fact directly, however modern operating systems provide their own sources of random bits based on the same principle.
Note that devices that measure radioactive decay can be easily hooked up to the Linux random number generator. :-)
---
The Hotmail addres is my decoy account. I read it approximately once per year.
I think you may have missed the point of your CS teacher's argument.
Yes, it is impossible to generate a truly random number using a simple mathematical formula. That's why these are all referred to as "pseudo-random number generators." The numbers they produce look random, but if you continue to generate numbers using the same function, it will eventually repeat itself.
However, it is possible to design random number generators that can actually generate random numbers. /dev/random on Linux is an example of this. It samples the times of the user's keypress and mouse movements (actually the time specific interrupts occured, but its basicly the same thing) along with other random sources to produce real random numbers. There is also specialized hardware that will listen to atmospheric noise and background radiation to producte random numbers as well.
Now, back to the point of this topic: TCP sequence number prediction. As someone else has already pointed out, this vulnerablity has been known about (and fixed) since 1996. The above mentioned /dev/random device has been used internally by the TCP/IP stack in Linux to generate cryptographically secure random initial sequence numbers for some time now.
---
The Hotmail addres is my decoy account. I read it approximately once per year.
gnapster works just fine with OpenNap servers.
---
The Hotmail addres is my decoy account. I read it approximately once per year.
Interesting.
So I can see a product in the marketplace, run off to the good old USPTO and apply for a patent for an idea that is used in that product, and then sue the maker of that product and there is nothing they can do about it?
The US patent system is even more screwed up than I previously thought...
---
The Hotmail addres is my decoy account. I read it approximately once per year.
Yes, there is definitely prior art.
gtk-themes beat them out by at least two months. If you look at the GNOME CVS log for gtkthemes.c, you'll see that it was first checked in in March of 1998, which is before that May of 1998 application date for Apple's patent.
Of course, Enlightenment also beat the Apple patent (by an even larger margin), however, IIRC, Enlightenment use pixmaps and scripts to do its work, while gtkthemes uses plugins (one of which can load arbitrary pixmap themese, but others, like Notif and Redmond95 are full-blown shared objects).
---
The Hotmail addres is my decoy account. I read it approximately once per year.
That isn't proof. WinSock is the Windows Socket interface, which is based on the Berkeley Socket interface. The WinSock DLLs convert the mostly standardized socket API into the native Windows's networking interface.
This does not indicate in any way that the Windows TCP/IP stack is derived from BSD code. (Although, I wouldn't be surprised if it was. nmap misidentifying Win2k as BSD is a bit suspicious.)
---
The Hotmail addres is my decoy account. I read it approximately once per year.
But there's one thing that you can't reasonably accomplish outside of the kernel: speed. Or, perhaps I should say, blindingly fast, beat-ther-crap-outta-NT speed. So, there are (obviously) tradeoffs. However, ther Linux kernel is usually well tested, and there are a lot of smart people working on the kernel. Someone would probably notice it, especially because it is a security sensitive area of the kernel.
BTW, TUX isn't equivalent to running Apache as a kernel thread. TUX has limited abilities. It only does the fast/easy stuff. Anything harder gets handed to a user-space process, whether it be a webserver or TUX client program. So the amount of functionality in TUX that is actually in-kernel is much smaller that Apache.
---
The Hotmail addres is my decoy account. I read it approximately once per year.
Its interesting how many of these media access control architectures that the various large corporations are pushing are built around software.
What these big corporations are forgetting is that software is just a bunch of bits stored on some magnetic media somewhere. These bits can be looked at, pondered over, duplicated and modified.
Yes, your operating system may verify that your software is special in some way. Perhaps your programs must be signed by one of these corporation's master keys before the program can even begin play with the imprisoned audio and video. But your operating system itself is just a bunch of bits, and bits can be changed. How can an operating verify it has not been altered or even verify that it verified itself?
Of course, there is always hardware. Sure, your hardware may insist that your software meets some specific, magical criteria before the software gets the privilege of looking at that imprisoned song, book or movie, but the hardware still depends upon the software. And software is just a bunch of bits. And bits can be learned from or changed. And hardware can be deceived.
And then there is the hardware itself. The opaque, unchanging, mysterious hardware. Or is it? Opaque? No, hardware can be studied as well. Logic analyzers, in-circuit emulators, oscilliscopes and other toys allow for the exploration of the depths of the machines. Unchanging? Also wrong. Flash memory, EPROMs, and soldering irons abound. Nothing is immutable. Mysterious? No as well. Someone designed it. Somewhere out there exists the source code to the firmware and the VHDL for the chips themselves. Nothing can go undiscovered forever.
So where does this leave us?
No matter what obstacles are thrown at us by those who espouse the ideal that absolutely no action should go uncharged, they will be overcome. There will always be a Jon Johansen or a Julien Stern and Julien Boeuf that step out of the corner and say "Hey wait, your system isn't so special at all."
Then those big corporations will start all over again. They will come up with their Next Great Thing, their New Magic Bullet, their Unbreakable Secure System. Their marketing departments and PR flaks will crow about how wonderfully great their new system is. Until someone else steps out of the depths...
Information is unstoppable.
---
The Hotmail addres is my decoy account. I read it approximately once per year.
Because two of these can run at the same time (one per CPU), the data doesn't have to be written to the disk between stages.
The data doesn't have to be written do disk anyway -- that the entire point of the -pipe option in gcc. All data is written to stdin of the child processes, resulting in faster compiles because nothing ever hits the disk until to assembler outputs the object file.
Multi-processor builds are faster because make (with the -j option) compiles several files in parallel (idealy, one per processor), not because data is piped from stage to stage in the compiler.
The reason they use make -j3 on a two-processor is to take advantage of the fact that compiling programs is both a compute-bound and I/O-bound operation. While one instance of the compiler is waiting for data to be read, another instance is busy generating code. Both processors are always in use, even when one of the instances of gcc is stalled waiting for an I/O operation to complete.
---
The Hotmail addres is my decoy account. I read it approximately once per year.
You missed the point.
Pinstripe and Guiness are types of beer, while Guiness and Fisher are Star Wars actors.
Each of the code names fits nicely with the last.
---
The Hotmail addres is my decoy account. I read it approximately once per year.
Yeah, but a buffer overflow in knfsd, smbfs, ncpfs, nfs or any of the device drivers would also lead to a total system compromise. I fail to see your point.
---
The Hotmail addres is my decoy account. I read it approximately once per year.
In case you were wondering, 2.4.0 supports hot-swapable hardware -- USB, PCMCIA, CardBus (which isn't much more than funny shaped PCI cards), IEEE-1394 (experimental), and generic PCI as well.
---
The Hotmail addres is my decoy account. I read it approximately once per year.
The author of the article that started this all has also interviewed Linus.
It's rather interesting in that Linus contradicts many of the comments that have been posted here -- that Linux will never support NUMA or big iron servers, and things like that.
Definitely worth the read...
---
The Hotmail addres is my decoy account. I read it approximately once per year.
Linus talked about this recently. Basically, it should work, but it isn't guaranteed to work and he would like to know about what breaks so it can be fixed. (There was a post on linux-kernel about this, but I can't find a link to it...)
---
The Hotmail addres is my decoy account. I read it approximately once per year.
Are you kidding? 2.0.38 is already dead. 2.0.39 was released in early January. :-)
---
The Hotmail addres is my decoy account. I read it approximately once per year.
2.4.0 won't boot on 386's (or at least some 386's, I don't remember) due to a small bug that's fixed in the 2.4.1 pre-patches.
IIRC, it also uses slightly more swap space to do exactly the same thing, so disk space may be an issue as well.
---
The Hotmail addres is my decoy account. I read it approximately once per year.
How does being in-kernel make a web server (or any type of server, for that matter) make it insecure?
Lot's of things are already in the kernel. Their presence doesn't hurt security, so why should a web-server?
Oh, btw. TUX isn't exactly a webserver. It's more of a kernel-side object cache that can be extened by modules or user-space apps to speak various protocols.
---
The Hotmail addres is my decoy account. I read it approximately once per year.
Most likely because *BSD doesn't have major corporate sponsorship like Linux does.
(However, TUX still beats the crap out of *BSD (and damn near anything else) at web-serving any day... :-)
---
The Hotmail addres is my decoy account. I read it approximately once per year.
Note that it said possible fraudulent use.
Credit card companies are very paranoid about card usage, and do all sorts of stuff to prevent criminals from getting away with too much.
For example, when my family went to Europe on vacation a couple years ago, MasterCard locked out our accout due to "suspicious activity."
When we got home a week later, we discovered a message on our answering machine asking us about our card usage, recorded on the afternoon that the card was disabled. ("Hello, this is MasterCard. We were calling you at your home in the US to ask you if you are in Europe right now...")
Moral of this story: call your credit card company before you go on vacation. And don't fly British Airways (en route to Heathrow, we were diverted to Montreal because the primary power generator on the plane died and the pilot didn't want to risk flying over the ocean in such a state. Which was good, because the lighting, toilets and air conditioning wasn't working. Didn't even get frequent flyer miles out of it... )
---
The Hotmail addres is my decoy account. I read it approximately once per year.
The following is one of their sample C++ applications:
OK, there was going to be a bastard-variant-of-C++ code excerpt here, but... (Dammit Taco, the lameness filter sucks...)
Anyway, the example I linked to above uses three proprietary extensions that Microsoft has introduced to the C++ language.
Programmers can now directly include .NET DLL's into their program. (God forbid they have to run some external tool that generates a C++ header file from an DLL or IDL description and then include that, I mean, think of all the extra typing they would have to do...)
So you want to declare a .NET managed (created and garbage collected by the runtime) class. As everyone knows, you have to introduce a new keyword to do this. There is absolutely no way you can make this class be derived from the NetManagedObject base class, that would (once again) require way too much typing if you were to require that the developers do it that way...
Once again, a new keyword was absolutely necessary to allow developers to declare properties in their classes. An external file that says that StringComponent::get_Count() is the get method for a read-only property called Count would be an incredible burden on the developers. (As would a /* %NET property Count(get_Count,NULL)% */ comment next the the declaration of get_Count(), and then running the source file through a preprocessor..)
---
The Hotmail addres is my decoy account. I read it approximately once per year.
Now here's where the REAL fun begins: Microsoft has to not only convince consumers to use .NET software, but it's got to convince programmers to write .NET software - which has its own programming language.
That isn't entirely true. Yes, they have developed a new programming language (C#) for their .NET thingy, but you can use any language that their compiler supports to generate .NET components.
Note that I said their compiler - instead of doing something simple, like using the framework of C++ to adapt it to .NET (i.e. Every .NET compatible object is derived from the DotNET class, or something like that), they have introduced new keywords (__gc comes to mind) which triggers some internal magic in the compiler that produces .NET compatible objects. This guarantees that code written in C++ for .NET will not be easily ported to other compilers without heavy modification (either to the compiler or to the program).
---
The Hotmail addres is my decoy account. I read it approximately once per year.
Software AG ported DCOM to Linux and, IIRC, several other Unixen some years ago. I haven't heard anything else about this, so I don't think it took off (why use DCOM when you can use CORBA?).
DCOM wasn't that hard for them to port, however not much would actually work using it because many COM interfaces use Windows APIs internally to do graphics or networking or whatever. So, yes, DCOM runs on other platforms, but it is basically useless because almost none of the COM components run on other platforms or ever will be able to run on other platforms without some one porting the entire Win32 API to those platforms. (Which is what Wine is doing, but it isn't finished yet...)
---
The Hotmail addres is my decoy account. I read it approximately once per year.
For instance the exam could cover recursion, file systems, memory allocation, etc. The exam does cover recursion, memory allocation and (to a limited extent) the file system.
---
The Hotmail addres is my decoy account. I read it approximately once per year.