Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.msdos.programmer > #661 > unrolled thread

Accessing the command line options in assembly

Back to article view | Back to comp.os.msdos.programmer

Contents

  Accessing the command line options in assembly Ruud <Ruud.Baltissen@apg.nl> - 2012-07-18 22:48 -0700
    Re: Accessing the command line options in assembly Ruud <Ruud.Baltissen@apg.nl> - 2012-07-18 23:03 -0700
      Re: Accessing the command line options in assembly Czerno <czerno@czerno.tk.invalid> - 2012-07-19 15:08 +0000
        Re: Accessing the command line options in assembly "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-07-19 15:13 -0400
          Re: Accessing the command line options in assembly Czerno <czerno@czerno.tk.invalid> - 2012-07-19 21:35 +0000
      Re: Accessing the command line options in assembly Ross Ridge <rridge@csclub.uwaterloo.ca> - 2012-07-19 13:07 -0400
        Re: Accessing the command line options in assembly Ruud Baltissen <rbaltissen@gmail.com> - 2012-08-02 12:53 -0700
          Re: Accessing the command line options in assembly Czerno <czerno@czerno.tk.invalid> - 2012-08-03 08:47 +0000
    Re: Accessing the command line options in assembly "R.Wieser" <address@not.available> - 2012-07-19 19:06 +0200
    Re: Accessing the command line options in assembly "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-07-19 15:14 -0400
    Re: Accessing the command line options in assembly Dirk Wolfgang Glomp <freecrac@web.de> - 2012-07-20 08:44 +0200
      Re: Accessing the command line options in assembly Czerno <czerno@czerno.tk.invalid> - 2012-07-20 09:36 +0000
        Re: Accessing the command line options in assembly Dirk Wolfgang Glomp <freecrac@web.de> - 2012-07-25 08:23 +0200

#661 — Accessing the command line options in assembly

Hallo allemaal,


This thread is related to my previous one, "Loading DOS high on a XT".
I use a driver, USE!UMBS.SYS, to make the UMB memory available. You
have to tell it what ranges are available. Unfortunately this is
hardcoded an you have to use DEBUG to change the settings. USE!
UMBS.SYS comes with the sources so I got the idea to alter the program
so it accepts command line options as well. The problem: I haven't any
idea how to do that :(

I did some googling but the nearest I could find:
http://maven.smith.edu/~thiebaut/ArtOfAssembly/CH13/CH13-9.html

Pointers to other URLs would be appreciated highly!
Thank you very much in advance!


Groetjes, Ruud Baltissen
www.Baltissen.org

[toc] | [next] | [standalone]

#662

> The problem: I haven't any idea how to do that :(

Oops, I wasn't precise enough. The article mentions where I can find
the commnad lin in memory, PSP:080h to be precise. But this is for DOS
programs, certainly COMs and maybe EXE. But now it is CONFIG.SYS that
does the job and USE!UMBS.SYS is loaded from address 0, the sources
say "org 0h", so where can I find the command line now?

Groetjes, Ruud Baltissen
www.Baltissen.org

[toc] | [prev] | [next] | [standalone]

#663

Ruud <Ruud.Baltissen@apg.nl> wrote:

>> The problem: I haven't any idea how to do that :(
> 
> Oops, I wasn't precise enough. The article mentions where I 
can find
> the commnad lin in memory, PSP:080h to be precise. 

You need to look-up a DOS programming reference to at least get 
an idea of the device driver interface. If you do not have a 
book, you might want to seek R. Brown's "interrupt list" : 
lookup entries such as "device driver" "request header"...

But, before or at the same time that you'll be doing the above 
suggested homework, try the following, it may solve your 
original problem :

In a previous article you wrote :
"I use a driver, USE!UMBS.SYS, to make the UMB memory 
available."

Fetch "HIRAM" instead from online Freeware/shareware 
repositories (Grabo mirrors). I think it works on a 8086, and it   
allows specifying the addresses of available blocks on its 
command line.

HTH

-- 
Czerno

[toc] | [prev] | [next] | [standalone]

#666

"Czerno" <czerno@czerno.tk.invalid> wrote in message
news:XnFA095AE5FBA677It7c80ztk1@193.252.117.183...
> Ruud <Ruud.Baltissen@apg.nl> wrote:
...

> In a previous article you wrote :
> "I use a driver, USE!UMBS.SYS, to make the UMB memory
> available."
>
> Fetch "HIRAM" instead from online Freeware/shareware
> repositories (Grabo mirrors). I think it works on a 8086, and it
> allows specifying the addresses of available blocks on its
> command line.
>

... Garbo ...

No, I'm not seeing it on Garbo mirrors as indexed by Yahoo and Google.


It's likely the HIRAM.ZIP here is the one you've mentioned...
http://www.uwe-sieber.de/util_e.html

I also found a different HIRAM.ZIP here...
http://www.mmnt.net/db/0/12/sharon.esrac.ele.tue.nl/pub/auto7p/


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#668

"Rod Pemberton" <do_not_have@notemailnot.cmm> wrote:

> "Czerno" <czerno@czerno.tk.invalid> wrote in message

>> Fetch "HIRAM" instead from online Freeware/shareware
>> repositories (Grabo mirrors). ....

> ... Garbo ...

Indeed. My typo...
 
> No, I'm not seeing it on Garbo mirrors as indexed by Yahoo and 
Google.

> It's likely the HIRAM.ZIP here is the one you've mentioned...
> http://www.uwe-sieber.de/util_e.html

Yes, that's the one I had in mind, I'm pretty sure it will work 
on a 8086 - Ruud (OP) will have to check and confirm it does. 
Sources are provided so it could be adapted ans reassembled if 
it didn't run as such "out of the box"... 
 
> I also found a different HIRAM.ZIP here...
> http://www.mmnt.net/db/0/12/sharon.esrac.ele.tue.nl/pub/auto7p

There are a handful of other possibly suitable drivers floating 
out on the air... Out of my head, UMBDRVR, a good one - but I 
don't think it was open source and unsure it worked on pre-80286 
processors.

Of course it wouldn't be terribly difficult either to roll up 
one's own driver, except for the fact OP is unexperienced in DOS 
programming (not meant to offence)

-- 
Czerno

[toc] | [prev] | [next] | [standalone]

#665

Ruud  <Ruud.Baltissen@apg.nl> wrote:
>Oops, I wasn't precise enough. The article mentions where I can find
>the commnad lin in memory, PSP:080h to be precise. But this is for DOS
>programs, certainly COMs and maybe EXE. But now it is CONFIG.SYS that
>does the job and USE!UMBS.SYS is loaded from address 0, the sources
>say "org 0h", so where can I find the command line now?

It's passed as a far pointer in the init request header.

					Ross Ridge

-- 
 l/  //	  Ross Ridge -- The Great HTMU
[oo][oo]  rridge@csclub.uwaterloo.ca
-()-/()/  http://www.csclub.uwaterloo.ca/~rridge/ 
 db  //	  

[toc] | [prev] | [next] | [standalone]

#704

Hallo allemaal,


I'm sorry for the late reply but I was visiting my relatives in Poland. Most of the time we spent at the place of my mother-in-law and they don't have Internet there.
 

Ross Ridge wrote:
> It's passed as a far pointer in the init request header.

That's correct, but not complete. The so called strategy routine receives this pointer and must take care of storing it. The pointer points to a place which holds various data. Various books and URLs described this data but weird enough only up to byte 17. But it are byte 18..21 of this place that together also form a pointer; in this case it points to the text of the command line. 
In fact just as Rudy Wieser writes, but at that time I didn't know what he meant, sorry!

But so far I haven't found how the line is ended, it certainly isn't a zero. So far I have the idea it is simply the CR and/or LF character. I used an existing UMB driver because I had the sources of it and added a piece of code that would overwrite one of its original starting messages with the line in CONFIG.SYS: USE!UMBS.SYS Testing....
I simply told the program to copy the line until the read value was smaller then 32 (= space). Worked fine!

I hope the above is clear. If not, you can find my email address at my site.


Groetjes, Ruud Baltissen
www.Baltissen.org

[toc] | [prev] | [next] | [standalone]

#707

Ruud Baltissen writes :

> But it are byte 18..21 of this place that together also form a 
pointer; in this case it points to the text of the command line. 

Right. At offset 12h in request block. Is a pointer to the text 
starting after the word DEVICE and subsequent separator, usually 
but not necessarily an = sign. Text is always capitalised by MS-
DOS, but other DOSes may keep original case.

> In fact just as Rudy Wieser writes, but at that time I didn't 
know what he meant, sorry!

> But so far I haven't found how the line is ended, it certainly 
isn't a zero. So far I have the idea it is simply the CR and/or 
LF character.

Various DOSes and even versions of MS-DOS may vary slightly. 
Usually the line end will be signalled by a LF (0Ah) but you'd 
better consider the first of CR, LF, NUL encountered (scanning 
left to right) as marking line end. Besides if it is YOUR 
driver, YOU get to define how to parse the parameters; I usually 
consider the line ended by ANY control byte (ASCII value under 
20h, excepting TAB which I treat as white space). You may also 
wish to allow for one or more comment delimiters (semi colon and 
or hash sign...) and stop processing a line on encountering one.

> I used an existing UMB driver because I had the sources of it 
and added a piece of code that would overwrite one of its 
original starting messages with the line in CONFIG.SYS: USE!
UMBS.SYS Testing....

I think whatever documentation you have been using up to now is 
old and inadequate. IMHO you should get RBIL (Ralf Brown's 
interrupt list, several places online).

Regards

-- 
Czerno

[toc] | [prev] | [next] | [standalone]

#664

Hello Ruud,

According to my documentation a pointer to the full commandline (IIRC
including the path/name of the driver) is provided in bytes 18 thru 21
(formatted as a Seg:Offs) in the request-structure to the 'Initialize'
command (index 0)

Hope that helps,
Rudy Wieser.


-- Origional message:
Ruud <Ruud.Baltissen@apg.nl> schreef in berichtnieuws
5def3ff2-4655-4df6-b641-4ca34af9af32@v9g2000vbc.googlegroups.com...
> Hallo allemaal,
>
>
> This thread is related to my previous one, "Loading DOS high on a XT".
> I use a driver, USE!UMBS.SYS, to make the UMB memory available. You
> have to tell it what ranges are available. Unfortunately this is
> hardcoded an you have to use DEBUG to change the settings. USE!
> UMBS.SYS comes with the sources so I got the idea to alter the program
> so it accepts command line options as well. The problem: I haven't any
> idea how to do that :(
>
> I did some googling but the nearest I could find:
> http://maven.smith.edu/~thiebaut/ArtOfAssembly/CH13/CH13-9.html
>
> Pointers to other URLs would be appreciated highly!
> Thank you very much in advance!
>
>
> Groetjes, Ruud Baltissen
> www.Baltissen.org

[toc] | [prev] | [next] | [standalone]

#667

"Ruud" <Ruud.Baltissen@apg.nl> wrote in message
news:5def3ff2-4655-4df6-b641-4ca34af9af32@v9g2000vbc.googlegroups.com...

> [...] so I got the idea to alter the program
> so it accepts command line options as well.

I'd take the suggestion of finding a version that supports
the command line already.

You might be able to load it from the command line using
devload, ldd, ctload, or loadsys.


David Woodhouse's devload
http://www.infradead.org/devload/

P. Frost's ldd in ddl.zip
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/system/ddl.zip

ctload
http://www.uwe-sieber.de/files/ctload.zip

G. W. Robinson's loadsys
http://www.uwe-sieber.de/files/loadsys.zip


I've listed all I'm aware of, since I don't know which works for
a 286, if any of them ...

Personally, I prefer ldd.  However, some drivers won't load with
it.  For them, I use devload.  Devload is still being maintained too.
I've not tried the other two.

I'm not sure of the primary ftp or websites for the last two.
They are mirrored on Uwe Sieber's UMBPCI page:
http://www.uwe-sieber.de/umbpci_e.html


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#669

Hallo Ruud

Am Wed, 18 Jul 2012 22:48:38 -0700 (PDT) schrieb Ruud:

> Hallo allemaal,
> 
> 
> This thread is related to my previous one, "Loading DOS high on a XT".
> I use a driver, USE!UMBS.SYS, to make the UMB memory available. You
> have to tell it what ranges are available. Unfortunately this is
> hardcoded an you have to use DEBUG to change the settings. USE!
> UMBS.SYS comes with the sources so I got the idea to alter the program
> so it accepts command line options as well. The problem: I haven't any
> idea how to do that :(
> 
> I did some googling but the nearest I could find:
> http://maven.smith.edu/~thiebaut/ArtOfAssembly/CH13/CH13-9.html
> 
> Pointers to other URLs would be appreciated highly!
> Thank you very much in advance!
> 
> 
> Groetjes, Ruud Baltissen
> www.Baltissen.org

To make sure that we can access the command tail of the current executable
we can get the segment address before. (In a situation if the current
process become a child PSP and was started within a parent executable using
INT21h AX=4B00h.)

RBIL->inter61b.zip->Interrup.h
--------D-2162-------------------------------
INT 21 - DOS 3.0+ - GET CURRENT PSP ADDRESS
	AH = 62h
Return: BX = segment of PSP for current process
Notes:	this function does not use any of the DOS-internal stacks and may
	  thus be called at any time, even during another INT 21h call
	the current PSP is not necessarily the caller's PSP
	identical to the undocumented AH=51h
SeeAlso: AH=50h,AH=51h

Dirk

[toc] | [prev] | [next] | [standalone]

#670

Dirk Wolfgang Glomp wrote:

> Hallo Ruud

>> UMBS.SYS comes with the sources so I got the idea to alter 
the program
>> so it accepts command line options as well. The problem: I 
haven't any
>> idea how to do that :(

> To make sure that we can access the command tail of the 
current executable
> we can get the segment address before. 
(...)
> INT 21 - DOS 3.0+ - GET CURRENT PSP ADDRESS
>      AH = 62h

Sorry, have to call nonsense! This above DOES NOT apply to 
Ruud's situation, therefore it is strongly *misleading* ! [FYI, 
during the initialisation phase of drivers, although there 
exists a PSP which belongs to the DOS 'sysinit' process, the 
"command tail" field at PSP:80h is NOT significant].

Regards

-- 
Cz.

[toc] | [prev] | [next] | [standalone]

#676

Am 20 Jul 2012 09:36:02 GMT schrieb Czerno:
> Sorry, have to call nonsense! This above DOES NOT apply to 
> Ruud's situation, therefore it is strongly *misleading* ! [FYI, 
> during the initialisation phase of drivers, although there 
> exists a PSP which belongs to the DOS 'sysinit' process, the 
> "command tail" field at PSP:80h is NOT significant].
> 
> Regards

Ok.

Dirk

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.msdos.programmer

csiph-web