NT did not evolve in any way from Windows 3.1. If it's said to have a design parent, that would to VMS (at the time Microsoft notoriously bought the people who designed VMS - but the design is similar in that there is a kernel with an API that runs in protected mode and several Application interfaces (virtual machines) that sit on top of that API - the Win32 subsystem is the most extensive such API and lives in such DLLs as Kernel32.dll, Advapi32.dll) - but the actual design was done from the ground up and incoporates features not found in a VMS kernel (ACLs, unicode, loadable driver model immediately come to mind). NT was not designed specifically for use as a client - it was designed to be a server (where MS did not have a good product - people were running OS/2 as a server if that tells you the benchmark they had to beat).
The window manager (User32.dll) does not run in kernel space - it runs in user mode. This is a minsconception created when the GDI was moved into Kernel Mode. This is now consistant with other drivers but the point of the move was to increase the granularity of the calls to Kernel mode. The drivers for the actual video cards (called miniport drivers because they implement a simpler subset of the graphics API) already ran in Kernel mode. So the change was to move complex GDI calls that resolved in multiple mini-port graphics driver calls into the kernel (reducing the number as expensive (10k-100k instructions) kernel mode switches - hench improving drawing performance).
The assertion that window messages must be used for IPCs is false. There do exist several mechanisms where this is the case (applications posting private window messages, clipboard transfers, DDE, and COM when used with single threaded apartments). However, you should note that all of these mechanisms are intended for use by use applications - and all of these mechanisms run in user mode (along with the window manager). For service applications there exist kernel event, mutexes, semaphores, memory mapped files, sockets and named pipes. For *real* IPC you can use COM in multi-threaded mode (where calls come in on kernel allocated threads for maximum concurrency). There also exist kernel objects designed for high-throughput servers like jobs, thread-pool managers (you give it tasks and the kernel manages a thread pool based on current server load), and IO completion ports (similar to a thread pool but thread list is user managed).
For Win2k - any server now integrates terminal services (previously found only on NT4.0 terminal server edition - the technology was merged forwards since the changes were too extensive to be a mere service pack). Effectively every server is now multiuser and supports remote applications like X does. Some other changes are a bit more difficult: like COM+ which integrates transaction processing, events, asynchronous IPC, object pooling (features previously in MTS) natively into the COM object model; NTFS reparse points let you create virtual directory trees (mounting volumes in a a tree just like UNIX), Dfs aggregates network shares into a single tree, hardware support for NT should increase since now it uses the same driver model as Win98/ME, Offline/Hierarchical storage.
The *massive* change that everyone's talking about is AD (Active Directory) - if any feature could be termed a Linux killer this is it. Any organization over a couple hundred people can benefit a lot from a directory service because they will surely have multiple domains by that point. AD also throws in replication of accounts, shares, mailboxes (Exchange 2k is implemented entirely in terms of AD) and files (you can create a domain share where the files are replicated among all the servers in that domain for maximum uptime).
All this is nice, but if you want to see the full extent of the vision at MS you have to watch the NT, IIS, VS, SQL Server axis. They put a lot of effort into larger scale design creating a lot of integration among their own products.
That's the really fun part. DVD players do not have facilities for updating. Although it would in theory be possible to do software decoding in set-top boxes (with flash ram), none of them are inplemented that way.
The MPAA cannot release movies with an alternate encryption format without killing compatibility. I would suggest that multiple formats (which could not be played in certain set top players) would destroy the market and possibly the format.
After the years they spent developing it, they aren't going to walk away from the format.
The cracking of CSS was inevitable anyways (it was only designed to prevent "casual" copying in the first place) since 40-bit encyption can be done in a few weeks but brute force. Still there is no makret for copying or distribution because the media for DVD RAMs is still more expensive that buying the original movies. Although you *could* downmix it (an 18 hour process) to fit on a pair of CDs, it would seem to be missing the point.
I really don't know why the DVD CCA is trying to defend a technology that *even they* expected to fail.
Maybe I should insert insert a derogatory remark about lawyers or something:-)
This is a very old setting, and unless you are a complete dumbass you put a password on the sa account. The problem was not caused by microsoft (they had to default it to something to let you set up the database, and leaving it blank should prompt someone to fill it in).
The bad press should go to the particular web sites who apparently don't see this as an obvious hole.
Linux will never reach C2 security, that requires every kernel object be secured with ACLs and issue security audit alarms on both success and failed opens. It also requires the capacity to use alternate identification mechanisms like biometrics or smart cards as opposed to just username/password. The POSIX APIs have no means to accopmlish either of these goals since it is resitricted to username/password and UGO security flags. The only reason NT made C2 is because they planned it that way from the beginning.
Similarly, no operating system that offers standards-conforming mail, news, web, ftp, netbios (or lan manager), dhcp, ldap, rpc or pptp will ever qualify for C2 because none of those meet C2 authentication requirements.
C2 is the highest rating a commercial operating system can get, higher ratings can only be internally developed within the government (or by government contractors) and cannot be kept online.
Wow, there are 5 separate completely false statements.
1. The WTO *is* evolving, that is the purpose of these meetings. However, it happens slowly (you try getting 135 countries to agree on something and you'll figure out why). 2. If you want information go to the WTO website (http://www.wto.org) - I got it first try. 3. The WTO *is* open, the entire set of rules is online, the reason most people don't think it's open is because they've never researched what it does. (The information is there, the people are ignorant). 4. The only voting people attending the meetings are the representative from the member countries (usually the trade minister from the respective country). It is up to the trade minister to bring a balanced viewpoint. The presenters are either from the member governments or from univeristies and research institutes (often contained in universities). 5. Bill Gates is not even attending.
This isn't an exploit at all. For those of you who don't know how signing works, here's a quick overview:
To sign a document: 1. Calculate a hash of the document (MD5 is the common method). 2. Encrypt the hash with your private key.
When the user want to verify that it came from you, they: 1. Calculate the hash of the document. 2. Decrypt the provided hash with the public key and check if they match.
So, at this point you know: 1. That the document was not modified since it was signed. 2. That the document came from the source that it was intended to come from.
The reason Microsoft is signing the security modules is to prevent someone from subsituting the DLL and then comprimising your security. (Since you can't sign without the private key).
Now, if this second key (and the third one for that matter), belong to another party, it means that your computers will accept security modules signed by them to run. However, only entities with the matching private key can release the modules.
This validation mechanism only affects the loading of the security module, not the actual secured data. The author of the security modules does not implicitely have access to the encrypted data without the private keys used to encode them. It would have to get your private keys, and then store them somewhere or send them somewhere in order to be able to read your data.
Open source code isn't implicitely bug free... nor is closed source code implicitely buggy. That's just a political issue, however, if a vendor writes UDI driver, which linux is compatible with... then it won't be neccessary for them to release the specs.
If the masters of linux are forward-thinking, then the linux kernel will contain a UDI driver model. Having copious drivers available can only be good for linux. Also, dropping the tight binding between the kernel and the drivers would be an architectural improvement (it's shouldn't be neccessary the recompile all of the drivers with the kernel).
The people who contribute to linux can't afford to compete with microsoft (who can afford to rewrite drivers with every windows version) by continually reinventing the wheel... there are too many other neccessary projects that require attention. Taking the burden of writing drivers away from the limited number of people writing free software, and transfering it to hardware vendors (who already make money selling hardware) makes sense.
It's not just 64 bits in this case; there are several new processor technologies. The most significant of which are: very long instruction words (the compiler packs multiple operations into a single instruction word); asynchronous memory reads, writes and asynchronous stack management (tell the processor to do a load several instructions before you need it and then check if it was successful later, stack management is done by allocating registers and the memory stack writes are automatically done in the background); true speculative evaluations (conditions are built into the instruction set so there's no loss when a speculative instruction never executes); register rotation (a group of number registers can be rotated so that several passes of a loop can be evaluated at the same time(using VLIWs)).
Despite the processor changes, the harder challenge has been to write a compiler that can take advantage of these features which are actually the cause of the greater performance.
Exaclty... there will be too many names for a single person to remember. Also, there are too many combinations of letter to prevent someone from just thinking of a different name (a variant).
The people they quoted in the article is truely idiots... I think they lack the vision to see where technology is actually going, and that's into more advanced search engines.
When I want to find a particular website, I go to Yahoo, type in the company name and then follow the link.
This isn't a reality check... because you missed an obvious application: intranets.
6 T1's is not as fast as 10 MBit ethernet... but many servers are connected to 100 Mb, or Gb ethernet. At that point, your bottleneck are going to be:
a) The internal IO architecture of the server harware. b) Processor speed and blocking within the application (multi-threading in the kernel).
The web-server example was contrived... unless you're running a site like yahoo (top 1% of servers), a web server serving external clients won't bog the system.
The test should have been done with a database server (Oracle for NT and linux) or a Notes server (also available for both). Then there's a better mix of processors/drive access/network.
Wow, some examples of either of your points would be appreciated. But I will jump you with some couterpoints first.
1) C++ reduces programmer efficiency by being hard to read/understand. Proof: Look at the number of C++ projects that founder for lack of contributions.
Your proof is not. I'm sure you can find numerous C projects that failed from a lack of contributions.
C++ is not harder to understand than any other language that you already understand. In fact, learning C++ is the best way to become a better C programmer. The languages constructs in C++ are well designed and teach you a means to structure a program even in their absence.
With capacity to use overloaded operators and type conversions, you can make code that is fundamentally more readable than with a C program. For example, the STL (often considered strange looking by those who have only glanced at it) has a standard syntax for iterating over the members of a container (lets say the type is Container):
Container c; for ( Container::iterator iter = c.begin ( ); iter != c.end; ++ iter ) iter->value;....
This will work whether the container is a vector, list, stack, map (associative list), set (indexed list).
In C, there would be separate functions for each type of collection (and conversions for the generic pointer). But the best part is that the semantics mimic efficient iteration of a C array.
struct s[20]; for ( struct s *iter = s; iter != s + 20; ++ iter ) s->value;....
In the case of the vector container, that is the typical implementation.
Given that C++ can mimic C semantics while encapsulating more complex behavior makes the language easier to read than an equivalent C project.
2) C++ reduces program efficiency by being hard (if not impossible) to compile into an efficient executable. Proof: OS's and other high-performance programs are written in C.
This is one of those statements that is never backed up with fact. Some people seem to think that the size and speed of your program is proportional to the number of keywords in the language.
Given that C++ is a superset of C (with the semantics of struct being slightly different). There is no reason that a C++ compiler will implicitely produce inferior code.
When is not often stated is that the keyword in C++ can produce better code given the opportunity.
I will review two language features that are often accused of causing inefficiency: dynamically bound functions, and exception handling.
The key thing to remember is that to reproduce the equivalent behavior is C for using these features the only difference is that you are writing the code yourself. In every case, the compiler would have done a better job itself.
Virtual function are often implemented as a virtual table of function calls. This means that a virtual function call requires a table index before the function call. This is one more instruction (some processors do this for you) in a function call that may be hundreds -- before you even get to the function.
The equivalent switch statement introduces a lot more code because it has to compare against all of the values. If you get fancy and make a similar lookup table... why didn't you just let the compiler do that for in the first place?
The estimate for exceptions is often estimated at a 5-10% overhead:
"This is huge." the C programmers cry.
But it's not so bad after you realize that your code if free from all of the error code checks. The ones where after every method call, you have to check whether it was successful before using the return value.
Freed of that burden, you can actaully use your return values. For example the C code:
If under C++, we define GetChickenFoo to return a valid pointer or throw an exception (give me foos or give me death!) we have:
GetChickenFoo ( )->layLotsOfEggs ( );
Which one would you rather write. Even better, this second code is more efficient because: there is no check (already done), there's no jump (pipelined processors hate those), and no early return (more code generated).
Over an entire project, you get your 5-10% back pretty quick (and possibly then some) all without you having to write more code.
There are more constructs like inlining, templates and (gasp!) template meta-programs (where you trick the compiler into generating the perfect source code for you depending on the context) which can improve code efficiency further.
For those who want to know how C++ can be used inefficiently, here are some things to look for: excessive duplicating of objects (through pass-by-value parameters and returns), excessive reallocations, excessive data type conversions, and the streams library (which has yet to have a fast implementation).
The NT Kernel can be recompiled for any process with a bit of glue logic. The reason microsoft wanted to drop teh other platforms is that they don't want to do driver support.
The reason the Alpha is still around is that it uses a PCI bus and PCI adapters as opposed to a proprietary bus.
CE is the NT kernel without most of the drivers required for a PC: multiple bus drivers, multiple file systems, midi devices, storage devices... (Yes it can run on a strongarm).
Actually, the memory manager is 64 bit, it always has been.
There's no reason you can't do 64-bit math (VC5 has a data type called __int64).
Ther strategy for making NT 64-bit is:
1) All APIs stay the smae and take 32 bit pointers (default is segment 0) 2) The memory region above 4GB is available for memory mapped files which are mapped through a new API.
This doesn't require a rewrite and is the stratedgy adopted by many UNIX vendors.
I doubt Merced will ship for another few years yet. (It been just-around-the-corner for a while). Intel introducing the Xeon and later the P3 is evidence that they don't expect to ship anything soon.
The only reason that Merced won't be a consumer chip for a while is that it uses a different (nobody has been able to make work) technology called very-long-instruction-word.
Knowing intel, they will provide an x86 compatibility layer, but for software to run faster, it will have to be recompiled.
Apple is the only company who has successfully migrated a user base to a new processor.
BTW, Intel made quite a bit of money on the PPro so I wouldn't call it a failure.
Slashdot Mirror
NT did not evolve in any way from Windows 3.1. If it's said to have a design parent, that would to VMS (at the time Microsoft notoriously bought the people who designed VMS - but the design is similar in that there is a kernel with an API that runs in protected mode and several Application interfaces (virtual machines) that sit on top of that API - the Win32 subsystem is the most extensive such API and lives in such DLLs as Kernel32.dll, Advapi32.dll) - but the actual design was done from the ground up and incoporates features not found in a VMS kernel (ACLs, unicode, loadable driver model immediately come to mind). NT was not designed specifically for use as a client - it was designed to be a server (where MS did not have a good product - people were running OS/2 as a server if that tells you the benchmark they had to beat).
The window manager (User32.dll) does not run in kernel space - it runs in user mode. This is a minsconception created when the GDI was moved into Kernel Mode. This is now consistant with other drivers but the point of the move was to increase the granularity of the calls to Kernel mode. The drivers for the actual video cards (called miniport drivers because they implement a simpler subset of the graphics API) already ran in Kernel mode. So the change was to move complex GDI calls that resolved in multiple mini-port graphics driver calls into the kernel (reducing the number as expensive (10k-100k instructions) kernel mode switches - hench improving drawing performance).
The assertion that window messages must be used for IPCs is false. There do exist several mechanisms where this is the case (applications posting private window messages, clipboard transfers, DDE, and COM when used with single threaded apartments). However, you should note that all of these mechanisms are intended for use by use applications - and all of these mechanisms run in user mode (along with the window manager). For service applications there exist kernel event, mutexes, semaphores, memory mapped files, sockets and named pipes. For *real* IPC you can use COM in multi-threaded mode (where calls come in on kernel allocated threads for maximum concurrency). There also exist kernel objects designed for high-throughput servers like jobs, thread-pool managers (you give it tasks and the kernel manages a thread pool based on current server load), and IO completion ports (similar to a thread pool but thread list is user managed).
For Win2k - any server now integrates terminal services (previously found only on NT4.0 terminal server edition - the technology was merged forwards since the changes were too extensive to be a mere service pack). Effectively every server is now multiuser and supports remote applications like X does. Some other changes are a bit more difficult: like COM+ which integrates transaction processing, events, asynchronous IPC, object pooling (features previously in MTS) natively into the COM object model; NTFS reparse points let you create virtual directory trees (mounting volumes in a a tree just like UNIX), Dfs aggregates network shares into a single tree, hardware support for NT should increase since now it uses the same driver model as Win98/ME, Offline/Hierarchical storage.
The *massive* change that everyone's talking about is AD (Active Directory) - if any feature could be termed a Linux killer this is it. Any organization over a couple hundred people can benefit a lot from a directory service because they will surely have multiple domains by that point. AD also throws in replication of accounts, shares, mailboxes (Exchange 2k is implemented entirely in terms of AD) and files (you can create a domain share where the files are replicated among all the servers in that domain for maximum uptime).
All this is nice, but if you want to see the full extent of the vision at MS you have to watch the NT, IIS, VS, SQL Server axis. They put a lot of effort into larger scale design creating a lot of integration among their own products.
That's the really fun part. DVD players do not have facilities for updating. Although it would in theory be possible to do software decoding in set-top boxes (with flash ram), none of them are inplemented that way.
:-)
The MPAA cannot release movies with an alternate encryption format without killing compatibility. I would suggest that multiple formats (which could not be played in certain set top players) would destroy the market and possibly the format.
After the years they spent developing it, they aren't going to walk away from the format.
The cracking of CSS was inevitable anyways (it was only designed to prevent "casual" copying in the first place) since 40-bit encyption can be done in a few weeks but brute force. Still there is no makret for copying or distribution because the media for DVD RAMs is still more expensive that buying the original movies. Although you *could* downmix it (an 18 hour process) to fit on a pair of CDs, it would seem to be missing the point.
I really don't know why the DVD CCA is trying to defend a technology that *even they* expected to fail.
Maybe I should insert insert a derogatory remark about lawyers or something
This is a very old setting, and unless you are a complete dumbass you put a password on the sa account. The problem was not caused by microsoft (they had to default it to something to let you set up the database, and leaving it blank should prompt someone to fill it in).
The bad press should go to the particular web sites who apparently don't see this as an obvious hole.
Linux will never reach C2 security, that requires every kernel object be secured with ACLs and issue security audit alarms on both success and failed opens. It also requires the capacity to use alternate identification mechanisms like biometrics or smart cards as opposed to just username/password. The POSIX APIs have no means to accopmlish either of these goals since it is resitricted to username/password and UGO security flags. The only reason NT made C2 is because they planned it that way from the beginning.
Similarly, no operating system that offers standards-conforming mail, news, web, ftp, netbios (or lan manager), dhcp, ldap, rpc or pptp will ever qualify for C2 because none of those meet C2 authentication requirements.
C2 is the highest rating a commercial operating system can get, higher ratings can only be internally developed within the government (or by government contractors) and cannot be kept online.
Wow, there are 5 separate completely false statements.
1. The WTO *is* evolving, that is the purpose of these meetings. However, it happens slowly (you try getting 135 countries to agree on something and you'll figure out why).
2. If you want information go to the WTO website (http://www.wto.org) - I got it first try.
3. The WTO *is* open, the entire set of rules is online, the reason most people don't think it's open is because they've never researched what it does. (The information is there, the people are ignorant).
4. The only voting people attending the meetings are the representative from the member countries (usually the trade minister from the respective country). It is up to the trade minister to bring a balanced viewpoint. The presenters are either from the member governments or from univeristies and research institutes (often contained in universities).
5. Bill Gates is not even attending.
This isn't an exploit at all. For those of you who don't know how signing works, here's a quick overview:
To sign a document:
1. Calculate a hash of the document (MD5 is the common method).
2. Encrypt the hash with your private key.
When the user want to verify that it came from you, they:
1. Calculate the hash of the document.
2. Decrypt the provided hash with the public key and check if they match.
So, at this point you know:
1. That the document was not modified since it was signed.
2. That the document came from the source that it was intended to come from.
The reason Microsoft is signing the security modules is to prevent someone from subsituting the DLL and then comprimising your security. (Since you can't sign without the private key).
Now, if this second key (and the third one for that matter), belong to another party, it means that your computers will accept security modules signed by them to run. However, only entities with the matching private key can release the modules.
This validation mechanism only affects the loading of the security module, not the actual secured data. The author of the security modules does not implicitely have access to the encrypted data without the private keys used to encode them. It would have to get your private keys, and then store them somewhere or send them somewhere in order to be able to read your data.
Open source code isn't implicitely bug free ... nor is closed source code implicitely buggy. That's just a political issue, however, if a vendor writes UDI driver, which linux is compatible with ... then it won't be neccessary for them to release the specs.
... there are too many other neccessary projects that require attention. Taking the burden of writing drivers away from the limited number of people writing free software, and transfering it to hardware vendors (who already make money selling hardware) makes sense.
If the masters of linux are forward-thinking, then the linux kernel will contain a UDI driver model. Having copious drivers available can only be good for linux. Also, dropping the tight binding between the kernel and the drivers would be an architectural improvement (it's shouldn't be neccessary the recompile all of the drivers with the kernel).
The people who contribute to linux can't afford to compete with microsoft (who can afford to rewrite drivers with every windows version) by continually reinventing the wheel
It's not just 64 bits in this case; there are several new processor technologies. The most significant of which are: very long instruction words (the compiler packs multiple operations into a single instruction word); asynchronous memory reads, writes and asynchronous stack management (tell the processor to do a load several instructions before you need it and then check if it was successful later, stack management is done by allocating registers and the memory stack writes are automatically done in the background); true speculative evaluations (conditions are built into the instruction set so there's no loss when a speculative instruction never executes); register rotation (a group of number registers can be rotated so that several passes of a loop can be evaluated at the same time(using VLIWs)).
Despite the processor changes, the harder challenge has been to write a compiler that can take advantage of these features which are actually the cause of the greater performance.
I agree that Java is great. It brings Exception Handling (not signals), Threading, Good UI and Good Documentation to Linux.
:)
No wonder the establishment hates it
Don't worry about ... I'm sure they'll ship a few extra to Canada :)
Exaclty ... there will be too many names for a single person to remember. Also, there are too many combinations of letter to prevent someone from just thinking of a different name (a variant).
... I think they lack the vision to see where technology is actually going, and that's into more advanced search engines.
The people they quoted in the article is truely idiots
When I want to find a particular website, I go to Yahoo, type in the company name and then follow the link.
This isn't a reality check ... because you missed an obvious application: intranets.
... but many servers are connected to 100 Mb, or Gb ethernet. At that point, your bottleneck are going to be:
... unless you're running a site like yahoo (top 1% of servers), a web server serving external clients won't bog the system.
6 T1's is not as fast as 10 MBit ethernet
a) The internal IO architecture of the server harware.
b) Processor speed and blocking within the application (multi-threading in the kernel).
The web-server example was contrived
The test should have been done with a database server (Oracle for NT and linux) or a Notes server (also available for both). Then there's a better mix of processors/drive access/network.
1) C++ reduces programmer efficiency by being hard to read/understand. Proof: Look at the number of C++ projects that founder for lack of contributions.
Your proof is not. I'm sure you can find numerous C projects that failed from a lack of contributions.
C++ is not harder to understand than any other language that you already understand. In fact, learning C++ is the best way to become a better C programmer. The languages constructs in C++ are well designed and teach you a means to structure a program even in their absence.
With capacity to use overloaded operators and type conversions, you can make code that is fundamentally more readable than with a C program. For example, the STL (often considered strange looking by those who have only glanced at it) has a standard syntax for iterating over the members of a container (lets say the type is Container):
Container c; ....
for ( Container::iterator iter = c.begin ( ); iter != c.end; ++ iter ) iter->value;
This will work whether the container is a vector, list, stack, map (associative list), set (indexed list).
In C, there would be separate functions for each type of collection (and conversions for the generic pointer). But the best part is that the semantics mimic efficient iteration of a C array.
struct s[20]; ....
for ( struct s *iter = s; iter != s + 20; ++ iter ) s->value;
In the case of the vector container, that is the typical implementation.
Given that C++ can mimic C semantics while encapsulating more complex behavior makes the language easier to read than an equivalent C project.
2) C++ reduces program efficiency by being hard (if not impossible) to compile into an efficient executable. Proof: OS's and other high-performance programs are written in C.
This is one of those statements that is never backed up with fact. Some people seem to think that the size and speed of your program is proportional to the number of keywords in the language.
Given that C++ is a superset of C (with the semantics of struct being slightly different). There is no reason that a C++ compiler will implicitely produce inferior code.
When is not often stated is that the keyword in C++ can produce better code given the opportunity.
I will review two language features that are often accused of causing inefficiency: dynamically bound functions, and exception handling.
The key thing to remember is that to reproduce the equivalent behavior is C for using these features the only difference is that you are writing the code yourself. In every case, the compiler would have done a better job itself.
Virtual function are often implemented as a virtual table of function calls. This means that a virtual function call requires a table index before the function call. This is one more instruction (some processors do this for you) in a function call that may be hundreds -- before you even get to the function.
The equivalent switch statement introduces a lot more code because it has to compare against all of the values. If you get fancy and make a similar lookup table ... why didn't you just let the compiler do that for in the first place?
The estimate for exceptions is often estimated at a 5-10% overhead:
"This is huge." the C programmers cry.
But it's not so bad after you realize that your code if free from all of the error code checks. The ones where after every method call, you have to check whether it was successful before using the return value.
Freed of that burden, you can actaully use your return values. For example the C code:
Foo *pFoo = GetChickenFoo ( );
if ( pFoo != NULL ) pFoo->layLotsOfEggs ( );
If under C++, we define GetChickenFoo to return a valid pointer or throw an exception (give me foos or give me death!) we have:
GetChickenFoo ( )->layLotsOfEggs ( );
Which one would you rather write. Even better, this second code is more efficient because: there is no check (already done), there's no jump (pipelined processors hate those), and no early return (more code generated).
Over an entire project, you get your 5-10% back pretty quick (and possibly then some) all without you having to write more code.
There are more constructs like inlining, templates and (gasp!) template meta-programs (where you trick the compiler into generating the perfect source code for you depending on the context) which can improve code efficiency further.
For those who want to know how C++ can be used inefficiently, here are some things to look for: excessive duplicating of objects (through pass-by-value parameters and returns), excessive reallocations, excessive data type conversions, and the streams library (which has yet to have a fast implementation).
The NT Kernel can be recompiled for any process with a bit of glue logic. The reason microsoft wanted to drop teh other platforms is that they don't want to do driver support.
... (Yes it can run on a strongarm).
The reason the Alpha is still around is that it uses a PCI bus and PCI adapters as opposed to a proprietary bus.
CE is the NT kernel without most of the drivers required for a PC: multiple bus drivers, multiple file systems, midi devices, storage devices
Actually, the memory manager is 64 bit, it always has been.
There's no reason you can't do 64-bit math (VC5 has a data type called __int64).
Ther strategy for making NT 64-bit is:
1) All APIs stay the smae and take 32 bit pointers (default is segment 0)
2) The memory region above 4GB is available for memory mapped files which are mapped through a new API.
This doesn't require a rewrite and is the stratedgy adopted by many UNIX vendors.
CE isn't another version of windows. It is Windows NT in an embedded system with a different shell.
Yes, you can buy an embedded version of NT with a Win32 subsystem (no GUI).
Did you forget to notice that most commercial software is *not* written in assembler.
NT is written almost entirely in C as well.
Print "Accelerated for Merced" on the box so people will know the difference you commerical software is doing just great thankyou.
I doubt Merced will ship for another few years yet. (It been just-around-the-corner for a while). Intel introducing the Xeon and later the P3 is evidence that they don't expect to ship anything soon.
The only reason that Merced won't be a consumer chip for a while is that it uses a different (nobody has been able to make work) technology called very-long-instruction-word.
Knowing intel, they will provide an x86 compatibility layer, but for software to run faster, it will have to be recompiled.
Apple is the only company who has successfully migrated a user base to a new processor.
BTW, Intel made quite a bit of money on the PPro so I wouldn't call it a failure.