For that matter, Intel emulates Intel's x86 architecture as much as AMD does (x86 instructions are translated into smaller RISC-like instructions on all modern CPUs).
In a sense, "instruction set" is to a modern CPU the same thing as "API" is to a piece of software.
MS is such an absurdly large company, I don't know why the hell they can't have a 'drivers' division.
Because this would mean they need to have an internal knowledge of the hardware (they were trying to write driver for), which would constitute violation of the hardware vendor's intellectual property.
The DOS WC games either fail miserably or need tweaking to get working.
This is because these are really not DOS games at all. They are games that access the hardware directly, and happen to run under OS (DOS) that lets them do that. Properly written Windows game that uses OS-provided API will still work.
IMHO, the Mac ends up having superior backward compatibility.
If my calculation is right, a human-rated liner maglev launch system would be about 2000 km long. And I bet this would cost less then Iraq war while bringing much more benefit to the humanity.
Let's see...
d = V^2 / (2 * a)
d - distance
V - velocity
a - acceleration
By replacing V=11000 m/s^2 (approx. Earth's escape velocity) and a=29.43 m/s^2 (3g, reasonably comfortable for humans), you get:
d = 2055725.45 m = 2055 km (or 1 276.9178 miles)
Of course, if we factor-in air resistance, the needed length would increase, but I reckon not by too much...
Incidentally, has anyone tried this new patch that's out to fix the Intellisense-dominating-your-processor-usage bug that MS finally noticed (about a year after everyone else)?
Yes, this seems to ease the load that is placed on the system during IntelliSense run. I used it for couple of weeks now and I didn't notice any ill effects.
Why in heaven's name would anyone want to go back to the moon? Because it's there? Get real.
Why in heaven's name would anyone want to go back to the America? Because it's there? Get real.
Heck, why even leaving the Africa?
Or the trees we felt so comfortably hanging from?
OK, you get my drift... Our species survived by expanding both its physical and intellectual frontiers. Getting to the Moon and staying there (hopefully, in a self-sufficient manner) is just the continuation of the survival strategy that served us so well in the past.
If I could find such a thing, I'd probably still write all my CGI programs in C instead of only writing the most performance-critical pieces in C. As it stands, it's enough of a pain to make C CGI code work correctly that it isn't worth the trouble for me, and so I suffer the performance hit (generally of PHP).
You make some good points, especially about fragility of C on server-side, but I think you are missing the main reason of why CGI in C (and CGI in general) is sub-optimal solution in most circumstances:
CGI does not provide state management.
Basically, you end-up with having to do all the initialization steps all over again for each HTTP request - you are unable to retain non-trivial state, such as database connection or COM reference, across the user session.
We had this particular problem with one of our recent project that exposed certain PTC Pro/INTRALINK (which is a kind of CAD version control system) functionality to the Web. First version of our application was CGI written in C++ that talks directly to Pro/INTRALINK API. We ended up having to reestablish Pro/INTRALINK connection each time user requests a new page. New solution, which is combination of ASP.NET and COM wrapper around Pro/INTRALINK API, is able to initialize COM object (which then connects to Pro/INTRALINK and does some other one-off tasks) at the start of the user session and then retain reference to this COM object until user session expires.
If even a relatively simple GUI of driver control panel is considered unsuitable for "non-native" technology, then it is understandable why more complex desktop applications are still far away from being routinely developed in such languages.
In my personal experience, I'm yet to see "non-native" application that does not feel sluggish compared to a similar native application.
I don't know how long the parse & prepare phase takes but I know it is not zero so there could be some speed improvement too.
Preparation of SQL statement is potentially expensive and usually involves analysis (by DBMS optimizer) of many ways the statement can be executed (what indexes to use, and in what order, how to combine sub-queries etc.).
This analysis can be more expensive then statement execution itself (especially for well designed SELECT statements).
So if you execute your statement more then once, it is always a good idea to prepare it.
This looks like a reasonable strategy from the view point of project deadlines. However, it invites cutting corners by your employees, in order to get the money more quickly, without caring much for the maintenance part of project's lifetime. Cutting corners in initial software construction inevitably raises cost (and frustration) both for developers and customers in later phases of software's life.
There is a great read from Fred Brooks - "The Mythical Man Month", that is still very relevant on this topic.
If your projects are small "fire and forget" endeavors, this might work well. However, if you projects are more long-term, requiring extensive maintenance period, you might be shooting yourself in the leg...
How would this "allow GPU chipmakers to slash driver development costs"?
As the matters stand now, chipmakers need to commit significant resources to implementation of OpenGL support (in addition to DirectX support). Vista's architecture allows them to make only DirectX driver and OpenGL functionality will "fall back" to that. Therefore cost savings.
You are correct on lower performance, but this seems to be a lesser problem then tone of this discussion would suggest. Ex-development lead for this project says: "When I left the project, we were well over 80% performance on average compared to the native OpenGL driver."
Let me make a suggestion... Produce a non-crippled version of the Windows that is localized to specific language and cannot be converted into any other language. Then sell it at lower price in economically poorer market that speaks that language.
One could not just re-import such Windows in US (UK, Germany, France...), simply because prospective customers could not use the foreign language. Therefore higher price of "western" Windows is preserved.
MS's way has always been toward having a single way of doing a single operation.
Actually, this is not exactly true.
Look at how long they sustained (technically) obsolete Win 9x line of their operating systems, instead of unifying on NT architecture.
If you look in Win32 API, you'll see plethora of "deprecated" functions that are there only to support the old applications.
This is nothing new - merely a consequence of how technology evolves, but illustrates quite nicely their reluctance to break compatibility just because it would be nice to unify on "newest and greatest". Hell, VisiCalc still runs on MS (except it is Windows this time)!
I doubt they will make anything to break compatibility with OpenGL applications. As other posted mentioned, MS's move could allow GPU chipmakers to slash driver development costs (with the tradeoff in performance), but there are competitive reasons this is unlikely to happen (CAD, Doom 4?), at least for the big chipmakers such as ATI/nVidia.
Both nVidia and ATI have professional products intended for CAD, that are based on essentially same architecture as their "mainstream" cards.
So, they have every incentive to write a good OpenGL driver regardless of what Microsoft is trying to do in the gaming market. That driver will then easily "trickle-down" to the mainstream...
Wast majority of people doing any sort of programming in the world are quite frankly not that good. Thus they need easy, preconfigured tools that will help them do the basically simple things they have to do, but that seem so difficult and intimidating to them.
I don't think that only junior programmers need user friendly tools. The less you need to think about the tool, the more brain power you have left for the real problem you are trying to solve. This is why tools such as Whole Tomato's Visual Assist are welcome at any level of programming.
I simply save a single large segment of data that contains all the necessary information
How do you "simply save" such a block of memory? If you are doing a simple memory dump into file, then all sorts of problems can crop-up. For example, you cannot save pointer in this manner because the next run of the same program will not necessarily have the same memory layout (i.e. even if same objects are created they may not be at the same address as the last run).
Other problems may occur... differences in alignment (because of change in compiler options), insertion of more variables in the next version of your program, differences in how compiler stores them (because you changed the compiler or compiler version)...
Basically, even if it works, it will be very difficult to attain any kind of portability (between program versions or platforms) for such save files.
Slashdot Mirror
For that matter, Intel emulates Intel's x86 architecture as much as AMD does (x86 instructions are translated into smaller RISC-like instructions on all modern CPUs).
In a sense, "instruction set" is to a modern CPU the same thing as "API" is to a piece of software.
Because this would mean they need to have an internal knowledge of the hardware (they were trying to write driver for), which would constitute violation of the hardware vendor's intellectual property.
This is because these are really not DOS games at all. They are games that access the hardware directly, and happen to run under OS (DOS) that lets them do that. Properly written Windows game that uses OS-provided API will still work.
Well, VisiCalc from 1981 (!) still works on modern Windows. You can try it out at: http://www.bricklin.com/history/vcexecutable.htm. Can you name any Mac program that can do that?
This might easily be reworded as: "There are just two kinds of software: the ones everybody complains about and the ones nobody uses."
If my calculation is right, a human-rated liner maglev launch system would be about 2000 km long. And I bet this would cost less then Iraq war while bringing much more benefit to the humanity.
Let's see...
d = V^2 / (2 * a)
d - distance
V - velocity
a - acceleration
By replacing V=11000 m/s^2 (approx. Earth's escape velocity) and a=29.43 m/s^2 (3g, reasonably comfortable for humans), you get:
d = 2055725.45 m = 2055 km (or 1 276.9178 miles)
Of course, if we factor-in air resistance, the needed length would increase, but I reckon not by too much...
...and, apparently, ORACLE - with "Oracle Developer Tools for Visual Studio .NET" (http://www.oracle.com/technology/tech/dotnet/tool s/index.html).
Yes, this seems to ease the load that is placed on the system during IntelliSense run. I used it for couple of weeks now and I didn't notice any ill effects.
Nope, this is 200 million light-years.
Only 200 light-years would be quite unimpressive... even our own galaxy is (much) larger than that (around 100,000 light years in diameter).
Why in heaven's name would anyone want to go back to the America? Because it's there? Get real.
Heck, why even leaving the Africa?
Or the trees we felt so comfortably hanging from?
OK, you get my drift... Our species survived by expanding both its physical and intellectual frontiers. Getting to the Moon and staying there (hopefully, in a self-sufficient manner) is just the continuation of the survival strategy that served us so well in the past.
If I could find such a thing, I'd probably still write all my CGI programs in C instead of only writing the most performance-critical pieces in C. As it stands, it's enough of a pain to make C CGI code work correctly that it isn't worth the trouble for me, and so I suffer the performance hit (generally of PHP).
You make some good points, especially about fragility of C on server-side, but I think you are missing the main reason of why CGI in C (and CGI in general) is sub-optimal solution in most circumstances:
CGI does not provide state management.
Basically, you end-up with having to do all the initialization steps all over again for each HTTP request - you are unable to retain non-trivial state, such as database connection or COM reference, across the user session.
We had this particular problem with one of our recent project that exposed certain PTC Pro/INTRALINK (which is a kind of CAD version control system) functionality to the Web. First version of our application was CGI written in C++ that talks directly to Pro/INTRALINK API. We ended up having to reestablish Pro/INTRALINK connection each time user requests a new page. New solution, which is combination of ASP.NET and COM wrapper around Pro/INTRALINK API, is able to initialize COM object (which then connects to Pro/INTRALINK and does some other one-off tasks) at the start of the user session and then retain reference to this COM object until user session expires.
Speed-up is several orders of magnitude.
An average PC nowadays holds enough power to run complex software programmed in an interpreted language (...)
2 15
Apparently, Intel does not agree with you:
http://www.behardware.com/news/lire/10-06-2006/#8
If even a relatively simple GUI of driver control panel is considered unsuitable for "non-native" technology, then it is understandable why more complex desktop applications are still far away from being routinely developed in such languages.
In my personal experience, I'm yet to see "non-native" application that does not feel sluggish compared to a similar native application.
For example, can your version control software tell you what text changed between two revisions of Word documents?
No, but Word itself can. Use "Tools / Compare and Merge Documents" (in Word 2003).
I don't know how long the parse & prepare phase takes but I know it is not zero so there could be some speed improvement too.
Preparation of SQL statement is potentially expensive and usually involves analysis (by DBMS optimizer) of many ways the statement can be executed (what indexes to use, and in what order, how to combine sub-queries etc.).
This analysis can be more expensive then statement execution itself (especially for well designed SELECT statements).
So if you execute your statement more then once, it is always a good idea to prepare it.
There is a great read from Fred Brooks - "The Mythical Man Month", that is still very relevant on this topic.
If your projects are small "fire and forget" endeavors, this might work well. However, if you projects are more long-term, requiring extensive maintenance period, you might be shooting yourself in the leg...
...the "busiest site on Earth" should be hosted on a farm of serious big iron and not x86i32.
;)
So Google is not "busiest site on Earth"
"Civilization advances by reducing the number of things one must do simultaneously."
I.e. specialization.
...very finely tuned to produce life
...if those rules were any different, the universe would be undifferentiated mush
"Life", as we know it.
"Mush", from our point of view.
Different laws of physic would make our kind of life impossible, but may well produce life that, while being different, is equally complex.
You would need fuel for this!
You are correct on lower performance, but this seems to be a lesser problem then tone of this discussion would suggest. Ex-development lead for this project says: "When I left the project, we were well over 80% performance on average compared to the native OpenGL driver."
I didn't think one Windows localization for all of the third world.
Rather, make one version per language.
Let me make a suggestion... Produce a non-crippled version of the Windows that is localized to specific language and cannot be converted into any other language. Then sell it at lower price in economically poorer market that speaks that language.
One could not just re-import such Windows in US (UK, Germany, France...), simply because prospective customers could not use the foreign language. Therefore higher price of "western" Windows is preserved.
Look at how long they sustained (technically) obsolete Win 9x line of their operating systems, instead of unifying on NT architecture.
If you look in Win32 API, you'll see plethora of "deprecated" functions that are there only to support the old applications.
This is nothing new - merely a consequence of how technology evolves, but illustrates quite nicely their reluctance to break compatibility just because it would be nice to unify on "newest and greatest". Hell, VisiCalc still runs on MS (except it is Windows this time)!
I doubt they will make anything to break compatibility with OpenGL applications. As other posted mentioned, MS's move could allow GPU chipmakers to slash driver development costs (with the tradeoff in performance), but there are competitive reasons this is unlikely to happen (CAD, Doom 4?), at least for the big chipmakers such as ATI/nVidia.
Both nVidia and ATI have professional products intended for CAD, that are based on essentially same architecture as their "mainstream" cards.
So, they have every incentive to write a good OpenGL driver regardless of what Microsoft is trying to do in the gaming market. That driver will then easily "trickle-down" to the mainstream...
Wast majority of people doing any sort of programming in the world are quite frankly not that good. Thus they need easy, preconfigured tools that will help them do the basically simple things they have to do, but that seem so difficult and intimidating to them.
I don't think that only junior programmers need user friendly tools. The less you need to think about the tool, the more brain power you have left for the real problem you are trying to solve. This is why tools such as Whole Tomato's Visual Assist are welcome at any level of programming.
I simply save a single large segment of data that contains all the necessary information
How do you "simply save" such a block of memory? If you are doing a simple memory dump into file, then all sorts of problems can crop-up. For example, you cannot save pointer in this manner because the next run of the same program will not necessarily have the same memory layout (i.e. even if same objects are created they may not be at the same address as the last run).
Other problems may occur... differences in alignment (because of change in compiler options), insertion of more variables in the next version of your program, differences in how compiler stores them (because you changed the compiler or compiler version)...
Basically, even if it works, it will be very difficult to attain any kind of portability (between program versions or platforms) for such save files.