Date:	Thu, 13 Mar 1997 03:03:14 -0500 (EST)
From:	"Mike A. Harris" <mharris AT blackwidow DOT saultc DOT on DOT ca>
Reply-To:	"Mike A. Harris" <mharris AT blackwidow DOT saultc DOT on DOT ca>
To:	"Colin W. Glenn" <cwg01 AT gnofn DOT org>
cc:	"'OpenDOS newsgroup'" <opendos AT mail DOT tacoma DOT net>
Subject:	Re: [opendos] OD case sensitivity
In-Reply-To:	<Pine.GSO.3.95.970312190009.4300H-100000@sparkie.gnofn.org>
Message-ID:	<Pine.LNX.3.95.970313025711.955L-100000@capslock.com>
Organization:	Total disorganization.
MIME-Version:	1.0
Sender:	owner-opendos AT mail DOT tacoma DOT net

On Wed, 12 Mar 1997, Colin W. Glenn wrote:

> On Wed, 12 Mar 1997, Mark Habersack wrote:
> > On 11 Mar 97 (at 19:18) Colin W. Glenn became famous by saying:
> > > Right, I'm talking about a patch until this is done.
> > So, you mean like a 'proxy' command.com to uppercase the env and load up the 
> > original one? This might be quite hard with some advanced features of OD...
> 
> How so?  The only potential problem I see is that the stack is undefined
> upon entry into the command processor, but seeing as you MUST define it as
> the permanent command shell, you never have to worry about exiting to an
> unknow machine state.  Them who forget to add the /p switch will need to
> be reminded by the little utility about adding it, or have it be added for
> them.  The proxy program name would be added in front of the command shell
> loading line, ie:
> 
> shell=c:\command.com /p /e:800
> 
> would become:
> 
> shell=c:\proxy c:\command.com /p /e:800
> 
> giving proxy the name and location of command.
> 
> > > Uh-huh, and not willing to sacrifice the work, loaded debug and wrote the
> > > entire memory to disk to pluck through later.  PAIN.
> > ;-)So you've just invented a coredump for DOS! ;-)
> 
> Only problem was, couldn't get debug to dump more that 65536 bytes at a
> time, gee, I wonder why?
> 
> Wishlist!  Coredump for OpenDOS!  Plus Full Memory Dump.  (warn those
> with multimegabyte machines about having enough free disk space before
> blowing in this command though;)

Dump full memory with DEBUG.

C:\>DEBUG CORE
-RDS
0
-RCS
0
-RIP
0
-RCX
0
-RBX
FFFF
-W

This is untested, however if it doesn't work, some minor tweaking
will get it to work.  Debug is capable of loading/saving files
greater than 64k, although it normally isn't used for files
bigger than 64k.  Normally we just manipulate CX before writing
to disk, however BX is also used.  Debug writes an amount of
bytes equal to:  BX:CX in length.  In other words, BX and CX
combined create a 32bit number which is the length.  The saving
is started from DS:IP or CS:IP, I can't remember.

Fiddle with it, you'll figure it out easily enough.


Mike A. Harris        |             http://blackwidow.saultc.on.ca/~mharris
Computer Consultant   |                  Coming soon: dynamic-IP-freedom...
My dynamic address: http://blackwidow.saultc.on.ca/~mharris/ip-address.html
mailto:mharris AT blackwidow DOT saultc DOT on DOT ca

    Caldera sues Microsoft - Visit Caldera's website: www.caldera.com

- Raw text -