> My point is, was always, that the functionality of the dos command prompt, the very API, was not abandoned, and exists even to this day. Here are a list of Windows commands: http://ss64.com/nt/ Most of these were taken from, and have the exact same API as the old dos commands.
The majority of that list are applications provided by the standard installation. Those commands are not features of the command line interpreter. A comparison to other OSs would be BusyBox, GNU coreutils, OSX command line developer tools, etc. As for the API remaining stable, not really, here is a comparison: http://www.robvanderwoude.com/batchcommands.php
> There is a whole set of functionality not possible on WinRT. For example, one cannot write a memory profiler like this in Metro: http://memprofiler.com/.
You can actually, it just wouldn't pass MS's review process and make it into the app store. That isn't a software change its a policy change.
> It might not be binary compatible with all existing Win32 programs, but it will exist, and it will not be Metro.
It would be binary compatible (assuming compilation for the same architecture). The executable format hasn't changed, they are just in-acting policies regarding what API's can be used via their app store review procedure just like apple does in its app store. Note that this is not the case between DOS programs and win32 programs, there is a complete binary compatibility break there.
The majority of that list are applications provided by the standard installation. Those commands are not features of the command line interpreter. A comparison to other OSs would be BusyBox, GNU coreutils, OSX command line developer tools, etc. As for the API remaining stable, not really, here is a comparison: http://www.robvanderwoude.com/batchcommands.php
> There is a whole set of functionality not possible on WinRT. For example, one cannot write a memory profiler like this in Metro: http://memprofiler.com/.
You can actually, it just wouldn't pass MS's review process and make it into the app store. That isn't a software change its a policy change.
> It might not be binary compatible with all existing Win32 programs, but it will exist, and it will not be Metro.
It would be binary compatible (assuming compilation for the same architecture). The executable format hasn't changed, they are just in-acting policies regarding what API's can be used via their app store review procedure just like apple does in its app store. Note that this is not the case between DOS programs and win32 programs, there is a complete binary compatibility break there.