DOS ain't dead

What about adding a virtual memory into HDPMI32 like CWSDPMI has? Windows programs usually don't care about enough memory - they rely on virtual memory services provided by win kernel. There can be unpredictable results in case when application tries to allocate more memory than is available.

> What about adding a virtual memory into HDPMI32 like CWSDPMI has? Windows
> programs usually don't care about enough memory - they rely on virtual
> memory services provided by win kernel. There can be unpredictable results
> in case when application tries to allocate more memory than is available.

Last I heard, Japheth disliked such implementation in CWSDPMI (and maybe the idea in general for his HDPMI tools).

Of course, CWSDPMI really only implemented it because (last I heard) it started on such old machines (386) w/ low memory that it was sorely needed in order to compile most C++ apps.

I think DPMIONE supports swapping, but I've never tested it. (Anyone?)

---
Know your limits.h

> There can be unpredictable results in case when application tries to allocate
> more memory than is available.

Yes, all poorly written applications can give "unpredictable results". Smart applications catch those "out of memory" errors and report them to the user.

> What about adding a virtual memory into HDPMI32 like CWSDPMI has?

Virtual memory was crucial in the days of 2,4,8 MB machines. Nowadays it's far less important. And IMO providing virtual memory is not the task of a DPMI host if it is possible to implement it in cpu ring 3. And with HDPMI, it CAN be implemented that way.

> Windows programs usually don't care about enough memory - they rely
> on virtual memory services provided by win kernel.

I don't know what the majority of Windows programs do. But I usually have disabled virtual memory when running Windows and have no problems so far.

---
MS-DOS forever!

> Of course, CWSDPMI really only implemented it because (last I heard) it
> started on such old machines (386) w/ low memory that it was sorely needed
> in order to compile most C++ apps.

Badly designed GCC relied on it on Loonix so DGJPP1 implemented it as well ... later CWSDPMI ... and it became the absolute default for all DGJPP applications

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

> What about adding a virtual memory into HDPMI32 like CWSDPMI has?

No SWAP is a feature

> Windows programs usually don't care about enough memory - they rely
> on virtual memory services provided by win kernel.

Somewhat true ... but

> There can be unpredictable results in case when application
> tries to allocate more memory than is available.

The results are pretty predictable and range from "desperately slow" to "unusably slow"

I wonder whether this request comes because of

- running of Win32 apps on HX (1)
or
- because of Blocek (2)

(1) I had no problem with HDPMI. Useful apps do work well. There are some very poorly designed apps (like "XVI32" file editor and several clones of it) that can "edit file of any size" - before editing you must "open" it, means copy the complete file into swapfile taking 5 minutes or more ... editing is slow as hell ... and finally complete file must be copied back. No loss if such stuff doesn't work on HX and never will. Also, there are several archivers (PAQ/KGB) NOT protected from swap, means you "can" compress with the "insane" level using 2 GiB of "memory" on a 512 MiB machine - but don't expect more 1 byte per second performance YES, you will have to kill it after several hours of HD running and no visible progress HDPMI32/HX is much better here - provides almost all memory to the app and if it's still not enough, the app aborts.

(2) This bug really must be fixed. I don't know whether it comes from your source, the "VendomGFX" or FPC code, but it's NOT a bug of HDPMI32. "fixing" a bug by creating an "anti-bug" never was a good idea: 25 years ago, when designing the 80286 PC, because of 1 or 2 buggy 8086 applications accessing (inexistent) memory > 1 MiB and relying the accesses to get mapped down to lowest 64 KiB of memory, the horrible A20 BUG was invented ... and persists up to now

Swapping / temp file usage can be much better implemented at application level, as used to be done on well designed 8086 software

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

> Badly designed GCC relied on it on Loonix so DGJPP1 implemented it as well

1) Did you ever design a real compiler? If not, then don't tell, that GCC is designed badly.
2) It's called DJGPP.

---
Forum admin

> > There can be unpredictable results in case when application
> > tries to allocate more memory than is available.
>
> The results are pretty predictable and range from "desperately slow" to
> "unusably slow"

No, that's only half the truth.

---
Forum admin

> No, that's only half the truth.

Please tell us the other half!

---
MS-DOS forever!

> > No, that's only half the truth.
>
> Please tell us the other half!

Crashes, incorrect results, ...?!

EDIT: Japheth, could you please have a look at HX 2.12 vs HT Editor 2.0.8?! Thanks!

---
Forum admin

> EDIT: Japheth, could you please have a look at HX 2.12 vs
> HT Editor 2.0.8?! Thanks!

There is not much to say: I downloaded this file ht-2.0.8-win32.exe and when I start it, nothing happens, nothing is displayed and I have to close the dos box the hard way. Not very promising . Seems to be a Unicode application, which is not really supported by hx. If you can create an ANSI version ...

---
MS-DOS forever!

> There is not much to say: I downloaded this file ht-2.0.8-win32.exe and
> when I start it, nothing happens, nothing is displayed and I have to close

Um, it "worked" for me on my ThinkPad 770 or in Bochs 2.3.

> the dos box the hard way. Not very promising . Seems to be a Unicode
> application, which is not really supported by hx. If you can create an
> ANSI version ...

OK. Let's close the HT thread. We still have Biew.

---
Forum admin

> > There is not much to say: I downloaded this file ht-2.0.8-win32.exe and
> > when I start it, nothing happens, nothing is displayed and I have to
> close
>
> Um, it "worked" for me on my ThinkPad 770 or in Bochs 2.3.

It works in WinXP, but not in Win9x.

In DOS, I'm getting a screen with very strange menus. This is due to the conversion of Unicode (UTF-16?) to ANSI/OEM not fully working in HX. Improving this support is on my todo list, but it will take time.

---
MS-DOS forever!

> It works in WinXP, but not in Win9x.

It never crashed for you?

> In DOS, I'm getting a screen with very strange menus. This is due to the

That's "normal".

---
Forum admin

> It never crashed for you?

Yes, it does crash in DOS.

> > In DOS, I'm getting a screen with very strange menus. This is due to
> the
>
> That's "normal".

I have just implemented conversion from UTF-16 to OEM for the "drawing" chars ... it still crashes of course, but it crashes now "more nicely".

---
MS-DOS forever!

> This is due to the conversion of Unicode (UTF-16?) to ANSI/OEM not fully working in HX.

About Unicode, see also FASM CPUID thread (with very nice screenshots):

http://board.flatassembler.net/topic.php?t=7171

(the CR/LF/TAB bug of HX is fixed now )

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

> you ever design a real compiler? If not, then don't tell, that GCC is designed badly

It's not trivial at all to design a compiler of 20 languages, 20 CPU's and 40 OS'es (incl. "OS"'es)

OTOH using temp files at application level instead of hogging huge amount of "memory" from the "kernel" would have been extremely trivial compared to this

> It's called DJGPP.

Yeah ... the "natural" alphabetical sortorder

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

> I have just implemented conversion from UTF-16 to OEM for the "drawing"
> chars ... it still crashes of course, but it crashes now "more nicely".

the crash - at least the one which occured when loading a binary - was due to a bug in emulation of Win32 function OemToCharBuff(). It has been fixed in current hxrtd.zip.

---
MS-DOS forever!

> the crash - at least the one which occured when loading a binary - was due
> to a bug in emulation of Win32 function OemToCharBuff(). It has been fixed
> in current hxrtd.zip.

Looks great!

But I still get this message in Bochs 2.3, when loading HT.EXE for the first time after reset:

dkrnl32: exception C0000092, flags=0 occured at BF:37513A
        ax=325EB4 bx=348000 cx=3261E2 dx=3792B8
        si=0 di=34721D bp=325ECC sp=325EB4
        ip = Module 'msvcrt.dll'+2E13A
dkrnl32: fatal exit!

Consecutive runs are OK.

---
Forum admin

> But I still get this message in Bochs 2.3, when loading
> HT.EXE for the first time after reset:
>
> dkrnl32: exception C0000092, flags=0 occured at BF:37513A
> ax=325EB4 bx=348000 cx=3261E2 dx=3792B8
> si=0 di=34721D bp=325ECC sp=325EB4
> ip = Module 'msvcrt.dll'+2E13A
> dkrnl32: fatal exit!
>
> Consecutive runs are OK.

I don't get this error running HT in true DOS and in DOS under VMware. So it must be a bug in Bochs.

---
MS-DOS forever!