I remember seeing ads for a one-handed keyboard in the computer magazines back in the early 80's. It was dome shaped, with two buttons for each finger and several for the thumb. IIRC, you had to basically memorize the binary values for the ASCII table to use the thing.
The TCP stack that shipped with NT 3.51 and all later versions was written from scratch by Microsoft engineers. I know this because I co-wrote the Windows NT Winsock implementation and I worked very closely with the TCP guys. Can I prove this? No, but just because you read something in a WSJ article doesn't prove anything, either.
Re:The problem with all these equations...
on
Rare Earth
·
· Score: 2, Insightful
It's also possible that we are the most advanced civilization to develop so far. How's that for a depressing thought?
For years, Microsoft wouldn't deal with hardware OEMs unless they agreed to a pricing scheme that required them to pay a fee to Microsoft for every PC sold, whether or not they actually loaded Windows on that PC.
This is a common misconception. Microsoft's licensing agreements with OEMs offered them a lower price for the OS if they agreed to the "per machine fee". This was actually easier on the OEMs -- less paperwork, less accounting, etc.
The OEMs always had the option to buy individual licenses at a higher rate.
The fact that the OEMs agreed to this makes them at least partially responsible IMHO.
Re:Summary of Tandy computer line
on
Tandys Never Die
·
· Score: 1
Having established itself as the leader in UNIX for small business, and having invested substantial time and dollars in building a relatively effective suppport infrastructure for UNIX, Tandy made the brilliant decision to abandon that market and focus exclusively on PC clone systems. Given their prominence in the PC world today, you can see how well that worked. The executive behind this decision later moved to Microsoft.
I assume the executive to which you refer is Jon Shirley. He did move to Microsoft back in the late 80's, but was he really the one responsible for this decision? I would think former Tandy CEO John Roach was most responsible.
In addition to source formatting (tabs, brace placement, etc) you need to agree to a standard mechanism for functions to return status values.
For example, if you look at the Win32 API (sorry; that's what I'm most familiar with) you will find the following mechanisms used to return error status:
BOOL - If FALSE, call GetLastError() to retrieve the Win32 status. Example: CreateProcess().
HANDLE - If INVALID_HANDLE_VALUE, call GetLastError() to retrieve the Win32 status. Example: CreateFile().
HANDLE - If NULL, call GetLastError() to retrieve the Win32 status. Example: CreateFileMapping().
DWORD - If some distinguished value (0? -1?), call GetLastError() to retrieve the Win32 status. Example: TlsAlloc().
DWORD - The Win32 status code. Example: RegQueryValueEx() - this API actually returns a LONG, not a DWORD, but you get the point.
HRESULT - The COM status code. Example: GetSiteNameFromSid().
There are also NT kernel APIs that fail by raising exceptions. The caller must wrap the API in a try/except handler to catch the exception and retrieve the error code.
It's not just the Win32 API that uses these mechanisms for returning status. I've seen app code that duplicates each of these. I've also seen coding errors caused by the programmer not checking for the correct condition. For example, if the app contained a function called OpenFileAndCreateMapping() that returned a HANDLE, how would you test the return value to determine if an error occurred? Test for NULL? INVALID_HANDLE_VALUE? Some other distinguished value?
The last coding style guide I created for a large project mandated that any function that can possibly fail must return a DWORD containing the Win32 status code. This made the code easier to write, review, and maintain.
You're assuming the contamination is on the outside of the lens. It could be some component within the camera "off gassing" and forming sludge on the inner lens surface.
Mr. Bradford's tests demonstrate inefficiencies in Win2K/XP's TCP/IP loopback implementation, not the Winsock implementation. The loopback interface is implemented down deep in the IP stack. Just before a packet is about to hit the net, it is checked to see if it should be "looped back". If so, it is queued off to a worker thread that does the grunt work. The end result is you get at least two thread context switches for each loopback packet (in each direction).
Don't get me wrong -- I'm not trying to make excuses for the loopback implementation, it sucks. I just think it's important to note what is actually getting measured. I have not studied the Linux loopback implementation, so I don't know how it compares with Win2K/XP.
I would like to see the tests run with the client & server applications on separate machines. Also, his sockspeedp6.cpp test is naive at best. On Win2K/XP at least, a properly written app can easily saturate a 100MB ethernet. At this point, the most meaningful performance metric becomes not "how fast is data transferred" but "how much CPU load is required to saturate the network".
Slashdot Mirror
I remember seeing ads for a one-handed keyboard in the computer magazines back in the early 80's. It was dome shaped, with two buttons for each finger and several for the thumb. IIRC, you had to basically memorize the binary values for the ASCII table to use the thing.
The TCP stack that shipped with NT 3.51 and all later versions was written from scratch by Microsoft engineers. I know this because I co-wrote the Windows NT Winsock implementation and I worked very closely with the TCP guys. Can I prove this? No, but just because you read something in a WSJ article doesn't prove anything, either.
It's also possible that we are the most advanced civilization to develop so far. How's that for a depressing thought?
I think that should be a Beowulf "flock". They do resemble sheep...
I think they will come in handy when trying to find one's self. This may cut down on those pesky time-consuming journeys of self discovery.
I'm currently out trying to find myself. If I should get back before I return, please keep me here.
What about Red Hat?
I bought Red Hat 7.2 and only got a bunch of CDs. No hat!
I can imagine the airports installing Hall Effect detectors to scan passengers for magnetic devices...
For years, Microsoft wouldn't deal with hardware OEMs unless they agreed to a pricing scheme that required them to pay a fee to Microsoft for every PC sold, whether or not they actually loaded Windows on that PC.
This is a common misconception. Microsoft's licensing agreements with OEMs offered them a lower price for the OS if they agreed to the "per machine fee". This was actually easier on the OEMs -- less paperwork, less accounting, etc.
The OEMs always had the option to buy individual licenses at a higher rate.
The fact that the OEMs agreed to this makes them at least partially responsible IMHO.
Having established itself as the leader in UNIX for small business, and having invested substantial time and dollars in building a relatively effective suppport infrastructure for UNIX, Tandy made the brilliant decision to abandon that market and focus exclusively on PC clone systems. Given their prominence in the PC world today, you can see how well that worked. The executive behind this decision later moved to Microsoft.
I assume the executive to which you refer is Jon Shirley. He did move to Microsoft back in the late 80's, but was he really the one responsible for this decision? I would think former Tandy CEO John Roach was most responsible.
For example, if you look at the Win32 API (sorry; that's what I'm most familiar with) you will find the following mechanisms used to return error status:
- BOOL - If FALSE, call GetLastError() to retrieve the Win32 status. Example: CreateProcess().
- HANDLE - If INVALID_HANDLE_VALUE, call GetLastError() to retrieve the Win32 status. Example: CreateFile().
- HANDLE - If NULL, call GetLastError() to retrieve the Win32 status. Example: CreateFileMapping().
- DWORD - If some distinguished value (0? -1?), call GetLastError() to retrieve the Win32 status. Example: TlsAlloc().
- DWORD - The Win32 status code. Example: RegQueryValueEx() - this API actually returns a LONG, not a DWORD, but you get the point.
- HRESULT - The COM status code. Example: GetSiteNameFromSid().
There are also NT kernel APIs that fail by raising exceptions. The caller must wrap the API in a try/except handler to catch the exception and retrieve the error code.It's not just the Win32 API that uses these mechanisms for returning status. I've seen app code that duplicates each of these. I've also seen coding errors caused by the programmer not checking for the correct condition. For example, if the app contained a function called OpenFileAndCreateMapping() that returned a HANDLE, how would you test the return value to determine if an error occurred? Test for NULL? INVALID_HANDLE_VALUE? Some other distinguished value?
The last coding style guide I created for a large project mandated that any function that can possibly fail must return a DWORD containing the Win32 status code. This made the code easier to write, review, and maintain.
You're assuming the contamination is on the outside of the lens. It could be some component within the camera "off gassing" and forming sludge on the inner lens surface.
Mr. Bradford's tests demonstrate inefficiencies in Win2K/XP's TCP/IP loopback implementation, not the Winsock implementation. The loopback interface is implemented down deep in the IP stack. Just before a packet is about to hit the net, it is checked to see if it should be "looped back". If so, it is queued off to a worker thread that does the grunt work. The end result is you get at least two thread context switches for each loopback packet (in each direction).
Don't get me wrong -- I'm not trying to make excuses for the loopback implementation, it sucks. I just think it's important to note what is actually getting measured. I have not studied the Linux loopback implementation, so I don't know how it compares with Win2K/XP.
I would like to see the tests run with the client & server applications on separate machines. Also, his sockspeedp6.cpp test is naive at best. On Win2K/XP at least, a properly written app can easily saturate a 100MB ethernet. At this point, the most meaningful performance metric becomes not "how fast is data transferred" but "how much CPU load is required to saturate the network".
Try http://www.davecentral.com/8966.html. I haven't tried it yet (no Win98 system :-) but CDFS.ZIP is available on this site.