DOS ain't dead

HX 2.16

BUG's:

1. Buggy relox handling in DPMILD32

2. Performance / timig bogus - regression in 2.16

3. Dates are not filled in and HXSRC is outdated

4. Redundant space between argv[0] and argv[1]

Other issues / wishlist:

6. Unconditional loading of SB16.DLL

7. MPLAYER GUI video output doesn't work anymore (broken on MPLAYER's side)

8. Various missing imports: GlobalMemoryStatusEx, a few in BOCHS, some in MPLAYER, ...

9. MediaInfo / CommandLineToArgvW / HELL32.DLL (I'm fixing this one)

10. Console + GUI : 2 "windows"

Recently fixed:

-1. FFMPEG-BUG / Spurious-seek-BUG (fixed in 2.16)

-2. OPTIPNG-BUG (get UI21DEB)

EDIT : added forgotten bug

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

Found a NEW cool BUG:

5. "StringFromGUID2" in OLE32.DLL returns EAX=0, should be EAX=39, download now: BUG.ZIP (1'380 Byte's)

System requirements:

- DOS with HX 2.17 (not yet available) or Windaube (ME, XP, Vista (untested, maybe best for now))
- OLE32.DLL
- At least 80386 20 MHz 8 MiB RAM for DOS, P1 100 MHz 128 MiB RAM for ME, P3 400 MHz 512 MiB RAM for XP, P4 >=3 GHz 4 GiB RAM for Vista

You will quickly find out that the thing doesn't even load, because of the "Relox-BUG" (fine in ME and XP), when you fix this one, it will work but not well, because of the "StringFromGUID2-BUG"

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

> Found a NEW cool BUG:
>
> 5. "StringFromGUID2" in OLE32.DLL returns EAX=0, should be EAX=39,
> download now:
> BUG.ZIP (1'380
> Byte's)
>

True! Fixed in HXRT v2.17 (just the StringFromGUID2 thing, the DPMILD32 issue is still in the queue).

---
MS-DOS forever!

I wrote:

> DOS with HX 2.17 (not yet available)

Heh, yesterday I was right and today I'm wrong

> or Windaube (ME, XP, Vista (untested, maybe best for now))

Rugxulo tested on Vista, works fully, so there is still space for improvements in DPMILD32 and DKRNL32 from 2009-12-20

> True! Fixed in HXRT v2.17

Great

> (just the StringFromGUID2 thing, the DPMILD32 issue is still in the queue).

Good.

DPMILD32:

> __.__.2009: version 3.8
> minor size reduction.

Less bloat is always good

OLEeeee:

> __/__/2009: V1.10
> StringFromGUID2 did always return S_OK (=0).
> stubs CreateItemMoniker + GetRunningObjectTable added.

MPLAYER ^^^ missing imports

DUSER32.DLL:

> __/__/2009: Version 2.14
> EnumDisplayDevicesA added.

Dummy

---------------------------------------------------------------------------

More old issues:

* DPMILD32 needs 2 attempts to load a PE, because it tries NE before

See also debug report: http://freefile.kristopherw.us/uploads/temp/mpwsdl.txt

---------------------------------------------------------------------------

One more BUG just discovered:

* It crashes if commandline is unreasonably long ( > 128 (?) chars )

But what crashes ? Both HX and DOS/32A
But where ? On both FreeDOS and EDR-DOS

---------------------------------------------------------------------------

Please look into the abovementioned 7-ZIP regression also.

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

Well, there are even more:

53. Exit code is truncated to 8 bits only, maybe a flaw rather than BUG, or just documentation bug ... GetExitCodeProcess

54. SET DPMILDR=8 has an evil and undocumented side effect:

> - bit 3 (DPMILDR=8): prevents loader from trying to run another
> application in the current DPMI client. Instead the int 21h, ax=4B00h
> call is routed to the next handler in the chain. This is useful if
> the applications to run cannot share the client, which is mostly the
> case for Win32 applications where the relocation information has
> been stripped from the binary. To make this finally work as expected,
> it must be ensured that the DPMI host will run clients in separate
> address spaces (see HDPMI docs for details).

it (fired by CreateProcessA) stops preferring PE over MZ and if there is no DPMIST32.BIN inside, it will execute just the stub, "Need HX-DOS Extender to run !" is the "optimal" result

55. README.TXT in DKRNL32 source DIR incorrectly writes:

> EXITPROC.ASM PROCESS ExitProcess
> GetExitCodeProcess

at this occasion, EXITPROC.ASM and PROCESSW.ASM could be integrated into PROCESS.ASM, they are ridiculously small

56. GPF:


3014 lstrcpy
3014 lstrcpyA
3044 lstrlen
3044 lstrlenA
3060 GetModuleHandleA
30C8 GetProcessHeap
30D0 IsBadReadPtr

dkrnl32: exception C0000005 (AKA GPF ?????), flags=0 occured at B7:12A084
        ax=8210 bx=100A7 cx=0 dx=128210
        si=126E47 di=126A00 bp=1268CC sp=1268C8
        ip = Module 'kernel32.dll'+3084  fs=?????????????????????

Filepos: $2484

2460  55                push ebp ; GetModuleHandleA
2461  8BEC              mov ebp,esp
2463  8B5508            mov edx,[ebp+8]
2466  23D2              and edx,edx
2468  750A              jnz $2474
246A  E8CDF3FFFF        call $183c
246F  8B4008            mov eax,[eax+8]
2472  EB06              jmp short $247a
                        ;--------------
2474  66B8824B          mov ax,$4b82
2478  CD21              int $21 ; Talk to DPMILD32, if present at all
247A  C9                leave
247B  C20400            ret 4

247E  8BFF              mov edi,edi ; NOPE

2480  55                push ebp ; GetProcessHeapEx (non-public ??????)
2481  8BEC              mov ebp,esp
2483  53                push ebx
2484  67648B1E3000      mov ebx,[word fs:$30] ; !!! BOOM !!! here it crashes
248A  8B430C            mov eax,[ebx+$0C]
248D  23C0              and eax,eax
248F  7532              jnz $24c3
2491  837D0800          cmp dword [ebp+8],0
2495  742C              jz $24c3
2497  6A00              push 0
2499  E8C2FFFFFF        call $2460
249E  8BD8              mov ebx,eax
24A0  035B3C            add ebx,[ebx+$3c]
24A3  8B4368            mov eax,[ebx+$68]
24A6  23C0              and eax,eax
24A8  7419              jz $24c3
24AA  8B4B6C            mov ecx,[ebx+$6c]
24AD  6A02              push 2
24AF  6A00              push 0
24B1  51                push ecx
24B2  50                push eax
24B3  6A00              push 0
24B5  E87A0E0000        call $3334
24BA  67648B1E3000      mov ebx,[word fs:$30]
24C0  89430C            mov [ebx+$0C],eax
24C3  5B                pop ebx
24C4  C9                leave
24C5  C20400            ret 4

24C8  6A01              push 1 ; GetProcessHeap
24CA  E8B1FFFFFF        call $2480
24CF  C3                ret ; What a sophisticated function


After "some" usage of LoadLibraryA (and a few other), a GPF in DKRNL32 occurs FS is secret, but SET DKRNL32=32 can reveal it: ZERO

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

I wrote:

> After "some" usage of LoadLibraryA (and a few other), a GPF

... maybe LoadLibraryA is not that badly needed to exploit this bug ... more likely CreateProcessA is the source of evil:

- It uses FS. Regrettably it also ZERO'izes it after usage so one call is fine but the next one causes the GPF : "ip = Module 'kernel32.dll'+3084" If I preserve FS, the problem is fixed ... almost

- now I can use CreateProcessA more than 1 time. But after 46 calls it GPF's again "ip = Module 'kernel32.dll'+243C" - same GPF on same instruction in other place inside DKRNL32, FS==0

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

> I wrote:
>
> > After "some" usage of LoadLibraryA (and a few other), a GPF
>
> ... maybe LoadLibraryA is not that badly needed to exploit this bug
> ... more likely CreateProcessA is the source of evil:
>
> - It uses FS. Regrettably it also ZERO'izes it after usage so one call is
> fine but the next one causes the GPF : "ip = Module 'kernel32.dll'+3084"
> If I preserve FS, the problem is fixed ... almost
>
> - now I can use CreateProcessA more than 1 time. But after 46 calls
> it GPF's again "ip = Module 'kernel32.dll'+243C" - same GPF on same
> instruction in other place inside DKRNL32, FS==0

There was a change in DPMILD32 v3.3.0: FS register is no longer used/modified.

Since OTOH the values of all segment registers are saved & restored when the DPMI-client switches to real-mode, the only case where FS might be changed outside of DKRNL32 is when another PE application is run in the very same client. Is this true here?

---
MS-DOS forever!

> There was a change in DPMILD32 v3.3.0

COOL

> 07/15/2007, V2.12: HDPMI V3.13, DPMILD32 V3.3.0, DKRNL32 V3.0,
> DADVAPI V2.7, DUSER32 V2.9.13, DGDI32 V1.9.8,
> OLE32 V1.6, OLEAUT32 V1.6, VESA32 V1.9.5, PESTUB V2.8
> don't mix DPMILD32 + DKRNL32 with older versions of these files.

otherwise ...

> 15.07.2007: version 3.3.0
> FS is no longer used/modified by DPMILD32.
> DPMILD32 does no longer allocate and initialize a TIB for DKRNL32.
> This is now handled entirely by DKRNL32.

Yeah ...

> Since OTOH the values of all segment registers are saved & restored when
> the DPMI-client switches to real-mode, the only case where FS might be
> changed outside of DKRNL32 is when another PE application is run in the
> very same client. Is this true here?

YES.

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

HX BUG's:

Someone IIRC wrote recently (sorry no time to search for the post just now):

> we deprecate UPX

Then you probably don't know PETITE

But I found 7 more "strange items maybe worth reporting" in HX:

20. [Critical BUG] PETITE packer (self-packed) and executables packed with it don't work in HX, hard freezer (memory corruption at address ZERO ???), fine in ME and XP.

21. [BUG] Strange complaints from DPMILD32 (maybe already reported a few 1'000 times):

> * pe_map.c, dumps a PE file
> * made with Watcom C32 version 11.0b on NT 4.0
> * (f) by B. Luevelsmeyer 1997, 1998, 1999

COOL ^^^

> C:\HHH>pemap
> this is a Windows NT character-mode executable

Good ^^^

> C:\HHH>dpmild32 pemap

> DPMI loader version 3.8.0
> Copyright (C) 1993-2009 Japheth

> dpmild32: import not found: VerLanguageNameA
> dpmild32: file KERNEL32.dll
> dpmild32: g:\hxdos\dgdi32.dll: cannot resolve imports

There is a missing junk import "VerLanguageNameA" in DKRNL32.DLL, but the really bad thing is that DPMILD32 complains about "dgdi32.dll" that is NOT INVOLVED at all. The report probably should be (just 1 line):

> DPMILD32: Import not found: "PEMAP.EXE" needs "VerLanguageNameA" in "KERNEL32.DLL"

22. [BUG] SB16.DLL should be loaded conditionally (flaw, already reported before), but it additionally has a BUG causing "funny" crashes with "some" sound cards. Got a "somewhat SB compatible" ISA card (no crappy SB-EMU), the sound is bad (this might be "unavoidable" because of the crappy SB "design" ???), but additionally PLAYWAVE.EXE crashes (low memory corruption ???) at exit. No problems in ME on very same PC. There were IIRC also plans to add PCI sound card support ...

23. [BUG / incompatibility / crappy design] Function "GetFileAttributes" is inconsistent with Windaube (XP is "mostly" consistent with ME, but still "strange" ... who the **** is the parent of the main directory, BTW ???) see TESTATTR.ZIP, HX could catch some "potentially unsafe" strings like ".."

24. [Flaw / incompatibility / missing feature ???] HX GUI displays garbage if a SDL app tries to brew a box bigger than the screen size. Im ME and XP it "works" (although far away from great ...). One possible solution would be to "center" the too big box "behind" the screen and discard what is outside.

25. DGDI32.DLL is bugged. For example the "17 Byte's demo" is fine in ME and XP, but doesn't work with HX : crashes in DGDI32.DLL. Depending of screen bitdepth, it crashes at various addresses, but always in the BigBlt function and REP MOVSD instruction - apparently at least one of ECX, ESI and EDI supplied in invalid If I comment out the call to this BigBlt then it "works" (no screen output at all ) but exposes 3 more BUG's:
- Double crash in DKRNL32.DLL at exit
- MessageBoxA previously displayed not removed (not available in the version supplied now )
- No margin of the "Window" is visible

BTW, I have a new highly superior version of this application, and I'm going to release it, with full source code, of course, but not before I can be sure that it also works with HX, of course. I'm sure you will love it , for multiple reasons, among others, my version is impossible to pack with UPX

26. [docs suggestion] BTWW, in HXSRC (from 2009-06) I can see some "notes" on BigBlt and StretchBlt, in the source code and separate text files, but apprently the implementation of both is incomplete and it's also incompletely documented how far they are incomplete

Instead of:


Function        Dummy
--------        -----

BigBlt
StretchBlt      Y
BrewProcess
IsUserAdmin     Y
DoSomething     Y
DoMoreEx        Y


while the presence of "Y" in the right column is rather random, the docs could reveal more useful info:


Function        Limitations
--------        -----------

BigBlt
StretchBlt      no ZOOM, fails if (dest size) <> (source size)
BrewProcess     processes don't run at same time
IsUserAdmin     dummy, returns always true
DoSomething     dummy, does nothing and reports success
DoMoreEx        dummy, always fails


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

Thanks for your reports!

---
MS-DOS forever!

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

> Thanks for your reports!

Seems there is a tiny update from 2010-06-03

What's new:

- ??? (I'll have to search for previous HXRT.ZIP and compare, and possibly retest ...)

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


        call    ?001                   ; $0040'1000  E8, 00000009
?001:   pop     edi                    ; $0040'100E  5F
        push    36                     ; $0040'100F  6A, 24
        push    edi                    ; $0040'1011  57
        call    ?002                   ; $0040'1012  E8, 0000000B
?002:   push    0                      ; $0040'1022  6A, 00
        call    near [?011]            ; $0040'1024  FF. 15, 00401106(d)
        shr     eax, 1                 ; $0040'102A  D1. E8
        jc      ?003                   ; $0040'102C  72, 01
        int 3   ; breakpoint or filler ; $0040'102E  CC      ; INT3
?003:   push    36                     ; $0040'102F  6A, 24
        push    edi                    ; $0040'1031  57
        call    ?004                   ; $0040'1032  E8, 0000000A
?004:   pop     eax                    ; $0040'1041  58
        push    eax                    ; $0040'1042  50
        adc     byte [eax], 0          ; $0040'1043  80. 10, 00
        push    0                      ; $0040'1046  6A, 00
        call    near [?011]            ; $0040'1048  FF. 15, 00401106(d)
        shr     eax, 1                 ; $0040'104E  D1. E8
        jc      ?005                   ; $0040'1050  72, 02
        ud2                            ; $0040'1052  0F 0B   ; UD2
?005:   push    36                     ; $0040'1054  6A, 24
        push    edi                    ; $0040'1056  57
        call    ?006                   ; $0040'1057  E8, 00000009
?006:   pop     eax                    ; $0040'1065  58
        push    eax                    ; $0040'1066  50
        adc     byte [eax], 0          ; $0040'1067  80. 10, 00
        push    0                      ; $0040'106A  6A, 00
        call    near [?011]            ; $0040'106C  FF. 15, 00401106(d)
        shr     eax, 1                 ; $0040'1072  D1. E8
        jc      ?007                   ; $0040'1074  72, 01
; Note: Undocumented opcode
        icebp                          ; $0040'1076  F1      ; INT1
?007:   push    36                     ; $0040'1077  6A, 24
        push    edi                    ; $0040'1079  57
        call    ?008                   ; $0040'107A  E8, 00000008
?008:   pop     eax                    ; $0040'1087  58
        push    eax                    ; $0040'1088  50
        adc     byte [eax], 0          ; $0040'1089  80. 10, 00
        push    0                      ; $0040'108C  6A, 00
        call    near [?011]            ; $0040'108E  FF. 15, 00401106(d)
        push    0                      ; $0040'1094  6A, 00
        call    near [?010]            ; $0040'1096  FF. 15, 004010E5(d)


Discovered 3 new bugs:

97. "[eip]" is wrong for INT3 crash. ME has the very same BUG - maybe cloned it from there ???

98. INT1 instruction (OBJCONV disassembles it as ICEBP - InterCityExpressBritishPetrol) doesn't work. Either it is completely ignored or it crashes far away from it's location with a wrong exception number far away from the expected 1 (ONE) - maybe related to the "SBEMU" hack in DKRNL32 ???

99. "MessageBoxA" fails to display the buttons if text size is <= 8 char's.

Testcase for those 3 BUG's : http://www.file-pasta.com/file/0/HXBUGS.ZIP

### DKRNL32 ###

INT3 (crashes, but [eip] is wrong ...) :

dkrnl32: exception 80000003, flags=0 occured at B7:40102F
ax=3 bx=401000 cx=146BE8 dx=0
si=400000 di=401005 bp=58B8 sp=126FF4
ip = Module 'hxbugs.exe'+102F
[eip] = 6A 24 57 E8 0A 00 00 00 4D 42 43 44
[esp] = 00112B0D 00000000 00000000 00905A4D 00000003 00000004
dkrnl32: fatal exit!

UD2 (good) :

dkrnl32: exception C000001D, flags=0 occured at B7:401052
ax=3 bx=401000 cx=146BE8 dx=0
si=400000 di=401005 bp=58B8 sp=126FF4
ip = Module 'hxbugs.exe'+1052
[eip] = 0F 0B 6A 24 57 E8 09 00 00 00 4D 42
[esp] = 00112B0D 00000000 00000000 00905A4D 00000003 00000004
dkrnl32: fatal exit!

INT1 (ignored, or "bad" crash - both wrong exception
number and wrong [eip] also)

### HDPMI32 ### (SET DKRNL32=32)

INT3 (ignored)

UD2 (OK)

INT1 (ignored - always ???)

### ME ###

INT3 (crashes, but [eip] is wrong ... cloned the BUG from here ???)

UD2 (OK)

INT1 (crashes, but [eip] is wrong ... also here ???)

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

Thanks for your reports!

However, I have to admit that I don't understand what the errors exactly are which you allegedly did find. And your test case download is of little help, because it's a binary only, without source - can't use that!

---
MS-DOS forever!

> However, I have to admit that I don't understand what the errors exactly
> are which you allegedly did find

Didn't I describe them just above ???

> And your test case download is of little
> help, because it's a binary only, without source

There is no source anymore, blame Anger Fog - OBJCONV is great but it has a critical BUG : it overwrites the original source code when disassembling

> - can't use that!

Just run it and try YES and NO at the 3 questions and check the crashes.

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

9072 wrote:

> Have you ever tried this?

YES.

> Because, AFAIK, it's not a real option - those dlls
> are "unusable" outside of ReactOS

ReactOS 0.3.12 is out (2010-10-20). What's new:

- Fixed some BUG's
- Introduced some BUG's (reportedly mostly due to bad hack removal)

What's not new:

- DLL's don't work with HX

- XCOPY.EXE doesn't work with HX either

### ReactOS 0.3.12 ###

"iexplore.exe" 73'728
55BEEC26EF87CC6D6B0F11CC77F62801

"xcopy.exe" 135'168
60B971E3D89F39F0E353CDC65A52C568

CRTDLL.DLL 188'416
472F7119E5E4DFEC09DF64AEE1C4C571

GLU32.DLL 1'024'000
EDF99645977D2484D3EADB35D3DC3AC4

MSVCRT.DLL 425'984
D92488ED42D4C72FF9A52D094A6C2FAF

OPENGL32.DLL 98'304
B986D17F610B00619E9FAD66DB1519B2

28 missing imports in "NTDLL.DLL" :

RtlAreBitsClear RtlAreBitsSet RtlInitializeBitMap
RtlSecondsSince1970ToTime RtlSetBits RtlTimeToSecondsSince1970
_snwprintf _wcsicmp abs bsearch ceil cos floor labs memcmp
memcpy memset sin sprintf sqrt strcmp strcpy strcspn strlen
vDbgPrintExWithPrefix wcscpy wcsncat wcsncpy

One more: 9051 wrote:

> Running the Perforce client with HX? (wsock32 fatal error)

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

> 7143 wrote (1 year ago) :

> Heh, seems that Japheth is just now uploading new files, found
> HXDEV216.zip.filepart 16-Nov-2009 09:52 820K

PS: latest MediaInfo 0.7.36 works great with HX (+UI21DEB on EDR-DOS)

http://sourceforge.net/projects/mediainfo/

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

New Win32 binaries of GNASH (SWF player) : http://benjaminwolsey.de/downloads/

Problems with HX:

* Missing DLL

127F08C 127F67C 0 0 1281AFC 127FCF4 wldap32.dll
ilt iat Hint
------------------------------------------------------
127F67C: 128116C 127FCF4: 128116C A ber_free
127F680: 1281178 127FCF8: 1281178 5F ldap_err2stringA
127F684: 128118C 127FCFC: 128118C 6D ldap_first_attributeA
127F688: 12811A4 127FD00: 12811A4 6F ldap_first_entry
127F68C: 12811B8 127FD04: 12811B8 75 ldap_get_dnA
127F690: 12811C8 127FD08: 12811C8 81 ldap_get_values_lenA
127F694: 12811E0 127FD0C: 12811E0 84 ldap_initA
127F698: 12811EE 127FD10: 12811EE 87 ldap_memfreeA
127F69C: 12811FE 127FD14: 12811FE A1 ldap_msgfree
127F6A0: 128120E 127FD18: 128120E A3 ldap_next_attributeA
127F6A4: 1281226 127FD1C: 1281226 A5 ldap_next_entry
127F6A8: 1281238 127FD20: 1281238 D5 ldap_search_sA
127F6AC: 128124A 127FD24: 128124A DD ldap_set_optionA
127F6B0: 128125E 127FD28: 128125E E3 ldap_simple_bind_sA
127F6B4: 1281274 127FD2C: 1281274 E6 ldap_sslinitA
127F6B8: 1281284 127FD30: 1281284 F0 ldap_unbind_s
127F6BC: 1281294 127FD34: 1281294 F4 ldap_value_free_len

http://technet.microsoft.com/en-us/library/cc978399.aspx

http://source.winehq.org/WineAPI/wldap32.html

maybe 17 dummies would fix the problem

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

> Win32 binaries of GNASH (SWF player) http://benjaminwolsey.de/downloads/
> maybe 17 dummies would fix the problem

Well, found a DLL having those 17 (38 KiB)

After patching LIBBOOST.DLL , GNASH happily loads and starts ... the problem is ... it does nothing useful, the screen is black Tried some switches (no sound, fullscreen) ... no luck

In XP it works (plays, reacts to clicks if interactive, some frames broken/hanging, sound runs away from the video, ...).

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

http://innounp.sourceforge.net/

InnoUnp doesn't work well with HX. Some installers (old 4.xx ???) do extract (at least until the process crashes with NTLFN issues), while other (5.xx ??? CC386 Win32 installer for example) don't, it says "file is corrupt or not Inno at all". It does extract in ME or XP, though. InnoUnp 0.35, same problem for older versions.

OWB: msg=9288 "owb under dos/HX" 2011-02

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

msg=9473 "PDF readers for DOS" 2011-02

MUPDF doesn't run although the problems are possibly easy to solve:

> dpmild32: import not found: IsProcessorFeaturePresent
> dpmild32: file KERNEL32.dll

Just return ZERO (or CPUID).

but there is still a crash "behind" this problem ...

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

> msg=9473 "PDF readers for DOS" 2011-02
>
> MUPDF doesn't run although the problems are possibly easy to solve:
>
> > dpmild32: import not found: IsProcessorFeaturePresent
> > dpmild32: file KERNEL32.dll
>
> Just return ZERO (or CPUID).

IIRC this function is implemented in the source already, but somehow didn't make it to table of exports.

The source is in procfeat.asm, but the export is commented out in dkrnl32.def.

---
MS-DOS forever!

> 20. [Critical BUG] PETITE packer (self-packed) and executables
> packed with it don't work in HX, hard freezer (memory corruption at
> address ZERO ???), fine in ME and XP.

PETITE.ZIP (48 KiB)

Still not fixed in 2.17 2011-May / 2011-Jun

#66. One more in HDPMI32 (the version from 2009-Dec / 2010-Jan):

BUG

Occurs randomly and rarely, NOT specific to content of the file

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

> #66. One more in HDPMI32 (the version from 2009-Dec / 2010-Jan):
>
> BUG
>
> Occurs randomly and rarely, NOT specific to content of the file

It occurs in HDPMI32, but is almost certainly a bug in DKRNL32.

;----------------------------------------------------------------
Compressing D1128.TAR 75%Exception 0E in ring 0
next client CS:EIP=00B7:0023C724,SS:ESP=00BF:008A1E98
EAX=008A0000 EBX=00000005 ECX=00002000 EDX=00398000 ESI=00398000
EDI=00012150 EBP=0000FE00 ESP=0000078C EFL=00013006 EIP=00004C8D
CS=0020 (FF801000,000067B3,409B) SS=0028 (00009090,FFFFEFFF,CF93)
DS=00BF (00000000,FFFFFFFF,CFF3) ES=004B (00000000,FFFFFFFF,CFF3)
FS=00EF (007A0000,00000FFF,00F3) GS=0000 (********,********,****)
LDTR=0038 (FF80A000,00000FFF,0082) TR=0030 (00009898,00000067,008B)
ERRC=0000 (********,********,****) PTE 1. Page LDT=0013D467
GDTR=07FF:FF808800 IDTR=07FF:FF809000 PTE CR2=00000006
CR0=80000033 CR2=00398000 CR3=00130000 CR4=00000200 TSS:ESP0=00000804
DR0-3=00000000 00000000 00000000 00000000 DR6=FFFF0FF0 DR7=00000400
LPMS Sel/Cnt=0087/0000 RMS=11F4:0200 open RMCBs=0000/0000 ISR=0000
[EIP]=F3 A5 8A C8 80 E1 03 F3 A4 1F 07 61
[ESP]=00BF 0000 00BF 0000 0000 0000 1215 0000
0000079C=FE00 0000 07B4 0000 0005 0000 8000 0039
000007AC=8000 0000 40F0 008A 3F64 0000 1215 0000
000007BC=8000 0039 00BF 0000 8000 0039 8000 0000
000007CC=8000 0001 8000 0000 40F0 008A 07EC 0000
000007DC=0005 0000 8000 0039 8000 0000 40F0 008A
terminate (c)lient or (s)erver now?
;----------------------------------------------------------------

It's a crash in HDPMI function "copy_far32_2_flat". The value of ECX=2000h (and EDI pointing to conventional memory) tells that it is within a int 21h, ah=40h translation.

The protected-mode int 21h in question can be found in DKRNL32, THREAD.ASM.

There is a - small - chance that setting ?SMOOTH=0 in THREAD.ASM and recreating dkrnl32.dll may fix this issue. Side effect: multi-threading will be less "smooth".

---
MS-DOS forever!

> It occurs in HDPMI32, but is almost certainly a bug in DKRNL32.

> It's a crash in HDPMI function "copy_far32_2_flat". The value of ECX=2000h
> (and EDI pointing to conventional memory) tells that it is within a int
> 21h, ah=40h translation.

> The protected-mode int 21h in question can be found in DKRNL32,
> THREAD.ASM.

> There is a - small - chance that setting ?SMOOTH=0 in THREAD.ASM and
> recreating dkrnl32.dll may fix this issue. Side effect: multi-threading
> will be less "smooth".

Thanks ... could it be related to the SB-hack (in the past off, now on) ?

----- -------- ----- ----- ------- ------ ------- ------- ------ ------ ------ ----- --------

Other issues:

[30] many recent apps don't work because missing GetHandleInformation (trivial, return ZERO ?) and TryEnterCriminalSection (trivial, just duplicate AlwaysEnterCriminalSection post #10308 2011-Aug ?)

Japheth wrote 2011-08-09 :

> Anyway, I don't want to modify any sources of the scheduled HX v2.17

[31] Dillo-Win32 doesn't work because of a missing import in COMCTL32.DLL ... ignoring results in silent exit

[32] MUPDF doesn't work because of a problem in post #10477 2011-Sep CreateWindowEx

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

2 more in HX:

#33: When a MessageBox is done



it doesn't vanish ^^^ from screen

CLOSED: fixed #34: GetFileTitleA does almost nothing (I fixed this one)

I also found BUG's in ME:

#ME/4572839478293: PE protection bits are apparently ignored: crash in HX as supposed, "fine" in ME !?!?!?

#ME/4572839478294: Get****FileNameW are dummy only

#ME/4572839478295: GetFileTitleA doesn't work reliably: it is bugged in all versions of Windaube, just in every version differently

#ME/4572839478296: The "task manager" is not reliable

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

> v2.17, release candidate 06/05/2011 HXRT
> Password: japheth HXGUI HXDEV HXD16 HXSRC
> Important Note: HXRT217.zip has to be made password-protected,
> because some anti-virus programs don't like file DKRNL32.DLL (a Win32
> emulation dll), which is contained in the package.



PS: hxdll.zip (1 year old)

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

> > v2.17, release candidate 06/05/2011 HXRT
> > Password: japheth HXGUI HXDEV HXD16 HXSRC
> > Important Note: HXRT217.zip has to be made password-protected,
> > because some anti-virus programs don't like file DKRNL32.DLL (a Win32
> > emulation dll), which is contained in the package.
>
>

Horrible that we have to work around lousy antiviruses. (I didn't check, but IMHO, putting the password as plaintext in the .ZIP comment would at least be semi-friendly.) Which ones in particular flag it? I do now see it in my copy of latest Avira (Windows), Expert Mode -> Configuration -> System Scanner -> Scan -> Exceptions (and also DEV_GPC's Win32 UNINSTAL.EXE), so I must've put it there. So at least there's that workaround.

You could probably also just disable heuristics entirely or choose "ignore" to manually ignore the warning (e.g. XPACK/Gen or whatever for TESTDRUG.EXE below).

> PS: hxdll.zip (1 year
> old)

Remind us again what that is supposed to do? (No sources and the text file is fairly useless.)

> Which ones in particular flag it?

They didn't tell in this case. Just this info:


Da alle verwendeten Virenscanner die Datei als Malware kennzeichnen, können wir die Onlinestellung nicht direkt erlauben. Aus diesem Grund haben wir diesen Fall nun direkt an das zuständige Bundesamt für IT Sicherheit weitergeleitet. Diese werden sich die Datei in kürze genauer anschauen und zusammen mit großen IT Sicherheitsfirmen, wie z.B. Symantec, entscheiden ob die Datei eine Malware ist oder nicht. Entsprechend der Rückmeldung können wir die weitere Onlinestellung dann erlauben oder müssen auf die Entfernung rechtlich bestehen. Aber dies entscheidet, wie geschrieben, dass Bundesamt. Wir werden Sie umgehend informieren sobald wir eine Rückmeldung erhalten haben.


But a month ago ( there was a "problem" with file ENUMMODE.EXE in HXRT216.zip ), they told me:


wir haben die Datei mit folgenden Scannern geprüft:

Norton Internet Security 2012
Bitdefender 2013
ESET Pro
AVAST Enterprise
Kaspersky Antivirus 2013

Dies sind aktuell die 5 TOP Virenscanner auf dem Markt, welche auf den meisten PCs zum Einsatz kommen.


So I guess they used exactly those scanners again.

The "problem" in ENUMMODE.EXE was that the code and data section was "merged" in the link step ( to save 512 bytes space ). This is something you shouldn't do these days if your file is to be public, but back then in 2005 it was pretty innocent.

I guess I'm going to switch to a server in West Samoa.

---
MS-DOS forever!

> > Which ones in particular flag it?
>
> They didn't tell in this case. Just this info:

Not sure if this particular DKRNL32.DLL is the same as online, I haven't re-downloaded here locally. Anyways, a quick (re)scan (of the one I do have) via http://www.virustotal.com/ shows 18/43 false positives:


Antivirus             Result                          Update
--------------------------------------------------------------
Agnitum               Trojan.Monder!9aKet0RsdrA       20121121
DrWeb                 Trojan.Virtumod.9813            20121122
Fortinet              W32/Monder.DKMF!tr              20121122
Ikarus                Trojan.Win32.Monder             20121122
K7AntiVirus           Trojan                          20121121
Kaspersky             Trojan.Win32.Monder.dkmf        20121122
Kingsoft              Win32.Troj.Monder.(kcloud)      20121119
McAfee                Generic.dx!b2r4                 20121122
McAfee-GW-Edition     Generic.dx!b2r4                 20121122
Norman                W32/Suspicious_Gen2.FQPJV       20121121
nProtect              Trojan/W32.Monder.80896.DZ      20121121
Panda                 Trj/CI.A                        20121121
TheHacker             Trojan/Monder.dkmf              20121121
TrendMicro            TROJ_GEN.R42Z2JS                20121122
TrendMicro-HouseCall  TROJ_GEN.R42Z2JS                20121122
VBA32                 Trojan.Monder.dkmf              20121122
VIPRE                 Trojan.Win32.Generic!BT         20121122
ViRobot               Trojan.Win32.S.Monder.80896.B   20121122


>
> ... blah blah blah blah blah ...
>

rexx -e"do random(1,20) ; say 'Nein sprechen sie Deutsch!' ; end"

(Google Translate helps a little but not much.)

> But a month ago ( there was a "problem" with file ENUMMODE.EXE in
> HXRT216.zip ), they told me:
>
>
> ... blah blah blah blah blah ...
>

At least that part was fairly obvious. It does actually make sense to avoid false positives, esp. with the five most popular, but even better if it can be recompiled / reassembled without problematic bits (even if it's really their fault, not yours ... dumb $@%@%$Ss heuristics).

> So I guess they used exactly those scanners again.
>
> The "problem" in ENUMMODE.EXE was that the code and data section was
> "merged" in the link step ( to save 512 bytes space ). This is something
> you shouldn't do these days if your file is to be public, but back then in
> 2005 it was pretty innocent.

I can't imagine it being a big deal. They must be really dumb to just search for specific bytes only and blindly assume there is no clash in the (big, complex) real world.

> I guess I'm going to switch to a server in West Samoa.

Please don't. Or do, I have no idea if that would be better or not.

Anyways, a quick brute force attempt at isolating the problematic area was this: I copied a random kilobyte of code from further down in DKRNL32.DLL over the header. Granted, it's not valid code anymore, but it at least was an attempt to see if that was the problem area. I rescanned online via VirusTotal and now it passes with 0/42 (and not 0/43, heh, dunno why).

I don't know if that helps, but it's a small hint (maybe).

> Not sure if this particular DKRNL32.DLL is the same as online, I haven't
> re-downloaded here locally.

Okay, quick update:

No, not the same, just re-downloaded latest HXRT217.ZIP, md5sum of DKRNL32.DLL (2011-08-21) is d68b3634dc02ea0f9ea710a559e24e14 (which still flags Avast, dang it, temporarily disabling asinine realtime protection).

VirusTotal now gives 33/43 false positives! Sheesh. And to prove how incredibly dumb they are, you can change the text "This is a PE dynamic link library" and it will knock off 10 scanners (only 23/43, heh).

Well, here's a potential simple workaround: change "PE" text signature to "PX". It's only one byte (offset 0x79 or 121). Then I get 0/42 results. I can't test well on this silly laptop, but a quick test of 7ZA.EXE under DOSBox ("7za t ccbi-2~1.7z") with slightly older HX (2009-11-16, 2.16 ??) shows that it still works fine even with "PX". (Can't imagine why it wouldn't, but who knows, heh.)

P.S. In the boring ol' U.S., today is Thanksgiving. (Yes, I'm awake way too late.) I'm grateful for BTTR, Japheth, FreeDOS, DJGPP, etc. etc!

---
Know your limits.h

> Horrible that we have to work around lousy antiviruses

...

> (I didn't check, but IMHO, putting the password as plaintext in the .ZIP
> comment would at least be semi-friendly

Better idea:

- switch form ZIP to 7-ZIP
- brew a better PWD than "japheth" and hide it better
- hide your HX files into something else looking innocent (PNG? OGV? ...) Hints about suitable tools (usable in DOS) are welcome

> You could probably also just disable heuristics entirely or choose "ignore"
> to manually ignore the warning (e.g. XPACK/Gen or whatever for
> TESTDRUG.EXE below)

I don't have any problems with the file. Maybe because I don't use those useless "antivirii" at all?

> Remind us again what that is supposed to do?

nothing

> Because all the virus scanners identify the file as malware, we can not allow
> the online status directly. For this reason we have this case now be passed
> directly to the responsible Federal Office for IT Security. This is the file will
> look in more detail soon, and along with major IT security companies, such
> as Symantec decide whether the file is malware or not. According to the
> feedback we can allow more online or position then must pass law on the
> distance. But this decision, as written, that the Federal Office. We will inform
> you when we receive a response.

Remember some pretty similar "Federal Office" burning down books with "not tolerable content" just cca 80 years ago?

> I guess I'm going to switch to a server in West Samoa.

Please do

> > The "problem" in ENUMMODE.EXE was that the code and data section was
> > "merged" in the link step ( to save 512 bytes space ). This is something
> > you shouldn't do these days if your file is to be public, but back then in
> > 2005 it was pretty innocent.

> I can't imagine it being a big deal.

It is. FASM had the same "bug" too

PS: HX BUG #35:

Tiny WinFloor demo doesn't work (hangs with empty black rectangle, reacts to nothing except CTL-ALT-DEL)

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

> > Horrible that we have to work around lousy antiviruses
>
> > (I didn't check, but IMHO, putting the password as plaintext in the .ZIP
> > comment would at least be semi-friendly
>
> Better idea:
>
> - switch form ZIP to 7-ZIP

Won't work. Most good ones can unpack various archives and exe packers, esp. the open source kind (.7Z).

> - brew a better PWD than "japheth" and hide it better

.ZIP passwords are incredibly easy to crack. Also, it's a pain trying to remember a billion passwords. If the "PX" hack isn't viable, I'll understand, but so far it seems like the least painful way to fix everything, at least in my naive worldview.

Or just only password protect DKRNL32.DLL and leave others unencrypted. Then the README.1ST could tell the password to unpack the remaining file.

Or just split the actual file into several pieces and let the user manually combine it (hopefully defeating detection).

> - hide your HX files into something else looking innocent (PNG? OGV? ...)

I don't think that will work. Lots of formats have subformats inside them, so smart antiviruses probably still scan them for various things.

> Hints about suitable tools
> (usable in DOS) are
> welcome

There was an old one on FASM's forum a few years ago, perhaps by ATV, but I don't remember where. Feel free to search.

> > You could probably also just disable heuristics entirely or choose
> "ignore"
> > to manually ignore the warning (e.g. XPACK/Gen or whatever for
> > TESTDRUG.EXE below)
>
> I don't have any problems with the file. Maybe because I don't use those
> useless "antivirii" at all?

They aren't useless, just overzealous and bloated and slow. It's a sad fact of life.

> Well, here's a potential simple workaround: change "PE" text signature to
> "PX". It's only one byte (offset 0x79 or 121). Then I get 0/42 results. I
> can't test well on this silly laptop, but a quick test of 7ZA.EXE under
> DOSBox ("7za t ccbi-2~1.7z") with slightly older HX (2009-11-16, 2.16 ??)
> shows that it still works fine even with "PX". (Can't imagine why it
> wouldn't, but who knows, heh.)

Ok, thanks for the hint! However, to encrypt the whole package is probably more fool-proved. It's not totally comfortable, but IMO DOS users should be used to - and enjoy - uncomfortable weather.

---
MS-DOS forever!

> > Well, here's a potential simple workaround: change "PE" text signature
> to
> > "PX".
>
> Ok, thanks for the hint! However, to encrypt the whole package is probably
> more fool-proved. It's not totally comfortable, but IMO DOS users should be
> used to - and enjoy - uncomfortable weather.




mkdir -p /tmp/blah && cd /tmp/blah
wget http://oldhome.schmorp.de/marc/data/fcrackzip-1.0.tar.gz
tar xzf fcrackzip*gz && configure && make
wget http://www.japheth.de/Download/HX/HXRT217.zip
fcrackzip -b -c a -v -l 1-8 HXRT217.zip


BTW, I cheated somewhat as I already knew the password was all lowercase and length 8 or less. So apparently in less than 10 minutes, it's already told me "possible pw found:" correctly (though keeps running). My previous attempt was apparently expecting more fancy passwords as it's still running (single core) 37 hours later! (John the Ripper - Jumbo, after zip2john prepares it). I didn't try old fzc from Sac.Sk (DOS!) because I was hoping the other would be better / faster. fcrackzip says it's portable and free unlike fzc (encrypted, asm-only). There's an old article (from 1995?) called kocher-pkzip-attack.txt (link broken in official Info-Zip FAQ) that says PKZIP encryption is fairly weak and shouldn't be relied upon. Especially nowadays with much faster computers, better compilers, multiple cores, SIMD, and things like Amazon EC2.

I really only did this to prove a point: ZIP passwords aren't infallible. Though I don't think "cracking" a .ZIP is justified (legal, moral, etc.) in 99% of cases. Hope this doesn't offend anyone!

> > Better idea:
> > - switch form ZIP to 7-ZIP

> Won't work. Most good ones can unpack various archives

1. F-PROT DOS can't
2. 7-ZIP will slow down pwd brute-forcing by factor cca 10'000'000 and prevent plain-text attacks
3. anyway, I meant use this one together with the other ideas

> just only password protect DKRNL32.DLL and leave others unencrypted

bad idea as the others may get wormed too at any time, as some of them already used to be in the past

> > - hide your HX files into something else looking innocent (PNG? OGV? ...)

> I don't think that will work. Lots of formats have subformats

It will. There are no subformats in PNG or OGV, and if it's done well, it's impossible to provide any evidence that there is some hidden data at all

Japheth wrote:

> History HDPMI
>
> 14.12.2012, version 3.17
>
> ■ bugfix: when int 33h, ax=000Ch or ax=0014h was used by a client,
> HDPMI might have corrupted DOS memory on exit.
> ■ Linker switched to jwlink (modified wlink).
> ■ new cmdline switch -x to restrict free memory to 256MB.
>
> 20.01.2009, version 3.16
>
> ■ Assembler switched to JWasm.
>
> 01.03.2008, version 3.15
>
> ■ bugfix: int 31h, ax=507h didn't return number of processed pages
> in ECX if function failed.

COOL.

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

> > > Better idea:
> > > - switch form ZIP to 7-ZIP
>
> > Won't work. Most good ones can unpack various archives
>
> 1. F-PROT DOS can't

But most others can unpack lots of archives. (Keep in mind that, IIRC, F-Prot for DOS was discontinued circa 2006, and I'm not sure if the updated data files still work or when last workable data files were available [2009??]. In other words, I don't use it anymore. But most new viruses aren't for DOS, so it's no biggie.)

> 2. 7-ZIP will slow down pwd brute-forcing by factor cca 10'000'000 and
> prevent plain-text attacks

I don't think Japheth intends to switch to .7z format. And there are newer encryption methods for .ZIP, though I honestly like the fact that it's easy to crack (in case someone forgets).

"Tips for selecting password length" (7z.htm , sounds naive and inaccurate but whatever)

> 3. anyway, I meant use this one together with the other ideas
>
> > just only password protect DKRNL32.DLL and leave others unencrypted
>
> bad idea as the others may get wormed too at any time, as some of them
> already used to be in the past

Yeah, I forgot others gave false positives too. Still, it shouldn't be too too hard to mask the warnings, but I don't think it's worth my time, esp. since Japheth seems happy with his password .ZIP.

> > > - hide your HX files into something else looking innocent (PNG? OGV?
> ...)
>
> > I don't think that will work. Lots of formats have subformats
>
> It will. There are no subformats in PNG or OGV, and if it's done well, it's
> impossible to provide any evidence that there is some hidden data at all
>

I don't think he will go for that. That's way too much indirection anyways, esp. for such a "clean" project.

> Japheth wrote:
>
> > History HDPMI
> >
> > 14.12.2012, version 3.17
>
> COOL.

Did you also notice that JWasm and JWlink had new releases?

> Yeah, I forgot others gave false positives too. Still, it shouldn't be too
> too hard to mask the warnings, but I don't think it's worth my time, esp.
> since Japheth seems happy with his password .ZIP.

I'm not "happy", but also don't want to invest more than a reasonable amount of time - it's not one of the things that I regard as "extremely interesting".

> Did you also notice that JWasm and JWlink had new releases?

the hdpmi update was needed because DOS4/GW apps - including the Watcom debugger WD - have difficulties with lots of RAM.

---
MS-DOS forever!

> And there are newer encryption methods for .ZIP

YES, but you need 7-ZIP anyway to extract such "ZIP" 's because:

1. PKZIP 2.50 can't
2. Wing-ZIP doesn't run in DOS (FYI: Wing-ZIP 17 released. What's new: increased bloat to 100 MiB )

> "Tips
> for selecting password length" (7z.htm , sounds naive and inaccurate
> but whatever)

It's correct. Igor ASSUME's that ML will continue working to the infinity. RTFF

> I don't think he will go for that. That's way too much indirection anyways,
> esp. for such a "clean" project.

It's less bad than providing evidence of innocence to the "federal office"

> Did you also notice that JWasm and JWlink had new releases?

YES, JAWASM 2.09 is out, and JAWASM 2.10 pre-release too, fixing multiple critical BUG's of 2.09. http://japheth.de/Download/JWasm/

Maybe there will be a release of HX 2.17 final too?

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

> Maybe there will be a release of HX 2.17 final too?

Yes. It has to wait until there exists a release version of jwlink.

---
MS-DOS forever!

> > Yeah, I forgot others gave false positives too. Still, it shouldn't be
> too
> > too hard to mask the warnings, but I don't think it's worth my time,
> esp.
> > since Japheth seems happy with his password .ZIP.
>
> I'm not "happy", but also don't want to invest more than a reasonable
> amount of time - it's not one of the things that I regard as "extremely
> interesting".

I would imagine that avoiding HX being flagged / deleted would be important, but I do also understand that it's more of their problem than yours. (One file on VirusTotal reported "VIRUS_UNKNOWN", heh, it "knows" it's a virus but doesn't know what or why or how??)

I also wonder at why they all have the same error. Do they share databases or test cases? They must. I hate this so badly, but whatever, unless "we" (eh?) manually work around it and/or heavily nag the antivirus people, what can we do?

> > Did you also notice that JWasm and JWlink had new releases?
>
> the hdpmi update was needed because DOS4/GW apps - including the Watcom
> debugger WD - have difficulties with lots of RAM.

I've never really used it, dunno. DOS386 claims it doesn't work (well, if at all) under FreeDOS. I don't know what specifically you mean here (DOS4GW.EXE proper? OpenWatcom malloc?). But I do know that dumb ol' paq8o8z reportedly used a lot more MBs of RAM with OW builds than DJGPP, presumably due to differing malloc implementation, page size rounding, or whatever.

> > And there are newer encryption methods for .ZIP
>
> YES, but you need 7-ZIP anyway to extract such "ZIP" 's because:
>
> 1. PKZIP 2.50 can't

Maybe you specifically need 7-Zip in DOS, maybe not. Dunno what else is out there or how many versions of other tools (cmdline) work under HX. AFAIK, there were (at one time) two competing encryption methods in .ZIP.

Not that I would mind if Japheth switched to .7z, but he doesn't discuss these things with me. It's not my call. I doubt you can convince him.

> 2. Wing-ZIP doesn't run in DOS (FYI: Wing-ZIP 17 released. What's new:
> increased bloat to 100
> MiB )

Have you ever tried any of them under HXGUI? (shrug) I mean, who knows what works, heavily doubt it, but I guess it's possible (aren't there cmdline tools add-ons?).

But yes, you're right, a quick search on Sac.SK shows a lot of WinZIP versions, from 1997 (Win 3.1, v6.3, 629 kb) to 2005 (Win95-XP, v9.0 SR1, 4077 kb) to 2010 ("Windows", v14.0, 13837 kb) to 2011 ("Windows", v15.5, 30254 kb) to 2012 (actually it seems 100 MB is both 32-bit and 64-bit installer, but you can still get them separately for half that each, heh, still very bloated, dunno why, quite ironic).

> > "Tips
> > for selecting password length" (7z.htm , sounds naive and
> inaccurate
> > but whatever)
>
> It's correct. Igor ASSUME's that
> ML will continue
> working to the infinity. RTFF

There's no way I believe those stats. And most people don't have anything worth password protecting anyways. With Amazon EC2, IBM Roadrunner, etc., it's probably incorrect to pretend that lots of governments (or Anonymous or whoever) don't have easy access to various brute force methods to crack anyone's data. Though I'm fairly noobish and don't do anything (useful or otherwise), so I'm pretty sure the aliens / criminals / governments don't give a crap about me.

> Maybe there will be a release of HX 2.17 final too?

With hotfix to disable EMS, I assume.

> > > "Tips for selecting password length" (7z.htm , sounds naive and inaccurate but whatever)
> >
> > It's correct. Igor ASSUME's that
> > ML will continue
> > working to the infinity. RTFF
>
> There's no way I believe those stats. And most people don't have anything
> worth password protecting anyways. With Amazon EC2, IBM Roadrunner, etc.,
> it's probably incorrect to pretend that lots of governments (or Anonymous
> or whoever) don't have easy access to various brute force methods to crack
> anyone's data.

25-GPU cluster cracks every standard Windows password in <6 hours

> "The five-server system uses a relatively new package of virtualization
> software that harnesses the power of 25 AMD Radeon graphics cards. It
> achieves the 350 billion-guess-per-second speed when cracking password
> hashes generated by the NTLM cryptographic algorithm that Microsoft has
> included in every version of Windows since Server 2003. As a result,
> it can try an astounding 95**8 combinations in just 5.5 hours, enough to
> brute force every possible eight-character password containing upper-
> and lower-case letters, digits, and symbols."

> > Well, here's a potential simple workaround: change "PE" text signature
> to
> > "PX". It's only one byte (offset 0x79 or 121). Then I get 0/42 results.
> I
> > can't test well on this silly laptop, but a quick test of 7ZA.EXE under
> > DOSBox ("7za t ccbi-2~1.7z") with slightly older HX (2009-11-16, 2.16
> ??)
> > shows that it still works fine even with "PX". (Can't imagine why it
> > wouldn't, but who knows, heh.)
>
> Ok, thanks for the hint! However, to encrypt the whole package is probably
> more fool-proved. It's not totally comfortable, but IMO DOS users should be
> used to - and enjoy - uncomfortable weather.

I believe that the virus-scanning software changes its scanning strategy when there is no valid PE header. While the removal of a PE header might be a working solution, it would impact the ability to find a real virus in DKRNL32.DLL in the future.

Here is a more subtle change that helps to reduce the false virus reports. I changed "KERNEL32.DLL" to "KERNEL32.dll" at offset 0x106D2 of the v216 version of DKRNL32.DLL. The results at virustotal.com dropped to 8/43. All of the generic errors disappeared, and only the Virumonde trojan reports remained.

I didn't test the resulting DLL yet. My time has been short lately. I have wanted to use HX to build the DOS-based diagnostics I use in my company's lab, but my apps need to survive a McAfee virus scan.

> I believe that the virus-scanning software changes its scanning strategy
> when there is no valid PE header.

It doesn't really help - just makes a few warnings disappear.

> Here is a more subtle change that helps to reduce the false virus reports.
> I changed "KERNEL32.DLL" to "KERNEL32.dll" at offset 0x106D2 of the v216
> version of DKRNL32.DLL. The results at virustotal.com dropped to 8/43. All
> of the generic errors disappeared, and only the Virumonde trojan reports
> remained.

I'll try.

---
MS-DOS forever!

FYI, FFMPEG 1.1.1 8 MiB works almost in DOS, and even FFPLAY does



Tiny problems:

# M$WCRT.DLL (must be from XP, ME is not acceptable)
# More missing DLL's (get 3 KiB)
# Missing imports (DPMILDR=128)
# Crash at earliest run (see report), subsequently "fixed" ???
# Waits for keypress (in XP it doesn't)
# Sometimes hangs on exit (push CTL-ALT-DEL -> BOOM, but output file is 100% correct)

CRASH

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

INNOUNP can't extract or even detect INNO 5.xx files under HX ...

... because ...

... yeah ...

... "LoadLibraryEx" ignores the "LOAD_LIBRARY_AS_DATAFILE" flag (like any other flags).

PS: patch the base address from $0040'0000 to some high value before extracting

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

> ... "LoadLibraryEx" ignores the "LOAD_LIBRARY_AS_DATAFILE" flag (like any
> other flags).

Good to know. I see that you have become a Windoze expert.

I suggest that you implement the functionality in loadlibx.asm ( there's no reason to bloat dpmild32 with such things ). It's a relatively simple thing, might be done in 50 lines of code. I will happily add your additions to HX and you'll be mentioned as contributor in the readme!

---
MS-DOS forever!

Sorry for bumping this HORRROR-thread, but there are 3 more:

#3333 : apart from the GDI crashing (PF) BUG (see several 1'000'000'000's posts above), there is a similar one in DRDDRDRAW,DLL too, investigated by Sherpya : BUG

#3334: apart from the 7-ZIP crypt+compression crashing (PF) BUG (see several 1'000'000'000's posts above), there is a 7-ZIP decrypt+decompression garbage BUG too

#3335: DPMILD32 crashes (GPF) with a long commandline:



PS: EDR-DOS also crashes with cca 500 Byte's commandline coming from a BAT'tery file ... but this testcase crashes DPMILD32 only and not DOS alone :-\

PPSS: I discovered this one accidentally ... when trying to "break" my excellent PSTRING example ... I couldn't "break" my code, but could "break" DPMILD32 instead

http://board.flatassembler.net/topic.php?p=156560#156560 (link inside "TESTCMPS.ASM" is bad, the only known BUG so far)

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

ReactorOS 0.3.16 is out:

"ReactOS-0.3.16-REL-live.zip" 55'714'743
A6DFBC70892DA398699F3F79A033D211

"ReactOS-LiveCD.iso" 179'482'624 2014-02-02 20:27
FFF9313045A22851F30782DF7F6A9B9C

"msvcrt.dll" 580'096 2014-01-03 02:14
D9EB'3111'B9F2'DFE1'DEFE'A705'85D0'2E81

What's new:

* it doesn't work anymore (see shot)
* new MSVCRT.DLL (but still not good enough for HX ... 9 missing imports) (see shot)

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

> ReactorOS 0.3.16 is out:
>
> "ReactOS-0.3.16-REL-live.zip" 55'714'743
> A6DFBC70892DA398699F3F79A033D211
>
> "ReactOS-LiveCD.iso" 179'482'624 2014-02-02 20:27
> FFF9313045A22851F30782DF7F6A9B9C
>
> "msvcrt.dll" 580'096 2014-01-03 02:14
> D9EB'3111'B9F2'DFE1'DEFE'A705'85D0'2E81

I just tried this with Oxford Oberon, but it still doesn't work (same as 0.3.15). I have no idea why 0.3.14 accidentally works okay in this case.