Anyway to turn off or limit the size of XMS memory?
Run DOS applications in Windows.
Brought to you by:
emendelson,
josschaars
I'm looking to use Vdos on a 64 bit terminal server and my apps don't need the 64mb of XMS memory. This allocation is making the memory per open screen (and people can have many open) such that on a terminal server environment with lots of people, I'll run out of ram.
Is there a flag or setting for config.txt to turn off XMS? I see I can swap to EMS but that will still have the 64mb allocation used up. I'm trying to lower the footprint for each running session. I don't actually need either EMS or XMS though 1024kb of XMS is what we've been using over the years and the language will use up to 1024kb of XMS. But even just a simple flag setting to turn off ems and xms entirely would be fine in my case.
Thanks for this great fork!
Extended memory (used as XMS or EMS) is actually 63MB. With the GB’s of Windows, no one before was is need for less. So there’s no option to set the amount of extended memory.
I’m unsure if the memory allocated, but not used/addressed, by vDos will even cost any physical memory of the terminal server. It gets swapped out
Jos
50 users with 5 screens open would need 17.5 gb on a terminal server as the ram per session is at about 70mb. Thus my desire to drop the xms. The ram per session should drop with that change.
I'll check under Terminal Server as your correct, the ram may not actually be used with multiple session since it's an exe allocating it.
Ok, checked and the xms 64mb is set aside whether the application is using it or not and each additional user and screen additionally allocates the whole amount. Sitting on an empty vDos c prompt uses the same ram out of the total available as running a program. Also, the memory goes up by about 70mb for each vDos c: prompt you have open. Running legacy programs in these sessions does not change the ram used.
If there is a way to turn off xms or ems or limit the amount allocated it will be very helpful for my specific needs.
When I start a single vDos instance in Windows 8, it needs at first 80MB memory.
Idle at the command prompt this drops down to 2MB in a minute of two.
Starting some applications this peaks to 10MB.
In Windows 7, the 80MB doesn’t drop, for that I had to start 100 vDos instances.
Idle at the command prompt the memory dropped to less than 1MB.
Starting some applications peaked to 12MB.
So with 50 users and 5 vDos active instances per user, you would need 250x 10-12MB = 2.5-3GB?
There’s no option to turn off or limit XMS or EMS, for this you would have to recompile the source.
Jos
We've got a version with 1mb allocated for either XMS or EMS. We are continuing to work on a parameter to pass to pick how much you want. When we get this done we'll plop up the code for you if you'd like to incorporate it in the released version. I wasn't able to duplicate your test and see the drop in ram with the current version of vDos in my real test system. But in any case, our tweak fully addresses my concerns.
With the rest of the C++ overhead in Vdos with 1mb allocated the total memory used drops to just under 10mb per open session instead of the 80mb. This will allow us to implement without restriction in our expected real life environment where we might see up to 200 sessions open.
Once we get this done I'll post up the code and make a donation!!
Thanks for your fine work on vDos - great program!!
Last edit: John Mason 2014-12-09
It is quite simple to add a parameter for the amount of XMS/EMS memory.
In vdos.cpp add: ConfAddInt(<parameter name="">, <default value="">);
To inquire it: ConfGetInt(<parameter name="">);
No idea if/how I’ll pick it up, no one so far had problems with the 63MB.
I was already thinking about dropping EMS=ON/OFF from config.txt and just always provide for 32MB of both XMS and EMS.
But there should probably also be an option for “bare” extended memory, at least it was needed for the DOS extender used by DataEase.
In your test case, did you start enough vDos instances to exhaust all Windows physical memory so Windows is forced to swap unused memory?
Jos
Perhaps something like MEM = xx, EXT|XMS|EMS?
xx being 1 to 63 MB, provided as specified.
Default being 32/16/..?MB for both XMS and EMS (no EXTended memory).
EMS = would be replaced by MEM =, providing all options one could need?
I like to have as little options as possible in config.txt, it would be nice to have none :).
Jos
Last edit: Jos Schaars 2014-12-09
I don't want to exhaust memory or even close. This would take memory away from database caching of which I want as much as I can get. That's one of many reasons I need to lower the base footprint of each vDos session.
I already have made some mods [I'm John Mason's employee]. There is now a MEMMB parameter in config.txt, and most of the constants (TOT_MEM_BYTES, etc) are handled via calculations where needed.
The only real problem is MEM_PAGES - it's used to setup a static array, which of course needs a constant size. So I have MEM_PAGES defined to 4096 (which is what it would be @ the old 64mb default memory size). It's inefficient, but the vDOS footprint is now 9.6mb instead of 73mb. ;) (In our 1MB memory size case.)
(And as an aside, a bit of a philosophical difference here... I prefer lots of options, with sensible defaults, to few options and thus less ability to customize things.)
(Also, yeah, Windows will swap in/out as needed, but we're talking 10, 20, 30, maybe even 50 or more, users on a Terminal Server here. The disk thrashing involved would be truly epic and not provide a good experience at all!)
Exhausting Windows memory was merely to see what remains if unused vDos memory is swapped out. To my own experience it doesn’t get swapped back in (when the application is running).
The MEMMB option is somewhat like I suggested with MEM = [xx,] EXT|XMS|EMS?
MEM_PAGES being 4096 instead of 128 (1MB extended memory) costs less than 16KB memory. In program code, leaving it at 4096 simplifies things. Some others like TLB_phys[] also aren’t that interesting. Perhaps some combined option to disable VGA and increase DOS base memory by a further 96KB would be more productive and useful?
I dislike options just for the sake of customizing things no one is in need for and keeping config.txt simple. Actually you were the first with this problem. Though a versatile option for memory usage could also be of benefit for mainly DOS extenders. For instance Phar Lap/FoxProX takes a while at startup to initialize all 63MB extended memory.
I look forwards to your modifications and see what you’ve done. And how to incorporate those in a general way (as far needed).
Jos
Last edit: Jos Schaars 2014-12-10
I've implemented it as a simple MEMMB = (some integer) ... So to get the default behavior as shipped you'd put in MEMMB = 64. In our case we have it as MEMMB = 1. Every place the old TOT_MEM_BYTES constant was used it just pulls the memory size in MB from the config array with ConfGetInt, multiplies it out, and all is well.
And yeah, this is a niche thing, running very old DataFlex 3.x code on 64-bit Terminal Server.
(Changed files are vdos.cpp, mem.h, dos_classes.cpp, xms.cpp, ems.cpp, and memory.cpp)
View and moderate all "General" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
You’ll send me the modified files?
After some more thought about memory settings, I think I’ll go for only the basic 1MB DOS memory by default (many don’t need extra memory) and add:
MEM = <nn>, EXT|XMS|EMS
To config.txt, where <nn> is the number of required MB’s: 1 to 63.
I think this is the most logical option, some default to ?? MB XMS and EMS would probably be confusing and I guess no DOS program uses both at the same time.
So the current behavior of vDos would be done by:
MEM = 63, XMS
(EMS = ON will be dropped)
Aside from the C++ overhead of runtime libraries, we also have the SDL and SDL_ttf libraries. Still on my to-do list to get rid of these. A first effort for dismissing the latter failed, so picking this up again dropped to a last place on my to-do list.
Googling for DOS-DataFlex, I came upon a reference to vDos’s forum itself: https://sourceforge.net/p/vdos/discussion/general/thread/1a85cf88.
“better solution is.. use the console mode runtime of dataflex 3.1 or 3.2, the dataflex app will be a true 32 bit app.”
So you could use this option to run the DataFlex application natively in Windows?
Jos
Last edit: Jos Schaars 2014-12-12
DataFlex changed their license model for those versions and it is PER USER for those versions; we have thousands of users, can't pass that on. We have an unlimited dist license for 3.01 and the VDF versions we use.
(So, not an option for us.)
Jos wrote, "I guess no DOS program uses both [EMS and XMS] at the same time." Actually, WordStar for DOS 7.0 Rev. D -- the final release -- can use both EMS and XMS simultaneously. ;)
Personally, I don't recommend it -- in my page on using WordStar under vDos, I suggest using only EMS under WordStar, as it leaves the largest amount of LOW DOS memory available to the program (WordStar uses some LOW DOS memory overhead to handle XMS, but not EMS):
http://sfwriter.com/ws-vdos.htm#ems
Still, I think it would be fine to support only one or the other under vDos. :)
To access XMS memory, a program requests DOS to swap a chunk of memory from XMS to conventional and back again. So some conventional memory has to be set aside as a buffer. EMS memory has its buffers in upper memory and no swapping is involved, a buffer is simply set to point to some part of the EMS memory.
Jos
View and moderate all "General" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
I don't know if this makes any sense but I remember QEMM had a utility called VIDRAM. It allowed you to have more memory than the standard 640kb. Something like 704kb or even more if I recalled correctly. Some programs could make use of this extra memory like XY Write III.
I found this on the internet:
"I have some software(QEMM's vidram.com) that disables VGA graphics and uses the adaptor RAM to add 64K or 96K to conventional memory. I was able to get 736K of conventional memory on my 8086 museum piece this way"
Is there any way to have something similar in vDOS?
Joaquin
Last edit: Anonymous 2014-12-14
I already mentioned this above. The first 64KB upper memory block (0xA000 – 0xAFFF) is occupied by the VGA card and only used when displaying graphics. If there’s no need for graphics, but only text mode, this 64KB could fairly easy by appended to the 640KB of DOS conventional memory. I’ll have a look at that.
Jos
View and moderate all "General" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
Thank you very much Jos.
Joaquin
Last edit: Anonymous 2014-12-15
View and moderate all "General" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
Jos, how is the new version of vDOS coming along? I don't want to look anxious or impolite, but I am really looking forward the new version with the VIDRAM option.
In any case, thank you for your great work.
Joaquín
I planned to release the new version some weeks ago. But was confronted by some hard to tackle bugs and had to postpone it.
It should now be ready to be released within two weeks.
However the VIDRAM option didn’t make it. I (still) don’t believe that many programs will profit from it, let alone need it.
I dislike adding another option to config.txt that probably won’t be used, except by a few.
And I saw the 704K.com program mentioned that would do the same.
Though I have my doubts that this works.
So if you could test it and conclude it indeed doesn’t, I rethink it.
Jos
View and moderate all "General" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
Jos,
I did not know about the 704K.com program! Anyway I have tried in a couple of systems and unfortunately it does not work for me.
I can understand your dislike, so I'm thinking that maybe you could help us (or point to us some clues) as to implement such an option by Peter/Catastrophicanomaly in vDOSxy. I think that way we all win, you keep the software just the way you like it, and there is an option for the rest of us.
I can assure you that this is a serious application, and having some extra memory would mean the world to us.
Again thank you for your on going help and work.
Joaquín
Last edit: J Prada 2015-03-26
The EMS = option in config.txt has already been changed to a more complex and versatile XMEM = <MB> XMS|EMS|EXT.
So it would not be that a big obstacle for me to change that to XMEM = [+]<MB> XMS|EMS|EXT.
If you could register at SourceForge, I could send you a copy of vDos to test where the DOS memory is temporary set at 704KB.
Jos