Question about CMD.EXE implementation

Ask your support questions in here

Moderator: Moderator Team

CLASystems
Posts: 5
Joined: Thu Jun 18, 2009 10:16 am

Re: Question about CMD.EXE implementation

Post by CLASystems »

Essentially, it's the old "First, make it work. Second, make it work correctly. Finally, make it work better" idea.

I fully agree. Thus, adding in a non-standard non-default new feature -- that cannot possibly be mistakenly taken for normal usage, where said differences would at best only effect those on notice that known kludges would be broken if they went out of their way to wake up a feature with difficulty and then naively expect that the non-standard feature should somehow not break their kludge when their kludge works fine when you don't go out of the way to wake up the hard-to-invoke superset option -- is at the end of the list, as opposed to off the list. Since it can only be awakened on a need-to-know basis, it cannot be suspected of any form of incompatibility. [I am referring to the CMD problem here.]

But no one wants to tackle my problem with TweakUI? This is a curiousity because

a) It's not technically part of XP; it is a free add-on for XP that comes with notice of no support whatsoever.

b) It is flawed in that it doesn't do what it says it does, an aberration because clearly the intent is to accurately implement what it says it does, just that in a few spots it fails to. The behavioris a bug, not a feature. Just as in many other utilities, correcting something to work as advertised is not creating incompatibility, rather it's removing incompatibility, especially since it's not in an environment where anyone has any business depending on the wrong behavior being corrected. [We are not talking about "fixing" aberrrant system calls!]

c) If MS had anyone working on it, they would tend to fix the bugs I stumbled upon, and quite possibly in the future, they might do it [if the program can be made relevant to Vista and/or Win7 while also maintaining XP compatibility]. So why do we have to wait until they do it?

This is not a design slavish incompatibility with a theoretical goal. This is a limited case of a localized bug, pure and simple. It does not have any possibility whatsoever of interfering with anyone's "experience" other than the totally warped notion of someone who a) Knows it doesn't work, b) Compensates for the mixup knowing how it behaves as opposed to what it says it's supposed to do on the screen, c) Wouldn't welcome an MS version that documented the bugs fixed in the new release. I fail to see any wisdom in being bug compatible in such a utility. This is not a linkable program that would be used in some twisted far-fetched scenario; it's a user-friendly subset of REGEDIT after all, etc. [And REGEDIT works!]

As to the copout notion about open-source: Yes, anything can be changed. But you really don't want people actually doing it unless it is acceptable to a reasonable consensus. Don't make the linux mistake of creating "balkanized" versions. There should be just one REACTOS. Add on whatever you want, submit it, get it approved for universal consumption, and if relevant, make its not-in-XP aspects be either invisible or not functional except if optionally woken up with sufficient difficulty that users cannot get in trouble unless they delve into it, etc. Create guidelines for how to do these superset things so that one size does fit all, etc.

cjl [should REACTOS be totally compatible with XP to the point that we can apply MS's service packs too? :roll: ]

Haos
Test Team
Posts: 2954
Joined: Thu Mar 22, 2007 5:42 am
Contact:

Re: Question about CMD.EXE implementation

Post by Haos »

I doubt we woult pursuit such level of binary compatibility... apart from that such updates would be useless for ROS and not very workload efficient.
As for your problem, all depends on how would the impact of necessary fix. Its a very difficult issue and we are only discussing it theoretically at this moment. Some cmd - oriented developer should participate in it.

Goplat
Developer
Posts: 6
Joined: Wed Oct 12, 2005 1:04 am

Re: Question about CMD.EXE implementation

Post by Goplat »

CLASystems wrote:To my knowledge, the latest REACTOS 0.39 command interpreter is lock-step compatible with a limitation of XP:

In Windows 95/98/98SE/ME, COMMAND.EXE allows DIR command output to have the short-name version of a filename on the left and the long-form on the right.
To show both short and long filenames in Windows NT or ReactOS, you can use DIR /X. It doesn't look the same as Windows 9x (it goes "date, size, short name, long name" instead of "short name, size, date, long name") but it does give the same information.
On a related topic: Is there support existent or planned for the /OV switch
I assume you meant /V, the delayed-expansion switch. Yes; this is implemented in ReactOS.

CLASystems
Posts: 5
Joined: Thu Jun 18, 2009 10:16 am

Re: Question about CMD.EXE implementation

Post by CLASystems »

It is true that /X gives an alternative to the 9x implementation, but what of a new switch to change the default? [Why is a superset an incompatibility?]

As to the /V:ON, yes, that's what I meant; [I thought I corrected that in another post, my bad!]

I use that mode a lot to get at the handy dandy new features to make some of the commands make more sense, etc. The reason it has to be implemented in such an arcane way is to maintain compatibility with older code ignorant of the extension. You essentially are forced to use a second instance of CMD executing another .BAT/CMD file such as CMD /V:ON /K FOO.BAT. [Note: New features are added; due to the way REM etc are implemented, older comments might now be incompatible!]

Thus, my original point: Why not add a too-hard-to-accidentally-enable mode to get the new [and in this case retro, ala 9x] feature implemented? [And again, not as a high-priority, just that it be put on the list of some stuff to accomplish eventually.]

cjl

Z98
Release Engineer
Posts: 3379
Joined: Tue May 02, 2006 8:16 pm
Contact:

Re: Question about CMD.EXE implementation

Post by Z98 »

Because if people start depending on that feature, which would be ROS specific, we then end up breaking compatibility with Windows.

Post Reply

Who is online

Users browsing this forum: Semrush [Bot] and 1 guest