Since today DosX dos extender always had problem on pcs with more than 64 Mb of memory.

I had Mr Doug Huffman (yes Mr DosX himself) by e-mail and he wrote i can
send those e-mail to
the newsgroup.

so i do.

it may interest some of you

Roland


Hi

thank you for DOSX 01,0515

the result of test: SUCCES !

details:

compiler: DM C++, DOSX model (mx)
program: TESTMEM: see atached files
test on pure dos mode (NOT on a windows dos box)
PC: PIII 750, W98SE, 640 Mo of memory (yes 640 Mo: 10 time 64 Mo !)

1- original configuration:
SC 6.10 -> SC 7.21 -> SC 7.5 -> SC 7.6b66 -> DM 7.70 -> DM 7.71

Dos Extender:

sdx.lod: 29/10/95
x32.lib: 09/11/94
cx.obj: 03/01/97    //??

Result:

without EMM386 /NOEMS on CONFIG.SYS: does NOT start: not enough memory ! with EMM386 /NOEMS on CONFIG.SYS: allocate 63.447 Mb

2- next configuration:

install DM815c, DM812dos (dos 16 lib), DM815x (dos32 lib)

Dos Extender:

zdx.lod: 24/05/95
x32.lib: 01/11/95
cx.obj: 17/10/93

I have to add x32.lib on the project

Result:

without EMM386 /NOEMS on CONFIG.SYS: 63.447 Mb
with EMM386 /NOEMS on CONFIG.SYS: same

3- last configuration:

same as 2

Dos Extender: new !!

zdx.lod: 15/05/01
x32.lib: 15/05/01
cx.obj: 17/10/93

Result:

without EMM386 /NOEMS on CONFIG.SYS: 511.639 Mb
with EMM386 /NOEMS on CONFIG.SYS: same

Okay !

Best regards

Roland

Doug Huffman a écrit :

> I don't know why it isn't able to allocate more memory.  Attached is the first new revision since 1995.  Try this, if it doesn't work, maybe you can send me a small example program and I can work on the problem here.
>
> Please test the attached extender and report any problems to me.  If it works well for you, I will put it on the website.
>
> Yes, you can post any of this on the news group.
>
> Thanks,
>
> Doug
>
> At 01:47 PM 05/14/2001 +0200, Roland wrote:
> >Thank you for your fast answer.
> >
> >Yes it works with 128 Mb of ram: with EMM386 on CONFIG.SYS, even with /NOEMS switch.
> >
> >The program works and don't say there is not enough memory at startup any more.
> >
> >But it seems there is no more memory avalable for the program: it seems it
> >can't
> >allocate more than 64Meg.
> >
> >rem: my program is running on pure dos mode, NOT on a Windows Dos box.
> >
> >Best regards
> >
> >Roland
> >
> >N.B: can i send your e-mail to Digital Mars C++ newsgroup ?
> >(news.digitalmars.com)
> >
> >
> >Doug Huffman a écrit :
> >
> > > Both of my computers have exactly 64 megs of memory, so I am not set up well to work on this problem.
> > >
> > > First, are you using the latest version of X-32 (available at
> > dosextender.com)?
> > >
> > > Second, what memory managers do you use?  himem.sys, EMM386?
> > >
> > > X-32 and DOSX both use the int 15 function 88h to get the amount of extended memory.  This BIOS interface is limited to 64 meg.  As I recall, the XMS interface supported by himem.sys also is limited to 64 megs since X-32 allocates the largest block of extended memory available and this is limited to 64 megs.
> > >
> > > I believe the VCPI interface supported by EMM386 provides the capability of exceeding the 64 meg limit, but I am not certain.  Install EMM386 and don't use the "NOEMS" switch.
> > >
> > > This would be a good thing for me to work on.  I am certain there are ways of getting around the 64 meg limit in the BIOS.  I will put this on my list of things to work on and see what I can do.
> > >
> > > I haven't had any new releases of X-32VM yet, the one on the internet is November 95.  I have made some bug fixes, but haven't released them yet.  I will try to get back to work on this in the next few weeks.
> > >
> > > Sincerely yours,
> > >
> > > Doug Huffman
> > >
> > > At 11:51 AM 05/04/2001 +0200, you wrote:
> > > >rv@ronetech.com
> > > >
> > > >10 year i use your Dos Extender with Symantec/Digital Mars C++.
> > > >Nice ! Congratulation.
> > > >One thing now is begining to be a problem is the 64 Mega byte of memory
> > > >limit that DOSX can use.
> > > >Is there something to do to break this limit ?
> > > >
> > > >Best regards
> > > >
> > > >Roland
> > > >
>
>   ------------------------------------------------------------------------
>                   Name: x320515.zip
>    x320515.zip    Type: Zip Compressed Data (application/x-zip-compressed)
>               Encoding: base64

Hi,

1- DOSX

well i had the new dos extender just to test.

Mr Huffman wrote that he will release the new version if test are good.

I prefer to let him decide the timing.

i think he will do it soon.

You may have a look at

www.dosextender.com

you will find Mr Huffman e-mail addresse.

I'm interested by everything concerning DOSX.

please let the newgroup know anything new about DOSX.

2- Flashtek debugger

i had flashtek debugger but i never was able to make it run.

in fact i didn't insisted a lot.

something i don't have is the user manual.

do you know where i can find it ?

Regards

Roland

rv@ronetech.com


Heinz Saathoff a écrit :

> Roland schrieb...
> > Since today DosX dos extender always had problem on pcs with more than 64 Mb of memory.
>
> Right, have noticed this too. And also without EMM386, only with HIMEM installed.
>
> > I had Mr Doug Huffman (yes Mr DosX himself) by e-mail and he wrote i can
> > send those e-mail to
> > the newsgroup.
>
> Is it possible to get the e-mail address of Doug Huffman? Is he still supporting that library? In addition to the SC-delivered DosX I bought the X32 Extender from Flashtek and this library has the same problem.
>
> [snip]
> > Dos Extender: new !!
> >
> > zdx.lod: 15/05/01
> > x32.lib: 15/05/01
> > cx.obj: 17/10/93
> >
> > Result:
> >
> > without EMM386 /NOEMS on CONFIG.SYS: 511.639 Mb
> > with EMM386 /NOEMS on CONFIG.SYS: same
> >
> > Okay !
>
> That sounds good. Is it possible/allowed to distribute the new files to the DMC download area (or e-mail to me)? I would be happy if this >64MB problem is also solved for my DOS-app.
>
> Regards,
>         Heinz

Roland schrieb...
> 1- DOSX
> 
> well i had the new dos extender just to test.
> 
> Mr Huffman wrote that he will release the new version if test are good.
> 
> I prefer to let him decide the timing.
> 
> i think he will do it soon.
> 
> You may have a look at
> 
> www.dosextender.com

I've just downloaded that version and will check if it's behaving better than the one I'm currently using.


> you will find Mr Huffman e-mail addresse.

Found it. Thanks.


> I'm interested by everything concerning DOSX.
> 
> please let the newgroup know anything new about DOSX.

Ok, will do so. BTW, I have some Problems with one DosX-App under Win95/98. My App intercepts the sytsem timer-interrupt and chains back to the original handler or does an own EndOfInterrupt and iret. This all works without problems in pure DOS or on WinNT. On Win95/98 the App crashes in functions that can't be wrong. It seems that the code area of my App is overwritten. The function code overwritten depends also on the order in which the objs are linked in.



> 2- Flashtek debugger
> 
> i had flashtek debugger but i never was able to make it run.

I once used it but now I don't because I also had problems. Today I do most debugging with printf messages.


> in fact i didn't insisted a lot.
> 
> something i don't have is the user manual.
> 
> do you know where i can find it ?

Maybe I still have it. I will have a look.


Regards,
	Heinz

Heinz Saathoff a écrit :

> BTW, I have some Problems with one DosX-App under Win95/98. My App intercepts the sytsem timer-interrupt and chains back to the original handler or does an own EndOfInterrupt and iret. This all works without problems in pure DOS or on WinNT. On Win95/98 the App crashes in functions that can't be wrong. It seems that the code area of my App is overwritten. The function code overwritten depends also on the order in which the objs are linked in.

What is funny is that we trap tick interrupt too on our DOSX program.

In fact we already noticed that we can't do what we want on a Windows Dos
box.
may be Windows want to know what we are doing with the system.

first thing is witch tick interrupt do you trap: int 8 (irq 0) or int 0x1c
(irq i don't remember: 0x1c-8) ?
i guess it is int 8 as you don't have to make an eoi for int 0x1c

we use to trap int 8 and even change timer frequency in pure dos mode. It does not work on a Windows Dos box.

In a tick interrupt, i think windows get the hand before you and make the eoi
before.
It prevent us to change interrupt frequency as well.

I think if you don't want your program to crash you can try this:

make an explicit eoi instead of an automatic eoi:

#define _PIC_EOI_PORT 0x20

#define _b_eoi(intno) outp(_PIC_EOI_PORT,0x60|(intno-8))

for irq 0..7

Since a long time we would like to make our program run on real time mode in a Windows Dos box.

Perhaps a TSR program lauched before Windows can get the interrupt before Windows, but i'm not sure.

An other solution can be to run at same privilege level as Windows: privilege
0.
I think only device driver can do it on Windows.
I'm not a Windows programmer (except some VBA with Acces) and i wonder if
device driver programming is
the easiest way to start..

A third solution could be to use some DPMI functions to modifie system setup.

As DPMI on a Windows Dos box is Windows itself, i'm not sure it give you the right..

What surprises me is that your program run on NT.

regards

Roland

Roland schrieb...
> 
> What is funny is that we trap tick interrupt too on our DOSX program.
> 
> In fact we already noticed that we can't do what we want on a Windows Dos
> box.
> may be Windows want to know what we are doing with the system.
> 
> first thing is witch tick interrupt do you trap: int 8 (irq 0) or int 0x1c
> (irq i don't remember: 0x1c-8) ?
> i guess it is int 8 as you don't have to make an eoi for int 0x1c

The system timer int8. I reprogrammed the timer to provide an higher interrupt rate (from 50 to 200 ticks/second). Internally I count the time and chain back to the original handler when a original tick is needed. Otherwise I issue my own EOI. Works under pure DOS and Win. I haven't testet the accuracy under Win but assume that it will not be as accurate as under pure DOS.

> we use to trap int 8 and even change timer frequency in pure dos mode. It does not work on a Windows Dos box.

Do you use the DOSX-API to chage the int-vector? The Manual says that the interrupt table may be relocated and therefore one should use the API instead of assuming the vector table at 0000:0000


> In a tick interrupt, i think windows get the hand before you and make the eoi
> before.
> It prevent us to change interrupt frequency as well.

In Windows the VDM should handle this and does it for me (haven't
measured the accuracy yet). Otherwise my App would have blocked because
I wait for a global counter to increase and this counter is incremented
in the ISR.

> I think if you don't want your program to crash you can try this:
> 
> make an explicit eoi instead of an automatic eoi:
> 
> #define _PIC_EOI_PORT 0x20
> 
> #define _b_eoi(intno) outp(_PIC_EOI_PORT,0x60|(intno-8))
> 
> for irq 0..7
> 
> Since a long time we would like to make our program run on real time mode in a Windows Dos box.

I assume you will not get real time behaviour in a DOS box. The DOS-Box is virtualized and so is the hardware port access. Therefor the specific EOI should not make any difference because the port access to the PIC is trapped by Windows.


> Perhaps a TSR program lauched before Windows can get the interrupt before Windows, but i'm not sure.
> 
> An other solution can be to run at same privilege level as Windows: privilege
> 0.
> I think only device driver can do it on Windows.

But the App must be run in kernal mode which is AFAIK only possible for driver-code. No chance for DOS code.

> I'm not a Windows programmer (except some VBA with Acces) and i wonder if
> device driver programming is
> the easiest way to start..
> 
> What surprises me is that your program run on NT.

I was also suprised. The VDM must be real good to handle this. The only question is the accuracy.


Regards,
	Heinz

Heinz Saathoff a écrit :

> Do you use the DOSX-API to chage the int-vector? The Manual says that the interrupt table may be relocated and therefore one should use the API instead of assuming the vector table at 0000:0000

no: writing vector table is not good,
we use interrupt package: int_intercept

> I assume you will not get real time behaviour in a DOS box. The DOS-Box is virtualized and so is the hardware port access. Therefor the specific EOI should not make any difference because the port access to the PIC is trapped by Windows.

we had crash fixed using specific eoi.

i'v just tried our program on real time mode on a Windows Dos box: for me Windows
trap timer 8254
port acces and prevent any change of  the tick interrupt frequency.

do you think a Windows program in association with a specific device driver can make real time ?

I don't care if Windows can't make multitasking while my program is running.

Regards

Roland