Board index » cppbuilder » Re: About date format in DOS under XP

Re: About date format in DOS under XP


2006-03-28 07:02:31 PM
cppbuilder105
Yes it should be as the time does not stand at one point!
Vladimir Grigoriev
"Rudy Velthuis [TeamB]" < XXXX@XXXXX.COM >wrote in message
Quote
At 12:34:29, 28.03.2006, Vladimir Grigoriev wrote:

>There is one detail that we should take into account. Of cource while a
>program is developing it adds new features and possiblities. This is
>true also for DOS. New versions of DOS had new commands. Why in this
>case DOS simulation under XP can not have a new command as START?

The command interpreter is not just a DOS emulation. It is a real command
shell.
--
Rudy Velthuis [TeamB] rvelthuis.de/

"Barabási's Law of Programming: Program development ends when the program
does what you expect it to do - whether it is correct or not."
-- Albert-Lászl?Barabási
 
 

Re:Re: About date format in DOS under XP

At 11:32:54, 28.03.2006, Andrue Cope [TeamB] wrote:
Quote
Vladimir Grigoriev wrote:

>The same is true for DOS simulation in Windows.

But the command prompt is not a DOS simulation. It is a Win32 command
prompt. CMD.EXE happens to know how to create a DOS simulation and
perform some limited communication with it but that's all.
Exactly.
--
Rudy Velthuis [TeamB] rvelthuis.de/
"When the rich think about the poor, they have poor ideas."
-- Evita Peron
 

Re:Re: About date format in DOS under XP

At 12:29:23, 28.03.2006, Vladimir Grigoriev wrote:
Quote
When you run DIR CMD.EXE executes its
internal code.
Exactly. 32 bit code.
--
Rudy Velthuis [TeamB] rvelthuis.de/
"Fill what's empty, empty what's full, and scratch where it itches."
-- the Duchess of Windsor, when asked what is the secret of a long and
happy life
 

{smallsort}

Re:Re: About date format in DOS under XP

Vladimir Grigoriev wrote:
Quote
I think that a main goal of CMD.EXE was to provide support for DOS.
You are wrong. The main goal was to provide a command console for
Windows. As it happens it made sense to make it look like a DOS prompt
since that's what a lot of people were still used to but they didn't
have to.
According to "Inside Windows NT" (published by Microsoft press; ISBN
1-55516-481-X) the subsystems (as they are colloquially known)
originally comprised:
Win16
MS-DOS
OS/2
POSIX (IEEE 1003.1)
The intention was to provide a host environment for each of the above
that was close as possible to the original and to allow a limited
degree of interopability. The idea behind it was primarily backwards
compatibility. A major part of this was making the subsystems
protected. That basically means making them into 'sand pit'. Somewhere
the applications can play without impacting anything else. Basically
isolation chambers.
Nowhere is there any requirement for any subsystem to provide anything
other than the standard API. The functions you mentioned for LFNs were
already part of MS-DOS 7 - a product that never shipped on its own but
was what Win9x ran on top of. If MS-DOS hadn't had those added during
development of Win95 then you wouldn't have them in XP either.
What you are looking for here is an extension to the MS-DOS API in
order to provide functionality that never existed in the original
versions of the operating system. Now technically that would be
possible but where is the point? What you'd end up with is a textual
environment with access to the Win32 API and we already have that. Have
had ever since Windows NT appeared. You can create such applications
now with Builder:
\File\New\Other\Console Wizard
Worse still what do we do about MS-DOS applications developed using the
Win32 API that are run under true native MS-DOS? It just doesn't make
sense. Or are you expecting Microsoft to release MS-DOS 8 that includes
support for the Win32 API?
As a software developer you should understand that even the world's
largest software developer isn't going to develop two projects that
both do exactly the same thing.
Quote
And I will not wonder if I will know
that the structure of CMD.EXE almost the same as internal structure of
COMMAND.COM.
Hardly. On my Win2k system COMMAND.COM is 50kB and CMD.EXE is 231kB.
Furthermore Int 0x21 is not available to CMD.EXE because it's a user
mode application.
Quote
Of cource I don't know how CMD.EXE is written but I am shure that it
internal DIR command should be based on those features and
possibilities that base DOS environment can provide.
What *base* operating system? Win32 is /historically/ derived from
MS-DOS but it isn't MS-DOS. It's a completely different operating
system. There is *no* MSDOS on your XP machine. There is an emulator
that acts a lot like MSDOS to those applications that run within it but
then the same kind of emulator exists on Linux and even Apple
Macintoshes.
This is the point that you don't seem to be getting. The last version
of Windows that could in anyway be said to be running on top of MS-DOS
was Windows 98. WinNT and descendents (including XP) DO NOT RUN ON TOP
OF DOS AND WERE COMPLETELY REWRITTEN FROM THE GROUND UP.
Windows XP is as closely related to Unix and MacOS as it is to DOS. I
dare say that some of the MS-DOS development team ended up working on
Windows and therefore some of their concepts got carried through
(things like drive letters and using '\' instead of '/' in paths) but
that's as far as it goes.
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html
 

Re:Re: About date format in DOS under XP

Vladimir Grigoriev wrote:
Quote
This is true
also for DOS. New versions of DOS had new commands. Why in this case
DOS simulation under XP can not have a new command as START?
Technically, no reason at all. The result would not be MS-DOS but hey -
whatever floats your boat.
If your complaint is about the technical possibility then fine. I will
happily agree that the MSDOS subsystem could be extended to provide
full access to the Win32 API. However I would respond by saying that
there's no point and I doubt very much that Microsoft have bothered.
Perhaps you could email them and ask for the source code for NTVDM.EXE
and make the changes yourself. I know that would never happen but in
all honesty that's what is needed to meet your demands.
Practically:Why bother? Development costs money and the START command
already exists. The entire environment you want already exists and has
done for nearly a decade.
The only people that /need/ MSDOS now are people using it where an
emulator is never going to be good enough. That is for applications
where direct unhindered access to the hardware is essential. We need it
for our disk imaging and recovery software because Windows (quite
rightly) won't let us mess about with storage media directly. We also
need it because sometimes you have a very limited window in which to
get a drive to come ready and you can't afford to wait half an hour
while Windows boots.
Whatever your application is you either shouldn't even be trying to run
it under Windows or else you should port it to Win32.
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html
 

Re:Re: About date format in DOS under XP

At 13:00:53, 28.03.2006, Vladimir Grigoriev wrote:
Quote
From historical point of view of developing DOS and then Windows (at
first as graphical DOS) I consider DIR as DOS command.
DIR existed before it, though.
--
Rudy Velthuis [TeamB] rvelthuis.de/
"I believe that sex is a beautiful thing between two people. Between
five, it's fantastic." -- Woody Allen
 

Re:Re: About date format in DOS under XP

Vladimir Grigoriev wrote:
Quote
Yes it should be as the time does not stand at one point!
Yes it does. Microsoft ceased development and support for it several
years ago. MS-DOS as provided by Microsoft is dead. Like CP/M it had
its day and like CP/M it is now largely consigned to history.
There are a number of public projects offering operating systems that
are based on the Digital Research code base (DR-DOS) and it would be
worth asking some of the developers about accessing the Win32 API.
Unfortunately (well actually it's one of the best aspects of Windows)
MS-DOS applications are constrained by NTVDM. There is nothing you can
write in any language (even assembly or machine language) that will let
you break out of that emulator.
If Microsoft haven't provided generic access to the Win23 API from
within the emulator then that's that. Such is the power of the modern
protected mode CPU.
As I've already posted:Windows XP is not DOS. It doesn't run DOS. It
provides an emulator that gives DOS applications (including
COMMAND.COM) their own little PC to play on. No one is interested in
developing that emulator any further because no one cares.
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html
 

Re:Re: About date format in DOS under XP

"Andrue Cope [TeamB]"
Quote
There is *no* MSDOS on your XP machine. There is an emulator
that acts a lot like MSDOS to those applications that run within it but
then the same kind of emulator exists on Linux and even Apple
Macintoshes.
I fully agree with you Andrue. But there is one point on which I disagree
with you. I think that any emulator should be based only on those features
that are provided or realised by the original system or at least declared in
the original system.
As for my question my experiment says me that there should be some interrupt
service that allows to get date format. Perhaps Microsoft as usual *gorgot*
to introduce this service to people.
Vladimir Grigoriev
 

Re:Re: About date format in DOS under XP

Andrue Cope [TeamB] wrote:
Quote
Or are you expecting Microsoft to release MS-DOS 8 that includes
support for the Win32 API?
Hmmm. According to Wikipedia there was an MS-DOS 8. There was even a PC
DOS 2000. OTOH they weren't exactly swollen with new features:
en.wikipedia.org/wiki/MS-DOS
"MS-DOS 7.0 - August 1995 - Shipped embedded in Windows 95. Included
Logical block addressing and Long File Name (LFN) support
MS-DOS 7.1 - August 1996 - Shipped embedded in Windows 95B (OSR2) (and
Windows 98 in June 1998). Added support for FAT32 file system
MS-DOS 8.0 - September 2000 - Shipped embedded in Windows ME. Last
version of MS-DOS. Removes SYS command, ability to boot to command line
and other features
PC DOS 2000 - Year 2000-compliant version with minor additional
features. Final member of the MS-DOS family "
MS-DOS 8 was lobotomised and PC DOS 2000 had its date/time handling
tweaked.
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html
 

Re:Re: About date format in DOS under XP

"Vladimir Grigoriev" < XXXX@XXXXX.COM >wrote in message
Quote
Remy, I have understood what you have said. But I'd like to note
that I can use long file names inside my DOS program running on
XP. There are corresponding DOS servirces as 714Eh and 714Fh.
Those are *not* DOS services. Those are 32-bit Windows API services. They
were introduced in Windows 95. They are listed in MSDN under the "Windows
9x Programming" section. Again, because the DOS command window is actually
a 32-bit application that emulates DOS, but not *not* pure DOS, it is using
the 32-bit Windows API for everything it does internally.
In fact, those Interrupts are wrapped by the FindFirstFile() and
FindNextFile() functions. You should be using those functions, not the
Interrupts directly.
Any way you try to look at it, everything you are trying to do comes back to
the 32-bit Windows API. Everything you are doing has NOTHING to do with
pure DOS at all. So you really need to stop trying to justify everything as
being DOS, because IT IS NOT DOS!
Quote
And I use indeed in my DOS program.
Then you are, in fact, already using the 32-bit Windows API in your console
application. So there is no reason why you can't also use the 32-bit
Windows API for the locale settings that you were originally asking for.
Gambit
 

Re:Re: About date format in DOS under XP

Andrue Cope [TeamB] < XXXX@XXXXX.COM >wrote:
Quote
[...]
This is the point that you don't seem to be getting. The last version
of Windows that could in anyway be said to be running on top of MS-DOS
was Windows 98. [...]
Um, what about ME?
Schobi
 

Re:Re: About date format in DOS under XP

"Andrue Cope [TeamB]"
Quote
I will happily agree that the MSDOS subsystem could be extended to provide
full access to the Win32 API.
I don' want such many possibilities! I have only one unpretentious desire
for getting short date format and nothing more! If emulated DOS command DIR
can use short date format I also want to use this feature!
On the other hand I think it was incorrectly to include this possibility in
DIR command. Either - or. (Sorry for my bad English)
Vladimir Grigoriev
 

Re:Re: About date format in DOS under XP

Gambit
Quote
Then you are, in fact, already using the 32-bit Windows API in your console
application.
I'd like to note that in my program I use indeed interrupt 21h servicers
714Eh and 714Fh. You wanted to say that they are part of Win 32 API? But
from the pure code inside my program they are servirces of DOS and nothing
more.
Vladimir Grigoriev
 

Re:Re: About date format in DOS under XP

Vladimir Grigoriev wrote:
Quote
I have only one unpretentious desire
for getting short date format and nothing more!
Well yes I'm exagerating to try and make the point. You are still
asking for an extension to an API that is no longer in production and
no longer supported. Worse still in order to provide that extension
Microsoft would have to modify one of their protected subsystems. Then
you'd have extended an API in a way that would be meaningless outside
of some arbitrary emulator. To cap it all off the functionality you
require would be readily available if only you port your application to
Win32.
I hope none of our responses have been too strong in our discussion
here but ultimately the problem you face is that you're developing for
a dead operating system in an environment it was never intended to run
under. It simply isn't reasonable to expect it to be kept up to date.
It does what it does and you have to take it or leave it. My
recomendation would be that you leave it :)
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html
 

Re:Re: About date format in DOS under XP

Vladimir Grigoriev wrote:
Quote
I think that any emulator should be based only on those features
that are provided or realised by the original system or at least
declared in the original system.
That would be a bit harsh. I think Microsoft were right in wanting a
degree of operability.
Quote
As for my question my experiment says me that there should be some
interrupt service that allows to get date format. Perhaps Microsoft
as usual gorgot to introduce this service to people.
No they just never got around to it or didn't feel it was important
enough. Back in the days of MS-DOS you couldn't go wasting RAM on
trivial things.
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html