Want a Batch Code for renaming a file with Current Date,Time Stamp and With Folder Name
sat
Description:
Consider I have 5 files (*.jpg) in my Folder "Test".
[eg:File name are 1) one.jpg, 2) two.jpg, 3)three.jpg, 4)
four.jpg, 5) five.jpg.]
I want all these (*.jpg) to be renamed as follows....
1)Test - 11-01-2007 131223.jpg
2)Test - 11-01-2007 131643.jpg
3)Test - 11-01-2007 131813.jpg
4)Test - 11-01-2007 132243.jpg
5)Test - 11-01-2007 132543.jpg
Note: File Name =>[FolderName - Date+Time Stamp].
foxidrive
Multipost - see alt.msdos
Richard Bonner
> Consider I have 5 files (*.jpg) in my Folder "Test".
> [eg:File name are 1) one.jpg, 2) two.jpg, 3)three.jpg, 4)
> four.jpg, 5) five.jpg.]
> I want all these (*.jpg) to be renamed as follows....
> 1)Test - 11-01-2007 131223.jpg
> 2)Test - 11-01-2007 131643.jpg
> 3)Test - 11-01-2007 131813.jpg
> 4)Test - 11-01-2007 132243.jpg
> 5)Test - 11-01-2007 132543.jpg
*** Depending on your DOS version, try this:
FOR %%F IN ("*.JPG") DO REN "%%F" "11-01-2007 %%F")
Richard Bonner
http://www.chebucto.ca/~ak621/DOS/
Dr J R Stockton
oups.com>, Fri, 12 Jan 2007 01:12:01, sat <kakas...@yahoo.co.in>
posted:
>Please send me the Batch code for the Below Description.
*** DO NOT MULTIPOST - Indians are supposed to be well-mannered ***
>I want all these (*.jpg) to be renamed as follows....
>
> 1)Test - 11-01-2007 131223.jpg
Silly. You should use YYYY-MM-DD, as per ISO; if the date has
separators, it's better for the time also to have separators; file names
are certainly allowed to have spaced on some on-topic OSs, but it's
better to avoid them if other punctuation is reasonable.
See my response to jscully79 dated a few minutes ago,
--
(c) John Stockton, Surrey, UK. REPLYyyww merlyn demon co uk Turnpike 6.05.
Web <URL:http://www.uwasa.fi/~ts/http/tsfaq.html> -> Timo Salmi: Usenet Q&A.
Web <URL:http://www.merlyn.demon.co.uk/news-use.htm> : about usage of News.
No Encoding. Quotes precede replies. Snip well. Write clearly. Mail no News.
Tika
> *** DO NOT MULTIPOST - Indians are supposed to be well-mannered ***
I hope you do know what kind of cr.. this response is.
> Silly. You should use YYYY-MM-DD, as per ISO; if the date has
> separators, it's better for the time also to have separators; file names
> are certainly allowed to have spaced on some on-topic OSs, but it's
> better to avoid them if other punctuation is reasonable.
Well, if you know of any (portable) way without using third-party
utilites on Windows that gives you the option to obtain the date and
time in this standard, please let us all know. We're still waiting for
MS to fix this.
Until then, one will have to use utilites like Logtext, DOFF, or HLDate.
foxidrive
>> Silly. You should use YYYY-MM-DD, as per ISO; if the date has
>> separators, it's better for the time also to have separators; file names
>> are certainly allowed to have spaced on some on-topic OSs, but it's
>> better to avoid them if other punctuation is reasonable.
>
>Well, if you know of any (portable) way without using third-party
>utilites on Windows that gives you the option to obtain the date and
>time in this standard, please let us all know. We're still waiting for
>MS to fix this.
>
>Until then, one will have to use utilites like Logtext, DOFF, or HLDate.
Roll your own. :)
@echo off
:: Code by Herbert Kleebauer
echo Bj@jzh`0X-`/PPPPPPa(DE(DM(DO(Dh(Ls(Lu(LX(LeZRR]EEEUYRX2Dx=>d_t.com
echo 0DxFP,0Xx.t0P,=XtGsB4o@$?PIyU WwX0GwUY Wv;ovBX2Gv0ExGIuht6>>d_t.com
echo LisqMz`wGH@wKuur`G@w?ogBgGG}G?j_egoNOG?w?`gBLksqgG`w?WgBgG>>d_t.com
echo G}G?R_MgoNMy?wSx@W?s?W?@zAB`LrFuBLyt~vuco{@LuKooD?BFHqrIcP>>d_t.com
echo _sdDxb1T??=?rILO_sdDqx1T??=?rILO_sdDnl1T??=?rILO_sdD`c1T??>>d_t.com
echo =?rILO_sdDgg1T??=?rILO_sdDll1T??=?rILO_sdDrr1T??=??IL?0xxx>>d_t.com
d_t.com>d_t.bat
call d_t.bat
del d_t.com
del d_t.bat
echo century: %_cy%
echo year: %_yr%
echo month: %_mo%
echo day: %_da%
echo hour: %_hh%
echo minute: %_mm%
echo second: %_ss%
Tika
> Roll your own. :)
Yep, writing machine code into an executabla does the trick.
Still not satisfying Average Joe.
Believe me, a few lines of C code will do the trick as well, and I
believe the same applies to Basic, Pascal, COBOL, FORTRAN, etc.
Any language will do, that I'm sure of.
We were talking about a batch file solution, and this is still not
possible because the boys (and maybe girls) in Redmond are still
sleeping when it comes to a standardized date and time format.
Timo Salmi
> Dr J R Stockton wrote:
>> You should use YYYY-MM-DD, as per ISO;
> Well, if you know of any (portable) way without using third-party
> utilites on Windows that gives you the option to obtain the date and
> time in this standard, please let us all know. We're still waiting
> for MS to fix this.
The last sentence would indicate that you also consider the newer OS
versions, not just the on-topic MS-DOS+Win../95/98/Me. The current OSes
come with Visual Basic Script which allows portable solutions for the
date elements, as e.g. in my NT/2000/XP script FAQ tscmd.
All the best, Timo
--
Prof. Timo Salmi ftp & http://garbo.uwasa.fi/ archives 193.166.120.5
Department of Accounting and Business Finance ; University of Vaasa
mailto:t...@uwasa.fi <http://www.uwasa.fi/~ts/> ; FIN-65101, Finland
Useful script files and tricks ftp://garbo.uwasa.fi/pc/link/tscmd.zip
Dr J R Stockton
14 Jan 2007 04:44:16, Timo Salmi <t...@uwasa.fi> posted:
>Tika <ti...@doesntexist.org> wrote:
>> Dr J R Stockton wrote:
>>> You should use YYYY-MM-DD, as per ISO;
>
>> Well, if you know of any (portable) way without using third-party
>>utilites on Windows that gives you the option to obtain the date and
>>time in this standard, please let us all know. We're still waiting
>>for MS to fix this.
>
>The last sentence would indicate that you also consider the newer OS
>versions, not just the on-topic MS-DOS+Win../95/98/Me. The current OSes
>come with Visual Basic Script which allows portable solutions for the
>date elements, as e.g. in my NT/2000/XP script FAQ tscmd.
Equally, WSH comes with JScript.
Some date/time tasks can be more readily done in VBScript; quite a few
can equally easily be done in either; a fair number can be done either
only or better in JScript.
JScript has the advantage that knowledge of it is applicable, in
general, to scripting in Web pages; only some browsers have VBScript.
VBScript has the advantage that it is used to a greater extent than
JScript in system administration (AFAICS from newsgroups).
On-topic Win98, at least, has VBS & JS.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 IE 6
news:comp.lang.javascript FAQ <URL:http://www.jibbering.com/faq/index.html>.
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
Richard Bonner
*** A batch file solution is possible by placing each part of the date
into a variable, then re-ordering the variable. I am very busy right
now, but part of the operation uses DATE and the pre-Win95 FOR command
that parses file names via the `/'. Modern versions of DOS and Windows CLI
can do it directly via FOR.
Richard
Tika
> *** A batch file solution is possible by placing each part of the date
> into a variable, then re-ordering the variable. I am very busy right
> now, but part of the operation uses DATE and the pre-Win95 FOR command
> that parses file names via the `/'.
That's why it doesn't work. There are at least several cases where it
goes wrong.
C:\>date /t
2007-01-20
C:\>date /t
20/01/2007
C:\>date /t
01/20/2007
C:\>date /t
20.01.2007
C:\>date /t
01.20.2007
How do you want to handle this?
No chance. ;)
This works reliably (taken from http://www.logtext.de/logtextcmd_en.html):
FOR /F "eol=; tokens=1-9,* delims=-:.+ " %%a IN ('LOGTEXT stdout ""
ECHO_ONLY') DO (
SET iYear=%%a
SET iMonth=%%b
SET iDay=%%c
SET iHour=%%d
SET iMin=%%e
SET iSec=%%f
SET iMis=%%g
SET iOfH=%%h
SET iOfM=%%i
)
Tika
> This works reliably (taken from http://www.logtext.de/logtextcmd_en.html):
Of course not under DOS, but on NT, 2000, XP, etc.
Todd Vargo
> Richard Bonner wrote:
> > *** A batch file solution is possible by placing each part of the date
> > into a variable, then re-ordering the variable. I am very busy right
> > now, but part of the operation uses DATE and the pre-Win95 FOR command
> > that parses file names via the `/'.
>
> That's why it doesn't work. There are at least several cases where it
> goes wrong.
>
> C:\>date /t
> 2007-01-20
>
> C:\>date /t
> 20/01/2007
>
> C:\>date /t
> 01/20/2007
>
> C:\>date /t
> 20.01.2007
>
> C:\>date /t
> 01.20.2007
>
> How do you want to handle this?
> No chance. ;)
Please show equivalent "ECHO %date%" outputs for each of above.
>
> This works reliably (taken from http://www.logtext.de/logtextcmd_en.html):
>
> FOR /F "eol=; tokens=1-9,* delims=-:.+ " %%a IN ('LOGTEXT stdout ""
> ECHO_ONLY') DO (
> SET iYear=%%a
> SET iMonth=%%b
> SET iDay=%%c
> SET iHour=%%d
> SET iMin=%%e
> SET iSec=%%f
> SET iMis=%%g
> SET iOfH=%%h
> SET iOfM=%%i
> )
Does Georg Pohl's Date_Var.com not work on NTish systems?
http://home7.inet.tele.dk/batfiles/main/pohlutil.htm
Was the point that add on utilities are more portable/reliable?
--
Todd Vargo
(Post questions to group only. Remove "z" to email personal messages)
Dr J R Stockton
Jan 2007 02:41:08, Richard Bonner <ak...@chebucto.ns.ca> posted:
>*** A batch file solution is possible by placing each part of the date
>into a variable, then re-ordering the variable. I am very busy right
>now, but part of the operation uses DATE and the pre-Win95 FOR command
>that parses file names via the `/'. Modern versions of DOS and Windows CLI
>can do it directly via FOR.
Be sure to include in comment warnings about the (expected) dependence
of any pure-DOS approach on the date format selected in the OS.
01/02/03 and 09/08/07 could each reasonably represent any one of three
dates.
Use NOWMINUS, via sig line 3; if you insist on FFF dates, you can use
COLS to rearrange.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 IE 6.
Web <URL:http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/> - see 00index.htm
Dates - miscdate.htm moredate.htm js-dates.htm pas-time.htm critdate.htm etc.
Richard Bonner
> Richard Bonner wrote:
> > *** A batch file solution is possible by placing each part of the date
> > into a variable, then re-ordering the variable. I am very busy right
> > now, but part of the operation uses DATE and the pre-Win95 FOR command
> > that parses file names via the `/'.
> That's why it doesn't work. There are at least several cases where it
> goes wrong.
*** The `/' in the FOR command was undocumented, but it worked as an
escape character with the result being a name parser. I don't know all
of the details because by the time I saw it discussed, I was using XSET
for environmental date work. It allows *any* date format and works on all
DOS systems.
Richard Bonner
http://www.chebucto.ca/~ak621/DOS/
Richard Bonner
> Jan 2007 02:41:08, Richard Bonner <ak...@chebucto.ns.ca> posted:
> >*** A batch file solution is possible by placing each part of the date
> >into a variable, then re-ordering the variable. I am very busy right
> >now, but part of the operation uses DATE and the pre-Win95 FOR command
> >that parses file names via the `/'. Modern versions of DOS and Windows CLI
> >can do it directly via FOR.
> Be sure to include in comment warnings about the (expected) dependence
> of any pure-DOS approach on the date format selected in the OS.
> 01/02/03 and 09/08/07 could each reasonably represent any one of three
> dates.
> --
> John Stockton
*** Good point, John.
For my own batch-file usage, I have set them up tp recognise yyyy-mm-dd
typed at the command line.
Richard Bonner
http://www.chebucto.ca/~ak621/DOS/
Tika
> Tika wrote:
>> Richard Bonner wrote:
>>> *** A batch file solution is possible by placing each part of the date
>>> into a variable, then re-ordering the variable. I am very busy right
>>> now, but part of the operation uses DATE and the pre-Win95 FOR command
>>> that parses file names via the `/'.
>> That's why it doesn't work. There are at least several cases where it
>> goes wrong.
>>
>> C:\>date /t
>> 2007-01-20
>>
>> C:\>date /t
>> 20/01/2007
>>
>> C:\>date /t
>> 01/20/2007
>>
>> C:\>date /t
>> 20.01.2007
>>
>> C:\>date /t
>> 01.20.2007
>>
>> How do you want to handle this?
>> No chance. ;)
>
> Please show equivalent "ECHO %date%" outputs for each of above.
They are exactly the same as the 'date /t' output.
>> This works reliably (taken from http://www.logtext.de/logtextcmd_en.html):
>>
>> FOR /F "eol=; tokens=1-9,* delims=-:.+ " %%a IN ('LOGTEXT stdout ""
>> ECHO_ONLY') DO (
>> SET iYear=%%a
>> SET iMonth=%%b
>> SET iDay=%%c
>> SET iHour=%%d
>> SET iMin=%%e
>> SET iSec=%%f
>> SET iMis=%%g
>> SET iOfH=%%h
>> SET iOfM=%%i
>> )
>
> Does Georg Pohl's Date_Var.com not work on NTish systems?
> http://home7.inet.tele.dk/batfiles/main/pohlutil.htm
Who wants a 16 bit application on his Windows system? We live in the
21st century.
Tika
> Tika wrote:
>> Richard Bonner wrote:
>>> *** A batch file solution is possible by placing each part of the date
>>> into a variable, then re-ordering the variable. I am very busy right
>>> now, but part of the operation uses DATE and the pre-Win95 FOR command
>>> that parses file names via the `/'.
>
>> That's why it doesn't work. There are at least several cases where it
>> goes wrong.
>
> *** The `/' in the FOR command was undocumented, but it worked as an
> escape character with the result being a name parser. I don't know all
Again, this is exactly why it can't work. You don't know the date format
of the target machine, you can't even guess it. No chance without a
third-party utility.
Todd Vargo
"Tika" <ti...@doesntexist.org> wrote in message
news:kMTuh.77973$UC.4...@newsfe5-win.ntli.net...
> Todd Vargo wrote:
> > Tika wrote:
> >> Richard Bonner wrote:
> >>> *** A batch file solution is possible by placing each part of the
date
> >>> into a variable, then re-ordering the variable. I am very busy right
> >>> now, but part of the operation uses DATE and the pre-Win95 FOR command
> >>> that parses file names via the `/'.
> >> That's why it doesn't work. There are at least several cases where it
> >> goes wrong.
> >>
> >> C:\>date /t
> >> 2007-01-20
> >>
> >> C:\>date /t
> >> 20/01/2007
> >>
> >> C:\>date /t
> >> 01/20/2007
> >>
> >> C:\>date /t
> >> 20.01.2007
> >>
> >> C:\>date /t
> >> 01.20.2007
> >>
> >> How do you want to handle this?
> >> No chance. ;)
> >
> > Please show equivalent "ECHO %date%" outputs for each of above.
>
> They are exactly the same as the 'date /t' output.
I know what you are saying to Bonner but your output excludes DOW.
==== Win95cmd capture
E:\>date/t
Sun 01/28/2007
====
> >> This works reliably (taken from
http://www.logtext.de/logtextcmd_en.html):
> >>
> >> FOR /F "eol=; tokens=1-9,* delims=-:.+ " %%a IN ('LOGTEXT stdout ""
> >> ECHO_ONLY') DO (
> >> SET iYear=%%a
> >> SET iMonth=%%b
> >> SET iDay=%%c
> >> SET iHour=%%d
> >> SET iMin=%%e
> >> SET iSec=%%f
> >> SET iMis=%%g
> >> SET iOfH=%%h
> >> SET iOfM=%%i
> >> )
> >
> > Does Georg Pohl's Date_Var.com not work on NTish systems?
> > http://home7.inet.tele.dk/batfiles/main/pohlutil.htm
>
> Who wants a 16 bit application on his Windows system? We live in the
> 21st century.
Because this is alt.msdos.batch not a.m.b.nt. The example you posted is not
"portable" because it uses CMD.EXE specific batch code therefore it can not
be considered "reliable".
Timo Salmi
> Todd Vargo wrote:
>> Tika wrote:
>>> Richard Bonner wrote:
>>>> *** A batch file solution is possible by placing each part of the
>>>> date
>>>> into a variable, then re-ordering the variable. I am very busy right
>>>> now, but part of the operation uses DATE and the pre-Win95 FOR command
>>>> that parses file names via the `/'.
>>> That's why it doesn't work. There are at least several cases where it
>>> goes wrong.
>>> C:\>date /t
>>> 2007-01-20
The same date issue has been discussed time and again both here and in
alt.msdos.batch.nt. Furthermore, obviously cmd.exe is being assumed
which is not a good assumption in for MS-DOS+Win../95/98/Me
>> Does Georg Pohl's Date_Var.com not work on NTish systems?
>> http://home7.inet.tele.dk/batfiles/main/pohlutil.htm
> Who wants a 16 bit application on his Windows system? We live in the
> 21st century.
No, we don't in alt.msdos.batch, but do in alt.msdos.batch.nt
> You don't know the date format of the target machine, you can't even
> guess it. No chance without a third-party utility.
Would you kindly revisit what has been written to you previously on a
similar comment you have made before in this same thread
http://www.google.com/groups?selm=45a99902$0$24627$9b536df3%40news.fv.fi
All the best, Timo
--
Prof. Timo Salmi ftp & http://garbo.uwasa.fi/ archives 193.166.120.5
Department of Accounting and Business Finance ; University of Vaasa
mailto:t...@uwasa.fi <http://www.uwasa.fi/~ts/> ; FIN-65101, Finland
Useful batch files and tricks ftp://garbo.uwasa.fi/pc/link/tsbat.zip
Tika
> I know what you are saying to Bonner but your output excludes DOW.
You are mistaken here. You might be right on your US system, but not on
others. That's why I'm saying that you need a third-party tool like
HLDate, DOFF, or Logtext. Or for pure DOS anything that's only 16 bit
DOS (maybe this Date_Var.com). Otherwise there's no portable solution.
> ==== Win95cmd capture
> E:\>date/t
> Sun 01/28/2007
> ====
This is exactly what I get here:
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\>date /t
2007-01-28
C:\>
>>> Does Georg Pohl's Date_Var.com not work on NTish systems?
>>> http://home7.inet.tele.dk/batfiles/main/pohlutil.htm
>> Who wants a 16 bit application on his Windows system? We live in the
>> 21st century.
>
> Because this is alt.msdos.batch not a.m.b.nt. The example you posted is not
> "portable" because it uses CMD.EXE specific batch code therefore it can not
> be considered "reliable".
Reliable is what runs on a target system without considering locale
settings. There's always a system that can't be supported.
foxidrive
>Todd Vargo wrote:
>> I know what you are saying to Bonner but your output excludes DOW.
>
>You are mistaken here. You might be right on your US system, but not on
>others. That's why I'm saying that you need a third-party tool like
>HLDate, DOFF, or Logtext. Or for pure DOS anything that's only 16 bit
>DOS (maybe this Date_Var.com). Otherwise there's no portable solution.
Roll your own. :) What's not portable about this?
Richard Bonner
> Who wants a 16 bit application on his Windows system? We live in the
> 21st century.
*** Small 16-bit applications run lickety split on modern computers.
Regardless, what difference does it make if it works as required?
Richard Bonner
http://www.chebucto.ca/~ak621/DOS/
Richard Bonner
> Richard Bonner wrote:
> > *** The `/' in the FOR command was undocumented, but it worked as an
> > escape character with the result being a name parser.
> Again, this is exactly why it can't work. You don't know the date format
> of the target machine, you can't even guess it. No chance without a
> third-party utility.
*** Ahh, yes, I see at what you are getting. You are correct. One can't
parse a string without knowing its format.
Richard Bonner
http://www.chebucto.ca/~ak621/DOS/
Herbert Kleebauer
> That's why it doesn't work. There are at least several cases where it
> goes wrong.
> 2007-01-20
> 20/01/2007
> 01/20/2007
> 20.01.2007
> 01.20.2007
>
> How do you want to handle this?
> No chance. ;)
No chance?
You already have been given a solution without any external
tool (by including binary code within the batch which isn't
more "external" than the batch code itself).
> Who wants a 16 bit application on his Windows system? We live in the
> 21st century.
What has the CPU mode (protected mode or V86 mode) to do with the
century? Maybe you can explain it to me.
> You are mistaken here. You might be right on your US system, but not on
> others. That's why I'm saying that you need a third-party tool like
> HLDate, DOFF, or Logtext. Or for pure DOS anything that's only 16 bit
> DOS (maybe this Date_Var.com). Otherwise there's no portable solution.
Are you sure again? If there are no other than the five formats you have
given above, then in W2k/XP the following should work (untested) but
nobody would be crazy enough to use such code instead of a few lines
of included ascii assembler code (but at least it is far better than
relying on external programs):
@echo off
setlocal
:loop
set d="%date%"
echo.>_._
if not %d%=="%date%" goto :loop
for /f "tokens=1-3 delims=0123456789 " %%i in ("%date%") do set d=%%i%%j%%k
for /f "tokens=1-3 delims=%d% " %%i in ("%date%") do (
set /a d=1%%i
set /a m=1%%j
set /a y=1%%k)
if %d% gtr %m% (
set d=%m%
set m=%d%)
if %m% gtr %y% (
set m=%y%
set y=%m%)
if %d% gtr %m% (
set d=%m%
set m=%d%)
set /a d=%d%-100
set /a m=%m%-100
set /a y=%y%-10000
if %d% gtr 12 goto :exit
if %d% equ %m% goto :exit
if %m% gtr 12 (
set m=%d%
set d=%m%
goto :exit)
xcopy /l /d:%m%-%d%-%y% _._ \|find "_._"
if errorlevel 1 goto :l1
xcopy /l /d:%d%-%m%-%y% _._ \|find "_._"
if not errorlevel 1 goto :exit
:l1
(set m=%d%
set d=%m%)
:exit
del _._
echo y=%y%
echo m=%m%
echo d=%d%
Tika
>> You already have been given a solution without any external
> tool (by including binary code within the batch which isn't
> more "external" than the batch code itself).
Yes, and believe me, I can write a much much better C program that does
the job, even an assembler program, if you like. In German: Von hinten
durch die Brust ins Auge. ;)
Have fun. ;)
>> Who wants a 16 bit application on his Windows system? We live in the
>> 21st century.
>
> What has the CPU mode (protected mode or V86 mode) to do with the
> century? Maybe you can explain it to me.
It requires to load a DLL on Windows (i.e. it loads and executes about a
100 times slower). 16 bit DOS is already at least 7 years old, so no one
should use these oldtimers anymore nowadays.
That might be quite a hint for the whole newsgroup as well. For Timo:
Yes, I'm sure that there are still millions of people using Windows
95/98/ME. It's dead, I can't help it anyway. ;)
>> You are mistaken here. You might be right on your US system, but not on
>> others. That's why I'm saying that you need a third-party tool like
>> HLDate, DOFF, or Logtext. Or for pure DOS anything that's only 16 bit
>> DOS (maybe this Date_Var.com). Otherwise there's no portable solution.
>
> Are you sure again? If there are no other than the five formats you have
Yes, I am. Until now I was not given any solution.
> given above, then in W2k/XP the following should work (untested) but
> nobody would be crazy enough to use such code instead of a few lines
> of included ascii assembler code (but at least it is far better than
> relying on external programs):
Why would someone write a batch file that outputs something in an
executable or VB script and then execute it again? If you have an
executable, just assemble and invoke it directly, if you have a VB
script, just invoke it with the proper interpreter. Why would someone
take the effort and write a batch file that outputs in the desired
language? I've never seen a batch file that outputs C source code and
then runs it through the compiler and the linker. Again, you really got
no better idea?
German: Von hinten durch die Brust ins Auge. ;)
> @echo off
You don't believe yourself that this code is portable between different
locale settings. Do I really go through it now? ;)
Tika
> The last sentence would indicate that you also consider the newer OS
> versions, not just the on-topic MS-DOS+Win../95/98/Me. The current OSes
> come with Visual Basic Script which allows portable solutions for the
> date elements, as e.g. in my NT/2000/XP script FAQ tscmd.
Last release was 2000. What do you want to hear?
There's no one in this world left who seriously considers a solution
that's only working on MSDOS+Win 95/98/ME. Wake up!
Tika
> *** Good point, John.
>
> For my own batch-file usage, I have set them up tp recognise yyyy-mm-dd
> typed at the command line.
Good point, Richard. Unfortunatly you are not all users (or even
Microsoft)... ;)
That would make things much easier.
Dr J R Stockton
Sun, 28 Jan 2007 02:27:02, Tika <ti...@doesntexist.org> posted:
>Again, this is exactly why it can't work. You don't know the date
>format of the target machine, you can't even guess it. No chance
>without a third-party utility.
ECHO.|DATE
gives something like
The current date is: 2007-01-28
Enter the new date: (yy-mm-dd)
In that, the date and date format are fully described, provided that
sufficient is known about the letters used for year, month, and day in
all applicable languages.
If that information is processed by a program generated by a DEBUG
script ...
In a *real* DOS machine, free of fenestration and suchlike (i.e. with no
Windows etc.), no other program will be running while the batch file is
running. One could save the date, locate the year field by trying 77 11
11, 11 77 11, 11 11 77 and seeing which worked, then locate the day
field with 22 22 11, 22 11 22, 11 22 22, then restore the date.
Better, no doubt, to use a script that calls Int21/2A.
--
Todd Vargo
There are people who do still use MSDOS..WinME and obviously solutions for
NT/2K/XP just do not work for them. The 16Bit examples already mentioned
work for all systems but you are using the narrow minded slow-code attitude
to dispute portability.
Tsk. Tsk.
Todd Vargo
> Todd Vargo wrote:
> > I know what you are saying to Bonner but your output excludes DOW.
>
> You are mistaken here. You might be right on your US system, but not on
> others. That's why I'm saying that you need a third-party tool like
> HLDate, DOFF, or Logtext. Or for pure DOS anything that's only 16 bit
> DOS (maybe this Date_Var.com). Otherwise there's no portable solution.
>
>
> > ==== Win95cmd capture
> > E:\>date/t
> > Sun 01/28/2007
> > ====
>
> This is exactly what I get here:
>
> Microsoft Windows XP [Version 5.1.2600]
> (C) Copyright 1985-2001 Microsoft Corp.
>
> C:\>date /t
> 2007-01-28
>
> C:\>
Sure this is what you get, but which format is the default installation? I
have seen this exact disucssion repeated enough times through the years to
know date format is user customizable. No I'm not mistaken about what you
was saying to Richard either. Been there, done that.
>
>
> >>> Does Georg Pohl's Date_Var.com not work on NTish systems?
> >>> http://home7.inet.tele.dk/batfiles/main/pohlutil.htm
> >> Who wants a 16 bit application on his Windows system? We live in the
> >> 21st century.
> >
> > Because this is alt.msdos.batch not a.m.b.nt. The example you posted is
not
> > "portable" because it uses CMD.EXE specific batch code therefore it can
not
> > be considered "reliable".
>
> Reliable is what runs on a target system without considering locale
> settings. There's always a system that can't be supported.
Sadly, you did not answer my question with an appropriate answer mostly
because you have an 'I'm right and you are wrong' attitude. So be it. :(
Todd Vargo
> Herbert Kleebauer wrote:
> >> Who wants a 16 bit application on his Windows system? We live in the
> >> 21st century.
> >
> > What has the CPU mode (protected mode or V86 mode) to do with the
> > century? Maybe you can explain it to me.
>
> It requires to load a DLL on Windows (i.e. it loads and executes about a
> 100 times slower). 16 bit DOS is already at least 7 years old, so no one
> should use these oldtimers anymore nowadays.
>
> That might be quite a hint for the whole newsgroup as well. For Timo:
> Yes, I'm sure that there are still millions of people using Windows
> 95/98/ME. It's dead, I can't help it anyway. ;)
You argued need for portability and reliability, but now you are saying
ignore older systems. Get off the fence and make up your mind.
Herbert Kleebauer
> Herbert Kleebauer wrote:
> > You already have been given a solution without any external
> > tool (by including binary code within the batch which isn't
> > more "external" than the batch code itself).
>
> Yes, and believe me, I can write a much much better C program that does
> the job, even an assembler program, if you like.
Maybe first you should give us a definition for a "much much better program".
And you completely missed the point. The worst thing you can do is,
to make the correct function of a batch program dependent on an
external program.
> >> Who wants a 16 bit application on his Windows system? We live in the
> >> 21st century.
> >
> > What has the CPU mode (protected mode or V86 mode) to do with the
> > century? Maybe you can explain it to me.
>
> It requires to load a DLL on Windows (i.e. it loads and executes about a
> 100 times slower).
Now I'm really curious. Please show me your "much better C or assembly
program" which can be executed without loading a DLL. And what do you
mean with "100 times slower"? Slower than what? Do you think the CPU
reduces clock frequency when executing code in V86 mode?
> 16 bit DOS is already at least 7 years old, so no one
> should use these oldtimers anymore nowadays.
That doesn't make any sense. Because such a program also can
be executed on a 7 year old system surely isn't a disadvantage.
Now please be more concrete and tell us, why "no one should use
these oldtimers anymore nowadays". The C specification is much
older, so why do you still use C?
> That might be quite a hint for the whole newsgroup as well. For Timo:
> Yes, I'm sure that there are still millions of people using Windows
> 95/98/ME. It's dead, I can't help it anyway. ;)
This also doesn't make any sense. What has V86 mode to do with
Win9x? Why is it ok to use "DOS programs" instead of Win32 programs
in Win9x but not in W2k/XP. (BTW I'm writing this on a Win98 PC,
so it can't be dead)
> >> You are mistaken here. You might be right on your US system, but not on
> >> others. That's why I'm saying that you need a third-party tool like
> >> HLDate, DOFF, or Logtext. Or for pure DOS anything that's only 16 bit
> >> DOS (maybe this Date_Var.com). Otherwise there's no portable solution.
> >
> > Are you sure again? If there are no other than the five formats you have
>
> Yes, I am. Until now I was not given any solution.
As you have seen, the solution is very simple so you should have
been able to find it yourself, especially because you can write
"much much better C program that does the job, even an assembler program".
> > given above, then in W2k/XP the following should work (untested) but
> > nobody would be crazy enough to use such code instead of a few lines
> > of included ascii assembler code (but at least it is far better than
> > relying on external programs):
>
> Why would someone write a batch file that outputs something in an
> executable or VB script and then execute it again?
Because, as I already said, the worst thing you can do is, to make
your batch dependent on an external program.
> If you have an
> executable, just assemble and invoke it directly, if you have a VB
If you already have an executable, then there is nothing to assemble.
> script, just invoke it with the proper interpreter. Why would someone
> take the effort and write a batch file that outputs in the desired
> language?
Because this is the only way to ensure that the batch can be
executed without needing an external program.
> I've never seen a batch file that outputs C source code and
> then runs it through the compiler and the linker. Again, you really got
> no better idea?
I suppose, besides you, anybody here has better ideas. What sense would it
make to replace the dependence on an 1 kbyte executable by a dependence on
a compiler with a few Mbyte. Maybe you don't have the slightest idea
of what you are speaking.
> > @echo off
>
> You don't believe yourself that this code is portable between different
> locale settings.
Then it shouldn't to hard for you (especially because you can write a much
much better C program that does the job) to prove it wrong. It was a quick
hack and I already have seen two small bugs. I really hope you will show me
why this code isn't "portable between different locale settings".
> Do I really go through it now? ;)
I hope so. Shouldn't be a big problem for such a great programmer.
Tika
> Maybe first you should give us a definition for a "much much better program".
Google? There are plenty of examples.
http://www.jfitz.com/dos/doff10_source.zip
> And you completely missed the point. The worst thing you can do is,
> to make the correct function of a batch program dependent on an
> external program.
Maybe that's the point. What's so bad about an external program?
External programs are making a computer work at all. One could consider
the batch file itself beeing already an external module. ;)
AFAIR the original DOS only had 9 or 11 internal commands.
>>>> Who wants a 16 bit application on his Windows system? We live in the
>>>> 21st century.
>>> What has the CPU mode (protected mode or V86 mode) to do with the
>>> century? Maybe you can explain it to me.
>> It requires to load a DLL on Windows (i.e. it loads and executes about a
>> 100 times slower).
>
> Now I'm really curious. Please show me your "much better C or assembly
> program" which can be executed without loading a DLL. And what do you
> mean with "100 times slower"? Slower than what? Do you think the CPU
> reduces clock frequency when executing code in V86 mode?
A Windows system (and no, Windows 98 has never been a real Windows
system ;) requires to load the whole 16 bit environment whenever you run
an old program. The CPU's frequency is not touched, but you should know
this yourself. ;)
Starting 'debug' here for the first time takes about 3 seconds. Starting
the above mentioned 'doff' takes no measurable time.
> Now please be more concrete and tell us, why "no one should use
> these oldtimers anymore nowadays".
I don't think I have to answer this, I'm sure you can do it yourself. If
a memory module dies you will have to obtain it from a scrap yard,
because you can't buy it anywhere else.
You really believe that someone takes an old Win 98 box and puts it in a
server room to run it as a production machine?
Unless, of course, someone has a memory module scap yard. ;)
The C specification is much
> older, so why do you still use C?
Maybe you should tell me about someone who still compiles 16 bit DOS
applications with C.
>> That might be quite a hint for the whole newsgroup as well. For Timo:
>> Yes, I'm sure that there are still millions of people using Windows
>> 95/98/ME. It's dead, I can't help it anyway. ;)
>
> This also doesn't make any sense. What has V86 mode to do with
> Win9x? Why is it ok to use "DOS programs" instead of Win32 programs
> in Win9x but not in W2k/XP. (BTW I'm writing this on a Win98 PC,
> so it can't be dead)
I see, you'll give it another year before you dump it. Or maybe only a
week, once a memory module dies. I hope the scrap yard in your basement
is big enough...
> As you have seen, the solution is very simple so you should have
Unfortunately I've not seen any solution that works everywhere yet
(excluding invoking external programs, of course).
>> Why would someone write a batch file that outputs something in an
>> executable or VB script and then execute it again?
>
> Because, as I already said, the worst thing you can do is, to make
> your batch dependent on an external program.
Is your newsreader a batch file that outputs the code into an executable
image and then starts it? ;)
Do you use any other applications that behave like this, despite viruses? ;)
You really gotta be kidding with this statement.
*Every* application is an external program, so please don't tell me
that's the 'worst thing you can do'. It's standard, it's what a computer
is for. Do live on *this* planet? ;)
> If you already have an executable, then there is nothing to assemble.
That's what I'm saying. ;)
>> script, just invoke it with the proper interpreter. Why would someone
>> take the effort and write a batch file that outputs in the desired
>> language?
>
> Because this is the only way to ensure that the batch can be
> executed without needing an external program.
Because external programs are soo baad...
ROTFL. ;)
>> I've never seen a batch file that outputs C source code and
>> then runs it through the compiler and the linker. Again, you really got
>> no better idea?
>
> I suppose, besides you, anybody here has better ideas. What sense would it
> make to replace the dependence on an 1 kbyte executable by a dependence on
> a compiler with a few Mbyte. Maybe you don't have the slightest idea
> of what you are speaking.
Actually, if you knew what you are talking about, you would have come up
with at least a few examples. It is normal for installation scripts on
Unix/Linux to compile and link the application before it's used. But
then, it is executed. It's not built every time it runs.
Because no one else would kill a fly with a tank. That is only a
brilliant invention without any sense of this newsgroup here. ;)
Because external programs are so bad. ;)
>>> @echo off
>> You don't believe yourself that this code is portable between different
>> locale settings.
>
> Then it shouldn't to hard for you (especially because you can write a much
> much better C program that does the job) to prove it wrong. It was a quick
> hack and I already have seen two small bugs. I really hope you will show me
> why this code isn't "portable between different locale settings".
It does not work when the year is only 2 digits.
Your attempt to retrieve the delimiters and guess the position of day,
month, and year, is a design flaw already. You can't find a way to
revert an algorithm for something that does not have an algorithm in the
first place, no matter how hard you try. I have no idea why you (or
someone else) are trying to argue about this. You can go for a 'best
guess', and you might be right on many occasions, but that's about it.
You will have to understand this, if you like it or not. Sorry, Alice.
Tika
> Roll your own. :) What's not portable about this?
It doesn't run on modern operating systems like Windows XP or 2003 for
non-privileged users, and it causes problems with some real-time-scan
virus scanners.
Tika
> Sure this is what you get, but which format is the default installation? I
This is what I get here, and I reckon that I'm not the only one. I have
no idea what the default installation is, and I believe neither have you.
> have seen this exact disucssion repeated enough times through the years to
> know date format is user customizable.
All I'm saying is that there's no reliable way to obtain a date within a
batch file without using an external application. But everyone wants to
tear me apart because of this, and everyone tries to convince me (or
themselves) that there is. ;)
Some even write a batch file that creates an external application to
circumvent the situation, although an external application stays an
external application, even if it is created on the fly. ;)
You might create an executable image during the installation process of
something, but on the fly for every single run? My common sense tells me
that this is a bit overkill, and MSDN tells me that it doesn't even work
on a properly set up modern system for a standard user.
>>> Because this is alt.msdos.batch not a.m.b.nt. The example you posted is
> not
>>> "portable" because it uses CMD.EXE specific batch code therefore it can
> not
>>> be considered "reliable".
That's why I didn't omit Date_Var.com. I don't have a Windows 98 system,
so I don't know what runs there and what doesn't.
>> Reliable is what runs on a target system without considering locale
>> settings. There's always a system that can't be supported.
>
> Sadly, you did not answer my question with an appropriate answer mostly
> because you have an 'I'm right and you are wrong' attitude. So be it. :(
I did answer your question, but sadly you expected a different one.
I don't even need the 'I'm right' attitude, because no one here has been
able to prove me wrong yet. The reason for this is as simple as it is:
There is no way for a batch file without any third-party tools to
reliably retrieve the current date.
Every few days someone asks for a date batch solution here or in the NT
group, and people answer with an example which does only work for the
OP, but without changes unfortunately not for everyone.
Tika
> sufficient is known about the letters used for year, month, and day in
> all applicable languages.
My point. ;)
> If that information is processed by a program generated by a DEBUG
> script ...
Huh? ;)
> In a *real* DOS machine, free of fenestration and suchlike (i.e. with no
> Windows etc.), no other program will be running while the batch file is
> running. One could save the date, locate the year field by trying 77 11
> 11, 11 77 11, 11 11 77 and seeing which worked, then locate the day
> field with 22 22 11, 22 11 22, 11 22 22, then restore the date.
No other program might be running in a 'real' DOS, but the day might
change if you run it at midnight. Your script will srew up the date
then. Very bad programming style...
> Better, no doubt, to use a script that calls Int21/2A.
On DOS, yes. Wasn't the Intel 286 the last PC processor that really
supported Int 21h? Nowadays a virtual machine is loaded and started, if
you do that. Just to retrieve the date? ;)
Todd Vargo
ISTM, your tangents keep moving further away from the portability and
reliability issue originally discussed.
Tika
> On Sun, 28 Jan 2007 12:16:08 GMT, Tika <ti...@doesntexist.org> wrote:
> Roll your own. :) What's not portable about this?
> echo second: %_ss%
You might as well want to omit the seconds in your script. It takes 4
seconds to execute here, so it does not seem to be very accurate.
Tika
> Tika wrote:
>> foxidrive wrote:
>>> Roll your own. :) What's not portable about this?
>> It doesn't run on modern operating systems like Windows XP or 2003 for
>> non-privileged users, and it causes problems with some real-time-scan
>> virus scanners.
>
> ISTM, your tangents keep moving further away from the portability and
> reliability issue originally discussed.
So, you're happy with a solution that does not work for some people at
all? ;)
foxidrive
Don't feed the troll, guys.
Herbert Kleebauer
> Herbert Kleebauer wrote:
> > Maybe first you should give us a definition for a "much much better program".
> Google? There are plenty of examples.
> http://www.jfitz.com/dos/doff10_source.zip
That is the C source of a program. I asked you to give a definition for
a "much much better program". Only if we have this definition, we can
prove if this C program is a "much much better program".
> > And you completely missed the point. The worst thing you can do is,
> > to make the correct function of a batch program dependent on an
> > external program.
> Maybe that's the point. What's so bad about an external program?
There is nothing wrong with an external program, the batch itself is
an external program. But it becomes bad, if an external program
depends on an other external program and if it can't be guaranteed
that the second external program is always distributed with the first
one.
> External programs are making a computer work at all. One could consider
> the batch file itself beeing already an external module. ;)
> AFAIR the original DOS only had 9 or 11 internal commands.
You don't have to restrict yourself to the internal commands of the
command interpreter (seems you are confusing "DOS" with "command.com").
You can safely use all programs of a standard OS installation but
you should avoid the use of external programs in a batch program.
> >>>> Who wants a 16 bit application on his Windows system? We live in the
> >>>> 21st century.
> >>> What has the CPU mode (protected mode or V86 mode) to do with the
> >>> century? Maybe you can explain it to me.
> >> It requires to load a DLL on Windows (i.e. it loads and executes about a
> >> 100 times slower).
> > Now I'm really curious. Please show me your "much better C or assembly
> > program" which can be executed without loading a DLL. And what do you
> > mean with "100 times slower"? Slower than what? Do you think the CPU
> > reduces clock frequency when executing code in V86 mode?
You always make some claims and when you asked for a proof, you just
tell something else. Where is your C program which can be executed
without loading a DLL?
> A Windows system (and no, Windows 98 has never been a real Windows
> system ;)
Again an interesting claim. Now please give some facts why Win98 isn't
a real Windows system. Was it a Windows system back in 1998 and
lost this attribute when it was replaced by XP or was it never a
Windows system?
> requires to load the whole 16 bit environment whenever you run
> an old program.
Mow, how big do you think is the "whole 16 bit environment" compared
to other Win32 programs.
> The CPU's frequency is not touched, but you should know
> this yourself. ;)
So you agree, that a V86 task doesn't run slower than a Win32 program
doing the same calculation.
> Starting 'debug' here for the first time takes about 3 seconds. Starting
> the above mentioned 'doff' takes no measurable time.
Maybe then you really should install DOS6 instead XP on such a slow PC.
> > Now please be more concrete and tell us, why "no one should use
> > these oldtimers anymore nowadays".
>
> I don't think I have to answer this, I'm sure you can do it yourself. If
If you make a claim and don't want to be classified as a troll, then you
have to backup your claim with facts. And no, I can't do it myself, but
I don't have to do it myself, because I never made such a claim.
> a memory module dies you will have to obtain it from a scrap yard,
> because you can't buy it anywhere else.
Now you lost me completely. What has a memory module to do with
a 16 bit application running in XP?
> You really believe that someone takes an old Win 98 box and puts it in a
> server room to run it as a production machine?
Where did I say something like that? What has the OS (Win98 / XP) to
do with a 16 bit application running under this OS?
> Unless, of course, someone has a memory module scap yard. ;)
Maybe it was far to late in the evening when you wrote this?
> > The C specification is much
> > older, so why do you still use C?
>
> Maybe you should tell me about someone who still compiles 16 bit DOS
> applications with C.
Again, what has the C source to do with the compiler you use to
compile it. If you don't like to use things older than 7 years,
then you shouldn't use C (which is much older), use C# instead.
> >> That might be quite a hint for the whole newsgroup as well. For Timo:
> >> Yes, I'm sure that there are still millions of people using Windows
> >> 95/98/ME. It's dead, I can't help it anyway. ;)
> >
> > This also doesn't make any sense. What has V86 mode to do with
> > Win9x? Why is it ok to use "DOS programs" instead of Win32 programs
> > in Win9x but not in W2k/XP. (BTW I'm writing this on a Win98 PC,
> > so it can't be dead)
> I see, you'll give it another year before you dump it. Or maybe only a
> week, once a memory module dies. I hope the scrap yard in your basement
> is big enough...
How is this an answer to my question? Why is it ok to run "DOS programs"
in Win98 but not in XP? Please try again to give an answer.
> > As you have seen, the solution is very simple so you should have
> Unfortunately I've not seen any solution that works everywhere yet
> (excluding invoking external programs, of course).
Didn't you see the solution in my post? Or wasn't it a solution?
In the latter case I asked you to prove it.
> >> Why would someone write a batch file that outputs something in an
> >> executable or VB script and then execute it again?
> >
> > Because, as I already said, the worst thing you can do is, to make
> > your batch dependent on an external program.
>
> Is your newsreader a batch file that outputs the code into an executable
> image and then starts it? ;)
Must have been really late. What sense does this sentence make?
> Do you use any other applications that behave like this, despite viruses? ;)
I only know about applications which install all necessary files
to execute the application. What would you say, if you install
a program and when you start it, you get the message that 5 DLL's
are missing. And installing a batch programs means, to copy it on
the disk. And if you start it and you get the message "program xyz
not found", then this is a very poor batch program. And maybe you
can give me a link which shows that this ever was use for virus
(not even the batch police in this group was able to provide such
a link).
> You really gotta be kidding with this statement.
>
> *Every* application is an external program, so please don't tell me
> that's the 'worst thing you can do'. It's standard, it's what a computer
> is for. Do live on *this* planet? ;)
There are many applications/programs which are not external but part
of a standard Windows installation. And there is nothing wrong to use
these programs in a batch program. But external programs should be
avoided when ever possible. And it is no excuse that you are not
smart enough to avoid them.
> > If you already have an executable, then there is nothing to assemble.
>
> That's what I'm saying. ;)
Oh no, you said: "If you have an executable, just assemble and invoke it
directly".
> >> script, just invoke it with the proper interpreter. Why would someone
> >> take the effort and write a batch file that outputs in the desired
> >> language?
> > Because this is the only way to ensure that the batch can be
> > executed without needing an external program.
>
> Because external programs are soo baad...
> ROTFL. ;)
If you still don't understand it, then you better continue ROTFL
instead of writing batch programs.
> >> I've never seen a batch file that outputs C source code and
> >> then runs it through the compiler and the linker. Again, you really got
> >> no better idea?
> >
> > I suppose, besides you, anybody here has better ideas. What sense would it
> > make to replace the dependence on an 1 kbyte executable by a dependence on
> > a compiler with a few Mbyte. Maybe you don't have the slightest idea
> > of what you are speaking.
>
> Actually, if you knew what you are talking about, you would have come up
> with at least a few examples.
Examples for what?
> It is normal for installation scripts on
> Unix/Linux to compile and link the application before it's used. But
> then, it is executed. It's not built every time it runs.
Now we are speaking about Linux and not Windows anymore? Maybe
you don't know, but in Linux it isn't easy to to get binary
compatibility between different Linux versions so you have to compile
it on the target system to get a proper binary. In Windows this
isn't a problem so you can distribute binaries. And there is no
need to generate the binary on the fly every time the batch is
executed. Just insert a "if exist xyz.com goto :skip" to skip
the echo lines. But in opposite to using an external program, the
batch also runs if the program doesn't exist (it simple creates
it using echo statements).
> Because no one else would kill a fly with a tank. That is only a
> brilliant invention without any sense of this newsgroup here. ;)
> Because external programs are so bad. ;)
Nice, now you compare 16 bit DOS program with a tank.
> >>> @echo off
> >> You don't believe yourself that this code is portable between different
> >> locale settings.
> >
> > Then it shouldn't to hard for you (especially because you can write a much
> > much better C program that does the job) to prove it wrong. It was a quick
> > hack and I already have seen two small bugs. I really hope you will show me
> > why this code isn't "portable between different locale settings".
>
> It does not work when the year is only 2 digits.
Why should it? You posted five different date formats with the
statement: "How do you want to handle this? No chance. ;)"
I think the posted code will handle this formats and it's up to
you to prove me wrong (maybe I'm wrong, I didn't spend much time
to write it).
> Your attempt to retrieve the delimiters and guess the position of day,
> month, and year, is a design flaw already.
Why do you think I "guess" the position of the day? Can't you read
such simple batch code? If I only "guess", then it shouldn't be a
problem to provide an example where I guess wrong.
> You can't find a way to
> revert an algorithm for something that does not have an algorithm in the
> first place, no matter how hard you try.
If I can't, why don't you prove the code wrong?
> I have no idea why you (or
> someone else) are trying to argue about this.
I don't argue. I have provided code and you have to show
me why it's wrong.
> You can go for a 'best
> guess', and you might be right on many occasions, but that's about it.
Then give me the example where the guess is wrong.
> You will have to understand this, if you like it or not. Sorry, Alice.
I will understand it if you give me the example where the code is wrong.
Mike Jones
You are evidently trolling, or are unaware of the DOS part of this NG's
name. Thankyou for reading.
Timo Salmi
It seems that you primarily are out trying to ruffle the feathers of the
regulars, but I am not biting more than this. Sorry.
Timo Salmi
> ECHO.|DATE
> gives something like
> The current date is: 2007-01-28
> Enter the new date: (yy-mm-dd)
Now, John, that is an excellent point. So obvious, yet so far missed, at
least be yours turly. With cmd.exe it is relatively easy to ascertain
the order from the latter. Yes, I know that is for alt.msdos.batch.nt
but it will be a good locale-independent method for my FAQ in there.
Thanks for the idea. I'll try to write a suitable script for it
requiring no third-party utility, and post there.
All the best, Timo
--
Prof. Timo Salmi ftp & http://garbo.uwasa.fi/ archives 193.166.120.5
Department of Accounting and Business Finance ; University of Vaasa
mailto:t...@uwasa.fi <http://www.uwasa.fi/~ts/> ; FIN-65101, Finland
Timo's FAQ materials at http://www.uwasa.fi/~ts/http/tsfaq.html
Timo Salmi
> Dr J R Stockton <repl...@merlyn.demon.co.uk> wrote:
>> ECHO.|DATE
>> gives something like
>> The current date is: 2007-01-28
>> Enter the new date: (yy-mm-dd)
>
> Now, John, that is an excellent point. So obvious, yet so far missed, at
> least be yours turly. With cmd.exe it is relatively easy to ascertain
> the order from the latter. Yes, I know that is for alt.msdos.batch.nt
> but it will be a good locale-independent method for my FAQ in there.
> Thanks for the idea. I'll try to write a suitable script for it
> requiring no third-party utility, and post there.
Since the thread started in alt.msdos.batch but the solution is for
alt.msdos.batch.nt I'll crosspost to both but set the followups to the
latter, only.
So, locale-independent date element's extraction with XP cmd.exe with no
third-party utilities.
@echo off & setlocal enableextensions
::
:: Still debugging?
set debug=true
::
:: Get the date from the first line of the date command
for /f "tokens=5 delims= " %%a in ('echo.^|date') do (
if not defined date_ set date_=%%a
)
if defined debug echo %date_%
::
:: Get the date format from the first line of the date command
for /f "tokens=5 delims= " %%a in ('echo.^|date') do (
set dateform_=%%a)
if defined debug echo %dateform_%
::
:: Get the order of the date information
set field1=%dateform_:~1,2%
set field2=%dateform_:~4,2%
set field3=%dateform_:~7,2%
if defined debug echo %field1% %field2% %field3%
echo.
::
:: Test and set according to the date format order
:: dd-mm-yy
if "%field1%"=="dd" (
set day_=%date_:~0,2%
if "%field2%"=="mm" (
set month_=%date_:~3,2%
set year_=%date_:~6,4%
)
)
:: mm-dd-yy
if "%field1%"=="mm" (
set month_=%date_:~0,2%
if "%field2%"=="dd" (
set day_=%date_:~3,2%
set year_=%date_:~6,4%
)
)
:: yy-mm-dd
if "%field1%"=="yy" (
set year_=%date_:~0,4%
if "%field2%"=="mm" (
set month_=%date_:~5,2%
set day_=%date_:~8,2%
)
)
:: yy-dd-mm
if "%field1%"=="yy" (
set year_=%date_:~0,4%
if "%field2%"=="dd" (
set day_=%date_:~5,2%
set month_=%date_:~8,2%
)
)
::
:: Display the result
if not defined day_ (
echo Error: Unindentified date format
goto :EOF
)
echo day_=%day_%
echo month_=%month_%
echo year_=%year_%
endlocal & goto :EOF
The output might be e.g.
C:\_D\TEST>cmdfaq
29.01.2007
(dd-mm-yy)
dd mm yy
day_=29
month_=01
year_=2007
Not tested for all the eventualities!
All the best, Timo
--
Prof. Timo Salmi ftp & http://garbo.uwasa.fi/ archives 193.166.120.5
Department of Accounting and Business Finance ; University of Vaasa
mailto:t...@uwasa.fi <http://www.uwasa.fi/~ts/> ; FIN-65101, Finland
Useful script files and tricks ftp://garbo.uwasa.fi/pc/link/tscmd.zip
Eman
> Dr J R Stockton <repl...@merlyn.demon.co.uk> wrote:
>> ECHO.|DATE
>> gives something like
>> The current date is: 2007-01-28
>> Enter the new date: (yy-mm-dd)
>
> Now, John, that is an excellent point. So obvious, yet so far missed, at
> least be yours turly. With cmd.exe it is relatively easy to ascertain
> the order from the latter. Yes, I know that is for alt.msdos.batch.nt
> but it will be a good locale-independent method for my FAQ in there.
This second row works well when your are under latin-
alphabet-based locale. Otherwise there is neither
"yy" nor "mm", and you just don't understand what this
"ыы-яя-йй" means. But this is not the only point, 'coz
there is another one. Under "LocalSystem" account on
some Windows this "yy-mm-dd" order simply does not
correspond to actual format of %date% in the 1st row.
Richard Bonner
> For Timo:
> Yes, I'm sure that there are still millions of people using Windows
> 95/98/ME. It's dead, I can't help it anyway. ;)
*** Ahh, the Microsoft brainwashing is working well. (-:
Richard Bonner
http://www.chebucto.ca/~ak621/DOS/
Richard Bonner
> Richard Bonner wrote:
> > *** Good point, John.
> >
> > For my own batch-file usage, I have set them up tp recognise yyyy-mm-dd
> > typed at the command line.
> Good point, Richard. Unfortunatly you are not all users (or even
> Microsoft)... ;)
*** Correct. (-:
Richard Bonner
http://www.chebucto.ca/~ak621/DOS/
Timo Salmi
> "Timo Salmi" <t...@uwasa.fi>
>> Dr J R Stockton <repl...@merlyn.demon.co.uk> wrote:
>>> The current date is: 2007-01-28
>>> Enter the new date: (yy-mm-dd)
>> Now, John, that is an excellent point. So obvious, yet so far
>> missed, at least be yours turly. With cmd.exe it is relatively easy
>> to ascertain the order from the latter. Yes, I know that is for
>> alt.msdos.batch.nt
> This second row works well when your are under latin- alphabet-based
> locale. Otherwise there is neither "yy" nor "mm", and you just don't
> understand what this "ыы-яя-йй" means. But this is not the only
> point, 'coz there is another one. Under "LocalSystem" account on some
> Windows this "yy-mm-dd" order simply does not correspond to actual
> format of %date% in the 1st row.
Thanks for the additional information. Yet, it is better to have a
partial solution than none at all. Besides, let's recall that we
do have the batch driven VBS solution, which is is not a third-party
solution. Locale-independent date in batches is cumbersome, but not
unsurmountable.
Dr J R Stockton
Sun, 28 Jan 2007 22:40:23, Tika <ti...@doesntexist.org> posted:
You are evidently a person of limited experience.
When a PC is to be interfaced to measuring equipment, for example, the
presence of an active Windows may well be intolerable (of course,
depending on the software, it may instead be essential). One may
require that the whole attention of the system, while measuring, be
given to the measurement task, without even momentary interruption for
anything else.
Then there's the case of family PCs. A family may not want to provide a
new PC for every family member, or even for every member who may want to
use one at any one time. If, then, the parents retain, say, a Windows
3.1 system, which is just as good as ever it was for many routine tasks,
they can be reasonably sure that the children will not want to use it
and will not break it. And a corresponding lack of a Net connection is
a good protection from malware too.
Old software is still as good as ever it was.
--
(c) John Stockton, Surrey, UK. ???@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Check boilerplate spelling -- error is a public sign of incompetence.
Never fully trust an article from a poster who gives no full real name.
Tika
> Tika wrote:
>> Google? There are plenty of examples.
>> http://www.jfitz.com/dos/doff10_source.zip
>
> That is the C source of a program. I asked you to give a definition for
> a "much much better program". Only if we have this definition, we can
> prove if this C program is a "much much better program".
Sorry, I didn't know that you don't have a definition of a 'much much
better program'. I really thought you were kidding.
- Reliable
- Fast
- Small
- Compatible to as many systems as possible
You could use more detailed descriptions for the points in this list,
and maybe this is where we have our different opinions. Dr Stockton
obviously does not run his batch file at midnight while Foxidrive is
happy with a solution that takes about 4 seconds to execute and doesn't
work on current operating systems for many users. That brings up the
next point:
- Easy to install
Setting permissions is part of the installation as well as copying in
any additional executables.
> There is nothing wrong with an external program, the batch itself is
> an external program. But it becomes bad, if an external program
> depends on an other external program and if it can't be guaranteed
> that the second external program is always distributed with the first
> one.
There should be a definition of external programs as well, and I guess
even for compatibility. XCOPY could be considered such an application.
Someone might have (deliberately or accidentally) deleted XCOPY.EXE to
only run a crippled Windows or DOS. Was there not even a restriction
about the amount of programs on the first MSDOS disk? Can't remember
now, but I've certainly seen many installed MSDOS systems that did not
have XCOPY. I have personally once crippled down a Windows NT system for
a special case to make it fit on a flash disk, XCOPY was one of the
files that could not make it on that disk, because it was not required
for the application to run.
Speaking of the points 'Reliable' and 'Compatible to as many systems as
possible' I can't see a real difference between 'real external programs'
and XCOPY.EXE. If your batch file uses XCOPY, then you will have to
ensure that it's in the PATH or your batch file's directory. If your
batch file writes into a folder, then you will have to ensure that it
can write into it (not on DOS or Windows 95/98/ME, of course). Since
Windows NT already, you've got no choice. That should cover the 'Easy to
install' requirement. Just copying a batch file into a directory is not
enough anymore if a different user is supposed to run it. Refer to the
MSDN for further information. You obviously have to catch up a lot.
> You don't have to restrict yourself to the internal commands of the
> command interpreter (seems you are confusing "DOS" with "command.com").
> You can safely use all programs of a standard OS installation but
> you should avoid the use of external programs in a batch program.
See the paragraph above. I can't agree to 'You should avoid the use of
external programs in a batch file'. I get the feeling that you never had
to install a batch file or one of your own applications in a domain, on
Windows XP, on Windows 2003, Windows NT, or Windows 2000. You obviously
never ran a batch file as a Windows service either.
If you so strongly believe that external programs are to be avoided,
then you should come up with a better explanation than the pure statement.
> You always make some claims and when you asked for a proof, you just
> tell something else. Where is your C program which can be executed
> without loading a DLL?
There is no C program that runs without a DLL, at least some APIs must
be provided by the OS, and if it's only the kernel. Windows loads most
of these DLLs anyway, so there's no loss in performance during startup,
because there is no disk access required at all.
You should refer to the MSDN on that, or use Google.
>> A Windows system (and no, Windows 98 has never been a real Windows
>> system ;)
>
> Again an interesting claim. Now please give some facts why Win98 isn't
> a real Windows system. Was it a Windows system back in 1998 and
> lost this attribute when it was replaced by XP or was it never a
> Windows system?
I never used Windows 95, or Windows 98, or Windows ME. The OS itself was
not reliable enough for a server or a developer machine and the file
system did not support proper hard drives, and if it did, it was too
slow. I directly moved from Windows NT 3.5 to Windows NT 4.0.
>> requires to load the whole 16 bit environment whenever you run
>> an old program.
>
> Mow, how big do you think is the "whole 16 bit environment" compared
> to other Win32 programs.
Compared to the above mentioned 'DOFF' program to retrieve a date the 16
bit environment is about 10 times as big (measured in memory consumption
and images loaded from disk). Considering speed, I've not measured it,
but you could easily run several solutions 100000 times and monitor the
difference.
I'm sure with a little bit of effort you will find plenty of sources.
> So you agree, that a V86 task doesn't run slower than a Win32 program
> doing the same calculation.
I believed you were joking on that one as well.
The 16 bit task runs with maybe half of the speed of a 32 bit
application, but is often slower, depending on the task. The difference
can also be much smaller. Most sources talk about between 20 and 30
percent. As said, that all depends on the program. Timers have to be
simulated and normally count for the biggest loss on multi-tasking
systems. Many games run several times as fast as their 16 bit
counterpart. Small 32 bit applications are loaded faster and benefit
from that. 16 bit applications might benefit from having several of them
running already which reduces the time to fire up the VM as well.
>> Starting 'debug' here for the first time takes about 3 seconds. Starting
>> the above mentioned 'doff' takes no measurable time.
>
> Maybe then you really should install DOS6 instead XP on such a slow PC.
The virtual machine has to be loaded and the command interpreter needs
to be prepared. I've tested this many times and on different machines,
the result stays pretty much the same.
>>> Now please be more concrete and tell us, why "no one should use
>>> these oldtimers anymore nowadays".
>> I don't think I have to answer this, I'm sure you can do it yourself. If
>
> If you make a claim and don't want to be classified as a troll, then you
> have to backup your claim with facts. And no, I can't do it myself, but
> I don't have to do it myself, because I never made such a claim.
I don't care if I'm classified as a troll by people who can't use Google.
>> a memory module dies you will have to obtain it from a scrap yard,
>> because you can't buy it anywhere else.
>
> Now you lost me completely. What has a memory module to do with
> a 16 bit application running in XP?
Completely destroyed context. Refer to my previous post.
>> You really believe that someone takes an old Win 98 box and puts it in a
>> server room to run it as a production machine?
>
> Where did I say something like that? What has the OS (Win98 / XP) to
> do with a 16 bit application running under this OS?
>
>> Unless, of course, someone has a memory module scap yard. ;)
>
> Maybe it was far to late in the evening when you wrote this?
Maybe you did not read good enough.
>>> The C specification is much
>>> older, so why do you still use C?
>> Maybe you should tell me about someone who still compiles 16 bit DOS
>> applications with C.
>
> Again, what has the C source to do with the compiler you use to
> compile it. If you don't like to use things older than 7 years,
> then you shouldn't use C (which is much older), use C# instead.
I don't think that the language makes a good program. I believe it's the
output. You still want to sell me that 16 bit applications are
state-of-the art. ;)
> How is this an answer to my question? Why is it ok to run "DOS programs"
> in Win98 but not in XP? Please try again to give an answer.
You really have no idea what Google is, or the MSDN, right?
Windows 98 is what is shipped with what Microsoft still called 'DOS'. In
other words: It is the last available version of MS-DOS.
> Didn't you see the solution in my post? Or wasn't it a solution?
> In the latter case I asked you to prove it.
- It uses an external program.
- The /d parameter of XCOPY uses a localized format on MSDOS 6.
- I believe that %Date% does not exist on MSDOS either (not 100 percent
sure).
- Does %Date% exist on Windows NT? I doubt that as well.
- Run at a particular time of day, it goes wrong (line 5 and 6).
It works, however, always reliable when the day is higher then 12.
>> Is your newsreader a batch file that outputs the code into an executable
>> image and then starts it? ;)
>
> Must have been really late. What sense does this sentence make?
It is supposed to redicule a batch file that outputs an executable. Was
quite late for you as well to overlook the smiley.
> I only know about applications which install all necessary files
> to execute the application. What would you say, if you install
> a program and when you start it, you get the message that 5 DLL's
> are missing. And installing a batch programs means, to copy it on
> the disk.
This is where you're wrong, because it works on your outdated operating
system. It is simply not enough to just copy it on the disk on a
computer with Windows NT or higher installed. See above. Or read the
MSDN about user rights, permissions, and the directory recommendations
from Microsoft.
And if you start it and you get the message "program xyz
> not found", then this is a very poor batch program. And maybe you
'Permission denied' is a similiar destructive message.
> can give me a link which shows that this ever was use for virus
> (not even the batch police in this group was able to provide such
> a link).
But you *do* know what a Smiley is at all?
> There are many applications/programs which are not external but part
> of a standard Windows installation.
I see, that's why they are not 'external'. ;)
They might be shipped with Windows, but they are still external.
And there is nothing wrong to use
> these programs in a batch program. But external programs should be
> avoided when ever possible.
I should use your own strategy: Can you please tell me why? I really
don't get this, my computer here is full of external programs, they are
literally everywhere on my hard disks.
I'm happy with a statement from you like 'It is my opinion that external
programs should be avoided', but please avoid claiming that statement to
be true. It is not more than your own expressed opinion, because the
rest of the world use external programs (in my opinion, BTW, even you
yourself, as I'm treating XCOPY as being an external program). In my
opinion, even writing an executable from a module to disk and then
invoking it from the same module is 'calling an external module'. The
vendor of your virus scanner has the same opinion, so I'm not quite alone.
And it is no excuse that you are not
> smart enough to avoid them.
There is no excuse to not be aware that write permissions do exist on
operating systems more recent than 7 years, even on much older ones.
>>> Because this is the only way to ensure that the batch can be
>>> executed without needing an external program.
>> Because external programs are soo baad...
>> ROTFL. ;)
>
> If you still don't understand it, then you better continue ROTFL
> instead of writing batch programs.
I understand that this is your opinion, and I accept it. It is still not
mine, and neither the one of those thousends of software vendors out
there, including the operating system's manufacturer.
> isn't a problem so you can distribute binaries. And there is no
> need to generate the binary on the fly every time the batch is
> executed. Just insert a "if exist xyz.com goto :skip" to skip
> the echo lines. But in opposite to using an external program, the
> batch also runs if the program doesn't exist (it simple creates
> it using echo statements).
This is what you believe, and I'm sure that it works on your Windows 98.
You should try it on anything that's been released later and uses NTFS.
Depending on the user who invokes the file he might have no right at all
to create this executable which pretty much applies to any user despite
the one who saved the file in the first place.
>> Your attempt to retrieve the delimiters and guess the position of day,
>> month, and year, is a design flaw already.
>
> Why do you think I "guess" the position of the day? Can't you read
> such simple batch code? If I only "guess", then it shouldn't be a
> problem to provide an example where I guess wrong.
Because you first guess the right position, then you check whether the
month is higher than 12, and when this works that is the only 100
percent reliable result. Surely, this covers 60 percent already.
> If I can't, why don't you prove the code wrong?
It is not wrong, but it doesn't work entirely. It does not work on MSDOS 6.
Would you trust it to be executed every few seconds over a few months
and never go wrong? I wouldn't, because there is some time between line
5 and line 6.
Tika
>> For Timo:
>> Yes, I'm sure that there are still millions of people using Windows
>> 95/98/ME. It's dead, I can't help it anyway. ;)
>
> *** Ahh, the Microsoft brainwashing is working well. (-:
No, but I believe that the average life cycle of a personal computer at
home might be about 5 years (I don't have sources). Windows 98 is
already 7 years old.
Tika
I wouldn't say this. My first PC was a Commodore PET, if you know this
"machine". ;)
> When a PC is to be interfaced to measuring equipment, for example, the
> presence of an active Windows may well be intolerable (of course,
> depending on the software, it may instead be essential). One may
> require that the whole attention of the system, while measuring, be
> given to the measurement task, without even momentary interruption for
> anything else.
>
> Then there's the case of family PCs. A family may not want to provide a
> new PC for every family member, or even for every member who may want to
> use one at any one time. If, then, the parents retain, say, a Windows
> 3.1 system, which is just as good as ever it was for many routine tasks,
> they can be reasonably sure that the children will not want to use it
> and will not break it. And a corresponding lack of a Net connection is
> a good protection from malware too.
>
> Old software is still as good as ever it was.
Sorry for the full-quote, but I had to leave it completely. I can fully
sign this, although I believe that no one needs a batch solution for
anything on those machines. Then, because of the 7 years of the last
release, the hardware dies slowly. If I count all computers of my
friends (might be about 50) there's only one left with Windows 98 (in
this case not even for the kids. He uses it to read emails).
Todd Vargo
> Todd Vargo wrote:
> > Sure this is what you get, but which format is the default installation?
I
>
> This is what I get here, and I reckon that I'm not the only one. I have
> no idea what the default installation is, and I believe neither have you.
You posted output of several different date formats. By your statement
above, it can only be assumed that your system returns the date in random
formats. I do not believe anyone's system returns date in random formats
each run.
> > have seen this exact disucssion repeated enough times through the years
> > to know date format is user customizable.
>
> All I'm saying is that there's no reliable way to obtain a date within a
> batch file without using an external application. But everyone wants to
> tear me apart because of this, and everyone tries to convince me (or
> themselves) that there is. ;)
No, you replaced "third party utility" as meaning "external application".
foxidrive presented a valid batch solution based on the original verbiage.
> Some even write a batch file that creates an external application to
> circumvent the situation, although an external application stays an
> external application, even if it is created on the fly. ;)
You originally said, "I'm saying that you need a third-party tool like...",
which when shown your statement is wrong with real batch code, you responded
with unproven claims and invalid or irrelevant tangents.
>
> You might create an executable image during the installation process of
> something, but on the fly for every single run? My common sense tells me
> that this is a bit overkill, and MSDN tells me that it doesn't even work
> on a properly set up modern system for a standard user.
This is yet another invalid/irrelevant tangent but wont discuss this one
further.
> I don't have a Windows 98 system,
> so I don't know what runs there and what doesn't.
Therefore your statement "there's no portable solution" is unsupported. A
posted solution asking "What's not portable about this?" requires (at
minimum) evidence that it does not work in a particular (valid) tested
environment in order to support a claim it does not work reliably. We have
only seen invalid/irrelevant tangents for support.
> There is no way for a batch file without any third-party tools to
> reliably retrieve the current date.
If you have proof (excluding invalid/irrelevant tangents) that the batch
solution already presented does not work, we would like to hear it.
Otherwise, it appears you have nothing productive to offer to the
group/discussion.
> Every few days someone asks for a date batch solution here or in the NT
> group, and people answer with an example which does only work for the
> OP, but without changes unfortunately not for everyone.
Yet another irrelevant tangent. Regardless of if a portable solution is
posted daily, someone will still ask for others to write problem specific
code rather than read existing posts with generalized information. If it
pleases you, every time a date related question is presented, feel free to
suggest they download your favorite utilities.
Tika
> Tika wrote:
>> Todd Vargo wrote:
>>> Sure this is what you get, but which format is the default installation?
> I
>> This is what I get here, and I reckon that I'm not the only one. I have
>> no idea what the default installation is, and I believe neither have you.
>
> You posted output of several different date formats. By your statement
> above, it can only be assumed that your system returns the date in random
> formats. I do not believe anyone's system returns date in random formats
> each run.
Please read my post again. I copied and pasted exactly the output I get.
Some statement like this from you only implies that you did not read
properly.
I never said that all the other formats came from my system without
changing the date format manually before. If someone really believed
that the format was returned randomly, then I can't help him. :)
> No, you replaced "third party utility" as meaning "external application".
Well, yes. I think you're right here. Sorry that I didn't make myself
clear on this in the first place. Although reading other posts from me
on the same subject would have probably clearified this.
> foxidrive presented a valid batch solution based on the original verbiage.
Yes, for this group. As mentioned before, it does not work reliably on
NT, 2000, XP. Refer to the MSDN for further information. It seems that
you don't know about permissions either.
> You originally said, "I'm saying that you need a third-party tool like...",
> which when shown your statement is wrong with real batch code, you responded
> with unproven claims and invalid or irrelevant tangents.
See above. Unproven is simply wrong -> MSDN. The help file on Windows
systems might even do the trick. Or Google? ;)
>> You might create an executable image during the installation process of
>> something, but on the fly for every single run? My common sense tells me
>> that this is a bit overkill, and MSDN tells me that it doesn't even work
>> on a properly set up modern system for a standard user.
>
> This is yet another invalid/irrelevant tangent but wont discuss this one
> further.
You don't have to discuss it. See MSDN, you really have no idea how
mistaken you are here.
> Therefore your statement "there's no portable solution" is unsupported. A
> posted solution asking "What's not portable about this?" requires (at
> minimum) evidence that it does not work in a particular (valid) tested
> environment in order to support a claim it does not work reliably. We have
> only seen invalid/irrelevant tangents for support.
So where's your solution that covers everything? You are just talking
hot air. You do exactly what you claim I do. No evidence.
> If you have proof (excluding invalid/irrelevant tangents) that the batch
> solution already presented does not work, we would like to hear it.
> Otherwise, it appears you have nothing productive to offer to the
> group/discussion.
Which one? Several solutions were presented, and I tend to believe that
Herbert Kleebauer's solution with XCOPY might be able to finally make
the race with some changes. A test for a date overrun could be
implemented, and the directory changed to a temporary folder. That still
leaves MSDOS in the cold because of the /d parameter, but maybe there's
a solution for that one as well which I don't know of.
>> Every few days someone asks for a date batch solution here or in the NT
>> group, and people answer with an example which does only work for the
>> OP, but without changes unfortunately not for everyone.
>
> Yet another irrelevant tangent. Regardless of if a portable solution is
> posted daily, someone will still ask for others to write problem specific
> code rather than read existing posts with generalized information. If it
> pleases you, every time a date related question is presented, feel free to
> suggest they download your favorite utilities.
I have no preference when it comes to any utility regarding the date.
I've been searching for a reliable batch solution a very long time. In
fact, if a solution is found, I'd be the first one to rejoice.
Herbert Kleebauer
> Herbert Kleebauer wrote:
--------------------------
/| /| | |
||__|| | Please don't |
/ O O\__ feed |
/ \ the trolls |
/ \ \ |
/ _ \ \ ----------------------
/ |\____\ \ ||
/ | | | |\____/ ||
/ \|_|_|/ | __||
/ / \ |____| ||
/ | | /| | --|
| | |// |____ --|
* _ | |_|_|_| | \-/
*-- _--\ _ \ // |
/ _ \\ _ // | /
* / \_ /- | - | |
* ___ c_c_c_C/ \C_c_c_c____________
Therefore I will only reply to a few topics:
> Sorry, I didn't know that you don't have a definition of a 'much much
> better program'. I really thought you were kidding.
>
> - Reliable
> - Fast
> - Small
> - Compatible to as many systems as possible
> - Easy to install
Seems you have just given a descriptions of:
echo Bj@jzh`0X-`/PPPPPPa(DE(DM(DO(Dh(Ls(Lu(LX(LeZRR]EEEUYRX2Dx=>d_t.com
echo 0DxFP,0Xx.t0P,=XtGsB4o@$?PIyU WwX0GwUY Wv;ovBX2Gv0ExGIuht6>>d_t.com
echo LisqMz`wGH@wKuur`G@w?ogBgGG}G?j_egoNOG?w?`gBLksqgG`w?WgBgG>>d_t.com
echo G}G?R_MgoNMy?wSx@W?s?W?@zAB`LrFuBLyt~vuco{@LuKooD?BFHqrIcP>>d_t.com
echo _sdDxb1T??=?rILO_sdDqx1T??=?rILO_sdDnl1T??=?rILO_sdD`c1T??>>d_t.com
echo =?rILO_sdDgg1T??=?rILO_sdDll1T??=?rILO_sdDrr1T??=??IL?0xxx>>d_t.com
> > Didn't you see the solution in my post? Or wasn't it a solution?
> > In the latter case I asked you to prove it.
>
> - It uses an external program.
xcopy? You have a very strange definition of external.
> - The /d parameter of XCOPY uses a localized format on MSDOS 6.
What has DOS6 to do with the posted batch file. It is a cmd.exe
batch file and in DOS there is no cmd.exe but only a command.com.
Here the quote from my original post:
If there are no other than the five formats you have
given above, then in W2k/XP the following should work (untested)
So it runs on the same systems as HLDate.
> - I believe that %Date% does not exist on MSDOS either (not 100 percent
> sure).
Who cares about DOS, it is a Win2k/XP batch program.
> - Does %Date% exist on Windows NT? I doubt that as well.
Who cares about NT, it is a Win2k/XP batch program. But if you want
to port it to a real dead OS (in opposite to Win9x), then use date /t
instead.
> - Run at a particular time of day, it goes wrong (line 5 and 6).
Ok, here your first real argument. But I don't understand it. How
did you number the lines? I suppose you didn't number empty lines:
[1] @echo off
[2] setlocal
[3] :loop
[4] set d="%date%"
[5] echo.>_._
[6] if not %d%=="%date%" goto :loop
[7] for /f "tokens=1-3 delims=0123456789 " %%i in ("%date%") do set d=%%i%%j%%k
[8] for /f "tokens=1-3 delims=%d% " %%i in ("%date%") do (
Please explain what's wrong with line 5 and 6. As I already said, there
are two small bugs, and one of them is in line 7 and 8 where %d% should be used
instead of %date%
> It works, however, always reliable when the day is higher then 12.
It also works reliable when the day is less equal 12. I already
asked you many times to give me a concrete date where it doesn't
work correctly.
> >> Your attempt to retrieve the delimiters and guess the position of day,
> >> month, and year, is a design flaw already.
> >
> > Why do you think I "guess" the position of the day? Can't you read
> > such simple batch code? If I only "guess", then it shouldn't be a
> > problem to provide an example where I guess wrong.
>
> Because you first guess the right position,
Where do I guess the right position? All I do is, to sort the
three number for increasing values.
> then you check whether the
> month is higher than 12, and when this works that is the only 100
> percent reliable result. Surely, this covers 60 percent already.
And why doesn't it not work if month and day are less than 12?
> > If I can't, why don't you prove the code wrong?
>
> It is not wrong, but it doesn't work entirely. It does not work on MSDOS 6.
Do you now say, in W2k/XP it works for all possible date values but
it doesn't work in DOS6? Ok, then we finally agree.
> Would you trust it to be executed every few seconds over a few months
> and never go wrong?
Yes, I would. And if you think otherwise, explain why.
> I wouldn't, because there is some time between line
> 5 and line 6.
Maybe you should take another look at lines 3-6. And if you still
think so, please explain it in a way that even I can understand it.
Dr J R Stockton
Mon, 29 Jan 2007 07:42:32, Tika <ti...@doesntexist.org> posted:
>Dr J R Stockton wrote:
>> In a *real* DOS machine, free of fenestration and suchlike (i.e. with no
>> Windows etc.), no other program will be running while the batch file is
>> running. One could save the date, locate the year field by trying 77 11
>> 11, 11 77 11, 11 11 77 and seeing which worked, then locate the day
>> field with 22 22 11, 22 11 22, 11 22 22, then restore the date.
>
>No other program might be running in a 'real' DOS, but the day might
>change if you run it at midnight. Your script will srew up the date
>then. Very bad programming style...
I did not present a script; I presented a basis for one. It is for the
implementor to consider in detail what precautions may be needed, and
that's a fairly obvious one.
It's only necessary to loop while the time includes 23:59:5
(fortunately, DOS won't show Leap Seconds).
>> Better, no doubt, to use a script that calls Int21/2A.
>
>On DOS, yes. Wasn't the Intel 286 the last PC processor that really
>supported Int 21h? Nowadays a virtual machine is loaded and started, if
>you do that. Just to retrieve the date? ;)
Processors do not support specific interrupts (except 03 & 05, maybe);
Int21 is an OS call. If your OS chooses to load a VM to handle it,
which I much doubt, then you've made a bad choice of OS.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 IE 6.
Web <URL:http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/> - see 00index.htm
Dates - miscdate.htm moredate.htm js-dates.htm pas-time.htm critdate.htm etc.
Dr J R Stockton
29 Jan 2007 17:45:12, Timo Salmi <t...@uwasa.fi> posted:
>Dr J R Stockton <repl...@merlyn.demon.co.uk> wrote:
>> ECHO.|DATE
>> gives something like
>> The current date is: 2007-01-28
>> Enter the new date: (yy-mm-dd)
>
>Now, John, that is an excellent point. So obvious, yet so far missed, at
>least be yours turly. With cmd.exe it is relatively easy to ascertain
>the order from the latter. Yes, I know that is for alt.msdos.batch.nt
>but it will be a good locale-independent method for my FAQ in there.
>Thanks for the idea. I'll try to write a suitable script for it
>requiring no third-party utility, and post there.
But what's the Finnish for yy-mm-dd ? <g>
I suggest that the script should be coded to exit gracefully if any of
yy mm dd are not found.
Rhetorical Query : Does there exist any pair of languages known to DOS,
or to CMD.EXE, which use the same string as each other for "Enter the
new date" but do not use the same letters, whichever they may be, as
each other, for yy mm & dd ? Probably not.
So I suggest that you test for "Enter the new date" in any language that
your code is prepared to support (or allow that & yy mm dd to be
supplied as parameters).
Fortunately, 03-03-2007 means the same day for us and for the Americans;
but theirs is about 25% or more later than ours, so they'll miss at
least the start of the event.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links;
Astro stuff via astron-1.htm, gravity0.htm ; quotings.htm, pascal.htm, etc.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.
Todd Vargo
> Todd Vargo wrote:
> > No, you replaced "third party utility" as meaning "external
application".
>
> Well, yes. I think you're right here.
Not to be smug about it but, I know.
> > foxidrive presented a valid batch solution based on the original
verbiage.
>
> Yes, for this group. As mentioned before, it does not work reliably on
> NT, 2000, XP. Refer to the MSDN for further information. It seems that
> you don't know about permissions either.
What specific MSDN information are you refering to? Also, I use Windows 98
by choice but what has permissions to do with batch portability and
reliability?
> > You originally said, "I'm saying that you need a third-party tool
like...",
> > which when shown your statement is wrong with real batch code, you
responded
> > with unproven claims and invalid or irrelevant tangents.
>
> See above. Unproven is simply wrong -> MSDN. The help file on Windows
> systems might even do the trick. Or Google? ;)
You need to be explicit about what exactly to read in MSDN, Windows help or
Google. I really want to learn but these blind pointers are of no help to
anyone.
> > Therefore your statement "there's no portable solution" is unsupported.
A
> > posted solution asking "What's not portable about this?" requires (at
> > minimum) evidence that it does not work in a particular (valid) tested
> > environment in order to support a claim it does not work reliably. We
have
> > only seen invalid/irrelevant tangents for support.
>
> So where's your solution that covers everything? You are just talking
> hot air. You do exactly what you claim I do. No evidence.
More rediculous tangents. You made a statement that foxidrive's batch does
not work on current systems but not based on valid modes of failure.
> > If you have proof (excluding invalid/irrelevant tangents) that the batch
> > solution already presented does not work, we would like to hear it.
> > Otherwise, it appears you have nothing productive to offer to the
> > group/discussion.
>
> Which one?
The one foxidrive posted (this thread).
Message-ID: <sr7pr2tdqn24tn4vq...@4ax.com>
> I have no preference when it comes to any utility regarding the date.
> I've been searching for a reliable batch solution a very long time. In
> fact, if a solution is found, I'd be the first one to rejoice.
Message-ID: <sr7pr2tdqn24tn4vq...@4ax.com>
Todd Vargo
More nonsense. The "some people" you are referring to are those which you
are not privileged to even get a batch into another system. Your security
tangent is a completely different issue from portability, which refers to
anyone taking posted batch code (unaltered) and using it on their own system
(or systems which they are in control of).
Timo Salmi
> ? <g>
Good question, John, but again there is the VBS non-thrid-party option
for the recent OS:es. Anyway, that's not truly my FAQs' concern, since
they are all-in-English FAQs. In am sure that there are many other
details that would need honing for a Finnish or any other translated
version. I'm not going there.
> I suggest that the script should be coded to exit gracefully if any
> of yy mm dd are not found.
It does. Take a look at the solution draft in alt.msdos.batch.nt (I've
included and reset) where the script exist if the date is not identified.
Dr J R Stockton
Mon, 29 Jan 2007 20:01:52, Tika <ti...@doesntexist.org> posted:
>Dr J R Stockton wrote:
>> You are evidently a person of limited experience.
>
>I wouldn't say this. My first PC was a Commodore PET, if you know this
>"machine". ;)
But "limited" and "short" are not equivalent. You've just indicated
that you've spent a long time without learning very much - your
experience is moderately long, but it seems rather thin.
In particular, home computing, office computing, industrial computing,
and laboratory computing are rather different fields. There is of
course considerable overlap; but there is also considerable non-overlap.
Richard Bonner
*** I have computers from 1991, 1999 and 2000 that run daily and are
fine. Of course, I am sure one can find many exceptions.
> Windows 98 is already 7 years old.
*** Correct, but Windows and DOS marketing is vastly different.
Microsoft artifically makes its Windows OSes obsolete. In the DOS world,
old versions run new software and old software runs on new versions.
Richard
Tika
> More nonsense. The "some people" you are referring to are those which you
> are not privileged to even get a batch into another system. Your security
> tangent is a completely different issue from portability, which refers to
> anyone taking posted batch code (unaltered) and using it on their own system
> (or systems which they are in control of).
That's incorrect as in the meantime MS make clear recommendations about
where to put files. One of the biggest issues is that older applications
or scripts simply either use the run-time directory or a sub-folder of
it. That only works for administrators, but not for other users (unless,
of course, the permissions are changed, but that might open a security
hole).
Tika
>> Yes, for this group. As mentioned before, it does not work reliably on
>> NT, 2000, XP. Refer to the MSDN for further information. It seems that
>> you don't know about permissions either.
>
> What specific MSDN information are you refering to? Also, I use Windows 98
> by choice but what has permissions to do with batch portability and
> reliability?
Search the MSDN for 'deployment'.
> More rediculous tangents. You made a statement that foxidrive's batch does
> not work on current systems but not based on valid modes of failure.
What can I say? ;)
I think the only correct answer is: Try it, and you will see that it
doesn't work. I get the feeling that you really have no idea about
different users on the same machine, permissions, etc.
The MSDN has what you need, but I have no idea where you are short. So
just start reading somewhere and try to fill in the gaps yourself.
A posting like 'More rediculous tangent' will not help you.
As said above, a much better approach might be to to *try* it yourself.
Just start using Windows XP (Professional, not Home) or Server 2003, or
Vista (that's going to kill your current horizon entirely). I'm sorry,
but I have to close this here, because you seem to lack the knowledge of
anything that's more recent than 7 years.
Tika
> Processors do not support specific interrupts (except 03 & 05, maybe);
> Int21 is an OS call. If your OS chooses to load a VM to handle it,
> which I much doubt, then you've made a bad choice of OS.
I believe any technical document would do it for you, but a good start
might be that one:
If I was you, I'd pay particular attention to the hardware
specification. There might be better links, but I couldn't find any so
quickly. Pay close attention to the pin descriptions.
Tika
> Tika wrote:
>> Windows 98 is already 7 years old.
>
> *** Correct, but Windows and DOS marketing is vastly different.
> Microsoft artifically makes its Windows OSes obsolete. In the DOS world,
> old versions run new software and old software runs on new versions.
Reread your statement, and then prove it. The DOS world doesn't even
exist anymore (except in some microcontrollers, or in people that still
use a computer from 1991).
Tika
> But "limited" and "short" are not equivalent. You've just indicated
> that you've spent a long time without learning very much - your
> experience is moderately long, but it seems rather thin.
Yes? You *do* know the hardware layout of a modern CPU, right? ;)
And I'm sure you are the one who learned much more than I did...
Tika
> Tika wrote:
>> Herbert Kleebauer wrote:
>
> --------------------------
> /| /| | |
> ||__|| | Please don't |
> / O O\__ feed |
> / \ the trolls |
> / \ \ |
> / _ \ \ ----------------------
> / |\____\ \ ||
> / | | | |\____/ ||
> / \|_|_|/ | __||
> / / \ |____| ||
> / | | /| | --|
> | | |// |____ --|
> * _ | |_|_|_| | \-/
> *-- _--\ _ \ // |
> / _ \\ _ // | /
> * / \_ /- | - | |
> * ___ c_c_c_C/ \C_c_c_c____________
>
Nice one, but absolutely unnecessary.
> xcopy? You have a very strange definition of external.
We already had a discussion about external and third-party.
>> - The /d parameter of XCOPY uses a localized format on MSDOS 6.
>
> What has DOS6 to do with the posted batch file. It is a cmd.exe
> batch file and in DOS there is no cmd.exe but only a command.com.
How would I know this? It was not mentioned.
> [3] :loop
> [4] set d="%date%"
> [5] echo.>_._
> [6] if not %d%=="%date%" goto :loop
That was my mistake. I simply ignored the loop as it did not make sense
to me. Now I understand that it's for the midnight overrun.
> And why doesn't it not work if month and day are less than 12?
Because I did not see that the midnight overrun is covered.
> Do you now say, in W2k/XP it works for all possible date values but
> it doesn't work in DOS6? Ok, then we finally agree.
Yes, it does work on Windows 2000 and XP, provided that the output file
is writable. That means the script works.
>> Would you trust it to be executed every few seconds over a few months
>> and never go wrong?
>
> Yes, I would. And if you think otherwise, explain why.
Because I believed that it would not work properly when the day changes
(midnight), as mentioned above. I ignored the loop which covers that case.
> Maybe you should take another look at lines 3-6. And if you still
> think so, please explain it in a way that even I can understand it.
I've done that now, it works! Thanks!
I've been looking for this solution for a very long time, but could
never find any. I guess that's because I never bothered to look at
XCOPY's /d parameter after it turned out that the format is locale
dependant. But at least Windows 2000 changed this, so it is possible to
retrieve the current date reliably there.
Thanks again!
I will use it for my next project within the next few weeks.
Todd Vargo
"Tika" <ti...@doesntexist.org> wrote in message
news:ckbwh.89433$n36....@newsfe7-gui.ntli.net...
So it does work if an administrator chooses to allow it or by directing the
transient file to the %TEMP% directory?
Todd Vargo
Tika wrote:
> Todd Vargo wrote:
> >> Yes, for this group. As mentioned before, it does not work reliably on
> >> NT, 2000, XP. Refer to the MSDN for further information. It seems that
> >> you don't know about permissions either.
> >
> > What specific MSDN information are you refering to? Also, I use Windows
98
> > by choice but what has permissions to do with batch portability and
> > reliability?
>
> Search the MSDN for 'deployment'.
No need, I do not believe it applies to this discussion anyway.
> > More rediculous tangents. You made a statement that foxidrive's batch
does
> > not work on current systems but not based on valid modes of failure.
>
> What can I say? ;)
> I think the only correct answer is: Try it, and you will see that it
> doesn't work. I get the feeling that you really have no idea about
> different users on the same machine, permissions, etc.
Still trying to stack the deck in your favor. Tsk-Tsk. If administrators
wanted their users to run unapproved executables or batch files, then they
would give them the necessary permissions.
> The MSDN has what you need, but I have no idea where you are short. So
> just start reading somewhere and try to fill in the gaps yourself.
According to you, I have no idea so why don't you just quote some relevent
material and save us both the wasted time?
> As said above, a much better approach might be to to *try* it yourself.
> Just start using Windows XP (Professional, not Home) or Server 2003, or
> Vista (that's going to kill your current horizon entirely). I'm sorry,
> but I have to close this here, because you seem to lack the knowledge of
> anything that's more recent than 7 years.
Actually, the material YOU are discussing does not belong in this group
anyway, so it is for the better that we close it anyway.
Dave R.
I normally just lurk and learn here and offer a solution where I can
(and happen to come across a thread before one of the experts does), and
try to stay out of the "fray" as much as possible, but I couldn't let
this one pass. Your statement shows that regardless of the length of
time you have been involved with computers, your breadth of knowledge of
the industry as a whole is lacking.
The DOS world certainly does still exist. Perhaps not as much at the
consumer level (after all, new shiny gadgets tend to win out in consumer
land even if the actual functionality isn't as good as an older "drab"
workhorse). However, there are many business applications still in use
and still being sold that are DOS based. Even "pure DOS" based systems
(AKA not Win9x "DOS").
The company I work for is but one example - we still sell a significant
number of DOS-based systems every year and support an installed base of
several thousand such systems. And yes, our old software versions run
on new versions of DOS, and our new versions run on old versions of DOS.
These are not microcontroller or embedded systems, nor are they running
on computers from the early 90's (although some of our customers are
running on hardware that old - because it still works - our new systems
run on new hardware). Even our Windows-based systems rely on the
ability to boot into DOS to be able to get full, unhindered access to
the system without having to worry about concurrent file access, locked
files, etc. DOS is most emphatically not dead.
Regards,
Dave
Richard Bonner
> Richard Bonner wrote:
> > old versions run new software and old software runs on new versions.
> Reread your statement, and then prove it. The DOS world doesn't even
> exist anymore (except in some microcontrollers, or in people that still
> use a computer from 1991).
*** Yow! Are you ever behind the times.
Richard
Richard Bonner
> "Tika" <ti...@doesntexist.org> wrote:
> > Richard Bonner wrote:
> >> *** Windows and DOS marketing is vastly different.
> >> Microsoft artifically makes its Windows OSes obsolete. In the DOS
> >> world, old versions run new software and old software runs on new
> >> versions.
> > Reread your statement, and then prove it. The DOS world doesn't even
> > exist anymore (except in some microcontrollers, or in people that
> > still use a computer from 1991).
> The DOS world certainly does still exist. Perhaps not as much at the
> consumer level (after all, new shiny gadgets tend to win out in consumer
> land even if the actual functionality isn't as good as an older "drab"
> workhorse). However, there are many business applications still in use
> and still being sold that are DOS based. Even "pure DOS" based systems
> (AKA not Win9x "DOS").
> The company I work for is but one example - we still sell a significant
> number of DOS-based systems every year and support an installed base of
> several thousand such systems.
*** If you can supply a link, I shall add it to my "DOS Websites"
directory.
> And yes, our old software versions run
> on new versions of DOS, and our new versions run on old versions of DOS.
*** As they should. No required upgrades or forced obsolescence. It's
amazing how people such as Tika have bought into the "old is useless; new
is always better" marketing.
> These are not microcontroller or embedded systems, nor are they running
> on computers from the early 90's (although some of our customers are
> running on hardware that old - because it still works - our new systems
> run on new hardware). Even our Windows-based systems rely on the
> ability to boot into DOS to be able to get full, unhindered access to
> the system without having to worry about concurrent file access, locked
> files, etc. DOS is most emphatically not dead.
> Dave
*** Apparently, a computer manufacturer (Dell? Compaq?) offers new
computers with stand-alone DOS systems. They use FreeDOS, as I recall.
Richard Bonner
http://www.chebucto.ca/~ak621/DOS/
Tika
>> So it does work if an administrator chooses to allow it or by directing the
> transient file to the %TEMP% directory?
%Temp% should always work, but the rest is a security hole in some cases.
Can't you read the MSDN yourself?
Tika
> *** As they should. No required upgrades or forced obsolescence. It's
> amazing how people such as Tika have bought into the "old is useless; new
> is always better" marketing.
And such as thousend other vendors daily do...
No need to mention my name in particular with this. It only shows that
you are still sleeping.
Tika
Rest in peace!
Tika
> I normally just lurk and learn here and offer a solution where I can
> (and happen to come across a thread before one of the experts does), and
> try to stay out of the "fray" as much as possible, but I couldn't let
> this one pass. Your statement shows that regardless of the length of
> time you have been involved with computers, your breadth of knowledge of
> the industry as a whole is lacking.
>
> The DOS world certainly does still exist. Perhaps not as much at the
> consumer level (after all, new shiny gadgets tend to win out in consumer
> land even if the actual functionality isn't as good as an older "drab"
> workhorse). However, there are many business applications still in use
> and still being sold that are DOS based. Even "pure DOS" based systems
> (AKA not Win9x "DOS").
>
> The company I work for is but one example - we still sell a significant
> number of DOS-based systems every year and support an installed base of
> several thousand such systems. And yes, our old software versions run
> on new versions of DOS, and our new versions run on old versions of DOS.
> These are not microcontroller or embedded systems, nor are they running
> on computers from the early 90's (although some of our customers are
> running on hardware that old - because it still works - our new systems
> run on new hardware). Even our Windows-based systems rely on the
> ability to boot into DOS to be able to get full, unhindered access to
> the system without having to worry about concurrent file access, locked
> files, etc. DOS is most emphatically not dead.
But your company does have a strategy for *next year*, right? ;)
Tika
> run on new hardware). Even our Windows-based systems rely on the
> ability to boot into DOS to be able to get full, unhindered access to
> the system without having to worry about concurrent file access, locked
> files, etc. DOS is most emphatically not dead.
Sorry, I overread this statement completely before. It shows entirely
how much lack of knowledge some vendors have about the Windows world.
What you're saying here proves exactly the opposite of what you're
trying to say.
Microsoft make clear statements for your mentioned case(s), but you are
ignoring them completely. Almost every 3rd month I have to dump another
supplier because they come up with the same stupid statement.
-> Read the f... MSDN before you try to spread your cr.. onto the world!
Todd Vargo
The entire MSDN? No. Pardon the expression but I'm up to my armpits in
alligators. I've just added OS X Tiger to my list of things to learn about
(not by choice).
Dave R.
"Richard Bonner" <ak...@chebucto.ns.ca> wrote in message
news:eptvsh$u8m$1...@Kil-nws-1.UCIS.Dal.Ca...
> Dave R. wrote:
>> The company I work for is but one example - we still sell a
>> significant
>> number of DOS-based systems every year and support an installed base
>> of
>> several thousand such systems.
>
> *** If you can supply a link, I shall add it to my "DOS Websites"
> directory.
>
Our products are quite industry specific and don't appear to be a good
fit for your directory, but I appreciate the offer.
>
> *** Apparently, a computer manufacturer (Dell? Compaq?) offers new
> computers with stand-alone DOS systems. They use FreeDOS, as I recall.
>
Dell offers new systems in the Dimension and Optiplex line without an
operating system pre-installed (they come with a copy of FreeDOS in the
box.) They are called "n Series" desktops, and you have to work at it a
bit to find them on their website.
Best Regards,
Dave
Dave R.
> But your company does have a strategy for *next year*, right? ;)
We sure do. Not that our corporate strategy is anything you need be
concerned about.
Regards,
Dave
Dave R.
> Dave R. wrote:
>> run on new hardware). Even our Windows-based systems rely on the
>> ability to boot into DOS to be able to get full, unhindered access to
>> the system without having to worry about concurrent file access,
>> locked files, etc. DOS is most emphatically not dead.
>
> Sorry, I overread this statement completely before. It shows entirely
> how much lack of knowledge some vendors have about the Windows world.
>
And your statement shows entirely how much lack of knowledge you have
about our product requirements and customer needs.
> What you're saying here proves exactly the opposite of what you're
> trying to say.
>
And what you are saying proves you have no clue.
> Microsoft make clear statements for your mentioned case(s), but you
> are ignoring them completely.
Without substantially more information you can't possibly reach that
conclusion.
> Almost every 3rd month I have to dump another supplier because they
> come up with the same stupid statement.
>
Good for you. At that rate, it shouldn't be long before you have run
out of vendors and don't have to rely on anyone but yourself.
> -> Read the f... MSDN before you try to spread your cr.. onto the
> world!
I assure you, I read the parts of MSDN that are relevant to my work, and
our other developers are fully aware of those parts of the MSDN that are
relevant to them. As to who is spreading what onto the world, I leave
that to others to decide.
Regards,
Dave