Windows XP and VIRTUAL arrays

[David Grogan]

I know this problem has been reported in this forum before,
but going through all the posts I haven't been able to get it to
work.

Basically what I need is a 10,000 element VIRTUAL array of 100
character fixed strings, but FRE(-11) is returning 0.

I have set the following in my CONFIG.NT...
dos=high, umb
device=%SystemRoot%\system32\himem.sys
files=40
buffers=40
I also tried setting the 'EMM=RAM' command, but that made no
difference.

I have the following set in _default.pif:
Conventional Memory:
Total - Auto, Initial - Auto,
Protected - unchecked
EMS memory: 16384
XMS memory: 16384, Uses HMA - Unchecked
DPMI memory: Auto

After all this is set FRE(-11) still returns 0 and the DOS 'MEM /c' command
returns:

Conventional Memory :

Name Size in Decimal Size in Hex
------------- --------------------- -------------
MSDOS 12496 ( 12.2K) 30D0
KBD 3296 ( 3.2K) CE0
HIMEM 1248 ( 1.2K) 4E0
COMMAND 3952 ( 3.9K) F70
DOSX 34720 ( 33.9K) 87A0
COMMAND 4880 ( 4.8K) 1310
KB16 6096 ( 6.0K) 17D0
FREE 112 ( 0.1K) 70
FREE 16 ( 0.0K) 10
FREE 588272 (574.5K) 8F9F0

Total FREE : 588400 (574.6K)

Upper Memory :

Name Size in Decimal Size in Hex
------------- --------------------- -------------
SYSTEM 212976 (208.0K) 33FF0
DOSX 128 ( 0.1K) 80
MSCDEXNT 464 ( 0.5K) 1D0
MOUSE 12528 ( 12.2K) 30F0
REDIR 2672 ( 2.6K) A70
FREE 1136 ( 1.1K) 470
FREE 2288 ( 2.2K) 8F0
FREE 29792 ( 29.1K) 7460

Total FREE : 33216 ( 32.4K)

Total bytes available to programs (Conventional+Upper) : 621616 (607.0K)
Largest executable program size : 587104 (573.3K)
Largest available upper memory block : 29792 ( 29.1K)

33554432 bytes total contiguous extended memory
0 bytes available contiguous extended memory
16628736 bytes available XMS memory
MS-DOS resident in High Memory Area

My exe is 231k, so that should leave plenty of space in conventional memory
for the EMM 64k page frame, or is this stored in Upper Memory?

Any ideas?




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

[Paul Dixon]

David,
the 64k page frame is stored in high memory somewhere, not in conventional memory.

Have you tried right clicking on the exe icon of your program, choose properties and click on the "memory" tab. Make sure the EMS memory is set to something reasonable in there.

Paul.

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

[David Grogan]

If the 64k page is stored in high memory, then the fact that
I only have 32k free there is probably the cause, no?

SYSTEM takes up 200k, so If I could move that conventional memory
maybe that would work. I tried removing the 'dos=high, umb' command
from CONFIG.NT but that made no difference. Is there any way to get
SYSTEM to load in conventional memory?

BTW I also had the same settings in my program .pif as in _default.pif.



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

[David Grogan]

I've just added the 'Echoconfig' command to the end of my CONFIG.NT,
and when I start a Command Prompt now it says:

Unrecognized command in CONFIG.SYS
Error in CONFIG.SYS line 59

Line 59 is the EMM=RAM command, so it looks like XP doesn't
support this command, I guess the help info in CONFIG.NT is
just left over from win2k and doesn't apply to XP (the command
isn't listed here either [link]http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/dos_cmds.mspx[/link]).

also, changing the DOS command to equal 'low, noumb' removes everything
bar SYSTEM from high memory, but unfortunatley this only leaves 42k free.



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

[Paul Dixon]

David,
my WinXP PC allows the line "EMM = RAM" so it is valid in the config.nt file but it didn't help.

I used to have no problem with EMS but I haven't used it for a few years. Now, on a new PC, I can't get it to work with either WinXP or Win98. The closest I got was a report something like EMM386 is unable to create a base for the page frame.

I have seen it mentioned on the internet that some hardware just isn't compatible with EMS anymore but I'd have thought that was unlikely.

I hope someone else can be of more assistance,

Paul.

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

[keith shelton]

Here is what I get when I run the mem/c command. I am running WinXP home.

Conventional Memory :

Name Size in Decimal Size in Hex
------------- --------------------- -------------
MSDOS 12496 ( 12.2K) 30D0
KBD 3296 ( 3.2K) CE0
EMM 176 ( 0.2K) B0
HIMEM 1248 ( 1.2K) 4E0
HASPDOS 336 ( 0.3K) 150
MOUSE 12528 ( 12.2K) 30F0
COMMAND 3728 ( 3.6K) E90
REDIR 2672 ( 2.6K) A70
DOSX 34720 ( 33.9K) 87A0
COMMAND 4448 ( 4.3K) 1160
KB16 6096 ( 6.0K) 17D0
FREE 112 ( 0.1K) 70
FREE 573184 (559.8K) 8BF00

Total FREE : 573296 (559.9K)

Upper Memory :

Name Size in Decimal Size in Hex
------------- --------------------- -------------
SYSTEM 258032 (252.0K) 3EFF0
DOSX 128 ( 0.1K) 80
MSCDEXNT 464 ( 0.5K) 1D0
FREE 912 ( 0.9K) 390
FREE 2528 ( 2.5K) 9E0

Total FREE : 3440 ( 3.4K)

Total bytes available to programs (Conventional+Upper) : 576736 (563.2K)
Largest executable program size : 572224 (558.8K)
Largest available upper memory block : 2528 ( 2.5K)

4194304 bytes total EMS memory
4194304 bytes free EMS memory

19922944 bytes total contiguous extended memory
0 bytes available contiguous extended memory
15580160 bytes available XMS memory
MS-DOS resident in High Memory Area

I have all of the memory tabs in the pif set to auto, and have checked protected memory.
KS

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

[Frank Cox]

Based on the messages here, it appears that I can get a whole lot more free DOS memory on my Linux boxes than Windows XP can manage.

Here is the output from mem /c under DOSEMU on Fedora Core 3. Note that FreeDOS SHARE is also resident:

QUOTE
Modules using memory below 1 MB:

Name Total Conventional Upper Memory
-------- ---------------- ---------------- ----------------
SYSTEM 14,112 (14K) 9,856 (10K) 4,256 (4K)
EMS 256 (0K) 0 (0K) 256 (0K)
COMMAND 3,984 (4K) 0 (0K) 3,984 (4K)
SHARE 13,072 (13K) 0 (0K) 13,072 (13K)
Free 742,416 (725K) 645,184 (630K) 97,232 (95K)

Memory Type Total Used Free
---------------- -------- -------- --------
Conventional 640K 10K 630K
Upper 116K 21K 95K
Reserved 268K 268K 0K
Extended (XMS) 16,384K 8,292K 8,092K
---------------- -------- -------- --------
Total memory 17,408K 8,591K 8,817K

Total under 1 MB 756K 31K 725K

Total Expanded (EMS) 2,048K (2,097,152 bytes)
Free Expanded (EMS) 2,048K (2,097,152 bytes)
Largest executable program size 630K (645,168 bytes)
Largest free upper memory block 92K ( 94,560 bytes)
FreeDOS is resident in the high memory area.
END OF QUOTE

Note that I didn't do anything special to get more available ram; with the exception of FreeDOS SHARE, this is just the way that DOSEMU installs out-of-the-box.

Anyone who needs lots of free DOS ram to run their programs may want to consider running them under Linux.

------------------
PB/DOS 3.5 on Fedora Linux

[Criss French]

I had an Asus motherboard, A7N266VM, micro ATX, early Nvidia
chipset, onboard video. I could never get enough free HMA to
give EMM386 it's requisite 64k frame. I was using 98SE, and pure
Dos7 (usually on a boot CD). Never got any joy.

I talked to Asus tech support, and they finally came up with the
fact that the board is not certified for DOS/Win98. Said that yes
the HMA is all used up by ROM's, tough luck. This was also verified
by me using 'mem'. I gave up prematurely on the issue when I upgraded
to a newer mobo without that issue.

... scratches head ... tries to remember ...

-You might be able to set Emm use a 32k pageframe?
-You might be able to disable some ROM shadowing in bios, which
I think always uses HMA for the shadow. Although maybe the
ROM's occupy the same address block shadowed or not?
-You might try using off-board video to avoid the ROM?
-Maybe some other HMA is somehow used by onboard LAN or other
periferals? Try disabling them?

Good luck.


------------------
What can go wrong will go wrong.
Anything can go wrong.
What hasn't?!?!

[Paul Dixon]

Criss,
mine's a similar Asus motherboard (A7N8X). I thought the same as you.. but there's no shadowing setup in the BIOS so that's out.

The usual is 4x16k page frames. but 1 is enough for EMS to work so if that could be done it may work, but I can't even get that on my system.

Paul.


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

[Bob Zale]

Now, admittedly, I'm a little biased... {smile} but it might not be a bad idea to consider the PowerBASIC Console Compiler for Windows. Similar syntax... and it addresses 2 Gigabytes of memory.

Regards,

Bob Zale
PowerBASIC Inc.


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

[David Grogan]

Thanks for all the replies, it seems that XP depends on individual
hardware specs allowing for EMS to get this working. Not acceptable,
as I don't know where the software is going to be installed.

Is there much difference between the Win32 Console compiler and v3.5?
I would only conisdder upgrading if it was going to be relatively painless,
as we have a very large code base. I previously upgraded from VBDos to PowerBasic,
which took several weeks (including random bug fixes which were required afterwards).

Thanks,
David

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

[Michael Mattias]

"Degree of pain" will depend an awful lot on what you do in your MS-DOS code.

There is no $LINK, there is no direct port I-O (as done in MS-DOS with INP/OUT), DEF SEG/PEEK-POKE are not used .. I think the PB/CC help file contains a section on this.. maybe if you ask PB Sales nicely, they will send you the help file or that section so you can decide just how painless converting your code will be.

Strangely enough, the biggest problem you might have is "scope": using PB/CC, all executable code must be within a procedure (a SUB or FUNCTION).. so if you haev a program with lots of vars shared across a lot of procedures, that will be a fair amount of work unless you make them all GLOBAL. (*shudder*)

Alan Earnshaw once published a 'tip' to handle this:

First, you recode your DOS program so it looks like this:

CALL MAIN
END

SUB MAIN ( )

...
END SUB

' all other subs and functions in your program go here

Once you have that working, you have the scope problem licked. THEN you port that code.

MCM