Can't get EMS for a PB program under Vista

[Davide Vecchi]

In XP and 2000, in every new installation of my PB/DOS app using virtual arrays, I just had to edit the shortcut properties, tab "Memory", changing the "Expanded memory" value from "None" to 16384. If I don't do that, I get error 202, which I can't find in the doc but I remember to be related to missing EMS (other threads I found do suggest so as well).

Now, the same modification of the shortcut doesn't seem to work under Vista. I keep getting the error 202 even after I modified the shortcut properties in the same way I modify it under XP/2000, that is to provide 16 MB of EMS.

Under Vista the shortcut properties also show a "Compatibility" tab, which allows to "Run the program in compatibility mode for [a previous Windows version]". I tried setting that to all the available versions (from XP down to 95), but the error 202 always occurs. It seems that the 16 MB of EMS aren't actually set up.

Any ideas ?

I found this thread that might relate to this problem (post #9 and #11), but it sounds like a bit of a hack under Vista... it dates back to Win 3.1... In Vista I have several system.ini files, and I'd have to fight with Vista to modify them due to being in protected positions, and I'm not sure it will work and it won't make the system unstable: one thing I learnt is that you better play within the rules with Vista, or you better don't use it. I'll try this just like a last resort.

[Davide Vecchi]

Web searches seem to suggest that EMS isn't available under Vista period. The most direct hint is this, but I saw more ones, none from Microsoft though.

Searching for "EMS" at the Vista section of http://support.microsoft.com gives zero results.

Pages I visited point to the solution of using an EMS emulator, like EMS Magic, DOSBox, and other ones I can't find references of anymore.

At this page it's reported that using VirtualPC to emulate a pre-Vista Windows version works fine, that's not a great option for the user but might be just perfect for the developer.

I'm not 100% convinced yet that EMS under Vista is simply unsupported. I'd have liked to find an unambiguous statement from Microsoft saying so, but I didn't find one. And why the shortcut properties do show the option to supply EMS memory to the DOS program, I don't know.

[Buck Huffman]

Have you considered using virtualpc to run a version of dos and then run your
app in that dos from the autoexec. The fact that the app is running in virtualpc
could be hidden from the user completely. That is in theory of course, since I
haven't actually done this myself. It would probably depend on the app that you
are trying to run more than anything. Just a thought.

buck

[Knuth Konrad]

VirtualPC seems overkill for that task, DOSBox should do just fine.

[Davide Vecchi]

Thanks for the suggestions. I didn't know that it's possible to run an app in VirtualPC in that way (actually I didn't know anything about Virtual PC in absolute, and not even about DOSBox). However using an emulator on the user PC is not a good option in this case. But it could be a good option for my development PC (Vista).

Now this task switched to low priority; when I'll get back to it I'll try DOSBox and VirtualPC, but first of all I'll put some effort into investigating what the shortcut property to provide EMS in Vista is there for. I tend to think that one could make it work in some way; it can't be there just to fool people...

[Buck Huffman]

VirtualPC seems overkill for that task, DOSBox should do just fine.

EMS in DOSBox does not appear to work with PBDos generated exe's(please correct me if
I'm wrong). For Linux users Dosemu also does not provide EMM for PBDos exe's. Freedos'
emm386 also appears to suffer from the same bug, but can be replaced with Japheth's driver
which has many other advantages as well. Japheth's EMM driver doesn't appear to work in
Dosemu though . That is why I suggested vpc. There are of course many other emulators
available: Qemu, Vmware, Virtualbox to name a few. If you plan to continue using DOS
programs on vista and later versions of windows you will do well to familiarize yourself with
one or more of these fine programs as they are quite useful.

Also if you don't have any old DOS versions laying around Freedos works quite well after
substituting Japheth's driver as mentioned above, or, from vista, you can get msdos 8 by
accessing the floppy format dialog from within explorer, selecting make bootable and format
a floppy (this tip requires a floppy drive of course). and there are many free and cheap DOS'es
available just a google search away.

buck

[Knuth Konrad]

EMS in DOSBox does not appear to work with PBDos generated exe's(please correct me if
I'm wrong).

Uhh, don't know. I don't have any PB/DOS applications at hand that use EMS. But DOSBox at least has switches in its configuration file for xms/ems support.

[jcfuller]

I wrote a Virtual Memory Manager VMM (use dosmem,Ems,or disk) for pb3.0 which I recompiled under 3.5 (which really doesn't need it). An example app I wrote to test it ran fine in the latest DosBox which I installed today.
This same app failed under FreeDos until I change EMM managers there.

James

[Buck Huffman]

I do have ems=true set in my Dosbox configuration file but if I try to run this program:

DIM VIRTUAL A(100) AS LONG

It reports error 202 expansion memory error. I would really like to be wrong about this,
but it's not very likely.

buck

[jcfuller]

I do have ems=true set in my Dosbox configuration file but if I try to run this program:

DIM VIRTUAL A(100) AS LONG

It reports error 202 expansion memory error. I would really like to be wrong about this,
but it's not very likely.

buck

You are correct Buck. I had just tried my VMM code which worked in the latest DosBox (0.72 I believe). PB's VIRTUAL() does not.
I dug out my old ( written in 1994) PBVMM code and uploaded it to my site.

http://www.jcfuller.com/PBVMM205.ZIP

I included three sources as I don't know what the differences are and at present don't have time to check.
Do with them what you want. released to the Public Today 02-13-2008.

James

[Buck Huffman]

Back to the original question:
You might want to try xteq's x-setup . I haven't tried it since it went commercial, but
they claim it can safely tweak over 1900 registry settings. I have used the freeware version
in the past and it did a lot of useful things. I don't hold out much hope for it to enable ems,
there is a free trial version available for download so it seems like it's at least worth a try.

As far as your concern about modifying "system.ini" , I believe the first comment in the file
states that it's "; for 16-bit app support". If that's not what this is then theres no such thing.
I know that anything you do in windows can cause a hard crash, so I understand your
fear. It's just a matter of how far your willing to go I suppose.

By the way, if you have more than one system.ini it's most likely the file at:

C:\Windows\System.ini

if there's more than one file in the c:\windows directory with that name then it's anybody's
guess as to which one it is.

buck

[Michael Mattias]

C:\Windows\System.ini
if there's more than one file in the c:\windows directory with that name then it's anybody's guess as to which one it is

I think it would actually be anybody's guess as to what corrupted the directory, and how if at all it can be fixed or if it's time to just throw away that drive.

[Davide Vecchi]

Thanks Buck; I see you're the author of the original suggestion about modifying system.ini . I decided to go for a different route though, using HUGE arrays instead of VIRTUAL, or porting the app to Windows if that won't give me enough memory.

It's sad that I have to do this extra work without any extra benefit, which wouldn't have been needed at all if Vista had worked, but after all, this is the only major problem I had with Vista, along with having to see perfectly working hardware devices trashed due to lack of Vista compatible drivers.

Aside from this, I can't say I got hit by Vista that much, so I'll accept this...

This time I can't join the chorus of criticism for the new M$ OS in itself, which under several aspects is an actual improvement. Of course they should have highlighted much more that it'd have broken many existing sw and hw, but hey, they can even not do that and people will "buy" Vista anyway, so...

xteq's x-setup would be interesting, but I decided to exclude any hack. They won with me !

[Davide Vecchi]

I think it would actually be anybody's guess as to what corrupted the directory

I think Buck meant in the c:\windows directory included subdirectories in it.

[Buck Huffman]

I think Buck meant in the c:\windows directory included subdirectories in it.

actually I've read about a technique by which you can have two files in the same directory
with the same name in xp and I suppose it works in vista too, by using different combinations
of small and capital letters. I don't remember exactly how it's done in windows, but it's
automatic in Linux and I find it somewhat annoying. You can turn it off I think? I just
haven't felt like messing with it.

buck

[Michael Mattias]

>by using different combinations of small and capital letters

But then it's not the same file name, is it?

MS-DOS and Windows are case-insensitive when it comes to file names, Unix IS case-sensitive. Maybe you can turn off/turn on case-sensitivity (I had never heard of such a thing, but if you say so, I'm not totally surprised that someone would have created the software to handle that), but then you are playing on a new pitch.

[Davide Vecchi]

I never heard of such a thing as two files with the same name in the same folder in Windows, regardless of capitalization.

All my 7 system.ini files are under C:\Windows and its subfolders:

C:\Windows
C:\Windows\winsxs
C:\Windows\winsxs\Backup
C:\Windows\winsxs\Manifests
3 x C:\Windows\winsxs\[Ostrogothic endless name]

[Mike Luther]

It is particularly interesting, even in IBM's horribly reliable OS/2, where a given file has the same "name" as a directory "name", as an executable or .CMD file, and there suddenly can be a VERY interesting conflict with even the EA attributes for files in the OS/2 complete object oriented system!

As in:

f:\slush\slush.cmd

or more interestingly:

f: \Slush\Slush.cmd

particularly where in a DOS-VDM, it all will be treated as capital letter operations ... yet in the OS/2 version of the same HPFS file system, the upper and lower case can actually be distinguished and a source of trouble at times!

FWIW ..

[Mike Doty]

In versions before Vista EMM=RAM in C:\WINDOWS\CONFIG.NT.
That no longer works in Vista.
Might be a way to set a page frame using Config.nt
Experimenting without any luck.

[Michael Mattias]

Mr. Doty;

I have nothing empirical, but viscerally it seems to me you support more MS-DOS applications than Carter's has little pills.

While I'm sure you look at this as a services opportunity, I'd have to look at it as an opportunity to sell some new Windows-based applications to these users.

MCM