No announcement yet.

Windows XP and VIRTUAL arrays

  • Filter
  • Time
  • Show
Clear All
new posts

    Windows XP and VIRTUAL arrays

    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

    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
    I also tried setting the 'EMM=RAM' command, but that made no

    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
    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?


    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.





      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.



        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][/link]).

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



          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,




            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.



              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:

              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


                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?!?!
                What can go wrong will go wrong.
                Anything can go wrong.
                What hasn't?!?!


                  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.




                    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.


                    Bob Zale
                    PowerBASIC Inc.




                      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).




                        "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
                        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.


                        Michael Mattias
                        Tal Systems (retired)
                        Port Washington WI USA
                        [email protected]