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

Question about CMD.EXE implementation

Post by CLASystems »

Hi to all.

I work with a lot of systems [no surpise!] and would like some specific info about the command-line interpreter.

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. This is the default there.

In WinXP you get the long-form or the short form on the right depending on /N or /-N, but not both.

Apparently, an older release for REACTOS made /-N work as in Win9x, which I consider a feature, and the WinXP implementation an aberration. By setting DIRCMD=/-N, I get what I want.

However, somewhere in more recent releases, this slavish XP limitation has apparently become the norm. Thus, the question: Can this earlier behavior be restored? [Or can my plea for restoring it be added to a wish-list or other feature request for an upcoming release, etc.]

Additionally, that older REACTOS CMD.exe is compatible with WinXP and Win 98SE as I have tested it. Is this kind of functionality still in the current CMD and expected to remain in the future?

On a related topic: Is there support existent or planned for the /OV switch when launching a second instance of CMD? This allows some advanced stuff beyond the norm in XP; not default because it is marginally syntax-incompatible with all prior versions, etc.

Thanks for any sane explanation in advance.

I really appreciate the overall REACTOS project; I hope I can submit some small amount of input into it as it progresses.

cjl
Lone_Rifle
Test Team
Posts: 802
Joined: Thu Apr 03, 2008 2:17 pm
Contact:

Re: Question about CMD.EXE implementation

Post by Lone_Rifle »

Hello CLASystems. We at ReactOS are aiming at compatibility with the NT family of OSes. As a result we have to aim to implement the dir command to closely mimic XP behaviour, as there may be batch/Powershell scripts (?) out there which actually depend on this - say, for example, if the script expects the timedate information on the last (note, not fourth!) column, but instead gets the long name information, which would in the old behaviour be on the fifth and thus last column. A potential compromise would be to include a ROS-only switch to mimic 9x behaviour, something I think would not go down well with the devs.
vicmarcal
Test Team
Posts: 2733
Joined: Mon Jul 07, 2008 12:35 pm

Re: Question about CMD.EXE implementation

Post by vicmarcal »

Hi,Goplat and me were working lately with the CMD.exe source code.
CLASystems wrote:Apparently, an older release for REACTOS made /-N work as in Win9x, which I consider a feature, and the WinXP implementation an aberration. By setting DIRCMD=/-N, I get what I want.

However, somewhere in more recent releases, this slavish XP limitation has apparently become the norm. Thus, the question: Can this earlier behavior be restored?

With earlier do you mean "earlier in Ros"?0.3.7 and 0.3.9 has same way of work.Maybe earlier?
Writting DIR /-N command shows you a short form and then the date.
Writting DIR /N shows you date and then long form
Writting DIR shows you date and then long form

Btw, ReactOS wants to behave in the same way that XP so you will have XP behaviour.
Of course you can change it in our cmd.exe code so you can have a personalized cmd.exe. Changing it isnt difficult, and you have skills.
That is the advantate of the open source, if you dont like a XP implementation you can go to the code and change the lines to restore a 98 previous way or work.
:)
CLASystems
Posts: 5
Joined: Thu Jun 18, 2009 10:16 am

Re: Question about CMD.EXE implementation

Post by CLASystems »

Thanks for the replies. The advantages of a community forum system! I hope in the future to be adding stuff instead of merely asking questions. [I have a much more than average amount of "experience" dealing with MS implementations of 98SE and XP.]

Yes, the CMD is a lot earlier that behaves the way I described. The file name is:

cmd-reactos-20010510.exe.

I fully understand about the compatibility. I myself have delved into all of the ingenious kludges such as getting the system drive by "calling" VOLUME.BAT and grabbing %3 and all that good stuff.

That's also why I asked about the enhanced mode. I misidentified it; I meant to ask about using another instance of CMD passed the /V:ON switch. I would hope someone has some information about this standard XP feature.

However, I think that REACTOS, given its history and attempts to describe some good stuff from the 9x era, owes us a ROS-only superset. That would involve waking up the feature with some "unsupported" [in the XP sense] switch or perhaps starting another instance with some new ROS switch such /9:ON. By making it that arcane to enable, there would not be any semblance of incompatibility or accidental usage, etc.

Just a general question:

What if it is found that something in XP is actually a bug. Do you slavishly immitate the mistake, or do you correct it? Just how far do you want to take "compatibility"? For example, Tweak UI has a small number of bugs; values aren't set correctly. Do you write a new utility that does it correctly or imitate the mistake?

My only point is there is a slippery slope between compatibility and sensibility.

cjl [Not really looking to have anyone 100% lock-step reimplement literally every last aspect of the "Windows Experience". Especially the sloth!]
GoBusto
Posts: 579
Joined: Fri Jan 25, 2008 11:13 am
Location: UK
Contact:

Re: Question about CMD.EXE implementation

Post by GoBusto »

CLASystems wrote:What if it is found that something in XP is actually a bug. Do you slavishly immitate the mistake, or do you correct it? Just how far do you want to take "compatibility"? For example, Tweak UI has a small number of bugs; values aren't set correctly. Do you write a new utility that does it correctly or imitate the mistake?
Generally, mistakes and bugs are cloned on the basis that some programs might exploit/rely on those bugs in order to run on Windows. One of the developers wrote a while ago that ReactOS is supposed to be an XP replacement, not a "perfect" implementation of the Win32/NT design (see here):
Ged Murphy wrote:Just so everyone knows the ReactOS stance on this:
- We must replicate the actual behaviour or the API's, not a personnal
preferred behaviour.
- MSDN should not be relied on, it isn't always correct.
- The Wine tests are designed for this exact thing, use them whenever
possible, or write your own test cases if it's not covered by them.
- The target usermode API we are aiming at is currently xp. Vista API's
(which we also implement) are an obvious exception to this.

If anyone feels compelled to improve the API's, then apply for a job at
Microsoft. This is where the API behavioural decisions are made, not in
ReactOS.

Hope that clears this up.
I'm sure that the developers would probably make exceptions in some cases, although there would probably be discussion about it on the mailing lists or IRC channels first. For example, Newsletter 46 seems to suggest that some of the context menu extensions - which are hard-coded in Windows - are not hard-coded in ReactOS.
There still remains a lot of work to do, including fixing up the context menus. Johannes' job is complicated by the fact that Microsoft did not properly implement all the context menu extensions, instead hardcoding some of them to prevent the user from deleting them. This is creating something of a mess as he tries to implement all of them in a standard fashion. His current solution is to rewrite the context menu handling and he is making good progress.
Of course, an actual developer would have to verify whether I'm right about that.
vicmarcal
Test Team
Posts: 2733
Joined: Mon Jul 07, 2008 12:35 pm

Re: Question about CMD.EXE implementation

Post by vicmarcal »

GoBusto: +1

I think you couldnt explain it better.

The problem of Bugs in XP is that some Apps expects those Bugs.Adding extra enhancements to our CMD or any other apps (without breaking the compatibility) as extra features would be nice(imo), but right now there are too much work to be done to win a basic compatibility. :)

We will be glad if you want to join our irc channel, there you can find any info you need :). Any collaboration(testing,debugging,patching..) is really appreciate.
hto
Developer
Posts: 2193
Joined: Sun Oct 01, 2006 3:43 pm

Post by hto »

IIRC, there are already some nonstandard features in CMD, which can be disabled / enabled by compile-time options. I think that more things could be added that way, if necessary.
vicmarcal
Test Team
Posts: 2733
Joined: Mon Jul 07, 2008 12:35 pm

Re: Question about CMD.EXE implementation

Post by vicmarcal »

The extra features comes(if i recall correctly) because we are using FreeDOS CMD,if i remember correctly the name of the project. So these features were kept.Some of them has been deleted nowadays, i still remember some weird rename function with more than 2 Paths to rename some folders at the same time, as the "feature" wasnt working correctly then it was removed and the rename function was fixed.
(It was my first Patch here btw ;) and Goplat almost killed me because i removed the Wildcards..hehe..so a second patch was sent...that oldies times ^^ )
CLASystems
Posts: 5
Joined: Thu Jun 18, 2009 10:16 am

Re: Question about CMD.EXE implementation

Post by CLASystems »

Hope I didn't open an old can of worms with this thread :!:

I just want to make my point a bit clearer; the responses now are confusing my own understanding:

I would think that for the most part, the zeal to be lock-step compatible has to do with how system calls [and any other variation of that idea] is perfectly understandable, high-priority, etc. I in no way am addressing anything like that.

However, when you start getting into badly-behaved XP quirks such as just exactly how a right-click property actually gets implemented, I question what audience are you addressing that would care? I fail to see just what being slavishly committed to imitating the mistakes accomplishes?

Going back to my TweakUI example: One obvious answer is to just write an alternate work-alike to be called whatever makes sense. Done properly, it would function on the REACTOS platform [once a lot of other undisputed work is done; we're not there yet, but it is clear what that entails] and by design would also work as a third-party application on XP.

But what if this utility was 100% the same in every conceivable way, except that the bugs regarding setting the particulars of the drive-letters-first settings were fixed in this version, instead of being "bug-compatible"? [Just so you know, there is documentation somewhere in MS that documents correctly what certain registry value bit settings do what. I use .reg files to set them accordingly. I then noticed that Tweak UI has seemingly the same settings within it. However, they don't work as stated; someone scrambled the menu actions and selection boxes relative to reality. Check it yourself if you wish. I can supply the .reg files themselves if you want]. I would assume the sane thing to do would be to proclaim a newer release and a list of bugfixes, not maintain a warped sense of status-quo.

The CMD processor represents a slight "mongrel" within this notion, because there are people who have implemented ingenious kludges that depend on precisely the expected behavior; making it "better" makes it incompatible. Thus, all of the known behaviors for all of the command actions as modifiable for all of the combinations of all of the known [and perhaps undocumented?] options have to work as the "original" does, to ensure none of these people's efforts would get broken.

However, there is nothing wrong with implementing a change where an unsupported switch option yields an error message instead becomes a functional option that changes as many rules as we would want. This is strictly speaking a superset implementation. Not a high priority perhaps, but something to be put on a wish-list, probably near the end if necessary, but certainly it at least deserves to ride in the back of the bus, or at least jump up onto the outside of the bus while it's moving.

Compromising some theoretical "pure" design has to be accomplished if doing so makes something function as needed. Again, implement some non-standard option to "purify" the implementation if you wish and implement it along the lines of a "debug kernel" approach as necessary.

But that's not the level of "compatibility" I am [attempting to] be addressing.

Consider WNTIPCFG, an obvious attempt to imitate the 95-up program Winipcfg. It has a quirk: There is inadequate screen real-estate should you have to chose more than one network connection from a list, while the original Winipcfg has that aspect done perfectly fine. Is there any point in slavishly cloning the needless difficulty in the weak implementation when the solution is obvious, namely better imitation of the original?

I hope I raised all of the appropriate firestorm issues on this narrow topic. Perhaps all of the best firefighters can appropriately snuff out the problems.

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

Re: Question about CMD.EXE implementation

Post by Haos »

The problem is that we cant perceive any of the feature in the global point of view. Every functionality is perceived by us via our our approach/view point. Things that are illogical to us, may as well be necessary for others applications to work. Thus "fixing" anything may result in decreased compatibility globally. Of course, some things should be tweakable, even beyond XP`s level, but it should be optional only and user should be warned of any possible consequences.
Radhad
Posts: 605
Joined: Wed Apr 12, 2006 5:09 pm
Contact:

Re: Question about CMD.EXE implementation

Post by Radhad »

And what about commands which do not exist in Windows but would help a lot? I think of tools like grep, which helps me a lot on my Linux based computers and I miss this function in Windows :)
The123king
Posts: 242
Joined: Mon Jun 16, 2008 6:51 pm

Re: Question about CMD.EXE implementation

Post by The123king »

Radhad wrote:And what about commands which do not exist in Windows but would help a lot? I think of tools like grep, which helps me a lot on my Linux based computers and I miss this function in Windows :)
ReactOS is opem-source. There';s nothing stopping you from implementing it yourself.
vicmarcal
Test Team
Posts: 2733
Joined: Mon Jul 07, 2008 12:35 pm

Re: Question about CMD.EXE implementation

Post by vicmarcal »

CLASystems wrote:Hope I didn't open an old can of worms with this thread
Heheh..not at all..we have worst worms and i think we have really clear which is ReactOS position.
CLASystems wrote:I would think that for the most part, the zeal to be lock-step compatible has to do with how system calls [and any other variation of that idea] is perfectly understandable, high-priority, etc. I in no way am addressing anything like that.
Sure, but also to provide to the final User a compatible GUI and compatible behavior. So they can feel comfortable inside ReactOS. That is why ReactOS has a basic notepad(as basic as XP notepad) instead a Notepad with Tabs. Or an Explorer who reminds the times of 98.
That´s the reason which explain why "right-click properties" are in the same place that are in Xp. And why it behaves in the same way as XP.
Of course i love the way of selecting that Linux has, but as you say that can go to a wishlist. Same with
Radhad wrote:how about commands which do not exist in Windows but would help a lot?
Why to a wishlist?
Because we dont have enough manpower to lose one dev creating new useful features or new commands or adding new useful apps.
Lone_Rifle
Test Team
Posts: 802
Joined: Thu Apr 03, 2008 2:17 pm
Contact:

Re: Question about CMD.EXE implementation

Post by Lone_Rifle »

CLASystems wrote: However, when you start getting into badly-behaved XP quirks such as just exactly how a right-click property actually gets implemented, I question what audience are you addressing that would care? I fail to see just what being slavishly committed to imitating the mistakes accomplishes?
Some of the devs do take your viewpoint, but the current coordinator has taken the position that we are to mimic in every manner possible; given Murphy's Law and Microsoft's general obscurity when it comes to laying down system-level documentation, the position is fairly reasonable.
GoBusto
Posts: 579
Joined: Fri Jan 25, 2008 11:13 am
Location: UK
Contact:

Re: Question about CMD.EXE implementation

Post by GoBusto »

From http://www.reactos.org/en/about_whatisreactos.html
Focus at present is on developing ReactOS to a stage where it is capable of running most Windows drivers and applications "out of the box." This does not mean that ReactOS will stop there, however; as new features are added to Windows, our developers be striving to incorporate such new features in future versions of ReactOS. Once the compatibility level has been reached, we may even choose to improve ReactOS beyond its Windows roots. These changes would be external from the main OS, and totally compatible with Windows, but they would add an extra advantage. For example, one of our goals is to have built-in POSIX compatibility, much like Windows Services for Unix. It could also be as simple as natively supporting multiple desktops however, instead of requiring a powertoy.
Essentially, it's the old "First, make it work. Second, make it work correctly. Finally, make it work better" idea.
Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests