DOS ain't dead

BUG? What BUG? (DOSX)

posted by DOS386, 14.06.2008, 15:02

> have severe difficulties to accept this as a bug

OK ... have severe doubt whether a deadlock can / should be considered as a desirable effect

> Then just don't do that!

Thanks for the hint ... trivial as hell (since I already know what the reason of the deadlock is, 3 days ago I didn't ) ... but this won't damage the fact that DPMILD32 has a bug

> Please provide a real Win32 application which doesn't run in HX

IIRC real Win32 applications ( Mozilla Firefox, Adobe Photosh**, IDE of WATCOM/CC386/VCC2010/... , ... ) don't run on HX anyway because of lack of the high level GUY API And since 99.99% of the "market" is occupied by M$-linker and LD, apparently setting the bit, there is not much space to find one

> BUG? What BUG?

The bug I already had isolated and exhaustively described above ?

BTW, it's of course not my BUG ... I "imported" it from Tomasz's DLL example ... and since nobody has complained so far one can assume that all versions of Windaube + possibly ReactOS + possibly Wine (or even Beer ??? ) don't care about this bit. And, if you want to be very rigid about 100% PE compliance, you can raise an error message rather than a deadlock

I wonder how the answer might have differed if I just pointed about Tomasz's DLL example not working with HX, without investigating / revealing why

> My fantastic deb32f debugger still uses DPMILD32 and 16bit dlls.

I see : This program requires Microsoft Windows ... anyway, roots of this debugger seem to be very old, parts have been converted to PE already, and IIRC cca 2 years ago you wrote something like "needs a redesign, already for 10 years" ...

> To gain 2 kB extended-memory/disk space?

Maybe a bit more ?

> And possibly introducing new bugs during the removal?

It's no way critical just the DPMILD32 source seems to be a bit ancient, PE support is "hacked" on the top of NE, and seems before a PE can be loaded, first the MZ header is read, analyzed, seeking to "next level", searching for "NE", failure, close the file, if PE is enabled at all, reopen the file, re-read MZ header, re-seek, re-read "next level" ... no big problem, since the debugger uses NE it's of course NOT a good idea for now

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

Complete thread:

• [BUG] unreadable reloXection deadlocks DPMILD32 - DOS386, 12.06.2008, 23:58 (DOSX)
  • BUG? What BUG? - Japheth, 13.06.2008, 08:40
    • BUG? What BUG? - DOS386, 14.06.2008, 15:02
      • BUG? What BUG? - Japheth, 14.06.2008, 15:57
        • 1. Closed: NOT a BUG | 2. Closed: NOT a BUG | 3. Closed: NB - DOS386, 19.06.2008, 09:04
          • 1. Closed: NOT a BUG | 2. Closed: NOT a BUG | 3. Closed: NB - DOS386, 19.06.2008, 09:06
          • 1. Closed: NOT a BUG | 2. Closed: NOT a BUG | 3. Closed: NB - Japheth, 19.06.2008, 10:29
            • 1. Closed: NOT a BUG | 2. Closed: NOT a BUG | 3. Closed: NB - DOS386, 20.06.2008, 09:51
            • Discovered a NEW BUG in DPMILD32 - DOS386, 18.12.2009, 03:21
              • Discovered a NEW BUG in DPMILD32 - Japheth, 19.12.2009, 07:44
                • Discovered a NEW BUG in DPMILD32 - DOS386, 19.12.2009, 14:04