Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to index page
Thread view  Board view
Japheth

Homepage

Germany (South),
23.12.2007, 10:02
 

EDR-DOS bug report (Users)

Post reply

Hello,

I wanted to finish DOS386's FAT+ tests, particularly to get the answer to the question what WinXP "chkdsk /F" does with files > 4 GB on FAT32, but ran in troubles with EDR-DOS (latest WIP). The details:

1. using the FAT+ int 21h, ax=7142 to create a huge file doesn't work as expected. It works for files up to 256 MB - 8 MB on a 6 GB FAT32 partition, but with larger files it fails. My testcase is a simple DEBUG script:

e 180 'xxx.txt',0
a 100
xor cx,cx
mov dx,180
mov ax,3C00     ;create file xxx.txt
int 21
mov bx,ax
mov cx,0
mov dx,1
mov ax,4200     ;grow file to size 1 first
int 21
mov cx,0        ;now use FAT+ function to let it grow beyond ...?
mov si,180
mov dword [si+0],FFFE000   ;this is 256-8 MB (last which works)
mov dword [si+4],0   ;set to 1 for file size >= 4 GB
mov dx,si            ;was it DS:DX or DS:SI?
mov ax,7142
int 21
mov cx,0
mov ah,40       ;write 0 bytes
int 21
mov ah,3E       ;close file
int 21
mov ax,4c00     ;terminate
int 21

r cx 100
r bx 0
n wrlarge.com
w
q

save this script with name WRLARGE.DEB, then run "DEBUG <WRLARGE.DEB" and finally run WRLARGE.COM

2. EDR-DOS is not fully compatible with JLOAD, the XDMA32 JLM is loaded TWICE, although there's just 1 line "DEVICE=JLOAD.EXE XDMA32.DLL" in CONFIG.SYS. Possibly EDR-DOS has a problem with device drivers with a resident size of 0?

3. I tried to mount NTFS and ext3 partitions with Paragon's NDOS.EXE driver. This works fine with MS-DOS 7.1 and FreeDOS 1.0, but with EDR-DOS, I don't get access to these partitions, instead the FAT32 partitions of the first physical disk are "shadowed", so C: and D: are "remounted" as "I:" and "J:".

@rr: is it possible to use another text color for the {code} tag? Dark blue/green would be fine.

---
MS-DOS forever!
rr

Homepage E-mail

Berlin, Germany,
26.12.2007, 13:53

@ Japheth
 

EDR-DOS bug report

Post reply

> @rr: is it possible to use another text color for the {code} tag? Dark
> blue/green would be fine.
Sure, but why? Many people prefer different colors. And I already had dark blue/dark green in the past. Dark blue looked very similar to black. Another survey? ;-)

---
Forum admin
david

26.12.2007, 17:53

@ Japheth
 

EDR-DOS bug report

Post reply

> 3. I tried to mount NTFS and ext3 partitions with Paragon's NDOS.EXE
> driver. This works fine with MS-DOS 7.1 and FreeDOS 1.0, but with EDR-DOS,
> I don't get access to these partitions, instead the FAT32 partitions of the
> first physical disk are "shadowed", so C: and D: are "remounted" as "I:"
> and "J:".
Hello Japheth,

I use IFSDRV on EDR-DOS WIP and I have not any problems to mount ext3 partitions
Yes, FAT32 drives are remounted but works both C: or I: :-D

David
DOS386

05.04.2009, 04:06

@ Japheth
 

EDR-DOS WIP 2009-03-28 released | many BUG's

Post reply

King Udo released a new version of EDR-DOS. There are many (cca 1) new features and many (cca 1'000'000) new and old bugs.

New features:

- Added GetFileInformationByHandle INT $21 AX=$71A6 (interesting see GETFINFO.ASM, bugs see below)

- Added NTLFNFind functions AX=$714E $714F $71A1 - apparently broken

- Added AX=$7143 BL=3/4 NTLFN Set/Get Last Write Time (BL=0/1 broken, horrible BUG)

Bugs:

- The legacy "doesn't-skip-NTLFN-entries-from-SFN-directory-search-BUG" is still in there

- The legacy multiple-slash-problem is still in there (fortunately there is UI21DEB - hack "X" :-) )

- Renaming a file in a subdirectory switches to main (reproductibility is always - if a small special condition (irrelevant according to Cm) is met :lol3:)

- DIR /A doesn't work

- INT $21 / AX=$7142 never pokes flag(C), and fails to return an error on faulty handle, on CL>2 it tries to return an error but fails also here

- INT $21 / AX=$7142 "64-KiB-BUG" is fixed since 2009-Jan version :-)

- GetFileInformationBy handle INT $21 AX=$71A6 never pokes flag(C), returned attributes are garbage ($42 ???), "is supposed to give the ""Unique File Identifier"" of an open file. Until someone can tell me how Windows determines this value, it will be shown as 0 instead" - this is a BUG of course, why not return the cluster number ?

- NTLFNFind functions AX=$714E $714F $71A1 are apparently broken (Kinesics doesn't work anymore, fortunately there is UI21DEB - hack "N" :-) )

- NTLFNPeekAttributes AX=$7143 BL=0 returns flag(C)=1 and AX=1 (!!!) - securely breaks many things (fortunately there is UI21DEB - hack "N" :-) )

oops forgot to retest Japheth's original bug :crying:

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***
ecm

Homepage E-mail

Düsseldorf, Germany,
05.04.2009, 09:51

@ DOS386
 

EDR-DOS WIP 2009-03-28 released | many BUG's

Post reply

> - Added AX=$7143 BL=3/4 LFN Set/Get Last Write Time (BL=0/1 broken,
> horrible BUG)
No, it's documented not to work. Read the documentation. If it returns CF set, ax=0001h then this should be fine for any well-written software. (Even badly written software should recognise that there was an error at all too.)

> - Renaming a file in a subdirectory switches to main (reproductibility is
> always - if a small special condition (irrelevant according to
> Cm) is met :lol3:)
Which condition exactly? And where did I say something about this? I don't know exactly what bug you're talking about here, anyway!

> - GetFileInformationBy handle INT $21 AX=$71A6 never pokes flag(C),
> returned attributes are garbage ($42 ???), "is supposed to give the
> ""Unique File Identifier"" of an open file. Until someone can tell me how
> Windows determines this value, it will be shown as 0 instead" - this is a
> BUG of course, why not return the cluster number ?
Cluster number plus the drive's number, of course. However it would still be quite useless because there's no function the unique file identifier is ever used for. And what to return for files on redirected drives? You can't know the cluster number (or equivalent), and there is no Int2F.11 function to retrieve such a number.

> - LFNFind functions AX=$714E $714F $71A1 are apparently broken (Kinesics
> doesn't work anymore)
Either it doesn't handle the case of SFNs only well, or it gives some weird LFN input which the kernel can't process correctly, or it just starts multiple concurrent searches which isn't supported but currently doesn't return an error either. It's probably worth reporting this to Udo.

> - LFN Get Attributes AX=$7143 BL=0 returns flag(C)=1 and AX=1 (!!!)
What's that surprising/shocking/... about this? This is the MS-DOS 2.x+ way of saying "invalid (sub)function".

> securely breaks many things
Stop using that software, or rewrite it with proper LFN support or none at all.

> oops forgot to retest Japheth's original bug :crying:
Considered creating a new thread?

---
l
DOS386

07.04.2009, 05:39

@ ecm
 

EDR-DOS WIP 2009-03-28 released | many BUG's

Post reply

> No, it's documented not to work. Read the documentation.

The only valid documentation is available at ???

> If it returns CF set, ax=1 then this should be fine for any well-written software.
Feel free to submit a list of "well-written software" :hungry:

GetFileAttributesA proc public uses ebx pName:ptr byte

local   szFile[MAX_PATH]:byte

;--- if a path ends with a '\', skip it. unless it is "\" or "x:\"

                mov             ebx, pName
                invoke  lstrlen, ebx
        .if (eax && (byte ptr [ebx+eax-1] == '\'))
                cmp eax, 2
            jb dontstrip
            cmp byte ptr [ebx+eax-2],':'
            jz dontstrip
                push eax
                invoke lstrcpy, addr szFile, ebx
            pop eax
            lea ebx, szFile
            mov byte ptr [ebx+eax-1],0
        .endif
dontstrip:
        mov     edx, ebx
                mov             ax,7143h
                mov             bl, 00                  ;file attributes
                stc
                int             21h
                jnc             success
                cmp             ax,7100h ; HEH ??? King Udo returns something else here ...
                jnz             error ; BOOM !!!
        mov     ax,4300h
        int     21h
        jc              error
success:
                mov             eax, FILE_ATTRIBUTE_NORMAL
                and             cx, 37h
                jz              @F
        movzx   eax,cx
@@:
done:
                @strace <"GetFileAttributesA(", &pName, ")=", eax>
        ret
error:
                movzx   eax, ax
        invoke  SetLastError,eax
                @mov    eax, -1
        jmp             done
        align   4
       
GetFileAttributesA endp

Apparently DKRNL32 is a poorly-written one :-(

> Even badly written software should recognise that there was an error at all
That's exactly what happens, but it is not useful :-P

> Which condition exactly?

Deleted the useless and never accessed "dot" . and .. "dotdot" entries ;-)

> And where did I say something about this?

Mail.

> don't know exactly what bug you're talking about here
See above

> > - LFN Get Attributes AX=$7143 BL=0 returns flag(C)=1 and AX=1 (!!!)
> What's that surprising/shocking/... about this? This is the MS-DOS 2.x+
> way of saying "invalid (sub)function".
See above, it does break.

> Stop using that software
AKA stop using all software

> or rewrite it with
> proper LFN support [1]
> or
> none at [2]
[2] is preferable from [1] , but I might not apply [2] either since UI21DEB can fix the problem immediately for all NTLFN-aware apps without the need to rewrite or recompile or to have the source at all :clap:

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***
Japheth

Homepage

Germany (South),
07.04.2009, 08:13

@ DOS386
 

EDR-DOS WIP 2009-03-28 released | many BUG's

Post reply

> Apparently DKRNL32 is a poorly-written one :-(
At least it is poorly formatted. However, IMO this is a tiny incompatibility in EDR-DOS, there is nothing wrong with this dkrnl32 code.

---
MS-DOS forever!
ecm

Homepage E-mail

Düsseldorf, Germany,
07.04.2009, 13:16

@ DOS386
 

EDR-DOS WIP 2009-03-28 released | many BUG's

Post reply

> > No, it's documented not to work. Read the documentation.
>
> The only valid documentation is available at ???
Inside the distributed patch or binary ZIP files. Ever downloaded them?

> > If it returns CF set, ax=1 then this should be fine for any well-written
> software.
>
> Feel free to submit a list of "well-written software" :hungry:
Apparently not much.

> Apparently DKRNL32 is a poorly-written one :-(
Yeah.

> Deleted the useless and never accessed "dot" . and ..
> "dotdot" entries ;-)
I still don't understand what you mean by "Renaming a file in a subdirectory switches to main". Did you delete dot and dotdot and then renaming a file in a subdirectory (using 21.56) switches back to the root in EDR-DOS?

> > Stop using that software
>
> AKA stop using all software
There's good old SFN software ;-P

> > or rewrite it with
> > proper LFN support [1]
> > or
> > none at [2]
[3] fake no 21.71 support at all on unsupported subfunctions of EDR-DOS i.e. return CF unchanged, al=0. This might show less ingenious programmers that this function is not supported. (But could break other software.) I'm still of the opinion that you have to expect error code 0001h on LFN (sub)functions as well. It's just what MS-DOS would do if some (say, the SUBST-related) 21.71 functions but not all were supported.

---
l
DOS386

13.04.2009, 09:37

@ ecm
 

EDR-DOS WIP 2009-03-28 released | many BUG's

Post reply

> Inside the distributed patch or binary ZIP files. Ever downloaded them?
Oops ... sorry, boasting with test results, but forgot to download the stuff before :confused:

> I still don't understand what you mean by "Renaming a file in a
> subdirectory switches to main". Did you delete dot and dotdot

YES, using Wde.

> and then renaming a file in a subdirectory (using 21.56)
Using REN

> switches back to the root in EDR-DOS?
YES, a strong sign that EDR-DOS does use the dot's :clap:

> There's good old SFN software

OK.

> [3] fake no 21.71 support at all on unsupported subfunctions of EDR-DOS
> i.e. return CF unchanged, al=0. This might show less ingenious programmers
> that this function is not supported. (But could break other software.)
Works very well for me, and can be switched at any time.

> I'm still of the opinion that you have to expect error code 0001h on LFN
> (sub)functions as well. It's just what MS-DOS would do if some (say, the
> SUBST-related) 21.71 functions but not all were supported.
OK, Japheth isn't and there is again no only valid specification defining how things are supposed to work, as usual :confused: At least I got a "fix" that works for me :-)

> Considered creating a new thread?
Of course NO, just to be prepared to the hypothetical case that someone wants to fix the bugs one day I prefer to bunch them together so they can be found easily :-P

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***
ecm

Homepage E-mail

Düsseldorf, Germany,
13.04.2009, 14:12

@ DOS386
 

EDR-DOS WIP 2009-03-28 released | many BUG's

Post reply

> > [3] fake no 21.71 support at all on unsupported subfunctions of EDR-DOS
> > i.e. return CF unchanged, al=0. This might show less ingenious
> programmers
> > that this function is not supported. (But could break other software.)
>
> Works very well for me, and can be switched at any time.
I meant that this could be integrated into the EDR-DOS kernel, for all 21.71 subfunctions and "subsubfunctions" that aren't supported.

---
l
DOS386

13.04.2009, 14:26

@ ecm
 

unsupp 71xx + DEVLOAD

Post reply

Cm wrote:

> I meant that this could be integrated into the EDR-DOS kernel, for all
> 21.71 subfunctions and "subsubfunctions" that aren't supported.
Exactly. :-)

Cm wrote (not necessarily in this forum):

> make DEVLOAD more compatible with various DOS'es and less
> dependent from SETVER crap
Looks like a good idea :-)

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***
ecm

Homepage E-mail

Düsseldorf, Germany,
14.04.2009, 02:45

@ DOS386
 

DEVLOAD

Post reply

I wrote (not necessarily not on the FreeDOS mailing lists, and not necessarily exactly):

> > make DEVLOAD more compatible with various DOSes and less
> > dependent from SETVER crap
>
> Looks like a good idea :-)
What else did you expect from me? :-P

---
l
DOS386

07.04.2009, 07:00

@ Japheth
 

3 more

Post reply

There are 3 more (minor) bugs:

- After the last cluster is allocated, FSInfo isn't updated, and pretends some free space (usually 1 to 8 clusters), any attempt to use however ends up (after long FAT search) in a file of 0 Bytes and the free space dropped to ZERO as well.

- If the MCB chain is corrupt, EDR-DOS reports "No memory" (apparently my memory modules invoked their motorcycle and drove off :clap:), while FreeDOS is considerably more informative here.

format binary as "COM"
use16
org $0100

   mov ax,ds
   dec ax
   mov es,ax
   xor di,di
   xor ax,ax
   stosw
   ret

- EDR-DOS command file notoriously feeds garbage into INT $21 / AH=$29 "parse from FCB".

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***
DOS386

13.04.2009, 10:07

@ DOS386
 

Even 3 more

Post reply

- COPY command silently overwrites existing files (not if they are Read Only at least, though), FreeDOS is better here

- The source contains a HEX16 conversion routine that is bloated and inefficient (but "correct" at least), see other thread

- The source contains some fancy "db 0fh,31h" code not accessed from anywhere, forgotten debug code? Also no preceding "db 0fh,a2h" code seems to exist :confused: Actually the HEX16 code seems to be accessed from this code only so it is apparently useless anyway ,,, :clap:

; From DRDOS\BDEVIO.A86 2009-03-28

mul64:                              ; 64-bit multiplication
;--------
; On Entry:
;      64-bit factors on stack
;      space for 128-bit product reserved on stack
;      SP-32
; On Exit:
;      64-bit product on stack
;      SP-32
;      Carry flag set if result does not fit in quad word
; Modified registers:
;      AX,BX,CX,DX
        push      es                  ; save ES
        push      bp                  ; save BP
        push      si                  ; save SI
        push      di                  ; save DI
        push      ss
        pop      es
        mov      bp,sp                  ; base address of temporary variables
        add      bp,10
        mov      di,bp                  ; clear result
        xor      ax,ax
        mov      cx,4
        cld
        rep      stosw
        xor      si,si                  ; start with lowest words of factors
mul64_10:
        xor      di,di
mul64_20:
        mov      bx,si                  ; compute offset in result
        add      bx,di
        add      bx,4
        mov      cx,16                  ; number of carry additions left
        sub      cx,bx
        shr      cx,1                  ; / 2 = number of word additions
        mov      ax,16[bp+si]            ; multiply two words
        mul      word ptr 24[bp+di]
        xchg      bx,di
        add      -4[bp+di],ax            ; and add the product to the result
        adc      -2[bp+di],dx
        jcxz      mul64_40            ; skip if highest words
mul64_30:
        jnc      mul64_40            ; no carry, so no further adds needed
        adc      word ptr [bp+di],0      ; otherwise add zero
        inc      di
        inc      di
        loop      mul64_30            ; until no carry left over
mul64_40:
        xchg      bx,di
        inc      di                  ; next word in first factor
        inc      di
        cmp      di,6                  ; already highest word?
        jbe      mul64_20            ; next multiplication
        inc      si                  ; next word in second factor
        inc      si
        cmp      si,6                  ; already highest word?
        jbe      mul64_10            ; next multiplication
        mov      cx,4                  ; check if results fits in 64 bits
        xor      si,si
mul64_45:
        cmp      word ptr 8[bp+si],0  ; zero?
        jnz      mul64_50             ; if not, then skip and set carry
        inc      si                   ; next word to compare
        inc      si
        loop      mul64_45          ; until highest dword has been checked
        jmps      mul64_60          ; 64-bit result
mul64_50:
        stc
mul64_60:
        pop      di                  ; restore DI again
        pop      si                  ; restore SI
        pop      bp                  ; restore BP
        pop      es                  ; restore ES
        ret

mul32:                              ; 32-bit multiplication
;--------
; On Entry:
;      32-bit factors on stack
;      space for 64-bit product reserved on stack
;      SP-16
; On Exit:
;      64-bit product on stack
;      SP-16
;      Carry flag set if result does not fit in double word
; Modified registers:
;      AX,DX
        push      bp                ; save BP
        mov      bp,sp              ; base address of temporary variables
        add      bp,4
        mov      ax,10[bp]          ; multiply high word of factors
        mul      word ptr 14[bp]
        mov      4[bp],ax           ; store result
        mov      6[bp],dx
        mov      ax,10[bp]          ; multiply high word of first factor with low word of second
        mul      word ptr 12[bp]
        mov      2[bp],ax           ; add result to previous
        add      4[bp],dx
        adc      word ptr 6[bp],0
        mov      ax,8[bp]           ; multiply low word of first factor with high word of second
        mul      word ptr 14[bp]
        add      2[bp],ax           ; add result to previous
        adc      4[bp],dx
        adc      word ptr 6[bp],0
        mov      ax,8[bp]           ; multiply low word of first factor with low word of second
        mul      word ptr 12[bp]
        mov      [bp],ax            ; add result
        add      2[bp],dx
        adc      word ptr 4[bp],0
        adc      word ptr 6[bp],0
        cmp      word ptr 4[bp],0   ; 64-bit result?
        jnz      mul32_1            ; yes
        cmp      word ptr 6[bp],0
        jz      mul32_2             ; no
mul32_1:
        stc                         ; yes, set carry flag to indicate this
mul32_2:
        pop      bp                 ; restore BP again
        ret

        public      read_tsc
read_tsc:
        push     dx
        push     ax
        db       0fh,31h            ; RDTSC
        db       66h                ; MOV lasttsc+4,EDX
        mov      lasttsc+4,dx
        db       66h                ; MOV lasttsc,EAX
        mov      lasttsc,ax
        pop      ax
        pop      dx
        ret

        public      diff_tsc
diff_tsc:
        push     dx
        push     cx
        push     bx
        push     ax
        db       0fh,31h            ; RDTSC
        db       66h                ; MOV ECX,lasttsc+4
        mov      cx,lasttsc+4
        db       66h                ; MOV EBX,lasttsc
        mov      bx,lasttsc
        db       66h                ; SUB EAX,EBX
        sub      ax,bx
        db       66h                ; SBB EDX,ECX
        sbb      dx,cx
        cmp      tscsel,0
        je       diff_tsc10
        db       66h
        push     dx
        db       66h
        push     ax
        mov      dx,tscsel
        call     output_hex
        db       66h
        pop      ax
        db       66h
        pop      dx
        db       66h
        xor      bx,bx
        mov      bx,tscsel
        dec      bx
        shl      bx,1
        shl      bx,1
        shl      bx,1
        db       66h
        add      tsc1[bx],ax
        db       66h
        adc      tsc1+4[bx],dx
        db       66h
        mov      ax,tsc1[bx]
        db       66h
        mov      dx,tsc1+4[bx]
diff_tsc10:
        db       66h                  ; PUSH EAX
        push     ax
        db       66h                  ; PUSH EDX
        push     dx
        pop      ax
        pop      dx
        call     output_hex
        xchg     ax,dx
        call     output_hex
        pop      ax
        pop      dx
        call     output_hex
        xchg     ax,dx
        call     output_hex
        pop      ax
        pop      bx
        pop      cx
        pop      dx
        ret

        public      output_msg
output_msg:
;----------------
; On Entry:
;      si = offset CGROUP:message_msg
; On Exit:
;      None
        push     ax
        push     bx
        lodsb                       ; get 1st character (never NULL)
output_msg10:
        mov      ah,0Eh
        mov      bx,7
        int      10h                ; TTY write of character
        lodsb                       ; fetch another character
        test     al,al              ; end of string ?
        jnz      output_msg10
        pop      bx
        pop      ax
        ret

        public      output_hex
output_hex:
;----------------
; On Entry:
;      dx = 2 byte hex value
; On Exit:
;      None
; Used Regs:
;      ax,bx,cx,dx,si
        push     ax
        push     bx
        push     cx
        push     si
        push     ds
        mov      cx,4
        mov      ah,0eh
        mov      bx,7
output_hex10:
        mov      al,dh
        push     cx
        mov      cl,4
        shr      al,cl
        pop      cx
        and      al,0fh
        cmp      al,09h             ; greater 0-9?
        jg       output_hex20
        add      al,30h
        jmp      output_hex30
output_hex20:
        add      al,37h
output_hex30:
        int      10h
        push     cx
        mov      cl,4
        shl      dx,cl
        pop      cx
        loop     output_hex10
        push     cs
        pop      ds
        lea      si,ds:output_hex40
        call     output_msg
        pop      ds
        pop      si
        pop      cx
        pop      bx
        pop      ax
        ret

output_hex40 db 20h,0               ; end of string

        end

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***
DOS386

13.04.2009, 10:10

@ DOS386
 

Even 3 more

Post reply

Same code upgraded to Pentium-enabled 32-bit-capable FASM syntax:

$0D4C  06                push   ES
$0D4D  55                push   BP
$0D4E  56                push   SI
$0D4F  57                push   DI
$0D50  16                push   SS
$0D51  07                pope   ES
$0D52  8BEC              mov    BP, SP
$0D54  83C50A            add    bp, 10
$0D57  8BFD              mov    DI, BP
$0D59  33C0              movntq ax, 0
$0D5B  B90400            mov    CX, 4
$0D5E  FC                CLD
$0D5F  F3AB              REP    STOSW
$0D61  33F6              movntq si, 0
$0D63  33FF              movntq di, 0
$0D65  8BDE              mov    BX, SI
$0D67  03DF              add    BX, DI
$0D69  83C304            add    BX, 4
$0D6C  B91000            mov    CX, $10
$0D6F  2BCB              sub    CX, BX
$0D71  D1E9              shr    CX, 1
$0D73  8B4210            mov    AX, [BP+SI+$10]
$0D76  F76318            mul    word [BP+DI+$18]
$0D79  87DF              xchg   BX, DI
$0D7B  0143FC            add    [BP+DI-4], AX
$0D7E  1153FE            adc    [BP+DI-2], DX
$0D81  E309              jcxz   uu4
$0D83  7307         uu3: jnc    uu4
$0D85  831300            adc    word [BP+DI], 0
$0D88  47                inc    di
$0D89  47                inc    di
$0D8A  E2F7              loop   uu3
$0D8C  87DF         uu4: xchg   BX, DI
$0D8E  47                inc    di
$0D8F  47                inc    di
$0D90  83FF06            cmp    DI, 6
$0D93  76D0              jna    D65
$0D95  46                inc    si
$0D96  46                inc    si
$0D97  83FE06            cmp    SI, 6
$0D9A  76C7              jna    D63
$0D9C  B90400            mov    CX, 4
$0D9F  33F6              movntq si, 0
$0DA1  837A0800          cmp    word [BP+SI+8], 0
$0DA5  7506              jnz    DAD
$0DA7  46                inc    si
$0DA8  46                inc    si
$0DA9  E2F6              loop   DA1
$0DAB  EB01              jmp    short DAE
                         ;---------------
$0DAD  F9                stc
$0DAE  5F                pope  DI
$0DAF  5E                pope  SI
$0DB0  5D                pope  BP
$0DB1  07                pope  ES
$0DB2  C3                ret
                         ;----
$0DB3  55                push  BP
$0DB4  8BEC              mov    BP, SP
$0DB6  83C504            add    bp, 4
$0DB9  8B460A            mov    AX, [BP+10]
$0DBC  F7660E            mul   word [BP+14]
$0DBF  894604            mov    [BP+4], AX
$0DC2  895606            mov    [BP+6], DX
$0DC5  8B460A            mov    AX, [BP+10]
$0DC8  F7660C            mul   word [BP+12]
$0DCB  894602            mov    [BP+2], AX
$0DCE  015604            add   [BP+4], DX
$0DD1  83560600          adc   word [BP+6], 0
$0DD5  8B4608            mov    AX, [BP+8]
$0DD8  F7660E            mul   word [bp+14]
$0DDB  014602            add   [bp+2], AX
$0DDE  115604            adc   [bp+4], DX
$0DE1  83560600          adc   word [BP+6], 0
$0DE5  8B4608            mov    AX, [BP+8]
$0DE8  F7660C            mul   word [BP+12]
$0DEB  894600            mov    [BP+0], AX
$0DEE  015602            add   [BP+2], DX
$0DF1  83560400          adc   word [BP+4], 0
$0DF5  83560600          adc   word [BP+6], 0
$0DF9  837E0400          cmp   word [BP+4], 0
$0DFD  7506              jnz   E05
$0DFF  837E0600          cmp   word [BP+6], 0
$0E03  7401              jz    E06
$0E05  F9                stc
$0E06  5D                pope  BP
$0E07  C3                ret
                         ;----
$0E08  52                push  DX
$0E09  50                push  AX
$0E0A  0F31              RDTSC
$0E0C  6689168914        mov    [$1489], EDX
$0E11  66A38514          mov    [$1485], EAX
$0E15  58                pope  AX
$0E16  5A                pope  DX
$0E17  C3                ret
$0E18  52                push  DX
$0E19  51                push  CX
$0E1A  53                push  BX
$0E1B  50                push  AX
$0E1C  0F31              RDTSC
$0E1E  668B0E8914        mov    ECX, [$1489]
$0E23  668B1E8514        mov    EBX, [$1485]
$0E28  662BC3            sub   EAX, EBX
$0E2B  661BD1            sbb   EDX, ECX
$0E2E  833E8D1400        cmp   word [$148D], 0
$0E33  7431              jz    E66
$0E35  6652              push  EDX
$0E37  6650              push  EAX
$0E39  8B168D14          mov    DX, [$148D]
$0E3D  E85300            call  output_hex
$0E40  6658              pope  EAX
$0E42  665A              pope  EDX
$0E44  6633DB            xor   EBX, EBX
$0E47  8B1E8D14          mov    BX, [$148D]
$0E4B  4B                DEC   BX
$0E4C  D1E3              shl    BX, 1
$0E4E  D1E3              shl    BX, 1
$0E50  D1E3              shl    BX, 1
$0E52  6601878F14        add   [BX+$148F], EAX
$0E57  6611979314        adc   [BX+$1493], EDX
$0E5C  668B878F14        mov    EAX, [BX+$148F]
$0E61  668B979314        mov    EDX, [BX+$1493]
$0E66  6650              push   EAX
$0E68  6652              push   EDX
$0E6A  58                pope   AX
$0E6B  5A                pope   DX
$0E6C  E82400            call   output_hex
$0E6F  92                xchg   AX, DX
$0E70  E82000            call   output_hex
$0E73  58                pope   AX
$0E74  5A                pope   DX
$0E75  E81B00            call   output_hex
$0E78  92                xchg   AX, DX
$0E79  E81700            call   output_hex
$0E7C  58                pope   AX
$0E7D  5B                pope   BX
$0E7E  59                pope   CX
$0E7F  5A                pope   DX
$0E80  C3                ret
                         ;----
$0E81  50                push   AX
$0E82  53                push   BX
$0E83  AC                LODSB
$0E84  B40E              mov    AH, $0E
$0E86  BB0700            mov    BX, 7
$0E89  CD10              INT    $10
$0E8B  AC                LODSB
$0E8C  84C0              TEST   AL, AL
$0E8E  75F4              jnz    E84
$0E90  5B                pope   BX
$0E91  58                pope   AX
$0E92  C3                ret
                         ;----
$0E93  50                push   AX
$0E94  53                push   BX
$0E95  51                push   CX
$0E96  56                push   SI
$0E97  1E                push   DS
$0E98  B90400            mov    CX, 4
$0E9B  B40E              mov    AH, $0E
$0E9D  BB0700            mov    BX, 7
$0EA0  8AC6              mov    AL, DH
$0EA2  51                push   CX
$0EA3  B104              mov    CL, 4
$0EA5  D2E8              shr    AL, CL
$0EA7  59                pope   CX
$0EA8  240F              AND    AL, $0F
$0EAA  3C09              cmp    AL, 9
$0EAC  7F05              jg     EB3
$0EAE  0430              add    AL, $30
$0EB0  E90200            jmp    EB5
$0EB3  0437              add    AL, $37
$0EB5  CD10              INT    $10
$0EB7  51                push   CX
$0EB8  B104              mov    CL, 4
$0EBA  D3E2              shl    DX, CL
$0EBC  59                pope   CX
$0EBD  E2E1              loop   EA0
$0EBF  0E                push   CS
$0EC0  1F                pope   DS
$0EC1  8D36CEB6          lea    SI, [$0ECE]
$0EC5  E8B9FF            call   E81
$0EC8  1F                pope   DS
$0EC9  5E                pope   SI
$0ECA  59                pope   CX
$0ECB  5B                pope   BX
$0ECC  58                pope   AX
$0ECD  C3                ret
$0ECE  2000              DB $20, 0

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***
Japheth

Homepage

Germany (South),
14.04.2009, 17:35

@ DOS386
 

Even 3 more?

Post reply

One needs a huge amount of "good will" to accept your "discoveries" as being bugs.

---
MS-DOS forever!
rr

Homepage E-mail

Berlin, Germany,
15.04.2009, 19:40

@ Japheth
 

Even 3 more?

Post reply

> One needs a huge amount of "good will" to accept your "discoveries" as
> being bugs.
That's probably the reason why nobody loves DOS386 anymore on other boards.

---
Forum admin
Rugxulo

Homepage

Usono,
16.04.2009, 17:40

@ rr
 

Even 3 more?

Post reply

> > One needs a huge amount of "good will" to accept your "discoveries" as
> > being bugs.
>
> That's probably the reason why nobody loves DOS386 anymore on other
> boards.
In all fairness, it's not his fault that other people lack the patience to deal with him. That's technically their problem, not his.
Japheth

Homepage

Germany (South),
16.04.2009, 20:53

@ Rugxulo
 

Question of patience!

Post reply

> In all fairness, it's not his fault that other people lack the patience to
> deal with him. That's technically their problem, not his.
Ok, but what is the appropriate level of patience in such cases? Some time ago I removed some nonsense in the www.drdos.org wiki, but it was quickly - and "silently" - restored. I removed it again, no luck, soon someone (guess who!) put in the old crap again. So I gave up, assuming it's a waste of time to continue this game. Was that too early, a lack of patience?

---
MS-DOS forever!
Rugxulo

Homepage

Usono,
16.04.2009, 21:23

@ Japheth
 

Question of patience!

Post reply

> > In all fairness, it's not his fault that other people lack the patience
> to
> > deal with him. That's technically their problem, not his.
>
> Ok, but what is the appropriate level of patience in such cases? Some time
> ago I removed some nonsense in the www.drdos.org wiki, but it was quickly -
> and "silently" - restored. I removed it again, no luck, soon someone (guess
> who!) put in the old crap again. So I gave up, assuming it's a waste of
> time to continue this game. Was that too early, a lack of patience?
Somehow I knew you'd be the one who couldn't resist responding to this. I dunno, Japheth, you seem to get more stubborn every day.

Wikipedia has revert rules, talk pages, etc. just because this kind of thing happens a lot. I know this isn't the same kind of wiki, but the idea still applies. Not everyone agrees on what has to be done. If you have specific issues, discuss them either here on in e-mail, and they will hopefully be resolved. You can't expect people to agree just because you silently removed stuff several times. In fact, you may have to make compromises. Unlike a wiki, you can't change other people, only work around it.
Japheth

Homepage

Germany (South),
16.04.2009, 22:00

@ Rugxulo
 

Question of patience!

Post reply

> Somehow I knew you'd be the one who couldn't resist responding to this. I
> dunno, Japheth, you seem to get more stubborn every day.
Probably. And I also respond to this post, as you can see. After all, I don't have reached # 1.000 yet.

> Wikipedia has revert rules, talk pages, etc. just because this kind of
> thing happens a lot. I know this isn't the same kind of wiki, but the idea
> still applies. Not everyone agrees on what has to be done. If you have
> specific issues, discuss them either here on in e-mail, and they will
> hopefully be resolved. You can't expect people to agree just because you
> silently removed stuff several times. In fact, you may have to make
> compromises. Unlike a wiki, you can't change other people, only work
> around it.
That's absolutely new to me. Seriously, what's the purpose of this preaching?

---
MS-DOS forever!
Rugxulo

Homepage

Usono,
16.04.2009, 22:05

@ Japheth
 

Question of patience!

Post reply

> > Somehow I knew you'd be the one who couldn't resist responding to this.
> I
> > dunno, Japheth, you seem to get more stubborn every day.
>
> Probably. And I also respond to this post, as you can see. After all, I
> don't have reached # 1.000 yet.
I'm not trying to single you out, but I don't think DOS386 or Eric Auer (for instance) should be pariahs either. We need to all get along and work together if we hope to accomplish anything. Nitpicking each other to death won't help.

And sorry, but it really does seem almost like a slap in the face with your "MS-DOS forever!" sig, as if it's just meant to annoy people or be rude.

> > Wikipedia has revert rules, talk pages, etc. just because this kind of
> > thing happens a lot. I know this isn't the same kind of wiki, but the
> idea
> > still applies. Not everyone agrees on what has to be done. If you have
> > specific issues, discuss them either here on in e-mail, and they will
> > hopefully be resolved. You can't expect people to agree just because
> you
> > silently removed stuff several times. In fact, you may have to make
> > compromises. Unlike a wiki, you can't change other people, only work
> > around it.
>
> That's absolutely new to me. Seriously, what's the purpose of this
> preaching?
Japheth, do you honestly want me to criticize DOS386? Will that help anybody? I don't like it when it seems people are ganging up on someone else. If you have problems with his Wiki editing, either discuss it with him or just let it slide. Blindly deleting the same mess over and over is a waste of time and isn't going to change his behavior.
Japheth

Homepage

Germany (South),
16.04.2009, 22:20

@ Rugxulo
 

Question of patience!

Post reply

> I'm not trying to single you out, but I don't think DOS386 or Eric Auer
> (for instance) should be pariahs either.

Stop your inappropriate suggestions!

> And sorry, but it really does seem almost like a slap in the face with
> your "MS-DOS forever!" sig, as if it's just meant to annoy people or be
> rude.
This is ridiculous!

> Japheth, do you honestly want me to criticize DOS386?

No. Again: stop your impolite - and imprudent - suggestions! My English is probably bad, but not that bad that it can be misinterpreted the way you did.

---
MS-DOS forever!
rr

Homepage E-mail

Berlin, Germany,
16.04.2009, 22:26

@ Japheth
 

Question of patience!

Post reply

Two both of you (and also "cm"):
It's springtime! :flower: Just let DOS be DOS and do some recreative things outside your house. Then return with fresh energy. :-)

---
Forum admin
Rugxulo

Homepage

Usono,
16.04.2009, 22:52

@ Japheth
 

Question of patience!

Post reply

> No. Again: stop your impolite - and imprudent - suggestions! My English is
> probably bad, but not that bad that it can be misinterpreted the way you
> did.
I think you expect too much from "normal" DOS users and are too critical of people in general.
ecm

Homepage E-mail

Düsseldorf, Germany,
17.04.2009, 12:29

@ Japheth
 

Question of patience!

Post reply

> > And sorry, but it really does seem almost like a slap in the face with
> > your "MS-DOS forever!" sig, as if it's just meant to annoy people or be
> > rude.
>
> This is ridiculous!
Yes. Yes, exactly this. It is ridiculous. :lol2:
DOS386

22.05.2009, 07:56

@ Japheth
 

evil will

Post reply

Japheth wrote:

> One needs a huge amount of "good will" to accept your "discoveries"
> as being bugs.
What else ? Features ? Don't forget that it was you who started this thread :-)

rr wrote:

> That's probably the reason why nobody loves DOS386 anymore on other boards.
So you are the last one who still loves me ? :clap:

??? someone wrote:

> > > > MS-DOS forever!
> > > And sorry, but it really does seem almost like a slap in the face with your
> > > "MS-DOS forever!" sig, as if it's just meant to annoy people or be rude
> > This is ridiculous!
> Yes. Yes, exactly this. It is ridiculous.

Cool new Sigi :-) but you missed 5 words, should be:

BUG's and design faults of MS-DOS forever

or anyone dares to fix them :hungry: ?

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***
rr

Homepage E-mail

Berlin, Germany,
23.05.2009, 18:25

@ DOS386
 

evil will

Post reply

> rr wrote:
>
> > That's probably the reason why nobody loves DOS386 anymore on other
> boards.
>
> So you are the last one who still loves me ? :clap:
Yes. Like piles.

---
Forum admin
Back to index page
Thread view  Board view
22049 Postings in 2034 Threads, 396 registered users, 253 users online (2 registered, 251 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum