Out of memory during compiling.

[E B Knoppert]

How can i improve mem settings for PB6?

I have declared > 4700 controls

Should i set something in config.sys?

Free mem in dos-box: 562.672..
Extended (XMS) 65.994.752

I don't use UMB

My DDT file is ~1.6Mb

[Gregery D Engle]

Well just something you should add to your config file is:

DEVICE=EMM386.EXE NOEMS
DOS=HIGH,UMB

Doing that should clear up some conventional memory for you. You should have atleast 600k+ of conventional. I have 604k

But I don't know if that will doing anything for PB6 because its a windows program, I have only had to make sure my memory modifications are made when I'm running true dos applications.

------------------
-Greg

[Scott Turchin]

This is what my config.sys looks like in Win95/98:


Anyway, hte point is, you don't WANT to do that except for Dos based programs.

If on NT you can make a few adjustments, on 98 not much y ou can do about THAT...
However, how much RAM do you have? (Should be at 128 at this point in time)...

Break the file down into separate files (See Don's DDOC for a beautiful example of doing this)...

Problem #2 here is that its a 16 bit Windows app, nothing against that but it's not getting the full flavor of Windows, what you MAY want to do is EDIT it in PB, but use the Compiler separate with the commandlines, I don't think this issue will BE an issue at that point in time..


Scott and his .02 cents worth LOL

------------------
Scott
mailto:[email protected][email protected]</A>

[Tim Wisseman]

It is not a problem with not enough RAM.

You have run into the memory limit of 16 bit programs (PB Compilers) under Windows.

Windows NT will give you a little more memory room for 16 bit programs than 95 / 98.

Your best bet is to break your program up into a small main EXE and move as much code as possible to support DLL's.

Tim



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

[Peter Manders]

> DEVICE=EMM386.EXE NOEMS
> DOS=HIGH,UMB

> Doing that should clear up some conventional memory for you. You should have atleast 600k+ of conventional. I have 604k


Not if he's using Windows 95B, which I think he is.
If so he's going to need the IOSYSDUT.EXE patch from Microsoft.
Without it you get 550kB max. I used to think M$ were boycotting DOS until I found the patch, searching for "DUT" in their FTP directory.

It won't help him much in this case though.

Peter.


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

[Peter Manders]

Oops, before people go off and download stuff, the above is for the DUTCH version of Windows 95B ONLY!!

Peter.


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

[Scott Turchin]

As you mentioned, there is a memory limit for 16 bit applications under 9x, NT is a LITTLE better as mentioned also..

But, vs having DLL's, why won't having separate .BAS files help in this case? (From the IDE I'm not sure, but from commandline it should be fine...???


Scott


------------------
Scott
mailto:[email protected][email protected]</A>

[Tim Wisseman]

>>But, vs having DLL's, why won't having separate .BAS files >>help in this case? (From the IDE I'm not sure, but from
>> commandline it should be fine...???

If the IDE is running out of memory, but the compiler is not than yes you are correct, divide the files up into smaller BAS files or use a command line to compile the program.

If the program is so large that the compiler itself is running out of memory than the program needs to be split into a EXE and DLLs.

Is it a IDE or Compiler out of memory problem?

Tim




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

[E B Knoppert]

I almost never use the IDE so, the compiler suffers from the mem problem.

I must tell you all that i did include smiles because, at this moment i wouldn't use this kind of DDT files because it was just a test.
I converted an old VB app's forms to DDT, the VB app has > 4400 controls.
The app really needs to be rebuild (this year)
In my case i wouldn't use DDT but i have a SDK version too but that code was even bigger.
So i asked it for DDT



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

[Scott Turchin]

Yer right, DLL time...


Scott

------------------
Scott
mailto:[email protected][email protected]</A>

[Gregery D Engle]

Originally posted by Peter Manders:
> DEVICE=EMM386.EXE NOEMS
> DOS=HIGH,UMB

> Doing that should clear up some conventional memory for you. You should have atleast 600k+ of conventional. I have 604k


Not if he's using Windows 95B, which I think he is.
If so he's going to need the IOSYSDUT.EXE patch from Microsoft.
Without it you get 550kB max. I used to think M$ were boycotting DOS until I found the patch, searching for "DUT" in their FTP directory.

It won't help him much in this case though.

Peter.

Thats incorrect. Windows 95B works fine. I have 50+ computer I'm in charge of and maybe 20 of them are windows 95B and the memory is about 600k.

------------------
-Greg

[Peter Manders]

Greg,

You're not using the Dutch version, I've fixed dozens of systems running Dutch W95B with this patch. All went from under 560kB in DOS to just over 600kB.
I think the German version had it too and maybe others as well but they have their own patches.

You can be sure it has this IO.SYS bug. Why would Microsoft have a patch for it then? They just never published it.

Peter.


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

[Tim Wisseman]

Why are you folks talking about DOS memory? This has nothing to do with DOS memory.

PB6 is a 16 bit Windows program, it and its IDE do not have anything to do with DOS memory.

When you run out of memory when you are compiling with PB6 you have run out of 16 bit Windows memory.



Tim

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

[Steve Hutchesson]

Tim is right here, 16 bit windows memory is the culprit as it limits the
absolute amount of memory available to the compiler. I tried adding a 13 meg
source file to a project and the compiler ran out of memory.

Now to be fair, 4000 odd controls is one hell of a lot of controls in an
application so it makes sense to break the application up as it is not
possible to display all of them at once. Depending on the design of the app,
this will make it a lot more managable and will get around the memory limit
imposed on the compiler by 16 bit windows.

Another choice is to start building dialog boxes as normal resources as they
take up less code than a DDT dialog and only have one mesage handling proc
for each dialog. It is not as easy as DDT but if it is done correctly, it
will end up smaller and you will reduce the memory demand on the compiler.

Regards,

[email protected]

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