4DOS under XP
Klaus Meinhard
Happy Christmas to you. I hope you all got what you wished for :-)
I have some unfullfilled wishes for 4DOS:
The defaults for running under XP should IMHO be the same as those for
Windows 95/98/ME. Especially the (INI-) defaults for LFNs should be the
same.
4DOS should recognize a NT type OS in the _DOS intvar. It supports the
recognition of OS/2, even though there was is a specialized 4OS2. Why
not NT?
The TITLEPROMPT var and the TITLE command are not recognized under XP.
There may be more.
I don't think that implementing this is contrary to the 4DOS free
licence. It would make life much easier for people who try to help
developement of 4DOS, but have only a XP type machine at hand.
--
* Klaus Meinhard *
4DOS Info - Info for DOS
www.4dos.info
Luchezar Georgiev
> Happy Christmas to you. I hope you all got what you wished for :-)
Happy Christmas to you too, and to everybody else who celebrates it now!
> The defaults for running under XP should IMHO be the same as those for
> Windows 95/98/ME. Especially the (INI-) defaults for LFNs should be the
> same.
As the NT API is inaccessible by 16-bit application programmes like 4DOS,
it treats NT like plain DOS. And I already explained why the defaults for
DOS of the LFN support are such. They will stay so, as long as I maintain
4DOS. Anyway, the defaults aren't so important as 4DOS.INI can be edited;
if someone wants a temporary change OPTION //directive=value can be used.
> 4DOS should recognize a NT type OS in the _DOS intvar. It supports the
> recognition of OS/2, even though there was is a specialized 4OS2. Why
> not NT?
Because 4DOS is more "tuned" for and useful in OS/2 than in NT. Unlike NT,
OS/2 still offers some of the 16-bit API. NT has thrown out all of this...
> The TITLEPROMPT var and the TITLE command are not recognized under XP.
Same reason. The 16-bit "WINOLDAP" API that Windows 9x/ME offered has been
removed from the NT. So a 16-bit programme has no way of using any NT API.
> I don't think that implementing this is contrary to the 4DOS free
> licence. It would make life much easier for people who try to help
> developement of 4DOS, but have only a XP type machine at hand.
Any serous DOS programme developer could easily install an older operating
system in addition to NT (without destroying anything). All that is needed
is resizing of the NTFS partition and adding a second, FAT32 partition. Or
a virtual machine like VMWARE could be installed. Or Linux with DOSEMU. Or
any other OS or virtualiser. Of course, nothing beats a vintage Windows 98
(on the other hand, why an NT user would be interested in 4DOS at all when
there's the free TCC/LE available?)!
Regards,
Lucho
Klaus Meinhard
> > The defaults for running under XP should IMHO be the same as those
> > for Windows 95/98/ME. Especially the (INI-) defaults for LFNs
> > should be the same.
> As the NT API is inaccessible by 16-bit application programmes like
> 4DOS, it treats NT like plain DOS. And I already explained why the
> defaults for DOS of the LFN support are such.
I accept that the NT API is inaccessible by 4DOS, but you can reliably
recognize NT etc. by its MS-DOS version 5.50 signature. I do not want to
change the defaults of plain DOS (where it wouldn't matter, I still
maintain), but under NT etc.
> They will stay so, as
> long as I maintain 4DOS.
Basta.
> Anyway, the defaults aren't so important as
> 4DOS.INI can be edited; if someone wants a temporary change OPTION
> //directive=value can be used.
I know that, and I use this. That it can be done manually doesn't
preclude that 4DOS could do it reliably and automagically, and I stand
by my opinion that it should.
> > 4DOS should recognize a NT type OS in the _DOS intvar. It supports
> > the recognition of OS/2, even though there was is a specialized
> > 4OS2. Why not NT?
> Because 4DOS is more "tuned" for and useful in OS/2 than in NT.
> Unlike NT, OS/2 still offers some of the 16-bit API. NT has thrown
> out all of this...
As shown above, you don't need a 32-bit API for this.
--
Mit freundlichem Gruß,
Klaus Meinhard
Luchezar Georgiev
> I know that, and I use this. That it can be done manually doesn't
> preclude that 4DOS could do it reliably and automagically, and I stand
> by my opinion that it should.
So, you only want the LFNs to be enabled by default when the DOS version is
5.50? Just one bit of friendliness to NT despite all the "use 4NT under NT"
warnings? How should one then treat these warnings then but as a hypocrisy?
I wouldn't like to say one thing while quietly doing the opposite. Actually
4DOS won't run in NT itself, only in its DOS emulator - by far not the best
one. And use of 4DOS in emulators isn't supported, as I state on my site :)
Regards,
Lucho
Klaus Meinhard
> So, you only want the LFNs to be enabled by default when the DOS
> version is 5.50?
... and %_DOS is MS-DOS. Yes, and that the %_DOS intvar shows at least
"Win NT".
> Just one bit of friendliness to NT despite all the "use 4NT
> under NT" warnings?
Just one bit of correct information.
> How should one then treat these warnings then but
> as a hypocrisy? I wouldn't like to say one thing while quietly doing
> the opposite. Actually 4DOS won't run in NT itself, only in its DOS
> emulator - by far not the best one. And use of 4DOS in emulators
> isn't supported, as I state on my site :)
That's silly. The above wouldn't use any 32-bit APIs, wouldn't overcome
any limitations 4DOS has under NT. It would just produce correct
information and, - yes- , be a piece of friendliness to users of 4DOS.
You decide if you can spare so "much" friendliness.
Matthias Tacke
> (on the other hand, why an NT user would be
> interested in 4DOS at all when there's the free TCC/LE available?)!
>
TCC/LE is crippled in a way that scipts running under 4DOS (and especially
when using your 4NT/TCC compatible enhancements) won't work at all.
I tried to find the function comparison table at www.jpsoft.com, but can't
get access. The site doesn't seem to be online.
--
Regards
Matthias
Caesar Romano
wrote Re Re: 4DOS under NT:
The site seem off-line to me also.
Luchezar Georgiev
>> I tried to find the function comparison table at www.jpsoft.com, but can't
>> get access. The site doesn't seem to be online.
> The site seem off-line to me also.
The page is http://jpsoft.com/help/tcc_and_tcclite.htm and it works for me.
Regards,
Lucho
Luchezar Georgiev
>> So, you only want the LFNs to be enabled by default when the DOS
>> version is 5.50?
> ... and %_DOS is MS-DOS.
I'm not aware of any DOS (real or emulated) that returns true version 5.50
but the DOS emulator of the NT. So I don't think the 2nd check is needed.
> Yes, and that the %_DOS intvar shows at least "Win NT".
This would be the only DOS emulator that will be detected by 4DOS. Not fair
to the others ;-)
Anyway, maybe the _WIN variable would also need to be changed?! Another bit
of friendliness to the non-regulated usage of 4DOS that probably amounts to
90% of its users. Sorry, 90% or 99% - 4DOS is NOT intended for use under NT
and if you want to use this vintage software - please do so under a vintage
operating system that nobody uses anymore. Be so kind to jump off the "band
wagon". Yes I know that noone will do that: then please bear with the small
inconveniences. I think that's a fair policy. Another policy is to warn, if
4DOS use is attempted under the NT DOS emulator. And yet another is to exit
in this case, after a warning. Be glad that 4DOS doesn't do any of these 2.
> That's silly. The above wouldn't use any 32-bit APIs, wouldn't overcome
> any limitations 4DOS has under NT. It would just produce correct
> information and, - yes- , be a piece of friendliness to users of 4DOS.
> You decide if you can spare so "much" friendliness.
OK, I'll think about this and decide whether to keep doing the silly thing.
But I like very much the last paragraphs of the _DOS and _WIN help topics -
especially the latter, quoted below:
"Note that 4DOS is not intended for use under the Windows NT line. 4DOS
does not check for these versions of Windows and does not report them in
the _WIN variable".
Although this note has been added by Charles Dye, I'm sure that that was an
intentional decision of Rex Conn (I mean, to not check for the NT in 4DOS).
Why should I change it? What has changed since he took this decision?!
Regards,
Lucho
Jaelani
> TCC/LE is crippled in a way that scipts running under 4DOS (and
> especially when using your 4NT/TCC compatible enhancements) won't work
> at all.
>
Interesting...
Could you post some examples of these scripts/lines please?
Regards,
Jaelani
Steve Fabian
| Klaus Meinhard пишет:
...
|| That's silly. The above wouldn't use any 32-bit APIs, wouldn't
|| overcome any limitations 4DOS has under NT. It would just produce
|| correct information and, - yes- , be a piece of friendliness to
|| users of 4DOS. You decide if you can spare so "much" friendliness.
|
| OK, I'll think about this and decide whether to keep doing the silly
| thing. But I like very much the last paragraphs of the _DOS and _WIN
| help topics - especially the latter, quoted below:
|
| "Note that 4DOS is not intended for use under the Windows NT line.
| 4DOS does not check for these versions of Windows and does not report
| them in the _WIN variable".
|
| Although this note has been added by Charles Dye, I'm sure that that
| was an intentional decision of Rex Conn (I mean, to not check for the
| NT in 4DOS). Why should I change it? What has changed since he took
| this decision?!
Things changed. There are now many people who attempt to use 4DOS in the NT
environment. More importantly, you have undertaken to continue enhancing
4DOS. It is reasonable for people who run both WinNT and xxxDOS to download
using the NT platform, and test new 4DOS versions there before moving it to
a DOS platform. This would be much simpler if the actual platform (which may
be composed of a combination of a WinNT OS and a DOS emulator) could be
discerned.
OTOH, the JPsoft license for the 4DOS as enhanced by you, Lucho, is not
valid on WinNT platforms. The correct approach to conform to the licensing
agreement would probably be to disable 4DOS entirely when such a platform is
detected.
Just my opinion.
--
Steve
Klaus Meinhard
> Or a virtual machine like VMWARE could be installed.
> Or Linux with DOSEMU. Or any other OS or virtualiser.
Your helpful suggestions bring to mind that TCC can determine if it runs
in a virtual PC (_virtualpc) or under VMWare (_vmware). Is it possible
to determine the fact and the make of a virtual dos box under 4DOS?
Klaus Meinhard
> OTOH, the JPsoft license for the 4DOS as enhanced by you, Lucho, is
> not valid on WinNT platforms. The correct approach to conform to the
> licensing agreement would probably be to disable 4DOS entirely when
> such a platform is detected.
To put it clearly: if that policy is pursued, I will stop participating
in _any_ 4DOS activity and take my site off the net.
The policy must clearly be to not make 4DOS into a significant
competitor to current JP Software command processors. Up to now Lucho
has been proud to have copied many intvars und functions from 4NT/TCC,
"following the course" Rex has set, making 4DOS similar to 4NT as far as
possible. Do I detect some bias here?
I am too lazy to look up the exact wording again, but Rex has expressed
that he doesn't care under which brand of DOS 4DOS runs. He excludes
compilation for other operating systems. For me that includes clearly
running under DOS, even a DOS emulator, and precludes the compilation
for e.g. NT, using NT 32bit APIs, ot Linux, using Linux APIs.
If in doubt, ask Rex by email, for heavens sake, or I will do so. I am
sure that Rex couldn't care less if 4DOS is able to detect another fact
about it's environment (e.g. that it is in the DOS console of NT, or VM
or whatever) and set its default values accordingly. IIRC Vista doesn't
even have a DOS compatible box any longer, so the whole question becomes
moot anyway in the near future.
Matthias Tacke
> Luchezar Georgiev wrote:
>
>> Or a virtual machine like VMWARE could be installed.
>> Or Linux with DOSEMU. Or any other OS or virtualiser.
>
> Your helpful suggestions bring to mind that TCC can determine if it runs
> in a virtual PC (_virtualpc) or under VMWare (_vmware). Is it possible
> to determine the fact and the make of a virtual dos box under 4DOS?
>
>
information. Sun's (former Innotek) VirtualBox Version 2.1.0 returns this:
@SMBSTR[TYPE,n]
Type n Meaning of the string
---------------------------------------
0 1 BIOS manufacturer name : innotek GmbH
0 2 BIOS version : VirtualBox
0 3 BIOS release date : 12/01/2006
1 1 system manufacturer name : innotek GmbH
1 2 system (product) name : VirtualBox
1 3 system (product) version : 1.2
1 4 system serial number : 0
2 1 main board manufacturer name
2 2 main board (product) name :
2 3 main board (product) version
2 4 main board serial number :
4 1 CPU socket designation :
4 2 CPU manufacturer name :
4 3 CPU version :
I know of some tools for vmware using proprietary api calls.
This API is described here:
http://chitchat.at.infoseek.co.jp/vmware/backdoor.html#top
HTH
Matthias
PS: the batch for the above output:
::SMB-INFO.BTM
@echo off
echo.
echo.@SMBSTR[TYPE,n]
echo.Type n Meaning of the string
echo.---------------------------------------
echo. 0 1 BIOS manufacturer name : %@SMBSTR[0,1]
echo. 0 2 BIOS version : %@SMBSTR[0,2]
echo. 0 3 BIOS release date : %@SMBSTR[0,3]
echo. 1 1 system manufacturer name : %@SMBSTR[1,1]
echo. 1 2 system (product) name : %@SMBSTR[1,2]
echo. 1 3 system (product) version : %@SMBSTR[1,3]
echo. 1 4 system serial number : %@SMBSTR[1,4]
echo. 2 1 main board manufacturer name %@SMBSTR[2,1]
echo. 2 2 main board (product) name : %@SMBSTR[2,2]
echo. 2 3 main board (product) version %@SMBSTR[2,3]
echo. 2 4 main board serial number : %@SMBSTR[2,4]
echo. 4 1 CPU socket designation : %@SMBSTR[4,1]
echo. 4 2 CPU manufacturer name : %@SMBSTR[4,2]
echo. 4 3 CPU version : %@SMBSTR[4,3]
Luchezar Georgiev
>> OTOH, the JPsoft license for the 4DOS as enhanced by you, Lucho, is
>> not valid on WinNT platforms. The correct approach to conform to the
>> licensing agreement would probably be to disable 4DOS entirely when
>> such a platform is detected.
I don't agree, because what 4DOS deals with is the DOS emulator of NT, not
NT itself. What the licence actually prohibits in my opinion, is using the
NT API, which 4DOS, as a 16-bit DOS programme, is completely unable to do.
("Porting" it to NT would mean first and foremost turning it into a 32-bit
programme and then switching to the NT API. Same for Linux, BSD, Mac OS X,
etc.)
> To put it clearly: if that policy is pursued, I will stop participating
> in _any_ 4DOS activity and take my site off the net.
To put it clearly: I don't intend to pursue it, DESPITE the above warning.
> The policy must clearly be to not make 4DOS into a significant
> competitor to current JP Software command processors. Up to now Lucho
> has been proud to have copied many intvars und functions from 4NT/TCC,
> "following the course" Rex has set, making 4DOS similar to 4NT as far as
> possible. Do I detect some bias here?
Yes, of course. The best source of ideas for 4DOS until recently has been
4NT, which is quite natural. (Lately I feel I've reached my limits here.)
If you feel that this breaches the 4DOS licence, I will have to "turn the
tick end" [of the stick] by pursuing the above policy. Do NOT force me do
it. It can't be effective anyway as the anti-4NT mechanism can be cracked
so it won't reach its goal but will have only bad consequences instead. I
will resign from 4DOS maintenance if placed between Scylla and Charybdis.
If you reply that I've placed myself there, then what to do, it's a fate.
> I am too lazy to look up the exact wording again, but Rex has expressed
> that he doesn't care under which brand of DOS 4DOS runs. He excludes
> compilation for other operating systems. For me that includes clearly
> running under DOS, even a DOS emulator, and precludes the compilation
> for e.g. NT, using NT 32bit APIs, ot Linux, using Linux APIs.
I agree 100%.
> If in doubt, ask Rex by email, for heavens sake, or I will do so.
I'm not in doubt.
> I am
> sure that Rex couldn't care less if 4DOS is able to detect another fact
> about it's environment (e.g. that it is in the DOS console of NT, or VM
> or whatever) and set its default values accordingly. IIRC Vista doesn't
> even have a DOS compatible box any longer, so the whole question becomes
> moot anyway in the near future.
No, Vista does have a DOS emulator but its DPMI memory is limited to 32 MB
and the full screen text video mode is not supported (unless triggered via
@DDCSTR :) We'll see about Windows 7...
Regards,
Lucho
Matthias Tacke
VMWare Player 2.5.2 running FreeDOS with 4DOS 7.98 returns:
@SMBSTR[TYPE,n]
Type n Meaning of the string
---------------------------------------
0 1 BIOS manufacturer name : Phoenix Technologies LTD
0 2 BIOS version : 6.00
0 3 BIOS release date : 08/15/2008
1 1 system manufacturer name : VMware, Inc.
1 2 system (product) name : VMware Virtual Platform
1 3 system (product) version : None
1 4 system serial number : VMware-(snipped)
2 1 main board manufacturer name Intel Corporation
2 2 main board (product) name : 440BX Desktop Reference Platform
2 3 main board (product) version None
2 4 main board serial number : None
4 1 CPU socket designation : CPU socket #0
4 2 CPU manufacturer name : GenuineIntel
4 3 CPU version : Pentium(R) Pro
BTW VMCHK out of the vmcmd-tools
http://chitchat.at.infoseek.co.jp/vmware/vmtools.html#vmcmd
will output the vmware version verbosely and also set the errorlevel.
--
Regards Matthias
ras...@highfiber.com
One alternative approach might be, instead of checking for NT, to test
the LFN API and enable LFN handling if the API is supported. (Note
that while I mention this as a technical possibility, I don't advocate
it as a *good* idea.)
I don't feel strongly about this issue. The present behavior seems
like a reasonable balance between encouraging 4DOS in "wrong"
environments and forbidding it. Tweaking an .INI file doesn't seem
too difficult for 4DOS's target audience. If it is, perhaps a tick
box might be added in the OPTION dialog...?
--
Charles Dye ras...@highfiber.com
lcaverly
> Matthias Tacke wrote:
>
> VMWare Player 2.5.2 running FreeDOS with 4DOS 7.98 returns:
>
> @SMBSTR[TYPE,n]
> Type n Meaning of the string
> ---------------------------------------
> 0 1 BIOS manufacturer name : Phoenix Technologies LTD
> 0 2 BIOS version : 6.00
> 0 3 BIOS release date : 08/15/2008
> 1 1 system manufacturer name : VMware, Inc.
> 1 2 system (product) name : VMware Virtual Platform
> 1 3 system (product) version : None
> 1 4 system serial number : VMware-(snipped)
> 2 1 main board manufacturer name Intel Corporation
> 2 2 main board (product) name : 440BX Desktop Reference Platform
> 2 3 main board (product) version None
> 2 4 main board serial number : None
> 4 1 CPU socket designation : CPU socket #0
> 4 2 CPU manufacturer name : GenuineIntel
> 4 3 CPU version : Pentium(R) Pro
>
> will output the vmware version verbosely and also set the errorlevel.
>
> --
> Regards Matthias
Hi,
Back on August 5th, Lucho made this all possible. I was able to get
the following from within Microsoft Virtual PC 2004 running MS-DOS
6.22 / 4DOS at that time;
c:\4dos>echo %@smbstr[2,1]
Microsoft Corporation
c:\4dos>echo %@smbstr[2,2]
Virtual Machine
c:\4dos>echo %@smbstr[2,3]
5.0
Joe
Klaus Meinhard
you've got my answers to your and Steve's postings mixed up.
Steve wrote:
> > > OTOH, the JPsoft license for the 4DOS as enhanced by you, Lucho,
> > > is not valid on WinNT platforms. The correct approach to conform
> > > to the licensing agreement would probably be to disable 4DOS
> > > entirely when such a platform is detected.
> Klaus Meinhard answered:
> > To put it clearly: if that policy is pursued, I will stop
> > participating in _any_ 4DOS activity and take my site off the net.
You wrote:
> I don't agree, because what 4DOS deals with is the DOS emulator of
> NT, not NT itself. What the licence actually prohibits in my opinion,
> is using the NT API, which 4DOS, as a 16-bit DOS programme, is
> completely unable to do. ("Porting" it to NT would mean first and
> foremost turning it into a 32-bit programme and then switching to the
> NT API. Same for Linux, BSD, Mac OS X, etc.)
which is exactly my opinion as I wrote later:
> > I am too lazy to look up the exact wording again, but Rex has
> > expressed that he doesn't care under which brand of DOS 4DOS runs.
> > He excludes compilation for other operating systems. For me that
> > includes clearly running under DOS, even a DOS emulator, and
> > precludes the compilation for e.g. NT, using NT 32bit APIs, ot
> > Linux, using Linux APIs.
> I agree 100%.
So we should see eye to eye about detecting facts about 4DOS'
environment and setting defaults accordingly, as long as no non-DOS API
is used. Where's the problem?
Luchezar Georgiev
> One alternative approach might be, instead of checking for NT, to test
> the LFN API and enable LFN handling if the API is supported. (Note
> that while I mention this as a technical possibility, I don't advocate
> it as a *good* idea.)
In fact, the LFN API is checked for every time a file or directory DOS call
is about to be made, as long as W9x/ME is detected or Win95LFN is enabled.
> I don't feel strongly about this issue. The present behavior seems
> like a reasonable balance between encouraging 4DOS in "wrong"
> environments and forbidding it. Tweaking an .INI file doesn't seem
> too difficult for 4DOS's target audience. If it is, perhaps a tick
> box might be added in the OPTION dialog...?
For whomever using 4DOS in NT is too difficult it may be easier to try TC.
Regards,
Lucho
Luchezar Georgiev
> You wrote:
>
>> I don't agree, because what 4DOS deals with is the DOS emulator of
>> NT, not NT itself. What the licence actually prohibits in my opinion,
>> is using the NT API, which 4DOS, as a 16-bit DOS programme, is
>> completely unable to do. ("Porting" it to NT would mean first and
>> foremost turning it into a 32-bit programme and then switching to the
>> NT API. Same for Linux, BSD, Mac OS X, etc.)
>
> which is exactly my opinion as I wrote later:
>
>>> I am too lazy to look up the exact wording again, but Rex has
>>> expressed that he doesn't care under which brand of DOS 4DOS runs.
>>> He excludes compilation for other operating systems. For me that
>>> includes clearly running under DOS, even a DOS emulator, and
>>> precludes the compilation for e.g. NT, using NT 32bit APIs, ot
>>> Linux, using Linux APIs.
>
>> I agree 100%.
Yes, I'm glad to ascertain that our opinions on this issue coincide indeed.
> So we should see eye to eye about detecting facts about 4DOS'
> environment and setting defaults accordingly, as long as no non-DOS API
> is used. Where's the problem?
The problem is that I don't want to say "A" knowing that the Latin alphabet
consists of as much of 26 letters. I wouldn't like the date / time function
story to repeat again, this time on the sloppy ground of running 4DOS in an
environment under which it's not intended to run. I hope I am clear enough.
Regards,
Lucho
Klaus Meinhard
> The problem is that I don't want to say "A" knowing that the Latin
> alphabet consists of as much of 26 letters. I wouldn't like the date
> / time function story to repeat again, this time on the sloppy ground
> of running 4DOS in an environment under which it's not intended to
> run. I hope I am clear enough.
You mean the only really original and unique developement for 4DOS? :-)
Oh, your clear enough, but it seems we happen to differ in what should
be 4DOS' role. How do you see its future? Only following 4NT as far as
the DOS API allows really seems at its end.
4DOS should not be a competitor to the current JP Software command
processors. Here we agree.
4DOS should not be compiled for other OSs. Here we agree too.
But IMHO 4DOS should do its best under DOS or its emulators, and here we
disagree. Where, please, has Rex definitely expressed his wish that 4DOS
may not run under emulators? Where has he expressed a wish not to enable
LFNs in emulators that support them? Rex has always done his best to
provide as much info to the user as the DOS API provides and to make
4DOS user-friendly.
You are construing a warning of restrictions of 4DOS under NT in the
Help files for users into a wish by Rex for developers. That is for me a
form of anticipatory obedience .
Please tell me if you have already done anything to contact Rex to
clarify the 4DOS license. If not, I will contact him and ask him to do
so. I have no wish, after spending 15 years of accompanying the
developement of 4DOS, to be painted as going again the provisions of the
license only because I'd like to see 4DOS developed further and
independently from the JPS command processors of other OSs.
Perhaps you (and a few others here) should read the license again:
Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so.
Note "without restriction", "without limitation to use, copy,
modify...", even selling is allowed.
The Software, or any portion of it, may not be compiled for use on any
operating system other than FreeDOS without written permission
from Rex Conn.
... which was later expanded by Rex to all other DOS versions.
We seem agree to the meaning of "compiled for use on any operating
system other than DOS". From where do you take the necessity of
further restrictions?
I think it's time that Rex clarifies this issue.
Luchezar Georgiev
>> The problem is that I don't want to say "A" knowing that the Latin
>> alphabet consists of as much of 26 letters. I wouldn't like the date
>> / time function story to repeat again, this time on the sloppy ground
>> of running 4DOS in an environment under which it's not intended to
>> run. I hope I am clear enough.
>
> You mean the only really original and unique developement for 4DOS? :-)
> Oh, your clear enough,
I think you didn't understand. I mean, I would not like to be enticed into
development of a whole series of new functions like it became for the time
/ date functions. I'm sure not sorry about them, quite the contrary, but I
feel that repeating the same exercise with the NT would be going too far.
> but it seems we happen to differ in what should
> be 4DOS' role. How do you see its future? Only following 4NT as far as
> the DOS API allows really seems at its end.
If you haven't noticed, I've already implemented a number of DOS-specific
features.
> You are construing a warning of restrictions of 4DOS under NT in the
> Help files for users into a wish by Rex for developers. That is for me a
> form of anticipatory obedience .
Sorry, this is wrong. I haven't construed anything - the "Windows NT Line"
Help topic was written by Charles Dye, not me (nevertheless, I like it ;-)
> Please tell me if you have already done anything to contact Rex to
> clarify the 4DOS license. If not, I will contact him and ask him to do
> so. I have no wish, after spending 15 years of accompanying the
> developement of 4DOS, to be painted as going again the provisions of the
> license only because I'd like to see 4DOS developed further and
> independently from the JPS command processors of other OSs.
I haven't contacted him on this since I haven't had such a question to him.
> Permission is hereby granted, free of charge, to any person obtaining
> a copy of this software and associated documentation files (the
> "Software"), to deal in the Software without restriction, including
> without limitation the rights to use, copy, modify, merge, publish,
> distribute, sublicense, and/or sell copies of the Software, and to
> permit persons to whom the Software is furnished to do so.
This was just copied from http://en.wikipedia.org/wiki/MIT_License by Jim Hall.
> Note "without restriction", "without limitation to use, copy,
> modify...", even selling is allowed.
>
> The Software, or any portion of it, may not be compiled for use on any
> operating system other than FreeDOS without written permission
> from Rex Conn.
>
> ... which was later expanded by Rex to all other DOS versions.
This is exactly the contradiction which caused me to use the 2004 freeware
licence in the binary archive.
> We seem agree to the meaning of "compiled for use on any operating
> system other than DOS". From where do you take the necessity of
> further restrictions?
Because 4DOS is just too frequently used in NT where 4NT/TCC should be used
instead.
> I think it's time that Rex clarifies this issue.
What do the other readers think?
By the way, as I understood today, Windows 7 will be 64-bit-only and will
not have any DOS emulator.
Regards,
Lucho
ras...@highfiber.com
>
> What do the other readers think?
I think the present behavior is the most reasonable, but I'm not
dogmatic about it -- I wouldn't be outraged if it were changed as
Klaus suggests.
--
Charles Dye ras...@highfiber.com
Klaus Meinhard
> I think you didn't understand. I mean, I would not like to be enticed
> into development of a whole series of new functions like it became
> for the time / date functions. I'm sure not sorry about them, quite
> the contrary, but I feel that repeating the same exercise with the NT
> would be going too far.
You're right. I don't understand you. The time the isodate / utctime
functions were developed were the most fun I had with 4DOS in the last
few years.
You really should consider where you want to take 4DOS. Do you only want
to follow what Rex does with TC religiously? You said yourself that this
exercise is fast becoming stale, TC now being far beyond the scope of
DOS APIs. Or do you want to do some original work (obviously here I
count the isodate / utctime functions in)? Is all this _work_ to you or
_fun_? I think it _should_ be fun.
> Because 4DOS is just too frequently used in NT where 4NT/TCC should
> be used instead.
Says who? If Rex had had any fears that 4DOS could be a competitor to TC
he wouldn't have made it free. Additionally he has provided with TCC/LE
a free NT command processor with much the same functional range as 4DOS.
Some of the very people in this group have advised Rex when the scope of
TCC/LE's functionality was decided. So why should he fear 4DOS? All it
can be today under NT is a drug leading to further addiction ( - TC). In
all other OSs Rex sees no market value.
Your challenge should be to make the most of 4DOS, not be a motherhen to
Rex. He can fend for himself.
Read the license again:
Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so.
--
Luchezar Georgiev
>> I think you didn't understand. I mean, I would not like to be enticed
>> into development of a whole series of new functions like it became
>> for the time / date functions. I'm sure not sorry about them, quite
>> the contrary, but I feel that repeating the same exercise with the NT
>> would be going too far.
>
> You're right. I don't understand you. The time the isodate / utctime
> functions were developed were the most fun I had with 4DOS in the last
> few years.
Yes, as I wrote above, I'm not sorry about them, quite the contrary, thank
you for these good ideas, but I would not like to follow your NT path now.
> You really should consider where you want to take 4DOS. Do you only want
> to follow what Rex does with TC religiously? You said yourself that this
> exercise is fast becoming stale, TC now being far beyond the scope of
> DOS APIs. Or do you want to do some original work (obviously here I
> count the isodate / utctime functions in)? Is all this _work_ to you or
> _fun_? I think it _should_ be fun.
It's both ;-) When one makes ONLY fun, he feels not so much responsibility.
> Says who? If Rex had had any fears that 4DOS could be a competitor to TC
> he wouldn't have made it free. Additionally he has provided with TCC/LE
> a free NT command processor with much the same functional range as 4DOS.
> Some of the very people in this group have advised Rex when the scope of
> TCC/LE's functionality was decided. So why should he fear 4DOS? All it
> can be today under NT is a drug leading to further addiction ( - TC). In
> all other OSs Rex sees no market value.
Of course, you're right.
> Your challenge should be to make the most of 4DOS, not be a motherhen to
> Rex. He can fend for himself.
I feel it another way. It's just conscience. Rule #1: Don't harm people you
respect! I just feel that people who use 4DOS in NT could buy TC instead...
> Permission is hereby granted, free of charge, to any person obtaining
> a copy of this software and associated documentation files (the
> "Software"), to deal in the Software without restriction, including
> without limitation the rights to use, copy, modify, merge, publish,
> distribute, sublicense, and/or sell copies of the Software, and to
> permit persons to whom the Software is furnished to do so.
As I already wrote, this text was copied and pasted from the "MIT licence"
(http://en.wikipedia.org/wiki/MIT_License) by Jim Hall (compare them - the
coincidence is full). But this text contradicts the restrictions below it.
How can one "sell" and "not use commercially" at the same time? How can he
"modify without restrictions" and "not port to any OS but DOS" at the same
time? It's like a Centaur - a horse with man's torso. Whom to follow?! The
horse or the torse? Ask any lawyer about this licence and he'll laugh over
it! That's why I included the original 2004 licence in my binary archives.
Regards,
Lucho
Luchezar Georgiev
>>> I think it's time that Rex clarifies this issue.
>> What do the other readers think?
> I think the present behavior is the most reasonable, but I'm not
> dogmatic about it -- I wouldn't be outraged if it were changed as
> Klaus suggests.
Yes, that seems pretty innocent. But remember the date/time functions: they
also started with the pretty innocent ISO week variable and function and...
ended with a full system of time and date functions. That was a really good
addition to 4DOS, but now, if we start adding NT or emulator functions, who
knows where we'll get? This time, we'd better not depart on this road since
it leads to somewhere elsewhere. After all, 4DOS is a DOS, not an NT shell!
Regards,
Lucho
FoxWolfie Galen
wrote:
> Because 4DOS is just too frequently used in NT where 4NT/TCC should
> be used instead.
I've read both sides of this, and all I can think of is why would someone
be using 4DOS in an NT environment when 4NT/TCC are better suited to that
use. And, if someone says, "but they are not free," there is always TCC/LE.
Letting 4DOS run under NT is probably ok, but I wouldn't recommend it to
anyone who needed to do anything beyond the basics. It can't navigate into
directories that are nine or more levels deep, or that have more than
around 64 characters in their pathname. It has, on occasion, been known to
treat long names differently than under not NT systems. Things like this
are not faults of 4DOS, but of the user going against what is recommended,
and against what 4DOS was made for.
> > I think it's time that Rex clarifies this issue.
>
> What do the other readers think?
I imagine that he would just shake his head and possibly even be mildly
annoyed. I'm sure that he'd rather have people at least trying out TCC/LE,
and perhaps upgrading to something he makes money on, than to repeat that
4DOS isn't meant for NT. By making it too easy and convenient to use under
NT, it just encourages use of the wrong tool for the job, especially now
that the right tool, TCC/LE, is free to use. Of course, this is all just my
own opinion, but increased NT support seems like it would be wasted effort.
If it happens, it won't bother me, but I'd rather have the time spent as in
the past, on other new features instead.
--
FoxWolfie / CubCoon
Klaus Meinhard
> I've read both sides of this, and all I can think of is why would
> someone be using 4DOS in an NT environment when 4NT/TCC are better
> suited to that use. And, if someone says, "but they are not free,"
> there is always TCC/LE.
So why should anybody care if someone uses 4DOS or TCC/LE?
Lucho has added so many features only present in 4NT before, that was
okay. But adding LFN support automatically in NT is a drama. The user
must do it by hand, or it infringes the license, goes against conscience
and responsibility.
> Letting 4DOS run under NT is probably ok, but
> I wouldn't recommend it to anyone who needed to do anything beyond
> the basics.
Not even Rex has prevented users running 4DOS under NT when it was still
commercial, or when he released the free version. It was "not
supported", the same way TCC/LE is "not supported" by JP Software's
support.
> It can't navigate into directories that are nine or more
> levels deep, or that have more than around 64 characters in their
> pathname. It has, on occasion, been known to treat long names
> differently than under not NT systems. Things like this are not
> faults of 4DOS, but of the user going against what is recommended,
> and against what 4DOS was made for.
That's exactly why there's Charles' warning.
> > > I think it's time that Rex clarifies this issue.
> > What do the other readers think?
> I imagine that he would just shake his head and possibly even be
> mildly annoyed. I'm sure that he'd rather have people at least trying
> out TCC/LE, and perhaps upgrading to something he makes money on,
> than to repeat that 4DOS isn't meant for NT. By making it too easy
> and convenient to use under NT, it just encourages use of the wrong
> tool for the job, especially now that the right tool, TCC/LE, is free
> to use.
So even if Rex says he doesn't give a damn we don't add a simple
convenience to NTVDM users? Just making LFN's the default in LFN
environments? I give up. Have it your way.
And a happy New Year to all.
Luchezar Georgiev
> So why should anybody care if someone uses 4DOS or TCC/LE?
If this "somebody" is the programmer, this is normal. Everybody cares what
what he creates or maintains is used for. I do, so probably does Rex Conn.
> Lucho has added so many features only present in 4NT before, that was
> okay. But adding LFN support automatically in NT is a drama. The user
> must do it by hand, or it infringes the license, goes against conscience
> and responsibility.
Well the difference is that I added the "many features only present in 4NT
before" to be used in DOS and W9x/ME, the environment 4DOS is written for.
Whereas your proposal is exclusively for use in NT. Otherwise you wouldn't
have made it, as you are reluctant to "downgrade" to Windows 9x/ME for the
sake of 4DOS. It's like sitting on a saddle in a car. Saddles are made for
horses! (Windows NT is to Windows 9x like a car is to a horse.) If you say
that W98 no longer runs in today's PCs - so does XP! I was so surprised to
learn that one couldn't "downgrade" Vista to XP in today's notebook PCs as
the SATA HDDs are not recognised by the original XP! Ultimately, it can be
done, but with some additional work. Same goes for W98 - only the required
work is more ;-)
> Not even Rex has prevented users running 4DOS under NT when it was still
> commercial, or when he released the free version. It was "not
> supported", the same way TCC/LE is "not supported" by JP Software's
> support.
Yes, I'm a "more catholic than the pope" ;-)
> So even if Rex says he doesn't give a damn we don't add a simple
> convenience to NTVDM users? Just making LFN's the default in LFN
> environments? I give up. Have it your way.
NT users mustn't be encouraged to run 4DOS in it even in the slightest way.
4DOS users mustn't be encouraged to run it in NT even in the slightest way.
These two are the corner stones to the die-hard DOS dinosaurs like me. 4DOS
isn't a mass product, so we could afford to "gargle" with this. And if this
leads to even one more purchase of TC by such an user it'll be even better.
I've never been able to make money (perhaps I haven't wanted to, but that's
another question). Why not at least slightly help someone who can do it and
does deserve? That's comradeship the Westerners have trouble understanding.
Watch the Cheburashka cartoon with English subtitles. YOU could understand!
> And a happy New Year to all.
Thank you and same to you! I announced my New Year present this morning ;-)
Regards,
Lucho
ras...@highfiber.com
> I imagine that he would just shake his head and possibly even be mildly
> annoyed.
I think you've nailed it. And if Mike were still around, he'd have
something suitably pithy to add....
--
Charles Dye ras...@highfiber.com
Luchezar Georgiev
> [...] It can't navigate into
> directories that are nine or more levels deep, or that have more than
> around 64 characters in their pathname.
Actually only the latter is true. The 64 character limit occurs since the
name string of the CDS (Current Directory Structure) of DOS has a 67-byte
size, 3 of which are devoted to the drive letter, colon and back slash.
But there is no 9-level limitation! I've tested this in the past, but now I
just repeated the test. I reached 32 levels before I got "Access denied" by
creating single character directories. 32 characters + 32 back slashes = 64
characters, therefore it's the 64-character limit that determined this one!
However while attempting to delete these directories I got a "4DOS internal
stack overflow" at the 16th level. This sets a practical limit of 15 levels
for 4DOS, which is more than enough in my opinion for 99.999% of the cases.
Regards,
Lucho
Luchezar Georgiev
> However while attempting to delete these directories I got a "4DOS
> internal stack overflow" at the 16th level. This sets a practical limit
> of 15 levels for 4DOS, which is more than enough in my opinion for
> 99.999% of the cases.
I mean, I got this error while RECURSIVELY deleting them with "DEL /S".
lcaverly
> Lucho,
>
> You really should consider where you want to take 4DOS. Do you only want
> to follow what Rex does with TC religiously? You said yourself that this
> exercise is fast becoming stale, TC now being far beyond the scope of
> DOS APIs. Or do you want to do some original work (obviously here I
> count the isodate / utctime functions in)? Is all this _work_ to you or
> _fun_? I think it _should_ be fun.
>
> Mit freundlichem Gruß,
>
> Klaus Meinhard
Hi,
What follows is a partial re-post of a message of mine from August
13;
As has been mentioned, though, is there a point when functions and
commands should not be added to 4DOS.COM? Is this why plug-ins were
developed for 4NT? Should 4DOS "Installable Commands" be the way to
add to 4DOS?
Wrappers can be easily made for stand-alone utilities, turning them
into variable functions. For example;
log=%@execstr[4dlog.exe %1 %2]
exp=%@execstr[4dexp.exe %1 %2]
Thus, 3 X 4 = 12;
c:\4dos>echo %@exp[%@eval[%@log[4] + %@log[3]]]
11.999999998944
Not as fast as an internal variable function, nor as fast as an
installable command, but it does work.
If in the future, if another needs a trig function, do they re-invent
the wheel, or look for someone who has developed an installable
command? When using 4NT, and I need a new function that 4NT does not
have, I take a look at the plug-in section of JPSoft (http://
www.jpsoft.com/plugins.htm), and if I can't find what I'm looking for,
I start up Delphi 2.0, and create my own.
Mind you, not everyone has the tools or the expertise to develop plug-
ins or installable commands, but the facilities do exist.
Just my 2 cents.
Joe
Luchezar Georgiev
> What follows is a partial re-post of a message of mine from August
> 13;
We've obviously started to rotate into a "vice circle" ;-)
> As has been mentioned, though, is there a point when functions and
> commands should not be added to 4DOS.COM? Is this why plug-ins were
> developed for 4NT? Should 4DOS "Installable Commands" be the way to
> add to 4DOS?
Sometimes. And sometimes, user functions...
> Wrappers can be easily made for stand-alone utilities, turning them
> into variable functions. For example;
>
> log=%@execstr[4dlog.exe %1 %2]
> exp=%@execstr[4dexp.exe %1 %2]
>
> Thus, 3 X 4 = 12;
>
> c:\4dos>echo %@exp[%@eval[%@log[4] + %@log[3]]]
> 11.999999998944
Remember the PC DOS ACALC command, a link to which I've posted on my 4DOS
site. You can do it with it, instead of the hypothetical 4DLOG and 4DEXP.
The only problem is that it shows the whole equation so you need to apply
@WORD, @FIELD or something similar to extract only the result if you want.
> If in the future, if another needs a trig function, do they re-invent
> the wheel, or look for someone who has developed an installable
> command? When using 4NT, and I need a new function that 4NT does not
> have, I take a look at the plug-in section of JPSoft (http://
> www.jpsoft.com/plugins.htm), and if I can't find what I'm looking for,
> I start up Delphi 2.0, and create my own.
No need to reinvent the wheel - ACALC has many "transcendental" functions.
> Mind you, not everyone has the tools or the expertise to develop plug-
> ins or installable commands, but the facilities do exist.
Sure. If you want to create something not existing so far, this is the way.
Regards,
Lucho
P.S. Happy New Year! It promises to be a tough one but that's a challenge!
lcaverly
> lcaverly пишет:
>
> No need to reinvent the wheel - ACALC has many "transcendental" functions.
>
> Lucho
Hi,
I agree. You might also want to check out ASET, which offers some
features that 4DOS does not offer. An overview of the features can be
found here (http://www.univ-orleans.fr/EXT/ASTEX/astex/doc/en/aset/
html/aset.htm).
The program can be downloaded from here (ftp://ftp.simtel.net/pub/
simtelnet/msdos/batchutl/aset10.zip)
Joe
Richard Bonner
(Re: Directory Level Limit)
> I reached 32 levels before I got "Access denied" by
> creating single character directories. 32 characters + 32 back slashes = 64
> characters, therefore it's the 64-character limit that determined this one!
> However while attempting to delete these directories I got a "4DOS internal
> stack overflow" at the 16th level. This sets a practical limit of 15 levels
> for 4DOS, which is more than enough in my opinion for 99.999% of the cases.
>
> Lucho
*** Would increasing the STACKS command in CONFIG.sys eliminate that
error?
How did you end up deleting that structure? DELTREE?
Richard Bonner
http://www.chebucto.ca/~ak621/DOS/
Steve Fabian
| Luchezar Georgiev (lu...@gawab.com) wrote:
| (Re: Directory Level Limit)
|| I reached 32 levels before I got "Access denied" by
|| creating single character directories. 32 characters + 32 back
|| slashes = 64 characters, therefore it's the 64-character limit that
|| determined this one!
|
|| However while attempting to delete these directories I got a "4DOS
|| internal stack overflow" at the 16th level. This sets a practical
|| limit of 15 levels for 4DOS, which is more than enough in my opinion
|| for 99.999% of the cases.
||
|| Lucho
|
| *** Would increasing the STACKS command in CONFIG.sys eliminate that
| error?
Not likely. For "recursive descent" you need table entries of fixed size,
and the number of entries allocated a priori is the limit.
| How did you end up deleting that structure? DELTREE?
I don't know how Lucho did it, but one of the methods that does work is to
use SUBST for the 15th level.
--
Steve
ras...@highfiber.com
> *** Would increasing the STACKS command in CONFIG.sys eliminate that
> error?
The StackSize directive in 4DOS.INI might be a better bet.
--
Charles Dye ras...@highfiber.com
Luchezar Georgiev
> I agree. You might also want to check out ASET, which offers some
> features that 4DOS does not offer. An overview of the features can be
> found here (http://www.univ-orleans.fr/EXT/ASTEX/astex/doc/en/aset/
> html/aset.htm).
>
> The program can be downloaded from here (ftp://ftp.simtel.net/pub/
> simtelnet/msdos/batchutl/aset10.zip)
Thank you! I wasn't aware of this programme - it seems quite powerful!
Regards,
Lucho
Luchezar Georgiev
>> *** Would increasing the STACKS command in CONFIG.sys eliminate that
>> error?
No - STACKS is for the hardware interrupt stacks of the DOS kernel only.
Increasing it helps when too many interrupts "arrive" at the same time -
the so-called "interrupt rain" ;-)
> The StackSize directive in 4DOS.INI might be a better bet.
If there was a way that the stack size of an executable file could be
changed dynamically... but I'm afraid this is impossible. By the time
4DOS.INI is processed, stack size is already set and can't be changed
anymore. It's the linker which sets the stack size, at build time.
Regards,
Lucho
Luchezar Georgiev
> *** Would increasing the STACKS command in CONFIG.sys eliminate that
> error?
No - see my other post (in reply to Charles Dye) for details.
> How did you end up deleting that structure? DELTREE?
In this case I simply rebooted the browser (I was testing in my JPC demo :)
However, on a real disk for 32 levels, one could first change the current
directory to the 17th level, delete levels 18-32, then change the current
directory to the 02nd level, delete levels 03-17, then change the current
directory to the root and delete levels 1 and 2.
Another way would be DELTREE. Yet another method (if the directory contents
is garbage which can't be removed) is to enter DISKEDIT, remove the level 1
directory entry, then run CHKDSK /F or SCANDISK to remove the lost clusters
Regards,
Lucho
lcaverly
Hi,
If you want even more power from the 4DOS Prompt, use the
STRINGS.COM that I sent you back on August 30th. It allows one to call
Interrupts, peek and poke memory, etc., all from a 4DOS batch file. An
example;
@echo off
rem -------------------------------------------------------------
rem
rem A batch file that returns a memory scan
rem BATMEM.BAT
rem Copyright 1992 Douglas Boling
rem
rem -------------------------------------------------------------
rem
rem First, get the pointer to the list of lists
rem
strings /i /b16 iret = interrupt 21, 5200
strings /b16 lloff = parse %iret%, 2
strings /b16 llseg = parse %iret%, 9
set iret=
rem
rem First memory block kept at ListOfList - 2
rem
strings /b16 lloff = sub %lloff%, 2
strings /b16 memseg = peek %llseg%, %lloff%, 2, 2
echo.
echo Block Owner Size Program
echo --------------------------------
strings /b16 totalmem = add %memseg%, 1
set freemem=0
:loop
rem
rem Parse the memory arena header
rem
strings /b16 memtype = peek %memseg%, 0, 1
strings /b16 memowner = peek %memseg%, 1, 2, 2
strings /b16 memsize = peek %memseg%, 3, 2, 2
strings /b16 memtemp = peek %memseg%, 8, 8
strings /b16 /p memtemp = char %memtemp%
strings /b16 memseg = add %memseg%, 1
rem
rem If block not PSP, don't print block name
rem
set memname=
set diff=-1
strings /b16 /q diff = sub %memseg%, %memowner%
if .%diff% == .0 goto skip1
goto skip2
:skip1
set memname=%memtemp%
:skip2
if NOT %memowner% == 0000 goto skip3
set memowner=FREE
strings /b16 freemem = add %freemem%, %memsize%
:skip3
rem
rem OK, print the results
rem
echo %memseg% %memowner% %memsize% %memname%
strings /b16 memseg = add %memseg%, %memsize%
strings /b16 totalmem = add %memsize%, %totalmem%
strings /b16 totalmem = add %totalmem%, 1
if %memtype% == 4D goto loop
echo.
strings /b16 memsize = mul %memsize%, 10
strings /b16 memsize = convert %memsize%, A
strings memsize = addcommas %memsize%
strings /b16 totalmem = mul %totalmem%, 10
strings /b16 totalmem = convert %totalmem%, A
strings /u totalmem = addcommas %totalmem%
echo %totalmem% bytes total conventional memory
echo %memsize% largest program executable size
echo.
rem
rem Done, clean up all vars
rem
set llseg=
set lloff=
set memseg=
set memowner=
set memsize=
set memtype=
set memname=
set memtemp=
set freemem=
set totalmem=
set diff=
INTERRUPT, PEEK and POKE would be great commands to have in 4DOS, but
why bother, as STRINGS.COM is an installable command, allowing these
commands to operate seamlessly with 4DOS.COM. Installable commands
keep 4DOS.COM (and COMMAND.COM) from becoming bloated, which is what
installable commands such as STRINGS.COM, PRINT.EXE, SHARE.EXE,
DOSKEY.COM, etc., are meant to do.
Joe
FoxWolfie Galen
<K_Mei...@t-online.de> wrote:
> So why should anybody care if someone uses 4DOS or TCC/LE?
I personally don't care what people do, but I still don't personally
recommend the use of 4DOS under NT based systems, at least for most people.
There are enough potential problems and shortcomings that it just wouldn't
be the best choice for most. If someone is sufficiently experienced with
4DOS that they are aware of the possible problems, then they would also be
aware of how to tweak a few settings in their ini file. I'm guessing that
if LFN support were enabled by default under NT, that more people would be
encountering unexpected issues. It would also encourage more new users to
use 4DOS instead of TCC. Most new users might not be aware of the
limitations of DOS under NT. To do anything to encourage 4DOS in an
environment it wasn't designed for would be a disservice to most people.
Advanced users like yourself know the limits and how to get around the
limits, but most users aren't likely to.
> Not even Rex has prevented users running 4DOS under NT when it was still commercial, or when he released the free version.
He didn't go out of his way to prevent it, but he also made it very clear
many times that he didn't support not recommend such use. I don't think he
really cared what advanced users did, but he was always quick to tell
people that 4DOS was not recommended under NT. I tend to agree with him in
general. "Not recommended" does not mean "can't use."
> So even if Rex says he doesn't give a damn we don't add a simple
> convenience to NTVDM users? Just making LFN's the default in LFN
> environments? I give up. Have it your way.
I think it's safe to say that anyone who understands the limitations of DOS
under NT also understands how to change from the default. Those who don't
understand how to change the default, are the people who really should be
using TCC instead. So, I don't see where there is a problem. I don't see it
as a convenience issue, as the required 10-second ini file change is a one
time thing only, and remains in effect even through countless upgrading.
Or, am I missing something?
I do like the fact that we can at least change some of the defaults to make
things nice under NT when needed, but if we find ourselves in that
environment on a regular basis, at what point is it better to use TCC?
> And a happy New Year to all.
One day done, and it's been happy so far. :)
--
FoxWolfie / CubCoon
FoxWolfie Galen
wrote:
> However while attempting to delete these directories I got a "4DOS internal
> stack overflow" at the 16th level. This sets a practical limit of 15 levels
> for 4DOS, which is more than enough in my opinion for 99.999% of the cases.
You are correct. I always heard people refer to an 8 directory limit, but
never tested it until just now. I see that I can go to 32 levels. Doing a
real-world test, I tried to access the files in my browser cache from 4DOS.
I got mixed results. My browser cache is located at:
C:\WINDOWS\APPLICA~1\MOZILLA\FIREFOX\PROFILES\XXXXXXXX.DEF\CACHE\
I can go into the directory using 4DOS, but because all the files in that
directory result in a pathname of over 67 characters, they could not be
accessed at all, if I booted to plain 4DOS, without Windows. When I
rebooted under Win98se, and started 4DOS from Windows, I was able to access
files in directories that were over 100 characters deep. 4DOS appears to be
smart enough to hook into some Windows LFN APIs if it sees them, under
Win9x. Seeing this work under Win98se, I just had to try it on an NT-based
system. I installed 4DOS on my XP system and attempted to access anything
in a longer-than 67-character directory. It failed. I tried with LFN
support both on and off. 4DOS can see the LFNs, but it cannot access the
large number of files that are stored in the deeper directories. What works
so nicely in Win 9x does not work at all in Win XP.
I did *not* see a stack overflow when attempting to delete files or
directories at any level on any system. I deleted the directories using RD,
one level at a time, with no errors. As expected, no path\filename
combination could exceed 67 characters, if I booted without Windows, or if
I was in XP. TCC/LE had no problem with directories that 4DOS could not
access in XP.
I just proved to myself that 4DOS likes Win 98, but it doesn't appear to
like Win XP as much. It still works in XP, but only within certain limits,
and enabling LFN support does not remove some of those limits. Under normal
circumstances, I'll still recommend 4NT/TCC/LE to people using NT systems,
and 4DOS to people using DOS and 9x/ME systems. Of course, my
recommendations are biased by what has worked best for me. Other people's
experiences may vary.
--
FoxWolfie / CubCoon
FoxWolfie Galen
wrote:
> I mean, I got this error while RECURSIVELY deleting them with "DEL /S".
Using DEL /SX, I get a stack error if there are 21 levels or more, but not
if there are 20 levels or fewer. It seems that the number varies from
system to system, so maybe some people can't even delete as many as 15 at a
time. I don't know if it makes a difference, but my StackSize is set to
10240, rather than the default of 8192. I don't remember ever changing
that, but I've been using the same settings for many years.
--
FoxWolfie / CubCoon
Steve Fabian
AFAIK the problem is that M$ wants people to buy new versions of programs,
and thus provides only very limited DOS emulation in XP via NTVDM. The
primary method to overcome many of the path length and depth limits is
SUBST. It works for 4DOS, and it works for any other DOS program, e.g.,
Lotus Magellan 2.0 and BRIEF.
--
Steve
Luchezar Georgiev
> If you want even more power from the 4DOS Prompt, use the
> STRINGS.COM that I sent you back on August 30th. It allows one to call
> Interrupts, peek and poke memory, etc., all from a 4DOS batch file.
Thanks, it's very powerful indeed! Same source code is available at
http://techref.massmind.org/techref/dos/command/strings/STRINGS.ASM
> rem A batch file that returns a memory scan
> rem BATMEM.BAT
> rem Copyright 1992 Douglas Boling
Is Douglas Boling the author of STRINGS.ASM? What does BATMEM.BAT do better
than the standard DOS MEM command?
> INTERRUPT, PEEK and POKE would be great commands to have in 4DOS, but
> why bother, as STRINGS.COM is an installable command, allowing these
> commands to operate seamlessly with 4DOS.COM. Installable commands
> keep 4DOS.COM (and COMMAND.COM) from becoming bloated, which is what
> installable commands such as STRINGS.COM, PRINT.EXE, SHARE.EXE,
> DOSKEY.COM, etc., are meant to do.
All of these commands but STRINGS are standard DOS external commands.
Regards,
Lucho
Luchezar Georgiev
Regards,
Lucho
Luchezar Georgiev
>> I mean, I got this error while RECURSIVELY deleting them with "DEL /S".
>
> Using DEL /SX, I get a stack error if there are 21 levels or more, but not
> if there are 20 levels or fewer. It seems that the number varies from
> system to system, so maybe some people can't even delete as many as 15 at a
> time. I don't know if it makes a difference, but my StackSize is set to
> 10240, rather than the default of 8192. I don't remember ever changing
> that, but I've been using the same settings for many years.
Thanks for reminding me this - I have still much more to learn before I can
say that I know 4DOS very well! I had forgotten about the StackSize setting
and it seems that the Tom Rawson's initialisation code can change the stack
size, so my previous comments are incorrect. Of course, this means that you
can increase the stack size and hence the maximal possible recursion depth.
Regards,
Lucho
Luchezar Georgiev
> You are correct. I always heard people refer to an 8 directory limit, but
> never tested it until just now. I see that I can go to 32 levels. Doing a
> real-world test, I tried to access the files in my browser cache from 4DOS.
> I got mixed results. My browser cache is located at:
>
> C:\WINDOWS\APPLICA~1\MOZILLA\FIREFOX\PROFILES\XXXXXXXX.DEF\CACHE\
>
> I can go into the directory using 4DOS, but because all the files in that
> directory result in a pathname of over 67 characters, they could not be
> accessed at all, if I booted to plain 4DOS, without Windows.
That's strange! The size of the above string is 65 characters. If we
include the null terminator, it becomes 66 characters, less than 67!
Therefore it fits into the CDS structure and shouldn't have problem.
Regards,
Lucho
Luchezar Georgiev
> | I just proved to myself that 4DOS likes Win 98, but it doesn't appear
> | to like Win XP as much. It still works in XP, but only within certain
> | limits, and enabling LFN support does not remove some of those
> | limits. Under normal circumstances, I'll still recommend 4NT/TCC/LE
> | to people using NT systems, and 4DOS to people using DOS and 9x/ME
> | systems. Of course, my recommendations are biased by what has worked
> | best for me. Other people's experiences may vary.
Exactly. That's what the warning Charles Dye added in the help is all about
> AFAIK the problem is that M$ wants people to buy new versions of programs,
> and thus provides only very limited DOS emulation in XP via NTVDM.
Yes, Microsoft crippled it intentionally, like they do every time they want
people to upgrade from some older technology to a new technology of THEIRS.
> The
> primary method to overcome many of the path length and depth limits is
> SUBST. It works for 4DOS, and it works for any other DOS program, e.g.,
> Lotus Magellan 2.0 and BRIEF.
Yes, SUBST is still available under NT, which will help the 4DOSinNTers...
Regards,
Lucho
Richard Bonner
> Richard Bonner wrote:
> | Luchezar Georgiev (lu...@gawab.com) wrote:
> | (Re: Directory Level Limit)
> || I reached 32 levels before I got "Access denied" by
> || creating single character directories. 32 characters + 32 back
> || slashes = 64 characters, therefore it's the 64-character limit that
> || determined this one!
> |
> || However while attempting to delete these directories I got a "4DOS
> || internal stack overflow" at the 16th level. This sets a practical
> || limit of 15 levels for 4DOS, which is more than enough in my opinion
> || for 99.999% of the cases.
> ||
> || Lucho
> | How did you end up deleting that structure? DELTREE?
> I don't know how Lucho did it, but one of the methods that does work is to
> use SUBST for the 15th level.
> --
> Steve
*** Thanks, I shall archive that trick in case I create excessively deep
directory structures. Right now, I don't think I have anything deeper than
seven or eight levels.
Richard Bonner
http://www.chebucto.ca/~ak621/DOS/
Richard Bonner
> On Jan 1, 7:23=A0am, ak...@chebucto.ns.ca (Richard Bonner) wrote:
> > *** =A0 Would increasing the STACKS command in CONFIG.sys eliminate that
> > error?
> The StackSize directive in 4DOS.INI might be a better bet.
> --
> Charles Dye ras...@highfiber.com
*** Interesting. I have not encountered a "Stack Overflow" message since
I switched to DR-DOS. In fact, I have a directive in my CONFIG.sys of:
STACKS=0,0
... so I assume that DR-DOS has enough internal stacks to accommodate my
demands.
Richard Bonner
http://www.chebucto.ca/~ak621/DOS/
Richard Bonner
> FoxWolfie Galen wrote:
(Snip Directory Structure Experiment)
> | I just proved to myself that 4DOS likes Win 98, but it doesn't appear
> | to like Win XP as much. It still works in XP, but only within certain
> | limits, and enabling LFN support does not remove some of those
> | limits. Under normal circumstances, I'll still recommend 4NT/TCC/LE
> | to people using NT systems, and 4DOS to people using DOS and 9x/ME
> | systems. Of course, my recommendations are biased by what has worked
> | best for me. Other people's experiences may vary.
> AFAIK the problem is that M$ wants people to buy new versions of programs,
> and thus provides only very limited DOS emulation in XP via NTVDM. The
> primary method to overcome many of the path length and depth limits is
> SUBST. It works for 4DOS, and it works for any other DOS program, e.g.,
> Lotus Magellan 2.0 and BRIEF.
> --
> Steve
*** I wonder what happens with DOS emulators such as DOS Box or VM Ware.
I tend to assume that XP would still hold lord over the whole works and
limit them.
Richard Bonner
http://www.chebucto.ca/~ak621/DOS/
Richard Bonner
> > lcaverly =D0=C9=DB=C5=D4:
> >
> > > =9A You might also want to check out ASET, which offers some
> > > features that 4DOS does not offer. An overview of the features can be
> > > found here (http://www.univ-orleans.fr/EXT/ASTEX/astex/doc/en/aset/
> > > html/aset.htm).
> >
> > > =9A The program can be downloaded from here (ftp://ftp.simtel.net/pub/
> > > simtelnet/msdos/batchutl/aset10.zip)
> If you want even more power from the 4DOS Prompt, use the
> STRINGS.COM that I sent you back on August 30th. It allows one to call
> Interrupts, peek and poke memory, etc., all from a 4DOS batch file.
>
> Joe
*** Joe: Do you have a website for it?
Richard Bonner
http://www.chebucto.ca/~ak621/DOS/
Richard Bonner
> Richard Bonner пишет:
(Re: Deep Directory Structure)
> > How did you end up deleting that structure? DELTREE?
(Snip)
> Yet another method (if the directory contents is garbage which can't
> be removed) is to enter DISKEDIT, remove the level 1 directory entry,
>then run CHKDSK /F or SCANDISK to remove the lost clusters
>
> Lucho
*** Hmm, that would have helped me last month when my FAT got corrupted
on my laptop during a battery failure. I was able to repair the FAT via
Norton Utilities, but it created some odd entries that I was unable to
remove. I toyed with Norton and was eventually able to delete those
entries, but it took a bit of doing.
If it happens again, I shall try your method.
Richard Bonner
http://www.chebucto.ca/~ak621/DOS/
Luchezar Georgiev
>> The StackSize directive in 4DOS.INI might be a better bet.
>
> If there was a way that the stack size of an executable file could be
> changed dynamically... but I'm afraid this is impossible. By the time
> 4DOS.INI is processed, stack size is already set and can't be changed
> anymore. It's the linker which sets the stack size, at build time.
Let me explain the above words of mine. I had forgotten about the existing
StackSize directive and thought that you propose one, which I wrote that I
couldn't implement (above words). But Tom Rawson and Rex Conn already did!
Regards,
Lucho
Klaus Meinhard
with all the excitement about the necessity to either protect the 4DOS
user against himself or Rex against loss of profit:
what about detection of a DOS emulator for 4DOS?
How many are out there there? You seem to fear to many. My off-hand
guess is about half a dozen, including Linux dosemu.
Is there a simple and reliable way to detect a) the fact that 4DOS is
running under an emulator and b) which one it is?
I can't see that this feature infringing any license topic, and the
scope doesn't seem to use up too many characters of the alphabet :-)
BTW, PEEK and POKE were long time ago proposed by me for a 4DOS upgrade,
but never implemented. I guess at that time Rex didn't want the user to
use 4DOS to hack its own registration data...
Luchezar Georgiev
>> The StackSize directive in 4DOS.INI might be a better bet.
>> --
>> Charles Dye ras...@highfiber.com
>
> *** Interesting. I have not encountered a "Stack Overflow" message since
> I switched to DR-DOS. In fact, I have a directive in my CONFIG.sys of:
>
> STACKS=0,0
>
These are different stacks - StackSize sets the 4DOS stack. STACKS sets the
hardware interrupt DOS kernel stacks. For more information about the STACKS
command, see http://www.vfrazee.com/ms-dos/6.22/help/stacks.htm
Regards,
Lucho
Luchezar Georgiev
> what about detection of a DOS emulator for 4DOS?
>
> How many are out there there? You seem to fear to many. My off-hand
> guess is about half a dozen, including Linux dosemu.
>
> Is there a simple and reliable way to detect a) the fact that 4DOS is
> running under an emulator and b) which one it is?
There is no general method. One user asked about detection of a particular
emulator some months ago. I don't remember who and which emulator but this
was one of the reasons why I implemented the @SMBSTR function. (There were
some examples here by users on detection of some of the DOS emulators with
@SMBSTR.)
> I can't see that this feature infringing any license topic, and the
> scope doesn't seem to use up too many characters of the alphabet :-)
No DOS programme was written for use in emulators and 4DOS is no exception.
Therefore, while 4DOS itself (as a free programme) isn't supported, its use
under a DOS or CPU emulator is even less supported (negatively supported?!)
> BTW, PEEK and POKE were long time ago proposed by me for a 4DOS upgrade,
> but never implemented. I guess at that time Rex didn't want the user to
> use 4DOS to hack its own registration data...
What do you mean? I/O port manipulation? If so, this could be done with
DEBUG. By the way - the NT won't let you manipulate the ports directly.
Windows 9x/ME too, but to a lesser degree. Anyway, I don't think that a
shell has to do anything with I/O ports in general except some specific cases.
Regards,
Lucho
lcaverly
> lcaverly пишет:
>
> > If you want even more power from the 4DOS Prompt, use the
> > STRINGS.COM that I sent you back on August 30th. It allows one to call
> > Interrupts, peek and poke memory, etc., all from a 4DOS batch file.
>
>
> > rem A batch file that returns a memory scan
> > rem BATMEM.BAT
> > rem Copyright 1992 Douglas Boling
>
> Is Douglas Boling the author of STRINGS.ASM? What does BATMEM.BAT do better
> than the standard DOS MEM command?
Douglas Boling is the author of STRINGS.ASM. BATMEM.BAT does nothing
better than the standard DOS MEM command. It demonstrates how to
perform low-level calls using Interrupts via the STRINGS.COM
Installable Command in a batch file.
>
> > INTERRUPT, PEEK and POKE would be great commands to have in 4DOS, but
> > why bother, as STRINGS.COM is an installable command, allowing these
> > commands to operate seamlessly with 4DOS.COM. Installable commands
> > keep 4DOS.COM (and COMMAND.COM) from becoming bloated, which is what
> > installable commands such as STRINGS.COM, PRINT.EXE, SHARE.EXE,
> > DOSKEY.COM, etc., are meant to do.
>
> All of these commands but STRINGS are standard DOS external commands.
PRINT.EXE, SHARE.EXE, DOSKEY.COM, and other "external" commands are
installable commands. They are all TSRs that use the DOS Multiplex
Interrupt, just as STRINGS.COM does, as a "back door" to the DOS
command line. Imagine how big COMMAND.COM would be if it incorporated
PRINT.EXE, SHARE.EXE, DOSKEY.COM, and all of the other Installable
Commands provided by Microsoft!
Thus, instead of adding anything else to 4DOS.COM or COMMAND.COM,
Installable commands are the way to go.
In the 4DOS Help, read "Technical Information for Programmers", and
read the section "Writing Installable Commands"
Joe
lcaverly
> Klaus Meinhard пишет:
>
> > what about detection of a DOS emulator for 4DOS?
>
> > How many are out there there? You seem to fear to many. My off-hand
> > guess is about half a dozen, including Linux dosemu.
>
> > Is there a simple and reliable way to detect a) the fact that 4DOS is
> > running under an emulator and b) which one it is?
>
> There is no general method. One user asked about detection of a particular
> emulator some months ago. I don't remember who and which emulator but this
> was one of the reasons why I implemented the @SMBSTR function. (There were
> some examples here by users on detection of some of the DOS emulators with
> @SMBSTR.)
>
> Lucho
Hi,
Back on August 5th, Lucho made this all possible. I was able to get
the following from within Microsoft Virtual PC 2004 running MS-DOS
6.22 / 4DOS at that time;
c:\4dos>echo %@smbstr[2,1]
Microsoft Corporation
c:\4dos>echo %@smbstr[2,2]
Virtual Machine
c:\4dos>echo %@smbstr[2,3]
5.0
Mind you, Microsoft Virtual PC emulates a PC, but does NOT emulate an
operating system. One can install one of many operating systems,
including MS-DOS, but you have to have the Install Disk(s).
So, whether you are running MS-DOS, Windows 98, or one of the other
1,519 OSes (list at http://vpc.visualwin.com), your OS will always
return Microsoft Corporation, Virtual Machine, from the BIOS,
regardless.
Joe
Luchezar Georgiev
> PRINT.EXE, SHARE.EXE, DOSKEY.COM, and other "external" commands are
> installable commands. They are all TSRs that use the DOS Multiplex
> Interrupt, just as STRINGS.COM does, as a "back door" to the DOS
> command line. Imagine how big COMMAND.COM would be if it incorporated
> PRINT.EXE, SHARE.EXE, DOSKEY.COM, and all of the other Installable
> Commands provided by Microsoft!
Of course. Moreover, in the Unix world, the shell doesn't have most of the
internal commands that COMMAND.COM has. For example the external "cp" does
COPY, the external "mv" - MOVE, the external "ls" - DIR, the external "rm"
- DEL, the external "mkdir" - MD, the external "rmdir" - RD, etc.
> Thus, instead of adding anything else to 4DOS.COM or COMMAND.COM,
> Installable commands are the way to go.
Sure.
> In the 4DOS Help, read "Technical Information for Programmers", and
> read the section "Writing Installable Commands"
Thanks to Charles Dye this formerly separate file is now a part of the help
Regards,
Lucho
ras...@highfiber.com
> *** Interesting. I have not encountered a "Stack Overflow" message since
> I switched to DR-DOS. In fact, I have a directive in my CONFIG.sys of:
>
> STACKS=0,0
>
> ... so I assume that DR-DOS has enough internal stacks to accommodate my
> demands.
It's been a long time, but I seem to remember that DOS's stacks (as
opposed to 4DOS's, or most other applications') are there mostly --
entirely? -- for the benefit of hardware interrupt handlers.
Depending on your computer system's specific hardware, zero stacks may
be a perfectly valid and reliable configuration, as well as saving
memory.
--
Charles Dye ras...@highfiber.com
lcaverly
http://www.edbfreak.dk/_dos/STRINGS.HTM
Joe
ras...@highfiber.com
> Let me explain the above words of mine. I had forgotten about the existing
> StackSize directive and thought that you propose one, which I wrote that I
> couldn't implement (above words). But Tom Rawson and Rex Conn already did!
I was wondering whether you knew something that I didn't, or if I knew
something you didn't.
There's always another treat to discover, isn't there? Lagniappe!
--
Charles Dye ras...@highfiber.com
lcaverly
Well, that link doesn't have the file, so try this one (ftp://
ftp.simtel.net/pub/simtelnet/msdos/batchutl/string25.zip)
Joe
ras...@highfiber.com
> Mind you, Microsoft Virtual PC emulates a PC, but does NOT emulate an
> operating system. One can install one of many operating systems,
> including MS-DOS, but you have to have the Install Disk(s).
>
> So, whether you are running MS-DOS, Windows 98, or one of the other
> 1,519 OSes (list athttp://vpc.visualwin.com), your OS will always
> return Microsoft Corporation, Virtual Machine, from the BIOS,
> regardless.
Yes. I would make a distinction between running in a *hardware*
emulator like VPC, Bochs, etc. and a simulated DOS environment such as
NT and OS/2 provides. The former is much less likely to be
problematic since you really are running under MS-DOS or DR DOS or
whatever.
Regarding DOS emulations, it's interesting that Rex goes out of his
way to support OS/2's DOS, but not NT's. Perhaps because OS/2 does a
better job of it?
--
Charles Dye ras...@highfiber.com
Luchezar Georgiev
> Yes. I would make a distinction between running in a *hardware*
> emulator like VPC, Bochs, etc. and a simulated DOS environment such as
> NT and OS/2 provides. The former is much less likely to be
> problematic since you really are running under MS-DOS or DR DOS or
> whatever.
JPC (Java PC) is a hardware emulator yet due to some omissions the CPU that
it emulates is detected as Pentium II but lacks the RDTSC instruction which
even the Pentium has. PicoXT is a hardware emulator but its CPU is detected
as a 386 while in reality it emulates an 8088. It is difficult to emulate a
CPU if you don't know its schematic or even block diagram and microcode. By
"reverse engineering", it's possible to do, but not 100% and only some have
succeeded in this (AMD, NEC Cyrix, Centaur, Transmeta and several others).
> Regarding DOS emulations, it's interesting that Rex goes out of his
> way to support OS/2's DOS, but not NT's. Perhaps because OS/2 does a
> better job of it?
Yes, the OS/2 DOS emulator is a "DOS better than DOS" - whereas the NT DOS
emulator is much worse. Also, by the time 4OS2 appeared, it was clear that
Microsoft will manage to kill OS/2 so 4OS2 probably wasn't as important as
4NT from commercial point of view. So incorporating some OS/2 support into
4DOS wasn't reducing the sales of the already [probably] poorly sold 4OS2.
All this is of course just speculations of mine. I have no inside info ;-)
Regards,
Lucho
Luchezar Georgiev
>> Regarding DOS emulations, it's interesting that Rex goes out of his
>> way to support OS/2's DOS, but not NT's. Perhaps because OS/2 does a
>> better job of it?
>
> Yes, the OS/2 DOS emulator is a "DOS better than DOS" - whereas the NT
> DOS emulator is much worse. Also, by the time 4OS2 appeared, it was
> clear that Microsoft will manage to kill OS/2 so 4OS2 probably wasn't as
> important as 4NT from commercial point of view. So incorporating some
> OS/2 support into 4DOS wasn't reducing the sales of the already
> [probably] poorly sold 4OS2. All this is of course just speculations of
> mine. I have no inside info ;-)
I forgot to add the important difference that OS/2 does have some 16-bit
API (that can be used by DOS programmes), whereas NT has none.
Regards,
Lucho
Luchezar Georgiev
>> Let me explain the above words of mine. I had forgotten about the existing
>> StackSize directive and thought that you propose one, which I wrote that I
>> couldn't implement (above words). But Tom Rawson and Rex Conn already did!
>
> I was wondering whether you knew something that I didn't, or if I knew
> something you didn't.
You knew something that I had completely forgotten.
> There's always another treat to discover, isn't there? Lagniappe!
Indeed, although I don't know the last word (not an English word?!).
Regards,
Lucho
Klaus Meinhard
> There is no general method. One user asked about detection of a
> particular emulator some months ago. I don't remember who and which
> emulator but this was one of the reasons why I implemented the
> @SMBSTR function. (There were some examples here by users on
> detection of some of the DOS emulators with @SMBSTR.)
Could we perhaps gather the results of as many different emulators as
are available by the readers here?
> No DOS programme was written for use in emulators and 4DOS is no
> exception. Therefore, while 4DOS itself (as a free programme) isn't
> supported, its use under a DOS or CPU emulator is even less supported
> (negatively supported?!)
I can't help but feel that this is a strange attitude.
> > BTW, PEEK and POKE were long time ago proposed by me for a 4DOS
> > upgrade, but never implemented. I guess at that time Rex didn't
> > want the user to use 4DOS to hack its own registration data...
> What do you mean? I/O port manipulation?
No, I mean reading from and writing to current memory. That's what PEEK
and POKE is about, isn't it? When 4DOS still needed a registration, I'm
sure someone would have found a way to "register" 4DOS in memory.
Klaus Meinhard
> Thus, instead of adding anything else to 4DOS.COM or COMMAND.COM,
> Installable commands are the way to go.
Please don't forget that, contrary to command.com, 4DOS can load most of
its bulk into HMA, where the installable commands are situated anyway.
The footprint of 4DOS in lower DOS mem needn't be more than abourt 8 KB.
Each installable command has its own overhead, so writing several of
these will take up more mem than incorporating them in 4DOS itself.
Generally speaking, if you're writing distributable batch files,
installable commands are a bad idea because you cannot depend on them
being loaded. That was one important reason 4DOS stayed integrated. I
hope it stays so.
--
Mit freundlichem Gru?,
Klaus Meinhard
Klaus Meinhard
> Regarding DOS emulations, it's interesting that Rex goes out of his
> way to support OS/2's DOS, but not NT's. Perhaps because OS/2 does a
> better job of it?
No, because IBM's OS/2 always had more sympathy than a MS OpSys, and he
had the expertise from 4OS2. When it soon became clear 4OS2 wasn't a
commercial success (i think it never made more than 10% market share),
4OS2 died with version 3 before and was set free, and further freeware
developement ran only to a few bug fixes. It was effectively dead much
more quickly than 4DOS.
NT, on the other hand, was a commercial success, and of course Rex
wanted to get people to use 4NT instead of 4DOS which had difficulties
because of its 16bit structure (and I still maintain that after
introducing TCC/LE Rex couldn't care less if some relicts still use 4DOS
under NT - they're not the intended customers anyway.).
Matthias Tacke
> Luchezar Georgiev wrote:
> Could we perhaps gather the results of as many different emulators as
> are available by the readers here?
>
--
Regards
Matthias
Luchezar Georgiev
> Please don't forget that, contrary to command.com, 4DOS can load most of
> its bulk into HMA, where the installable commands are situated anyway.
4DOS can swap to XMS, EMS or disk, but not to HMA. The resident part of
4DOS can be loaded to low or upper memory and takes about 4 KB, without
counting the environment and alias sizes (they can be loaded into upper
memory too). There is also a tiny part of 4DOS (about 300 bytes), which
loads always in low memory.
> The footprint of 4DOS in lower DOS mem needn't be more than abourt 8 KB.
> Each installable command has its own overhead, so writing several of
> these will take up more mem than incorporating them in 4DOS itself.
If an installable command (TSR) has an unload option, it can be loaded on
demand and after doing its job, unloaded (e.g. KSTACK can already do it).
> Generally speaking, if you're writing distributable batch files,
> installable commands are a bad idea because you cannot depend on them
> being loaded. That was one important reason 4DOS stayed integrated.
That's probably the biggest advantage of 4DOS compared to BASH for example.
> I hope it stays so.
It will stay as it is.
Regards,
Lucho
Luchezar Georgiev
> Could we perhaps gather the results of as many different emulators as
> are available by the readers here?
It'd be better to do this in a separate thread, as Matthias suggested.
>> No DOS programme was written for use in emulators and 4DOS is no
>> exception. Therefore, while 4DOS itself (as a free programme) isn't
>> supported, its use under a DOS or CPU emulator is even less supported
>> (negatively supported?!)
>
> I can't help but feel that this is a strange attitude.
This is the only possible attitude. I don't care that most of the DOS users
today use an emulator. Let me repeat - no DOS programme is written for such
use, and 4DOS is no exception. The emulator is like a wall outside which is
impossible to look. That's exactly the goal of an emulator, to be invisible!
> No, I mean reading from and writing to current memory. That's what PEEK
> and POKE is about, isn't it?
What use do you see for such low-level and near scope (1-4 bytes) commands?
> When 4DOS still needed a registration, I'm
> sure someone would have found a way to "register" 4DOS in memory.
It wasn't needed to "fiddle" with its encrypted registration data. It was
enough to create a 4DOS.DAT subdirectory, rename 4DOS.HLP to 4DOS.HEL and
change the "HLP" sequence in 4HELP.EXE to "HEL" to block the registration
mechanism. There is a Bulgarian proverb: "A poor man is a devil alive" :)
Regards,
Lucho
FoxWolfie Galen
wrote:
> FoxWolfie Galen ?????:
> > C:\WINDOWS\APPLICA~1\MOZILLA\FIREFOX\PROFILES\XXXXXXXX.DEF\CACHE\
> That's strange! The size of the above string is 65 characters. If we
> include the null terminator, it becomes 66 characters, less than 67!
> Therefore it fits into the CDS structure and shouldn't have problem.
Correct. I can go into that directory, because it does not exceed 67
characters. Once there, I cannot access the files in that directory. The
actual files in that directory look like this - all 73 characters long.
C:\WINDOWS\APPLICA~1\MOZILLA\FIREFOX\PROFILES\XXXXXXXX.DEF\CACHE\54388C~1
C:\WINDOWS\APPLICA~1\MOZILLA\FIREFOX\PROFILES\XXXXXXXX.DEF\CACHE\2A4CD9~1
C:\WINDOWS\APPLICA~1\MOZILLA\FIREFOX\PROFILES\XXXXXXXX.DEF\CACHE\9480A5~1
--
FoxWolfie / CubCoon
Luchezar Georgiev
>>> C:\WINDOWS\APPLICA~1\MOZILLA\FIREFOX\PROFILES\XXXXXXXX.DEF\CACHE\
>
>> That's strange! The size of the above string is 65 characters. If we
>> include the null terminator, it becomes 66 characters, less than 67!
>> Therefore it fits into the CDS structure and shouldn't have problem.
>
> Correct. I can go into that directory, because it does not exceed 67
> characters. Once there, I cannot access the files in that directory. The
> actual files in that directory look like this - all 73 characters long.
>
> C:\WINDOWS\APPLICA~1\MOZILLA\FIREFOX\PROFILES\XXXXXXXX.DEF\CACHE\54388C~1
> C:\WINDOWS\APPLICA~1\MOZILLA\FIREFOX\PROFILES\XXXXXXXX.DEF\CACHE\2A4CD9~1
> C:\WINDOWS\APPLICA~1\MOZILLA\FIREFOX\PROFILES\XXXXXXXX.DEF\CACHE\9480A5~1
Since these files are not directories but normal files, the size of their
names shouldn't be added to the total size, as the CDS structure includes
just the directory name, without the file name. Just tested in my Windows
98 directory. It's named "W98", not Windows. Hence, the size of the cache
directory here is 60 characters including the null terminating character:
C:\W98\APPLIC~1\MOZILLA\FIREFOX\PROFILES\4YN97F~1.DEF\CACHE
to which, if we add 1 for the back slash separator and the 8 characters of
the file name, we get 69 characters: greater than 67, yet everything works
- the files can be accessed. This proves that what does matter is only the
size of the full path (must be < 67), excluding the size of the file name.
Regards,
Lucho
FoxWolfie Galen
wrote:
> Since these files are not directories but normal files, the size of their
> names shouldn't be added to the total size, as the CDS structure includes
> just the directory name, without the file name. Just tested in my Windows
> 98 directory. It's named "W98", not Windows. Hence, the size of the cache
> directory here is 60 characters including the null terminating character:
>
> C:\W98\APPLIC~1\MOZILLA\FIREFOX\PROFILES\4YN97F~1.DEF\CACHE
>
> to which, if we add 1 for the back slash separator and the 8 characters of
> the file name, we get 69 characters: greater than 67, yet everything works
> - the files can be accessed. This proves that what does matter is only the
> size of the full path (must be < 67), excluding the size of the file name.
I can not access any of the files in my cache directory, under plain 4DOS,
without Win98 loaded. The dir command simply ignores the files. The copy,
rename and del commands give errors indicating that the file was not found.
Some applications like Norton Commander and a text editor even say that
drive C: is not formatted.
If I try the same things under 4DOS, while Win98 is running, then all 4DOS
commands, like dir, copy, rename and delete work perfectly. Other DOS
programs like Norton Commander still fail, even with Win98 running.
I don't know how it's programmed, but it is acting as if anything with a
path+name combination of over 67 characters is accessed, it simply does not
work without Win98 running. I can't find any DOS programs that can see such
files if I boot without Windows. With Win98, 4DOS lets me see everything. I
have not done as much detailed testing of 4DOS under WinXP, as I normally
don't have it installed on that system.
None of this appears to be a limit in 4DOS. They are just observations of
how it behaves under plain DOS and under Windows on my systems.
--
FoxWolfie / CubCoon
Luchezar Georgiev
>> [..] the size of the cache
>>
>> C:\W98\APPLIC~1\MOZILLA\FIREFOX\PROFILES\4YN97F~1.DEF\CACHE
>>
>> to which, if we add 1 for the back slash separator and the 8 characters of
>> the file name, we get 69 characters: greater than 67, yet everything works
>> - the files can be accessed. This proves that what does matter is only the
>> size of the full path (must be < 67), excluding the size of the file name.
>
> I can not access any of the files in my cache directory, under plain 4DOS,
> without Win98 loaded. The dir command simply ignores the files. The copy,
> rename and del commands give errors indicating that the file was not found.
> Some applications like Norton Commander and a text editor even say that
> drive C: is not formatted.
Strange! Try temporarily (just for the test) renaming WINDOWS to WIN or W98
or something else that is shorter than WINDOWS. Do these problems persist?
> None of this appears to be a limit in 4DOS. They are just observations of
> how it behaves under plain DOS and under Windows on my systems.
Of course.
Regards,
Lucho
FoxWolfie Galen
wrote:
> >> C:\W98\APPLIC~1\MOZILLA\FIREFOX\PROFILES\4YN97F~1.DEF\CACHE
> Strange! Try temporarily (just for the test) renaming WINDOWS to WIN or W98
> or something else that is shorter than WINDOWS. Do these problems persist?
Sorry for the delay. I have company for a few days and had little time to
test. I've now tested though.
Changing WINDOWS to W98 still does not allow me to access files in my
Firefox Cache from plain 4DOS. Changing WINDOWS to just W still doesn't
work. I can go into the CACHE directory from plain 4DOS, but cannot access
the actual cache files, which all happen to have names that are 11
characters long.
These don't let me access the files:
C:\WINDOWS\APPLIC~1\MOZILLA\FIREFOX\PEOFILES\XXXXXX~1.DEF\CACHE\
C:\W98\APPLIC~1\MOZILLA\FIREFOX\PEOFILES\XXXXXX~1.DEF\CACHE\
C:\W\APPLIC~1\MOZILLA\FIREFOX\PEOFILES\XXXXXX~1.DEF\CACHE\
Changing WINDOWS to W98 and changing MOZILLA to MOZ does work. This lets me
do DIR, COPY, DEL, etc, on the cached files.
C:\W98\APPLIC~1\MOZ\FIREFOX\PEOFILES\XXXXXX~1.DEF\CACHE\
For some reason, it is acting as if the path plus the filename must be
under 67 characters, rather than just the path being under. No program I
have for DOS seems to be letting me past that limit. 4DOS lets me past it,
but only when run from Windows.
So you can access the individual 11-character cached filenames from
C:\W98\APPLIC~1\MOZILLA\FIREFOX\PROFILES\4YN97F~1.DEF\CACHE\ on your
system, when booted to plain 4DOS, where there is no Windows API? I can't
do that unless my path is four characters shorter. I wonder what is
different about our systems.
--
FoxWolfie / CubCoon
Luchezar Georgiev
> For some reason, it is acting as if the path plus the filename must be
> under 67 characters, rather than just the path being under. No program I
> have for DOS seems to be letting me past that limit.
Strange. The name field in the CDS structure doesn't hold file names. This
means that there is some other limitation in your case but not in mine.
> So you can access the individual 11-character cached filenames from
> C:\W98\APPLIC~1\MOZILLA\FIREFOX\PROFILES\4YN97F~1.DEF\CACHE\ on your
> system, when booted to plain 4DOS, where there is no Windows API? I can't
> do that unless my path is four characters shorter. I wonder what is
> different about our systems.
I wonder too... What Firefox version is yours, by the way? Mine is 2.0.0.20
Regards,
Lucho
Steve Fabian
| What Firefox version is yours, by the way? Mine is 2.0.0.20
Though I am not the one asked, I have 3.0.5.
--
Steve
Luchezar Georgiev
> | What Firefox version is yours, by the way? Mine is 2.0.0.20
>
> Though I am not the one asked, I have 3.0.5.
3.0.5 requires NT. 2.0.20 is the last that works with W98. (We were talking
about its cache directory and files there.) FF3.x.x could work with W98 but
the KernelEx extensions must be installed and probably other things done...
Regards,
Lucho
FoxWolfie Galen
wrote:
> I wonder too... What Firefox version is yours, by the way? Mine is 2.0.0.20
Same here. That is the highest I can use on my Win98se system, without
making changes that affect the stability of my OS.
I'm not worried about 4DOS not being able to see files that are stored in
deep paths under a plain DOS boot, as I have no need to do that. I normally
use 4DOS from within Win98, where it works fine. The difference in how our
systems work is purely a curiosity and not a problem. I like to understand
why things work or not work.
--
FoxWolfie / CubCoon
FoxWolfie Galen
wrote:
> 3.0.5 requires NT. 2.0.20 is the last that works with W98. (We were
> talking about its cache directory and files there.) FF3.x.x could work
> with W98 but the KernelEx extensions must be installed and probably
> other things done...
I installed the kernel extensions about six months ago, just to see Firefox
3.x work. It worked good, but made other programs less stable. It also
added to the time it took to restart Windows. I ended up going back to
using 98se without the extensions, as Firefox 2.x is perfectly good enough
for me. There is a *small* chance that 2.0.0.21 might come out, but I think
2.0.0.20 will remain as the last for Win98.
--
FoxWolfie / CubCoon
Luchezar Georgiev
> I like to understand why things work or not work.
So do I.
Regards,
Lucho
WhiteTea
> Klaus Meinhard пишет:
>
> >> So, you only want the LFNs to be enabled by default when the DOS
> >> version is 5.50?
> > ... and %_DOS is MS-DOS.
>
> I'm not aware of any DOS (real or emulated) that returns true version 5.50
> but the DOS emulator of the NT. So I don't think the 2nd check is needed.
>
> > Yes, and that the %_DOS intvar shows at least "Win NT".
>
> This would be the only DOS emulator that will be detected by 4DOS. Not fair
> to the others ;-)
>
> Anyway, maybe the _WIN variable would also need to be changed?! Another bit
> of friendliness to the non-regulated usage of 4DOS that probably amounts to
> 90% of its users. Sorry, 90% or 99% - 4DOS is NOT intended for use under NT
> and if you want to use this vintage software - please do so under a vintage
> operating system that nobody uses anymore. Be so kind to jump off the "band
> wagon". Yes I know that noone will do that: then please bear with the small
> inconveniences. I think that's a fair policy. Another policy is to warn, if
> 4DOS use is attempted under the NT DOS emulator. And yet another is to exit
> in this case, after a warning. Be glad that 4DOS doesn't do any of these 2.
>
> > That's silly. The above wouldn't use any 32-bit APIs, wouldn't overcome
> > any limitations 4DOS has under NT. It would just produce correct
> > information and, - yes- , be a piece of friendliness to users of 4DOS.
> > You decide if you can spare so "much" friendliness.
>
> OK, I'll think about this and decide whether to keep doing the silly thing.
> But I like very much the last paragraphs of the _DOS and _WIN help topics -
> especially the latter, quoted below:
>
> "Note that 4DOS is not intended for use under the Windows NT line. 4DOS
> does not check for these versions of Windows and does not report them in
> the _WIN variable".
>
> Although this note has been added by Charles Dye, I'm sure that that was an
> intentional decision of Rex Conn (I mean, to not check for the NT in 4DOS).
> Why should I change it? What has changed since he took this decision?!
>
> Regards,
> Lucho
Dear Lucho,
I am happy with 4Dos just like it is. It works very well under XP.
I am currently making up an alias.lst to replace my doskey macro file.
Thanks,
Andy