Re: [Freedos-user] a unique directory tree question?

[Karen Lewellen]

Hi Bret,
In this case i wish to only remove the directory and sub directories 
pkunzip created when I tried to unzip the first incomplete zip archive.
I will not lose anything, the new correct archive includes all the 
materials that did end up in place plus new material.  As the directory 
is now, I may never find anything because much of what did unzip properly 
is in the  wrong place.
I may back up this just in case, but would feel better starting cleanly 
fresh.
Thanks again,
Kare


On Tue, 28 Jun 2016, Bret Johnson wrote:

> The DELTREE utility should work OK, though it's a dangerous utility to use.  
> You can easily end up accidentally deleting some things that you really 
> wanted to keep.
>
> I generally only use DELTREE in a small, "confined" case where I'm really 
> sure there's nothing "hidden" or forgotten that I really don't want to delete 
> (I don't know your exact situation).  When I'm trying to do a "large" project 
> where I'm not sure of the consequences, I generally use a dedicated visual 
> file management utility (I personally like Necromancer's DOS Navigator, 
> though there are a ton of similar programs out there).
>
> 
> Affordable Wireless Plans
> Set up is easy. Get online in minutes.
> Starting at only $9.95 per month!
> www.netzero.net?refcd=nzmem0216
>
> --
> Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
>

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.1 crashing in VirtualBox 5.0.22

[Rugxulo]

Hi,

On Tue, Jun 28, 2016 at 3:55 PM, Abe Mishler  wrote:
>
> Strange, right? And not just on one computer, but three separate ones; each
> running different hardware and software (host OS). Although I would expect
> that the underlying differences are abstracted away by VirtualBox.

It's not really that strange. EMS is rarely used nowadays, and DOS (in
all its billions of setups) isn't highly tested by emulators. Their
focus is on other, more popular, guests.

It's impossible (or maybe unprofitable) to test every emulator under
the sun (dozens!), plus having to work around all the bugs and missing
features. Some OSes present bigger problems than others (OS/2,
OpenBSD), even requiring VT-X compatible hardware.

I would recommend you (also) test under QEMU if you're that worried or
want (potentially) better stability. At least Windows (32-bit or
64-bit) binaries are easily available below (not to mention that QEMU
runs on various other host OSes too, e.g. Linux):

http://qemu.weilnetz.de/

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] a unique directory tree question?

[Rugxulo]

Hi, Bret,

(somewhat off-topic)

On Tue, Jun 28, 2016 at 6:21 PM, Bret Johnson  wrote:
> The DELTREE utility should work OK, though it's a dangerous utility to use.  
> You can easily end up
> accidentally deleting some things that you really wanted to keep.

Backup backup backup!

> I generally only use DELTREE in a small, "confined" case where I'm really 
> sure there's nothing "hidden"
> or forgotten that I really don't want to delete (I don't know your exact 
> situation).  When I'm trying to do a
> "large" project where I'm not sure of the consequences, I generally use a 
> dedicated visual file management
> utility (I personally like Necromancer's DOS Navigator, though there are a 
> ton of similar programs out there).

There's a newer fork of NDN available here (as I assume you're still
using old classic from 2010):

= 
https://drive.google.com/folderview?id=0B_wEiYjzVkC0ZGtkbENENzF1Nms=drive_web

= (actually, I discovered it here, but while the maintainer [CandyMan]
hasn't really promoted it, he's still somewhat active in other
projects) http://board.flatassembler.net/topic.php?p=186222#186222

EDIT: I don't actually know if this now is newer than the ones of his
that I still have on my hard drive (from this past March). I didn't
test them much, and with no one else actively interested, it seemed a
less valuable way to spend my time. So I'm just telling you for
completeness, if you want to test them.   :-/

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] a unique directory tree question?

[Bret Johnson]

The DELTREE utility should work OK, though it's a dangerous utility to use.  
You can easily end up accidentally deleting some things that you really wanted 
to keep.

I generally only use DELTREE in a small, "confined" case where I'm really sure 
there's nothing "hidden" or forgotten that I really don't want to delete (I 
don't know your exact situation).  When I'm trying to do a "large" project 
where I'm not sure of the consequences, I generally use a dedicated visual file 
management utility (I personally like Necromancer's DOS Navigator, though there 
are a ton of similar programs out there).


Affordable Wireless Plans
Set up is easy. Get online in minutes.
Starting at only $9.95 per month! 
www.netzero.net?refcd=nzmem0216

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.1 crashing in VirtualBox 5.0.22

[Eric Auer]

Hi Uli and Abe,

indeed it seems like it is not trivial to find the right
excluded areas for UMB to have stability. Having no page
frame is okay - EMS 4 aware software can still use EMS,
only EMS 3 software will miss a frame.

Normally it is enough to have 550k conventional free.

To explain the different memory types:

low DOS memory - the usual 640 kB that you always use,
  where you want to have at least 500 something free.

HMA - provided by HIMEM - lets mainly DOS kernel load high

XMS - provided by HIMEM - lets various DOS programs enjoy
  extra megabytes (ramdisk, dos extenders, caches etc.)

UMB - provided by EMM386 - lets you load various drivers
  high, can also be provided by UMBPCI or other hardware
  drivers, can cause stability issues in conflict cases

EMS - provided by EMM386 or old special hardware - lets
  old DOS programs enjoy some extra memory for page swap
  and extra data storage, not often needed by modern apps

VCPI - provided by EMM386 - lets DOS extenders share the
  protected mode with EMM386, so if you do not load EMM386
  in the first place, you will not need VCPI either. The
  special GEMMIS feature is similar, but for Windows 3.

DPMI - provided by Windows and some DOS extenders - lets
  programs which use DOS extenders share protected mode,
  popular for modern games. Often, games come with their
  own DPMI driver to be able to run outside of Windows,
  using XMS or raw memory in that case.

Raw memory - if you use protected mode "by hand", you can
  of course use all those megabytes outside the first DOS
  megabyte-and-a-bit, too. But using XMS or DPMI often is
  more convenient.

What does this tell you for normal users? You should load
HIMEM for HMA and XMS. If you need space to load drivers
high, you should also use EMM386. The rest will be magic
DOS extender use of whatever suitable memory you have and
only in rare cases you would actually need EMS :-)

Note that HIMEMX and XMGR are like HIMEM and JEMM386 is
like EMM386, while JEMMEX is like both HIMEM and EMM386
combined into a single driver, with some pros and cons.

Regards, Eric



--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.1 crashing in VirtualBox 5.0.22

[Abe Mishler]

Guys,

> On Jun 28, 2016, at 3:39 PM, Ulrich Hansen  wrote:
> 
> 
>> Am 28.06.2016 um 21:19 schrieb Ulrich Hansen :
>> 
>> The trick is to load PCNTPK low in option 1. Then it won’t crash with your 
>> JEMMEX options. At least for me. :-)
>> 
>> PCNTPK INT=0x60
> 
> Okay, and FDAPM crashes too. I need to load it into conventional memory as 
> well.
You are running a more advanced FreeDOS configuration than me at the moment. 
Mine is still a vanilla install. Nothing extra.
> 
> All in all it seems your configuration 
> 
>> 1?DEVICE=C:\FDOS\BIN\JEMMEX.EXE NOEMS X=C900-DFFF I=TEST NOVME NOINVLPG
> 
> 
> is pretty unstable, at least for me.
> 
It seems like you should be excluding a different region of memory. From your 
screenshot: E300-EDFF.

> But the default line didn’t work for you at all. Hmm.
Strange, right? And not just on one computer, but three separate ones; each 
running different hardware and software (host OS). Although I would expect that 
the underlying differences are abstracted away by VirtualBox.

> 
> 
> --
> Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.1 crashing in VirtualBox 5.0.22

[Rugxulo]

Hi,

On Tue, Jun 28, 2016 at 12:56 PM, Abe Mishler  wrote:
>
> It's apparent that a well written book might help me come up
> to speed on all of these memory modes and managers.

I'm not an expert, but the simple answer is you don't need all of
them. Pure XMS (and optional DPMI) should suffice for most uses. Don't
overcomplicate it. Don't worry about every feature under the sun
unless an app you want to run direly needs it (unlikely). EMS is quite
old and rare, and even without EMM386, the amount of conventional
memory free should be "good enough" for most existing programs, so you
probably don't need UMBs at all. (But see UMBPCI. Or EMS Magic, which
reuses conventional memory, which is sometimes better for
compatibility.) Besides, you can "JEMM386 LOAD" (and "UNLOAD") later
if you (temporarily) need EMS for something (but not for UMBs).

Somebody, when preparing FD 1.1, was perhaps overzealous for features
when trying to support JEMMEX. But, for the record, VBox is not
necessarily bug-free or a primary target (remember that DOS is meant
for actual native booting, or at least was before UEFI). So yes,
presumably EMM386 (et al.) work better on "real" native hardware than
emulators. That can't be avoided, but perhaps it's not wise to
recommend (or even include) overcomplicated JEMMEX config lines in
future FD versions. (This has been discussed before, so you're not the
first one to notice this hanging VBox + JEMMEX behavior.)

P.S. Emulators are still (usually) run on top of advanced host OSes.
So I'm not sure certain low-level DOS things are directly useful there
(software cache, screen saver, ultra DMA). So I wouldn't worry about
those either.

> My interest is in programming anyways (I'm new to DOS but not programming).
> Any suggestions?

The officially recommended compilers / languages are C (OpenWatcom)
and assembler (NASM). But the DJGPP tree is quite nice too (and
includes barely-related offshoots like Free Pascal, FreeBASIC, and
more). None of these need EMS or UMBs.

So it's unlikely you'll be interested in EMS at all. Stick to real
mode (640 kb) or DPMI (2 GB).

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.1 crashing in VirtualBox 5.0.22

[Ulrich Hansen]

> Am 28.06.2016 um 21:19 schrieb Ulrich Hansen :
> 
> The trick is to load PCNTPK low in option 1. Then it won’t crash with your 
> JEMMEX options. At least for me. :-)
> 
> PCNTPK INT=0x60

Okay, and FDAPM crashes too. I need to load it into conventional memory as well.

All in all it seems your configuration 

> 1?DEVICE=C:\FDOS\BIN\JEMMEX.EXE NOEMS X=C900-DFFF I=TEST NOVME NOINVLPG


is pretty unstable, at least for me.

But the default line didn’t work for you at all. Hmm.


--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.1 crashing in VirtualBox 5.0.22

[Ulrich Hansen]

> Am 28.06.2016 um 20:41 schrieb Ulrich Hansen :
> 
> If I look closely, I find that PCNTPK crashes at boot. So I have no network. 
> No wonder all the memory is free.
> https://www.lazybrowndog.net/freedos/files/freedos1.1-vbox-opt1-memory2.png 
> 
> 
> So your solution won’t work for all VirtualBox users…
> I have Version 5.0.14 r105127 running in OS X 10.10.5.

Okay. I also tried it with the new version 5.0.22 but everything’s the same. 
BUT:

The trick is to load PCNTPK low in option 1. Then it won’t crash with your 
JEMMEX options. At least for me. :-)

PCNTPK INT=0x60


--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.1 crashing in VirtualBox 5.0.22

[Ulrich Hansen]

Hi Abe (and hi Eric!)

> Am 28.06.2016 um 16:42 schrieb Abe Mishler :
> 
> 1?DEVICE=C:\FDOS\BIN\JEMMEX.EXE NOEMS X=C900-DFFF I=TEST NOVME NOINVLPG
> 
> Boot option 1 (http://tinypic.com/r/zm1boj/9 ):
> Total memory Free: 26,699K
> Total Expanded (EMS): 8,576K
> Free Expanded (EMS): 8,192K
> Largest executable program size: 597K
> Largest free upper memory block: 2K


With the FreeDOS 1.1 default line

1?DEVICE=C:\FDOS\BIN\JEMMEX.EXE NOEMS X=TEST I=TEST NOVME NOINVLPG

I get less free conventional memory:

Boot option 1 
(https://www.lazybrowndog.net/freedos/files/freedos1.1-vbox-opt1-memory.png 
)
Total memory Free: 26,682K
Total Expanded (EMS): 8,576K
Free Expanded (EMS): 8,192K
Largest executable program size: 579K
Largest free upper memory block: 2K

If I try your configuration in my FreeDOS 1.1 VirtualBox image I get even 601K 
executable program size BUT:
If I look closely, I find that PCNTPK crashes at boot. So I have no network. No 
wonder all the memory is free.
https://www.lazybrowndog.net/freedos/files/freedos1.1-vbox-opt1-memory2.png 


So your solution won’t work for all VirtualBox users…
I have Version 5.0.14 r105127 running in OS X 10.10.5.


PS: I use a screencast software to record boot messages in VBox - otherwise 
they move to quickly to read them.

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS 1.1 crashing in VirtualBox 5.0.22

[Abe Mishler]

On 6/28/2016 11:08 AM, Eric Auer wrote:
>
> Hi Abe,
>
>> Based on Eric's suggestion of using more cautious settings,
>> I found the JEMMEX doc page
>> (http://help.fdos.org/en/hhstndrd/base/jemmex.htm)
>
> The documentation is also included in your installation on disk.
>
>> 1?DEVICE=C:\FDOS\BIN\JEMMEX.EXE NOEMS X=C900-DFFF I=TEST NOVME NOINVLPG
>
> You could also try X=TEST Without I=TEST, but excluding C900 to DFFF
> seems to be an even more cautious choice for your specific system.
>
Doing that results in an additional message before crashing so it looks 
like I will have to stick with the specific exclusion.

The additional message:
Warning: no suitable page frame found, EMS functions limited.

>> Boot option 1 no longer crashes, but it doesn't appear to be an
>> improvement over boot option 2...
>
> Option 2 loads SHARE and uses HIMEMX together with JEMM386 instead
> of JEMMEX which combines "HIMEM" and "EMM386" into a single driver.
> Option 2 also moves the PCNTPK network packet driver to UMB, which
> is why you have slightly more "largest executable program size" in
> option 2 compared to option 1 in spite of option 2 loading SHARE.
>
> You can try using LH for PCNTPK, but if you do not use internet in
> DOS, you could simply comment out the whole line that loads PCNTPK.
>
> If you only use EMS-aware software which is EMS 4.0 compatible,
> you can disable EMS 3.2 compatible page frames with some option
> for JEMMEX and JEMM386: That way, you get 64 kB extra space for
> UMB use, so it will be easier to LH things and gain low space.
>
> I think today EMM386 is more often used for UMB and less often
> for EMS. If you only use UMB but do not need EMS at all, you
> can also disable EMS 3.2 compatible page frames, of course :-)
>
>> Boot option 1 (http://tinypic.com/r/zm1boj/9): [JEMMEX]
>> Total memory Free: 26,699K
>> Total Expanded (EMS): 8,576K
>> Free Expanded (EMS): 8,192K
>> Largest executable program size: 597K
>> Largest free upper memory block: 2K
>
>> Boot option 2 (http://tinypic.com/r/2zzjl77/9): [HIMEMX+JEMM386]
>> Total memory Free: 26,669K
>> Total Expanded (EMS): 31M
>
> Interesting that JEMM386 defaults to offer more EMS than JEMMEX.
>
>> Free Expanded (EMS): 25M
>
> Odd, what happened to the other 6 MB of EMS?
>
I was wondering that myself...

>> Largest executable program size: 610K
>
> This is because that option loads SHARE & network drivers high.
>
>> Largest free upper memory block: 4K
>
> This is interesting: In spite of loading more things into UMB,
> you have more UMB left. That MIGHT mean that option 2 does not
> have the X=C900-DFFF option but still is lucky enough to avoid
> a crash? It could already be unstable, though. Maybe it would
> still crash as soon as you use the network in DOS.
>
Right, I didn't block that region in option 2. I used networking with 
option 2 to install the VBOX-FIX COM patch earlier. I didn't experience 
a crash. Perhaps I was "lucky". What's interesting is that there is no 
delay loading the UIDE driver so maybe Oracle has fixed the bus scan 
problem with VirtualBox rendering the patch unnecessary. Perhaps someone 
else can duplicate these results and confirm.

> ALSO, the option 2 takes the "dangerous" step of explicitly
> including the monochrome graphics card text memory area as
> UMB memory (I=B000-B7FF). This means that attempts to use a
> program which uses monochrome video modes may cause crashes.
> It could also be the real reason why more UMB is free there.
>
I was going to use option 2 even after all of this, but I will remain 
with option 1 now that it works; especially since you have indicated 
twice now that option 2 might be unstable. Thanks for that insight.

> I think that even 597 kB of low DOS memory is plenty for old
> DOS programs. New DOS programs use a DOS extender anyway, so
> they will be able to use your EMS and XMS, which are several
> megabytes. You can use other MEM command line options to see
> more details. Check the output of "MEM /?" to learn more :-)
>
> Regards, Eric
>
> PS: Do you use a special MOUSE or the usual CTMOUSE driver?
>
I have not installed a mouse driver or configured the mouse in any way. 
My AUTOEXEC.BAT has the standard "MOUSE" command in it.

> PPS: I see 1.1 uses XMGR in option 3 and 4DOS in option 4,
> not sure if those are included in the 1.2 distro any more.
>
For the record it looks like 4DOS is also in option 3, but thanks for 
the info. It's apparent that a well written book might help me come up 
to speed on all of these memory modes and managers. My interest is in 
programming anyways (I'm new to DOS but not programming). Any suggestions?
>
Thanks,
Abe

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information 

Re: [Freedos-user] FreeDOS 1.1 crashing in VirtualBox 5.0.22

[Eric Auer]

Hi Abe,

> Based on Eric's suggestion of using more cautious settings,
> I found the JEMMEX doc page
> (http://help.fdos.org/en/hhstndrd/base/jemmex.htm)

The documentation is also included in your installation on disk.

> 1?DEVICE=C:\FDOS\BIN\JEMMEX.EXE NOEMS X=C900-DFFF I=TEST NOVME NOINVLPG

You could also try X=TEST Without I=TEST, but excluding C900 to DFFF
seems to be an even more cautious choice for your specific system.

> Boot option 1 no longer crashes, but it doesn't appear to be an 
> improvement over boot option 2...

Option 2 loads SHARE and uses HIMEMX together with JEMM386 instead
of JEMMEX which combines "HIMEM" and "EMM386" into a single driver.
Option 2 also moves the PCNTPK network packet driver to UMB, which
is why you have slightly more "largest executable program size" in
option 2 compared to option 1 in spite of option 2 loading SHARE.

You can try using LH for PCNTPK, but if you do not use internet in
DOS, you could simply comment out the whole line that loads PCNTPK.

If you only use EMS-aware software which is EMS 4.0 compatible,
you can disable EMS 3.2 compatible page frames with some option
for JEMMEX and JEMM386: That way, you get 64 kB extra space for
UMB use, so it will be easier to LH things and gain low space.

I think today EMM386 is more often used for UMB and less often
for EMS. If you only use UMB but do not need EMS at all, you
can also disable EMS 3.2 compatible page frames, of course :-)

> Boot option 1 (http://tinypic.com/r/zm1boj/9): [JEMMEX]
> Total memory Free: 26,699K
> Total Expanded (EMS): 8,576K
> Free Expanded (EMS): 8,192K
> Largest executable program size: 597K
> Largest free upper memory block: 2K

> Boot option 2 (http://tinypic.com/r/2zzjl77/9): [HIMEMX+JEMM386]
> Total memory Free: 26,669K
> Total Expanded (EMS): 31M

Interesting that JEMM386 defaults to offer more EMS than JEMMEX.

> Free Expanded (EMS): 25M

Odd, what happened to the other 6 MB of EMS?

> Largest executable program size: 610K

This is because that option loads SHARE & network drivers high.

> Largest free upper memory block: 4K

This is interesting: In spite of loading more things into UMB,
you have more UMB left. That MIGHT mean that option 2 does not
have the X=C900-DFFF option but still is lucky enough to avoid
a crash? It could already be unstable, though. Maybe it would
still crash as soon as you use the network in DOS.

ALSO, the option 2 takes the "dangerous" step of explicitly
including the monochrome graphics card text memory area as
UMB memory (I=B000-B7FF). This means that attempts to use a
program which uses monochrome video modes may cause crashes.
It could also be the real reason why more UMB is free there.

I think that even 597 kB of low DOS memory is plenty for old
DOS programs. New DOS programs use a DOS extender anyway, so
they will be able to use your EMS and XMS, which are several
megabytes. You can use other MEM command line options to see
more details. Check the output of "MEM /?" to learn more :-)

Regards, Eric

PS: Do you use a special MOUSE or the usual CTMOUSE driver?

PPS: I see 1.1 uses XMGR in option 3 and 4DOS in option 4,
not sure if those are included in the 1.2 distro any more.



--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] a unique directory tree question?

[Karen Lewellen]

Hi  Bret,
Thanks for such an informative reply.
I actually suspect you may  be correct about the combination of file names.
I requested that the person commissioned to gather and zip the information 
do it a second time.
The new .zip archive is..about twice as large as the first one.  as in from 
about half a gig to almost a full one, with these all being text files.
I suspect that either they did not get everything the first time, or their 
correcting special characters in the file names, something they told me 
ended up  being needful, produced a zip file with all the goods.
I suspect? it will be best to create the entire archive again, rather than 
try and let pkunzip fix the first one with this new zip archive.
  If I wish to remove everything, would this be the deltree utility?  its 
been  a long long time, and I am using ms dos  7.1
Thanks again,
Kare


On Tue, 28 Jun 2016, Bret Johnson wrote:

> I'm a little late responding to this.  I haven't seen these particular things 
> discussed yet, and I think they need to be.
>
> Regarding directories, there is the "width" (the number of 
> files/subdirectories in a {sub}directory) and the "height" (the number of 
> levels of subdirectories underneath the root).  The root directory does have 
> a width limit which is defined when the drive is formatted (usually 128, 256, 
> or 512).  The root directory is the only one with a width limit -- there is 
> no limit to the number of files/subdirectories in a subdirectory (other than 
> the fact that all of the entries must be uniquely named).  Also, as a side 
> note, early versions of FAT did not even allow subdirectories.
>
> While technically there is no limit to the depth, the entire name of a file, 
> including the drive letter, colon, backslashes, and dots, cannot be longer 
> than 64 characters total when using short (8.3) names.  DOS uses 64-byte 
> buffers to transfer names back and forth internally as it is manipulating the 
> files and directories, and that is a hard limit.
>
> So, if your directory names are only one or two characters each, you can go 
> several levels deep.  If they're all 8 letters (or even longer if you use 8.3 
> directory names), you can only go a few levels deep.  Also not that the 
> 64-character limit applies AFTER the file names are expanded (e.g., if you 
> normally use "." and "..", or leave out the drive letter, use SUBST drives, 
> use environment variables, etc.).
>
> When using Long File Names, there is also a limit, but it is much longer -- 
> 260 characters.
>
> ---
>
> Regarding your particular problem, I suspect it is related to the 
> relationship between short and long file names, and the naming 
> inconsistencies that occur between different systems as directories and files 
> are manipulated.  I will give a specific example.
>
> Many years ago (when Windows 95 was still en vogue), the IT department at a 
> company I worked for sent out a batch file that everybody was supposed to run 
> on their computer to fix some kind of problem (I don't remember exactly what 
> it was supposed to fix, and it is irrelevant to the point, anyway).  In 
> Windows there is a "Program Files" directory, which is normally PROGRA~1 when 
> using short file names.  In the batch file the IT department sent out, it 
> referenced the directory as PROGRA~1 wither bothering to check if PROGRA~1 
> even existed.  On my computer, it didn't -- I had manipulated my directory 
> structure enough that my short name for "Program Files" was PROGRA~2 instead 
> of PROGRA~1.  I called the IT department and told them what I found, and they 
> basically told me it was my fault and they weren't going to change their 
> batch file.
>
> It's possible that your particular problems are related to something like 
> that -- the short file names of one computer conflict with or somehow 
> "confuse" the other computer.  I don't think you said which DOS LFN program 
> you were using (there are several of them and they all have their own 
> quirks).  It's possible that one of the programs (PKZIP/PKUNZIP, the LFN 
> program, the DOS kernel) is buggy, or that some combination of the programs 
> is acting weird, particularly if the short file names are not consistent on 
> the different computers.  When you're mixing long and short file names 
> together you need to be very careful -- things don't always work quite like 
> you would expect.
>
> Long File Names are nice, but the way MS actually implemented them in FAT 
> was, in my opinion, a horrible design.
> 
> Fivebreak.com
> 40 Years of the Same Photo Together, But The Last One is Incredible
> http://thirdpartyoffers.juno.com/TGL3141/5772286c618f6286c1e97st02vuc
>
> --
> Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their 

Re: [Freedos-user] FreeDOS 1.1 crashing in VirtualBox 5.0.22

[Abe Mishler]

Hi Ulrich,

Thanks for the link. I compared the 2 files and didn't find anything of 
significance. Your change:

IF "%config%"=="2" PCNTPK INT=0x60
IF NOT "%config%"=="2" LH PCNTPK INT=0x60

seems smart, however.

Based on Eric's suggestion of using more cautious settings, I found the 
JEMMEX doc page
(http://help.fdos.org/en/hhstndrd/base/jemmex.htm)

and learned how to change the JEMMEX options. I excluded the region of 
memory that might already be in use (indicated in the original error 
message):
1?DEVICE=C:\FDOS\BIN\JEMMEX.EXE NOEMS X=C900-DFFF I=TEST NOVME NOINVLPG

Boot option 1 no longer crashes, but it doesn't appear to be an 
improvement over boot option 2. Here is what I am getting from C:\mem 
after boot:

Boot option 1 (http://tinypic.com/r/zm1boj/9):
Total memory Free: 26,699K
Total Expanded (EMS): 8,576K
Free Expanded (EMS): 8,192K
Largest executable program size: 597K
Largest free upper memory block: 2K

Boot option 2 (http://tinypic.com/r/2zzjl77/9):
Total memory Free: 26,669K
Total Expanded (EMS): 31M
Free Expanded (EMS): 25M
Largest executable program size: 610K
Largest free upper memory block: 4K

I don't have much experience with the way DOS memory works. What do you 
think of these results? Anything else I should be looking at?

Thanks,
Abe

On 6/27/2016 8:23 PM, Ulrich Hansen wrote:
> Hi Abe,
>
> if you like, take a look at:
>
> https://www.lazybrowndog.net/freedos/virtualbox
>
> There are three VirtualBox images of FreeDOS 1.1.
>
> I put quite some effort in them to make them work. I remember the crash
> you are talking about, but, sorry, I don’t remember how I fixed it
> (wasn’t it something about not loading high something?? Very sorry.
> Maybe you compare the AUTOEXEC.BAT and FDCONFIG.SYS of the FreeDOS 1.1
> VirtualBox image?
>
> -
> AUTOEXEC.BAT
>
> @echo off
> SET LANG=EN
> SET MTCPCFG=C:\FDOS\MTCP.CFG
> SET WATTCP.CFG=C:\FDOS
> SET PATH=%dosdir%\BIN;C:\DOSZIP
> SET NLSPATH=%dosdir%\NLS
> SET HELPPATH=%dosdir%\HELP
> SET TEMP=%dosdir%\TEMP
> SET TMP=%TEMP%
> SET BLASTER=A220 I5 D1 H5 P330
> SET DIRCMD=/P /OGN /4
> SET COPYCMD=/-Y
> if "%config%"=="4" goto end
> SHSUCDX /QQ /D3
> LH SHSUCDHD /QQ /F:FDBOOTCD.ISO
> LH FDAPM APMDOS
> IF "%config%"=="2" LH SHARE
> LH DOSLFN
> REM NLSFUNC C:\FDOS\BIN\COUNTRY.SYS
> REM DISPLAY CON=(EGA),858,2)
> REM MODE CON CP PREP=((858) C:\FDOS\CPI\EGA.CPX)
> REM KEYB US,858,C:\FDOS\bin\keyboard.sys
> REM KEYB GR,,keyboard.sys /NOHI
> REM CHCP 858
> IF "%config%"=="2" PCNTPK INT=0x60
> IF NOT "%config%"=="2" LH PCNTPK INT=0x60
> DHCP
> REM M2WAT.COM  transfers the mTCP configuration to
> WATTCP.CFG.
> REM Disable it, if you want to use a custom WATTCP.CFG.
> C:\FDOS\M2WAT.COM 
> MOUSE
> DEVLOAD /H /Q %dosdir%\BIN\UIDE.SYS /H /D:FDCD0001 /S5
> SHSUCDX /QQ /~ /D:?SHSU-CDR,D /D:?SHSU-CDH,D /D:?FDCD0001,D
> /D:?FDCD0002,D /D:?FDCD0003,D
> MEM /C /N
> IF NOT "%config%"=="4" SHSUCDX /D
> GOTO END
> :END
> SET AUTOFILE=%0
> SET CFGFILE=C:\FDCONFIG.SYS
> alias reboot=fdapm warmboot
> alias reset=fdisk /reboot
> alias halt=fdapm poweroff
> alias shutdown=fdapm poweroff
> alias cfg=edit %cfgfile%
> alias auto=edit %0
> echo Done processing startup files %cfgfile% and %0
> echo Type HELP to get support on commands and navigation
> echo.
> echo Welcome to the FreeDOS 1.1 operating system (http://www.freedos.org)
>
>
> -
> FDCONFIG.SYS
>
> !COUNTRY=001,858,C:\FDOS\BIN\COUNTRY.SYS
> !SET DOSDIR=C:\FDOS
> !LASTDRIVE=Z
> !BUFFERS=20
> !FILES=40
> !MENUCOLOR=7,0
> MENUDEFAULT=1,5
> MENU 1 - Load FreeDOS with JEMMEX, no EMS (most UMBs), max RAM free
> MENU 2 - Load FreeDOS with EMM386 (Expanded Memory) and SHARE loaded
> MENU 3 - Load FreeDOS including XMGR XMS-memory driver
> MENU 4 - Load FreeDOS without drivers
> 123?DOS=HIGH
> 12?DOS=UMB
> 12?DOSDATA=UMB
> 1?DEVICE=C:\FDOS\BIN\JEMMEX.EXE NOEMS X=TEST I=TEST NOVME NOINVLPG
> 2?DEVICE=C:\FDOS\BIN\HIMEMX.EXE
> 2?DEVICE=C:\FDOS\BIN\JEMM386.EXE X=TEST I=TEST I=B000-B7FF NOVME NOINVLPG
> 3?DEVICE=C:\FDOS\BIN\XMGR.SYS
> 3?SHELL=C:\FDOS\bin\4dos.com  C:\FDOS\bin /E:1024
> /P:C:\AUTOEXEC.BAT
> 4?SHELL=C:\FDOS\BIN\COMMAND.COM  C:\FDOS\BIN /E:1024
> /P=C:\AUTOEXEC.BAT
> 12?SHELLHIGH=C:\FDOS\BIN\COMMAND.COM  C:\FDOS\BIN
> /E:1024 /P=C:\AUTOEXEC.BAT
>
>
> --
> Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
>
>
>
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> 

Re: [Freedos-user] a unique directory tree question?

[Bret Johnson]

I'm a little late responding to this.  I haven't seen these particular things 
discussed yet, and I think they need to be.

Regarding directories, there is the "width" (the number of files/subdirectories 
in a {sub}directory) and the "height" (the number of levels of subdirectories 
underneath the root).  The root directory does have a width limit which is 
defined when the drive is formatted (usually 128, 256, or 512).  The root 
directory is the only one with a width limit -- there is no limit to the number 
of files/subdirectories in a subdirectory (other than the fact that all of the 
entries must be uniquely named).  Also, as a side note, early versions of FAT 
did not even allow subdirectories.

While technically there is no limit to the depth, the entire name of a file, 
including the drive letter, colon, backslashes, and dots, cannot be longer than 
64 characters total when using short (8.3) names.  DOS uses 64-byte buffers to 
transfer names back and forth internally as it is manipulating the files and 
directories, and that is a hard limit.

So, if your directory names are only one or two characters each, you can go 
several levels deep.  If they're all 8 letters (or even longer if you use 8.3 
directory names), you can only go a few levels deep.  Also not that the 
64-character limit applies AFTER the file names are expanded (e.g., if you 
normally use "." and "..", or leave out the drive letter, use SUBST drives, use 
environment variables, etc.).

When using Long File Names, there is also a limit, but it is much longer -- 260 
characters.

---

Regarding your particular problem, I suspect it is related to the relationship 
between short and long file names, and the naming inconsistencies that occur 
between different systems as directories and files are manipulated.  I will 
give a specific example.

Many years ago (when Windows 95 was still en vogue), the IT department at a 
company I worked for sent out a batch file that everybody was supposed to run 
on their computer to fix some kind of problem (I don't remember exactly what it 
was supposed to fix, and it is irrelevant to the point, anyway).  In Windows 
there is a "Program Files" directory, which is normally PROGRA~1 when using 
short file names.  In the batch file the IT department sent out, it referenced 
the directory as PROGRA~1 wither bothering to check if PROGRA~1 even existed.  
On my computer, it didn't -- I had manipulated my directory structure enough 
that my short name for "Program Files" was PROGRA~2 instead of PROGRA~1.  I 
called the IT department and told them what I found, and they basically told me 
it was my fault and they weren't going to change their batch file.

It's possible that your particular problems are related to something like that 
-- the short file names of one computer conflict with or somehow "confuse" the 
other computer.  I don't think you said which DOS LFN program you were using 
(there are several of them and they all have their own quirks).  It's possible 
that one of the programs (PKZIP/PKUNZIP, the LFN program, the DOS kernel) is 
buggy, or that some combination of the programs is acting weird, particularly 
if the short file names are not consistent on the different computers.  When 
you're mixing long and short file names together you need to be very careful -- 
things don't always work quite like you would expect.

Long File Names are nice, but the way MS actually implemented them in FAT was, 
in my opinion, a horrible design.

Fivebreak.com
40 Years of the Same Photo Together, But The Last One is Incredible
http://thirdpartyoffers.juno.com/TGL3141/5772286c618f6286c1e97st02vuc

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user