DOS ain't dead

I'm having a bit of a problem with Protected Mode DOS. I have developed an application using Borland Pascal 7.01 + Turbo Vision. Initially I compiled for Real Mode (but running in an XP command prompt) and I started getting a stack overflow error. So I doubled the stack size with no change except I then got a heap overflow error.

So I thought that if I compiled for a Protected Mode target - given all that extra memory that would be available - the heap overflow error should disappear. So, after placing the required PM Borland managers in the app directory (DPMI16BO.OVL and RTM.EXE) I tried again in an XP command prompt. This time the app didn't load and I received an "Unhandled exception at 0020 1A9E Err 0002".

So I thought maybe I need 'real' DOS to make this work. So I powered up FreeDOS (with EMM.EXE and HIMEM.SYS) and ran the app again - but with exactly the same result - "Unhandled exception at 0020 1A9E Err 0002". I swapped EMM.EXE and HIMEM.SYS for JEMMEX.EXE. This time launching the app crashed FreeDOS completely.

So am I wrong to believe that Protected Mode would give me more Heap space? If I'm not then my app has other 'issues', obviously!
I did a search on Google for this error and came up with a discussion of the same Error 0002 from about 6 years ago on the FreeDOS discussion group and which also mentioned BP 7. So the supplementary question is: are there issues with FreeDOS and/or BP 7 with respect to Protected Mode?

TIA

---
Paul
Melbourne, Australia

> So am I wrong to believe that Protected Mode would give me more Heap space?

I wouldn't think so, but perhaps certain things (static strings??) are still limited to a single 64 kb segment. Dunno.

> If I'm not then my app has other 'issues', obviously!

Most likely, but it could be a bug (in FreeDOS or BP7, as neither is perfect and known bugs do exist).

> I did a search on Google for this error and came up with a discussion of
> the same Error 0002 from about 6 years ago on the FreeDOS discussion group
> and which also mentioned BP 7. So the supplementary question is: are there
> issues with FreeDOS and/or BP 7 with respect to Protected Mode?

I wouldn't think so. But perhaps you had other conflicting software (try a cleaner boot without a lot of TSRs or drivers or memory managers). XP's NTVDM is pretty good re: 16-bit pmode (DPMI 0.9), but perhaps it couldn't handle whatever (rare but happens sometimes). But since you tested in raw DOS also, I'm skeptical. I assume you weren't shelling out from a 32-bit DPMI app or anything goofy like that, as obviously that's unsupported.

Try creating as small a testcase (source snippet) as possible and try again. Try to isolate the problem. Also be sure (in DOS) to load HDPMI16.EXE first and see if that helps. (Otherwise, sadly I can't help, I don't have BP7.)

Rugxulo:

> I assume you weren't shelling out from a 32-bit
> DPMI app or anything goofy like that, as obviously that's unsupported.

No, I am launching straight from the executable.

> Try creating as small a testcase (source snippet) as possible and try
> again. Try to isolate the problem.

Yes, I'll do this just to test out the Protected Mode environment.

>Also be sure (in DOS) to load HDPMI16.EXE first and see if that helps.

Would I load this as well as the Borland DPMI servers (DPMI16BI.OVL and RTM.EXE)?

>(Otherwise, sadly I can't help, I don't have BP7.)

No problem - thanks for the suggestions and response.

---
Paul
Melbourne, Australia

> >Also be sure (in DOS) to load HDPMI16.EXE first and see if that helps.
>
> Would I load this as well as the Borland DPMI servers (DPMI16BI.OVL and
> RTM.EXE)?

Just load it manually before running the app (or use "-r" for resident use if needed more than one). I don't think you should have to do anything else (e.g., you won't have to mess with Borland files).

> Just load it manually before running the app (or use "-r" for resident use
> if needed more than one). I don't think you should have to do anything else
> (e.g., you won't have to mess with Borland files).

Nah, my app won't load - it looks for RTM.EXE.

I've been doing some Protected Mode test progs which still give me heap overflow errors. I'm mystified as to why, but I won't trouble this forum with them since they don't appear to have any relation to DOS or FreeDOS.

Thanks for your help.

---
Paul
Melbourne, Australia

> So am I wrong to believe that Protected Mode would give me more Heap space?

I don't know TP, but it might very well be that stack and (local) heap have to share a 64 kB (DGROUP) segment in both real- and protected-mode.

However, it should be possible to additionally create "far heaps", which are not limited to 64 kB - I guess this should be possible in both real- and protected-mode. Of course, "far heaps" will return FAR ( == 4 byte ) pointers.

---
MS-DOS forever!

> are there issues with FreeDOS and/or BP 7 with respect to Protected Mode?

"with FreeDOS" would apply if the BP thing worked in EDR-DOS

The issue is about BP's 16-bit DPMI only ... ever considered FreePASCAL ?

PS: don't use HIMEM+EMM from FreeDOS 1.0 or DR-DOS as they most likely will boost possible PM problems.

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

> > So am I wrong to believe that Protected Mode would give me more Heap
> space?
>
> I don't know TP, but it might very well be that stack and (local) heap have
> to share a 64 kB (DGROUP) segment in both real- and protected-mode.
>
> However, it should be possible to additionally create "far heaps", which
> are not limited to 64 kB - I guess this should be possible in both real-
> and protected-mode. Of course, "far heaps" will return FAR ( == 4 byte )
> pointers.

Japheth: I probably need to check and clarify with ex-Borlanders on the Delphi/Pascal newsgroups. I guess I'll probably be able to get a definitive answer there.

Thanks

---
Paul
Melbourne, Australia

> The issue is about BP's 16-bit DPMI only ... ever considered FreePASCAL ?

Yes. I have FreePascal also but I'm using Turbo Vision and FP's equivalent (FreeVision)is not 100% compatible with Turbo Vision e.g. stuff that works in TV doesn't work in FV.

> PS: don't use HIMEM+EMM from FreeDOS 1.0 or DR-DOS as they most likely will
> boost possible PM problems.

I will use JEMMEX.EXE then.

Thanks

---
Paul
Melbourne, Australia

> Japheth: I probably need to check and clarify with ex-Borlanders on the
> Delphi/Pascal newsgroups. I guess I'll probably be able to get a definitive
> answer there.

Yes. If no: there should exist a tool TDUMP.EXE. Use it with your EXE as argument and post the output here. It might be helpful.

---
MS-DOS forever!

> > The issue is about BP's 16-bit DPMI only ... ever considered FreePASCAL
> ?
>
> Yes. I have FreePascal also but I'm using Turbo Vision and FP's equivalent
> (FreeVision)is not 100% compatible with Turbo Vision e.g. stuff that works
> in TV doesn't work in FV.

What are the bugreport numbers ?

Afaik the only known issue is the missing colorselection dialog, that Borland licensees can probably just copy and minimally adapt from BP sources.

> > So am I wrong to believe that Protected Mode would give me more Heap
> space?
>
> I don't know TP, but it might very well be that stack and (local) heap have
> to share a 64 kB (DGROUP) segment in both real- and protected-mode.

Afaik TP has one segment for (static)data for all compilation units combined, both initialized and not, and stack and heap are both FAR and grow from opposite parts of the memory.

In protected mode there IIRC is some segment descriptor limit (8192?) though, so sometimes programs with very finely grained allocations don't gain from PM because they exchange the memory limitation for the segment descriptor one.

IIRC there are ways (and alternate dpmi/rtm's) to do something about it
I'm not that deep into the PM bits though, since I quickly moved to 32-bit afterwards.

The problems sound a bit strange though, since stack and heap combined should be like in the magnitude of 16MB in PM . One wonders if there is not some infinite recursion or datacorruption somewhere.

> However, it should be possible to additionally create "far heaps", which
> are not limited to 64 kB - I guess this should be possible in both real-
> and protected-mode. Of course, "far heaps" will return FAR ( == 4 byte )
> pointers.

Heap and stack are afaik both FAR. So afaik it is like the C "large" model. (Huge adds a data segment per compilation unit iirc, which is not supported by C)

1) It seems you do some invalid manipulations with pointers to variables.
It is extremely unlikely you found a bug in Borland pascal.
You have to carefully debug your code and not to loose time when blaming FreeDOS or BP.

2) In protected mode under BP you of course have more heap space. However you are still limited in size of variable (can't excess 64KB), in global variables on stack (max 64KB) and local stacks (valid inside only one unit)

---
DOS-u-akbar!

> 1) It seems you do some invalid manipulations with pointers to variables.
> It is extremely unlikely you found a bug in Borland pascal.
> You have to carefully debug your code and not to loose time when blaming
> FreeDOS or BP.

Laaca: I'm not 'blaming' BP or FreeDOS - I'm trying to understand why I'm getting the error. I am quite prepared to accept that my app design and implementation is at fault but, after hours of poring over the code, I can't see anything which is obviously at fault. I have been very careful to Dispose of any structures created by using New once they have served their purpose.

> 2) In protected mode under BP you of course have more heap space. However
> you are still limited in size of variable (can't excess 64KB), in global
> variables on stack (max 64KB) and local stacks (valid inside only one unit)

Indeed, this may well be the problem. At this stage, if it is the problem, I'm not sure how to overcome it.

Thanks.

---
Paul
Melbourne, Australia

> I don't know TP, but it might very well be that stack and (local) heap
> have to share a 64 kB (DGROUP) segment in both real- and protected-mode.
> Afaik TP has one segment for (static)data for all compilation units
> combined, both initialized and not, and stack and heap are both FAR and
> grow from opposite parts of the memory.
>

Marcov: it may well be that I have too much data. At this stage I'm not sure how to get over that hurdle. I can't see anything in my code that is obviously incorrect.

Thanks

---
Paul
Melbourne, Australia

> > Japheth: I probably need to check and clarify with ex-Borlanders on the
> > Delphi/Pascal newsgroups. I guess I'll probably be able to get a
> definitive
> > answer there.
>
> Yes. If no: there should exist a tool TDUMP.EXE. Use it with your EXE as
> argument and post the output here. It might be helpful.

Japheth: no obvious answers from Borland/Delphi people. I have a TDUMP listing of the app (verbose display) which is 585 KB in length. Is there any way to post this as an attachment to a forum posting?

---
Paul
Melbourne, Australia

> Japheth: no obvious answers from Borland/Delphi people. I have a TDUMP
> listing of the app (verbose display) which is 585 KB in length. Is there
> any way to post this as an attachment to a forum posting?

We probably don't need it in "verbose" format. However, you can send the full dump to the contact address found at http://www.japheth.de.

---
MS-DOS forever!

OK, I think I've found the cause of the problem. I'm using a 3rd party B-Tree database system which has a heap setting to reserve space for its own use. I've experimented with this setting and minimized the B-Tree's use of the heap which resulted in avoiding an 'out of memory' error which I was receiving previously.

Hopefully this has solved the problem.

---
Paul
Melbourne, Australia

> Marcov: it may well be that I have too much data. At this stage I'm not
> sure how to get over that hurdle. I can't see anything in my code that is
> obviously incorrect.

You didn't reply what went wrong with FPC (e.g. was it runtime or while compiling?). As said I'm not aware of problems, but I do realize that if you have a dirty codebase is harder to port to 32-bit.

If Japeth doesn't find something ( I assume he will), then I would try to get it working (or parts working) with freepascal, and to compile as much as possible with -gtt, range checking etc; to validate as much as possible.

Just to see if you can dig up pointers to what could be wrong.

>
> We probably don't need it in "verbose" format. However, you can send the
> full dump to the contact address found at
> http://www.japheth.de.

Japheth: thanks for the offer. I've just posted a message indicating that I think I've found the cause of the problem, namely a heap usage setting in a 3rd party B-Tree system I'm using. Hopefully this will solve the problem.

I'll hold off sending the dump to you on the assumption that this solution holds.

Thanks again.

---
Paul
Melbourne, Australia

> You didn't reply what went wrong with FPC (e.g. was it runtime or while
> compiling?). As said I'm not aware of problems, but I do realize that if
> you have a dirty codebase is harder to port to 32-bit.

Marcov: it compiled OK but the run time result was incorrect. I posted the code snippet on the FreePascal FreeVision board about 2 months ago but had no reply.

Given that I was told that Free Vision is not 100% compatible with Turbo Vision and that there is no documentation for Free Vision I did not persist.

> If Japeth doesn't find something ( I assume he will), then I would try to
> get it working (or parts working) with freepascal, and to compile as much
> as possible with -gtt, range checking etc; to validate as much as
> possible.
>
> Just to see if you can dig up pointers to what could be wrong.

See my other recent posts. I have changed a heap usage setting in a 3rd party B-Tree system I'm using and this seems to have solved the problem, both for the real and protected mode compilations of my app.

---
Paul
Melbourne, Australia

> > You didn't reply what went wrong with FPC (e.g. was it runtime or while
> > compiling?). As said I'm not aware of problems, but I do realize that if
> > you have a dirty codebase is harder to port to 32-bit.
>
> Marcov: it compiled OK but the run time result was incorrect. I posted the
> code snippet on the FreePascal FreeVision board about 2 months ago but had
> no reply.

Yeah, those boards are not terribly popular. I looked it up, but it is nothing compilable, just fragements so it is hard to do a quick test.

If you have a small compilable example you can also sent it to fpc at pascalprogramming dot org

Note that the place to report bugs is http://bugs.freepascal.org

> Given that I was told that Free Vision is not 100% compatible with Turbo
> Vision

Nothing is 100% compatible. It is more than close enough as far as I know though. I think your expectations played tricks with you here.

>and that there is no documentation for Free Vision I did not
> persist.

Partially that is because it is compatible enough to use BP's.

> See my other recent posts. I have changed a heap usage setting in a 3rd
> party B-Tree system I'm using and this seems to have solved the problem,
> both for the real and protected mode compilations of my app.

I saw yes. It was posted one or two minutes before my reply, so it crossed.

> Yeah, those boards are not terribly popular. I looked it up, but it is
> nothing compilable, just fragements so it is hard to do a quick test.

> >and that there is no documentation for Free Vision I did not
> > persist.
>
> Partially that is because it is compatible enough to use BP's.
>
Marcov: frankly Turbo Vision presents quite a steep learning curve. If I am using the TV Programmer's Guide to develop an app with Free Vision and something doesn't work as expected what's wrong - an error in my code or an incompatibility between FV and TV?

I'm not really prepared to add a further complicating factor - and delay - in trying to figure it out, particularly as my experience with the FV message board - in getting a response - wasn't particularly good.

But thanks for offering to run tests. I've finished the app with TV so there's no need now.

---
Paul
Melbourne, Australia

> > Partially that is because it is compatible enough to use BP's.
> >
> Marcov: frankly Turbo Vision presents quite a steep learning curve. If I am
> using the TV Programmer's Guide to develop an app with Free Vision and
> something doesn't work as expected what's wrong - an error in my code or an
> incompatibility between FV and TV?

Well obviously test with TV in paralel for a while till you are sure.

> I'm not really prepared to add a further complicating factor - and delay -
> in trying to figure it out, particularly as my experience with the FV
> message board - in getting a response - wasn't particularly good.

> But thanks for offering to run tests. I've finished the app with TV so
> there's no need now.

With this mentality, in a few years when we have this discussion again, the state of FV will be still the same too. (and actually that is the problem with FV)