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

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

16 bit code

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

Contents

  16 bit code "Bill Cunningham" <nospam@nspam.invalid> - 2016-11-26 16:34 -0500
    Re: 16 bit code Harry Potter <rose.joseph12@yahoo.com> - 2016-11-26 14:38 -0800
      Re: 16 bit code Harry Potter <rose.joseph12@yahoo.com> - 2016-11-26 14:40 -0800
    Re: 16 bit code rridge@csclub.uwaterloo.ca (Ross Ridge) - 2016-11-26 22:58 +0000
      Re: 16 bit code pete@nospam.demon.co.uk - 2016-11-27 07:15 +0000
      Re: 16 bit code rridge@csclub.uwaterloo.ca (Ross Ridge) - 2016-11-27 20:59 +0000
    Re: 16 bit code Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-11-26 20:08 -0500
    Re: 16 bit code "R.Wieser" <address@not.available> - 2016-11-27 09:38 +0100
      Re: 16 bit code "Bill Cunningham" <nospam@nspam.invalid> - 2016-11-27 14:37 -0500
        Re: 16 bit code "R.Wieser" <address@not.available> - 2016-11-27 21:42 +0100
        Re: 16 bit code Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-11-27 21:20 -0500
      Re: 16 bit code "Bill Cunningham" <nospam@nspam.invalid> - 2016-11-27 14:47 -0500
        Re: 16 bit code "R.Wieser" <address@not.available> - 2016-11-27 21:59 +0100
          Re: 16 bit code "Bill Cunningham" <nospam@nspam.invalid> - 2016-11-27 16:40 -0500
            Re: 16 bit code "R.Wieser" <address@not.available> - 2016-11-28 08:34 +0100
          Re: 16 bit code rugxulo@gmail.com - 2016-11-27 14:08 -0800
            Re: 16 bit code "Bill Cunningham" <nospam@nspam.invalid> - 2016-11-27 17:47 -0500
              Re: 16 bit code "Bill Cunningham" <nospam@nspam.invalid> - 2016-11-27 17:49 -0500
        Re: 16 bit code Jim Leonard <MobyGamer@gmail.com> - 2017-01-04 11:05 -0800

#2322 — 16 bit code

    This is a disasssembly of a driver code. The ext was .sys. Which is DOS 
is probably always a driver. Does anyone know what it's saying. There's no 
ints called. This isn't source code. Maybe you can't get that from a 
disassembly.



210D:0100 0F            DB 0F
210D:0101 00B98AFF      ADD [BX+DI+FF8A],BH
210D:0105 F3            REPZ
210D:0106 AE            SCASB
210D:0107 47            INC DI
210D:0108 61            DB 61
210D:0109 031F          ADD BX,[BX]
210D:010B 8BC3          MOV AX,BX
210D:010D 48            DEC AX
210D:010E 12B1048B      ADC DH,[BX+DI+8B04]
210D:0112 C6F70A        MOV BH,0A
210D:0115 0AD0          OR DL,AL
210D:0117 D348DA        ROR WORD PTR [BX+SI-26],CL
210D:011A 2BD0          SUB DX,AX
210D:011C 3400          XOR AL,00
210D:011E FC            CLD
210D:011F 2000          AND [BX+SI],AL


nasm would asemble this.

Bill

[toc] | [next] | [standalone]

#2323

On Saturday, November 26, 2016 at 4:34:43 PM UTC-5, Bill Cunningham wrote:
> This is a disasssembly of a driver code. The ext was .sys. Which is DOS 
> is probably always a driver. Does anyone know what it's saying. There's no 
> ints called. This isn't source code. Maybe you can't get that from a 
> disassembly.
> 
> 
> 
> 210D:0100 0F            DB 0F
> 210D:0101 00B98AFF      ADD [BX+DI+FF8A],BH
> 210D:0105 F3            REPZ
> 210D:0106 AE            SCASB
> 210D:0107 47            INC DI
> 210D:0108 61            DB 61
> 210D:0109 031F          ADD BX,[BX]
> 210D:010B 8BC3          MOV AX,BX
> 210D:010D 48            DEC AX
> 210D:010E 12B1048B      ADC DH,[BX+DI+8B04]
> 210D:0112 C6F70A        MOV BH,0A
> 210D:0115 0AD0          OR DL,AL
> 210D:0117 D348DA        ROR WORD PTR [BX+SI-26],CL
> 210D:011A 2BD0          SUB DX,AX
> 210D:011C 3400          XOR AL,00
> 210D:011E FC            CLD
> 210D:011F 2000          AND [BX+SI],AL
> 
> 
> nasm would asemble this.
> 
> Bill

This looks like 386 code to me.  From my experience, 0Fh is a prefix on the 286+'s to use an extended opcode.  Try NASM.  I think it contains a 32-bit disassembler.  :)

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

#2324

On Saturday, November 26, 2016 at 5:38:56 PM UTC-5, Harry Potter wrote:
> Try NASM.  I think it contains a 32-bit disassembler.  :)

My error.  You already have NASM.  :)

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

#2325

Bill Cunningham <nospam@nspam.invalid> wrote:
>    This is a disasssembly of a driver code. The ext was .sys. Which is DOS 
>is probably always a driver. Does anyone know what it's saying. There's no 
>ints called. This isn't source code. Maybe you can't get that from a 
>disassembly.

It's not valid Intel code, either in 16-bit mode or 32-bit mode.
It's probably some sort of data.

Note that you can give any file an extension of .SYS, so it's not
necessarily an MS-DOS device driver just because it has that extension.

					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]

#2327

On 26th Nov 2016 at 22:58 "Ross Ridge" <rridge@csclub.uwaterloo.ca> wrote:

> Bill Cunningham <nospam@nspam.invalid> wrote:
> >    This is a disasssembly of a driver code. The ext was .sys. Which is DOS
> >is probably always a driver. Does anyone know what it's saying. There's no
> >ints called. This isn't source code. Maybe you can't get that from a
> >disassembly.
> 
> It's not valid Intel code, either in 16-bit mode or 32-bit mode.
> It's probably some sort of data.
> 
> Note that you can give any file an extension of .SYS, so it's not
> necessarily an MS-DOS device driver just because it has that extension.
> 
>                                         Ross Ridge

Agreed - CONFIG.SYS is no device driver!  This certainly doesn't look 
like any normal sort of DOS device driver, which would start with 
FFFFFFFF, e.g.

        org     0

;start of header

        dd      -1               ; link to next driver - set by DOS
        dw      ?                ; device attribute
        dw      offset STRATEGY  ; pointer to strategy routine
        dw      offset INTERRUPT ; pointer to interrupt routine
        db      'ABCDEFGH'       ; 8 bytes for device name
RHaddr  dw      ?, ?             ; storage for request header address
        etc...

For example, this is what the start of ANSI.SYS looks like (DOS 6.22):

C:\DOS>debug ansi.sys
-d
0C1D:0100  FF FF FF FF 53 C0 C1 00-CC 00 43 4F 4E 20 20 20   ....S.....CON   
0C1D:0110  20 20 5E 10 70 01 70 01-70 01 83 03 43 04 70 01     ^.p.p.p...C.p.
0C1D:0120  D7 04 03 05 03 05 70 01-70 01 70 01 70 01 70 01   ......p.p.p.p.p.
0C1D:0130  70 01 70 01 70 01 70 01-27 0A 41 6B 06 42 73 06   p.p.p.p.'.Ak.Bs.
0C1D:0140  43 5B 06 44 66 06 48 2D-06 4A E7 06 4B 24 07 52   C[.Df.H-.J..K$.R
0C1D:0150  5D 07 66 2D 06 68 64 07-6C 60 07 6D B7 06 6E 38   ].f-.hd.l`.m..n8
0C1D:0160  07 70 A1 07 71 88 06 73-A5 06 75 AE 06 00 00 00   .p..q..s..u.....
0C1D:0170  07 01 FF 08 04 F8 01 05-FF 80 07 F8 70 08 88 00   ............p...
-q

So your code looks to me like it's some sort of data file used by some 
proprietary application.

Pete
-- 
Believe those who are seeking the truth.
Doubt those who find it.  -  André Gide

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

#2333

Bill Cunningham <nospam@nspam.invalid> wrote:
>    This is a disasssembly of a driver code. The ext was .sys. Which is DOS 
>is probably always a driver. Does anyone know what it's saying. There's no 
>ints called. This isn't source code. Maybe you can't get that from a 
>disassembly.

Ross Ridge <rridge@csclub.uwaterloo.ca> wrote:
>It's not valid Intel code, either in 16-bit mode or 32-bit mode.
>It's probably some sort of data.

I think I figured out what it is.  As it happens, I ran DEBUG under
MS-DOS 6.22 (running in a VM) and saw the exact same disassembly despite
the fact that I didn't give it a file name to load, let alone that of
the file you're trying to disassemble.  That means the "code" that I
disassembled is just whatever happened to be left in memory by whatever
else was using it before.

That "code" is probably a transient data buffer allocated by COMMAND.COM,
which freed it (but didn't erase it) before running DEBUG (or any other
command).  That frees up space for the program being run.

I'm guessing your problem is either DEBUG wasn't able to load your driver,
or you didn't actually specify a file on the command line for it to load.

					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]

#2326

On Sat, 26 Nov 2016 16:34:41 -0500
"Bill Cunningham" <nospam@nspam.invalid> wrote:

(I added alt.lang.asm.  You could also try comp.lang.asm.x86.)

>     This is a disasssembly of a driver code. The ext was .sys. Which
> is DOS is probably always a driver. Does anyone know what it's
> saying. There's no ints called. This isn't source code. Maybe you
> can't get that from a disassembly.
> 
> 
> 
> 210D:0100 0F            DB 0F
> 210D:0101 00B98AFF      ADD [BX+DI+FF8A],BH
> 210D:0105 F3            REPZ
> 210D:0106 AE            SCASB
> 210D:0107 47            INC DI
> 210D:0108 61            DB 61
> 210D:0109 031F          ADD BX,[BX]
> 210D:010B 8BC3          MOV AX,BX
> 210D:010D 48            DEC AX
> 210D:010E 12B1048B      ADC DH,[BX+DI+8B04]
> 210D:0112 C6F70A        MOV BH,0A
> 210D:0115 0AD0          OR DL,AL
> 210D:0117 D348DA        ROR WORD PTR [BX+SI-26],CL
> 210D:011A 2BD0          SUB DX,AX
> 210D:011C 3400          XOR AL,00
> 210D:011E FC            CLD
> 210D:011F 2000          AND [BX+SI],AL
> 
> 
> nasm would asemble this.

Well, it probably wouldn't assemble it as it is.


A hex dump doesn't reveal any text data: (sorry, line wraps)

00000000  0f 00 b9 8a ff f3 ae 47  61 03 1f 8b c3 48 12 b1
|..¹.ÿó®Ga...ÃH.±|
00000010  04 8b c6 f7 0a 0a d0 d3  48 da 2b d0 34 00 fc 20
|..Æ÷..ÐÓHÚ+Ð4.ü |
00000020 00
|.|


ndisasm -b16

00000000  0F                db 0x0f
00000001  00B98AFF          add [bx+di-0x76],bh
00000005  F3AE              repe scasb
00000007  47                inc di
00000008  61                popaw
00000009  031F              add bx,[bx]
0000000B  8BC3              mov ax,bx
0000000D  48                dec ax
0000000E  12B1048B          adc dh,[bx+di-0x74fc]
00000012  C6                db 0xc6
00000013  F7                db 0xf7
00000014  0A0A              or cl,[bp+si]
00000016  D0D3              rcl bl,1
00000018  48                dec ax
00000019  DA2B              fisubr dword [bp+di]
0000001B  D0                db 0xd0
0000001C  3400              xor al,0x0
0000001E  FC                cld
0000001F  2000              and [bx+si],al

Of course, 0F is not a valid instruction anymore, and so is not a valid
code entry point, unless it's actually 8086 code which had the obsolete
"POP CS" instruction, or some of the "undocumented" 0x0F instructions
that have existed (IBTS, XBTS, UMOV, CMOV, LOADALL, UDx, RDPMC, 286
hang, SETO, PFCMPGE, etc), or 0x0F instructions for the V20 processor,
or 0x0F escape instructions for various emulators, like Virtual PC,
etc.  However, AFAIK, the undocumented 0x0F instructions and escapes,
all seem to be followed by a value other than zero ...

The single math coprocessor instruction FISUBR in the middle of a bunch
of regular instruction, would seem to indicate that this might just be
a bunch of data, junk, or padding, but that could be because NDISASM
doesn't like the 0xC6 MOV encoding.  Of course, this "break" or
dis-jointed code in the middle, might also seem to imply that there is
some data stored in-between two code pieces?

If we skip a couple of bytes, the start looks better, but we still
don't know what is correct:

...
00000002  B98AFF            mov cx,0xff8a
00000005  F3AE              repe scasb
...

It could very well start with an 8086 POP CS:

00000000  0F                pop cs              ; 8086 only
00000001  00B98AFF          add [bx+di-0x76],bh
00000005  F3AE              repe scasb
...

NDISASM doesn't seem to like the 0xC6.  Perhaps, it's not valid for
16-bit code?  The C6 MOV instruction is C6 /0, and will encode as C6 C7
0A.  Apparently, that's not a valid instruction encoding with F7
instead of C7.  Although, it may execute on some earlier processors, as
it could be undocumented form.

If we correct the three bytes for the 0xC6 MOV that NDISASM doesn't
like:

00000000  0F                pop cs
00000001  00B98AFF          add [bx+di-0x76],bh
00000005  F3AE              repe scasb
00000007  47                inc di
00000008  61                popaw
00000009  031F              add bx,[bx]
0000000B  8BC3              mov ax,bx
0000000D  48                dec ax
0000000E  12B1048B          adc dh,[bx+di-0x74fc]
00000012  C6C70A            mov bh,0xa
00000015  0AD0              or dl,al
00000017  D348DA            ror word [bx+si-0x26],cl
0000001A  2BD0              sub dx,ax
0000001C  3400              xor al,0x0
0000001E  FC                cld
0000001F  2000              and [bx+si],al

Now, it doesn't look too bad.  The FISUBR is gone.  The address in the
ADC instruction seems odd though.  Although, it still appears to be
"junk" code, or perhaps compiler generated, as it's not obvious that
it's doing anything useful.

It does look slightly better as 32-bit, with 0xC6 MOV fixed, but it
still has the 0F.

...
00000002  B98AFF            mov cx,0xff8a
00000005  F3AE              repe scasb
00000007  47                inc di
00000008  61                popaw
00000009  031F              add bx,[bx]
0000000B  8BC3              mov ax,bx
0000000D  48                dec ax
0000000E  12B1048B          adc dh,[bx+di-0x74fc]
00000012  C6C70A            mov bh,0xa
00000015  0AD0              or dl,al
00000017  D348DA            ror dword [eax-0x26],cl
0000001A  2BD0              sub edx,eax
0000001C  3400              xor al,0x0
0000001E  FC                cld
0000001F  2000              and [eax],al

If you want to correctly disassemble a piece of code, you need to have
actually stepped through it or disassembled it from a known code entry
point.  The reason you need to know the entry point is that the x86
instruction set is full, i.e., any byte could be code or data.  So,
there is really nothing which can indicate whether you're looking at
data or code.


Anyway, my guess is it's junk or data, but I've also seen compiled C
code that looks similarly useless.  So, maybe it's compiled C or
Pascal, etc.


Rod Pemberton

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

#2328

Bill,

> This is a disasssembly of a driver code. The ext was .sys

Bill, a suggestion: either upload the driver you're tryint to disassemble to
somewhere we can download it from, or download a driver from the web and
post the URL to it.   That way we have a bit more to work with than just the
few lines of code and/or data you're posting, and can possibly even tell you
what the file actually is used for (how to look at it).

As for that code ?   As I have mentioned before (and Pete now also has
done), a DOS device driver (normally) starts with the first four bytes being
FF.  If you do not see those its highly likely you're not looking at a DOS
mode/style device driver.

Regards,
Rudy Wieser


-- Origional message:
Bill Cunningham <nospam@nspam.invalid> schreef in berichtnieuws
o1cv35$n1s$1@dont-email.me...
>     This is a disasssembly of a driver code. The ext was .sys. Which is
DOS
> is probably always a driver. Does anyone know what it's saying. There's no
> ints called. This isn't source code. Maybe you can't get that from a
> disassembly.
>
>
>
> 210D:0100 0F            DB 0F
> 210D:0101 00B98AFF      ADD [BX+DI+FF8A],BH
> 210D:0105 F3            REPZ
> 210D:0106 AE            SCASB
> 210D:0107 47            INC DI
> 210D:0108 61            DB 61
> 210D:0109 031F          ADD BX,[BX]
> 210D:010B 8BC3          MOV AX,BX
> 210D:010D 48            DEC AX
> 210D:010E 12B1048B      ADC DH,[BX+DI+8B04]
> 210D:0112 C6F70A        MOV BH,0A
> 210D:0115 0AD0          OR DL,AL
> 210D:0117 D348DA        ROR WORD PTR [BX+SI-26],CL
> 210D:011A 2BD0          SUB DX,AX
> 210D:011C 3400          XOR AL,00
> 210D:011E FC            CLD
> 210D:011F 2000          AND [BX+SI],AL
>
>
> nasm would asemble this.
>
> Bill
>
>

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

#2329

"R.Wieser" <address@not.available> wrote in message 
news:583a9ad7$0$21545$e4fe514c@news.xs4all.nl...
> Bill,
>
>> This is a disasssembly of a driver code. The ext was .sys
>
> Bill, a suggestion: either upload the driver you're tryint to disassemble 
> to
> somewhere we can download it from, or download a driver from the web and
> post the URL to it.   That way we have a bit more to work with than just 
> the
> few lines of code and/or data you're posting, and can possibly even tell 
> you
> what the file actually is used for (how to look at it).
>
> As for that code ?   As I have mentioned before (and Pete now also has
> done), a DOS device driver (normally) starts with the first four bytes 
> being
> FF.  If you do not see those its highly likely you're not looking at a DOS
> mode/style device driver.
>
> Regards,
> Rudy Wieser

    Ok I see. Now if I remember right I booted into DOS and the CDROM driver 
was not cdrom.sys, but indeed oakcdrom.sys. Tht came with win98. So that 
would be 32 bit. OK cdrom.sys might be better to try with 16 bit code.

Bill

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

#2331

Bill,

>     Ok I see. Now if I remember right I booted into DOS and the
> CDROM driver was not cdrom.sys, but indeed oakcdrom.sys.
> Tht came with win98. So that would be 32 bit.

The oakcdrom.sys on my Windows 98se (under \Windows\command\ebd) is in fact
a simple 16-bit EXE style executable (recognisable by its first to bytes
being 'MZ', and no 'PE' anywhere near).

Regards,
Rudy Wieser


-- Origional message:
Bill Cunningham <nospam@nspam.invalid> schreef in berichtnieuws
o1fcjg$ht2$1@dont-email.me...
>
> "R.Wieser" <address@not.available> wrote in message
> news:583a9ad7$0$21545$e4fe514c@news.xs4all.nl...
> > Bill,
> >
> >> This is a disasssembly of a driver code. The ext was .sys
> >
> > Bill, a suggestion: either upload the driver you're tryint to
disassemble
> > to
> > somewhere we can download it from, or download a driver from the web and
> > post the URL to it.   That way we have a bit more to work with than just
> > the
> > few lines of code and/or data you're posting, and can possibly even tell
> > you
> > what the file actually is used for (how to look at it).
> >
> > As for that code ?   As I have mentioned before (and Pete now also has
> > done), a DOS device driver (normally) starts with the first four bytes
> > being
> > FF.  If you do not see those its highly likely you're not looking at a
DOS
> > mode/style device driver.
> >
> > Regards,
> > Rudy Wieser
>
>     Ok I see. Now if I remember right I booted into DOS and the CDROM
driver
> was not cdrom.sys, but indeed oakcdrom.sys. Tht came with win98. So that
> would be 32 bit. OK cdrom.sys might be better to try with 16 bit code.
>
> Bill
>
>

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

#2338

On Sun, 27 Nov 2016 14:37:35 -0500
"Bill Cunningham" <nospam@nspam.invalid> wrote:

> oakcdrom.sys. Tht came with win98. So that would be 32 bit.

No.

Windows 98/SE starts with 16-bit MS-DOS which has been modified to work
with Windows 98/SE.  This DOS uses some undocumented M$ APIs to
transfer control to 32-bit Windows.  Windows has it's own device drivers
that can't be used with DOS.  So, any standalone device driver is going
to be 16-bit DOS code.

AFAIK, there is no 32-bit device driver format for DOS.  Although, in
theory, it's possible to have 32-bit drivers for DOS, which would work
with 32-bit DPMI apps.  These drivers, of course, likely wouldn't be
coded to work with regular 16-bit DOS apps.  The DPMI host and XMS
drivers would need to support some additional protocols, like GEMMIS.
This might also be possible with a VCPI host.  The DPMI protocols were
originally developed by M$ for a 32-bit DOS, but they killed that DOS
before it was ever released, and went with developing Windows.

Albeit, at this point in time, it appears no one is going to develop a
32-bit DOS.  FreeDOS-32 was a decent attempt while it lasted.


Rod Pemberton

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

#2330

Now does this look more like it. 16 bit code? I don't see any 32 bit 
registers there. That I know of.

Bill

1947:0100 0F            DB 0F
1947:0101 00B98AFF      ADD [BX+DI+FF8A],BH
1947:0105 F3            REPZ
1947:0106 AE            SCASB
1947:0107 47            INC DI
1947:0108 61            DB 61
1947:0109 031F          ADD BX,[BX]
1947:010B 8BC3          MOV AX,BX
1947:010D 48            DEC AX
1947:010E 12B1048B      ADC DH,[BX+DI+8B04]
1947:0112 C6F70A        MOV BH,0A
1947:0115 0AD0          OR DL,AL
1947:0117 D348DA        ROR WORD PTR [BX+SI-26],CL
1947:011A 2BD0          SUB DX,AX
1947:011C 3400          XOR AL,00
1947:011E 36            SS:
1947:011F 1900          SBB [BX+SI],AX

cdrom.sys

Bill

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

#2332

Bill,

> Now does this look more like it.

Not really I'm afraid.   There are a a number of commands in there that
simply do not make any sense.  Like the one at 1947:0101, which has BX in
its target and BH in its source, together with a negative offset.   And
neither of the registers (BX, DI) are initialised yet.

> I don't see any 32 bit registers there.

And you never will, as DOS-es debug.exe does not know them, and therefore
can't display them.   Instead you will see DB lines appear (like the one at
1947:0100) which indicate an unknown (for debug.exe) machinecode command.
Some of those DB commands are prefixes, altering the size of a register
(from BX to EBX perhaps).

Regards,
Rudy Wieser


-- Origional message:
Bill Cunningham <nospam@nspam.invalid> schreef in berichtnieuws
o1fd5h$kjt$1@dont-email.me...
>
> Now does this look more like it. 16 bit code? I don't see any 32 bit
> registers there. That I know of.
>
> Bill
>
> 1947:0100 0F            DB 0F
> 1947:0101 00B98AFF      ADD [BX+DI+FF8A],BH
> 1947:0105 F3            REPZ
> 1947:0106 AE            SCASB
> 1947:0107 47            INC DI
> 1947:0108 61            DB 61
> 1947:0109 031F          ADD BX,[BX]
> 1947:010B 8BC3          MOV AX,BX
> 1947:010D 48            DEC AX
> 1947:010E 12B1048B      ADC DH,[BX+DI+8B04]
> 1947:0112 C6F70A        MOV BH,0A
> 1947:0115 0AD0          OR DL,AL
> 1947:0117 D348DA        ROR WORD PTR [BX+SI-26],CL
> 1947:011A 2BD0          SUB DX,AX
> 1947:011C 3400          XOR AL,00
> 1947:011E 36            SS:
> 1947:011F 1900          SBB [BX+SI],AX
>
> cdrom.sys
>
> Bill

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

#2334

"R.Wieser" <address@not.available> wrote in message 
news:583b4895$0$21418$e4fe514c@news.xs4all.nl...
> Bill,
>
>> Now does this look more like it.
>
> Not really I'm afraid.   There are a a number of commands in there that
> simply do not make any sense.  Like the one at 1947:0101, which has BX in
> its target and BH in its source, together with a negative offset.   And
> neither of the registers (BX, DI) are initialised yet.
>
>> I don't see any 32 bit registers there.
>
> And you never will, as DOS-es debug.exe does not know them, and therefore
> can't display them.   Instead you will see DB lines appear (like the one 
> at
> 1947:0100) which indicate an unknown (for debug.exe) machinecode command.
> Some of those DB commands are prefixes, altering the size of a register
> (from BX to EBX perhaps).
>
> Regards,
> Rudy Wieser
>
>
> -- Origional message:
> Bill Cunningham <nospam@nspam.invalid> schreef in berichtnieuws
> o1fd5h$kjt$1@dont-email.me...
>>
>> Now does this look more like it. 16 bit code? I don't see any 32 bit
>> registers there. That I know of.
>>
>> Bill
>>
>> 1947:0100 0F            DB 0F
>> 1947:0101 00B98AFF      ADD [BX+DI+FF8A],BH
>> 1947:0105 F3            REPZ
>> 1947:0106 AE            SCASB
>> 1947:0107 47            INC DI
>> 1947:0108 61            DB 61
>> 1947:0109 031F          ADD BX,[BX]
>> 1947:010B 8BC3          MOV AX,BX
>> 1947:010D 48            DEC AX
>> 1947:010E 12B1048B      ADC DH,[BX+DI+8B04]
>> 1947:0112 C6F70A        MOV BH,0A
>> 1947:0115 0AD0          OR DL,AL
>> 1947:0117 D348DA        ROR WORD PTR [BX+SI-26],CL
>> 1947:011A 2BD0          SUB DX,AX
>> 1947:011C 3400          XOR AL,00
>> 1947:011E 36            SS:
>> 1947:011F 1900          SBB [BX+SI],AX
>>
>> cdrom.sys

    OK I used ndisasm and no switches to see if anything 32 bit might pop 
up. Well there was a tremendous difference. Debug.exe seems to be ok for 
manually changing values in registers and moving them, but doesn't 
unassemble very good.
    A hexdump says this type of file is MZ. Now I have heard of NE files, 
but MZ must be an older file format. And strings in the dump say, "CDDRVR" 
and indictate MS ownership.

Bill

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

#2339

Bill,

> Debug.exe seems to be ok for manually changing values in
> registers and moving them, but doesn't unassemble very good.

debug.exe was ment as a minimal *debugging* tool, and as such does its work
quite well (even allowing you to execute part of the code, not stepping into
routines, and setting breakpoints).   It was never ment as a *disassembling*
tool.

> A hexdump says this type of file is MZ. Now I have heard
> of NE files, but MZ must be an older file format.

Not exactly.  *all* .EXE files start with MZ.  That part can than be
followed by either an NE (New Executable) or PE (Portable Executable)
executable block (when either exists the MZ is normally nothing than a "you
can't run this in DOS" (small) bit of code).

By the way: PE style files are (pretty much) the successor of NE style
files.

Regards,
Rudy Wieser


-- Origional message:
Bill Cunningham <nospam@nspam.invalid> schreef in berichtnieuws
o1fjq2$ema$1@dont-email.me...
>
> "R.Wieser" <address@not.available> wrote in message
> news:583b4895$0$21418$e4fe514c@news.xs4all.nl...
> > Bill,
> >
> >> Now does this look more like it.
> >
> > Not really I'm afraid.   There are a a number of commands in there that
> > simply do not make any sense.  Like the one at 1947:0101, which has BX
in
> > its target and BH in its source, together with a negative offset.   And
> > neither of the registers (BX, DI) are initialised yet.
> >
> >> I don't see any 32 bit registers there.
> >
> > And you never will, as DOS-es debug.exe does not know them, and
therefore
> > can't display them.   Instead you will see DB lines appear (like the one
> > at
> > 1947:0100) which indicate an unknown (for debug.exe) machinecode
command.
> > Some of those DB commands are prefixes, altering the size of a register
> > (from BX to EBX perhaps).
> >
> > Regards,
> > Rudy Wieser
> >
....
>
>     OK I used ndisasm and no switches to see if anything 32 bit might pop
> up. Well there was a tremendous difference. Debug.exe seems to be ok for
> manually changing values in registers and moving them, but doesn't
> unassemble very good.
>     A hexdump says this type of file is MZ. Now I have heard of NE files,
> but MZ must be an older file format. And strings in the dump say, "CDDRVR"
> and indictate MS ownership.
>
> Bill
>
>

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

#2335

Hi,

On Sunday, November 27, 2016 at 2:56:54 PM UTC-6, R.Wieser wrote:
> 
> > I don't see any 32 bit registers there.
> 
> And you never will, as DOS-es debug.exe does not know them, and therefore
> can't display them.

Somewhat pointless nitpicking here, but while that's true for MS-DOS
(and presumably PC-DOS), it's not true for DR-DOS or FreeDOS. Not sure
about others as I don't have every variation under the sun (e.g. ROM-DOS
or PTS-DOS).

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

#2336

<rugxulo@gmail.com> wrote in message 
news:816fdd52-3f86-4d64-8c54-1d8686571d43@googlegroups.com...

> Somewhat pointless nitpicking here, but while that's true for MS-DOS
> (and presumably PC-DOS), it's not true for DR-DOS or FreeDOS. Not sure
> about others as I don't have every variation under the sun (e.g. ROM-DOS
> or PTS-DOS).

    RDOS. And versions dealing with DEC machines like PDPs. Was debug there? 
Probably not.

Bill

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

#2337

"Bill Cunningham" <nospam@nspam.invalid> wrote in message 
news:o1fnoc$sl2$1@dont-email.me...
>
> <rugxulo@gmail.com> wrote in message 
> news:816fdd52-3f86-4d64-8c54-1d8686571d43@googlegroups.com...
>
>> Somewhat pointless nitpicking here, but while that's true for MS-DOS
>> (and presumably PC-DOS), it's not true for DR-DOS or FreeDOS. Not sure
>> about others as I don't have every variation under the sun (e.g. ROM-DOS
>> or PTS-DOS).
>
>    RDOS. And versions dealing with DEC machines like PDPs. Was debug 
> there? Probably not.

    DOSes. 6.2x and DOS 7 Is what I am interested in.

Bill

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

#2375

On Sunday, November 27, 2016 at 1:47:10 PM UTC-6, Bill Cunningham wrote:
> cdrom.sys

If you post a link to the actual file, I can provide disassembly of the driver (if it really is a .SYS driver that follows conventions).

[toc] | [prev] | [standalone]

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

csiph-web