Announcement

Collapse
No announcement yet.

Can't get EMS for a PB program under Vista

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Scott Turchin
    replied
    Just an FYI - and I'm not sure about on VISTA but on all other 32 bit OS's y ou have an AUTOEXEC.NET and an CONFIG.NT located in your windows\system32 folder.

    When you run COMMAND.COM from a CMD.exe window these act as a dos machine booting up...

    I was able to load ansi.sys and set a custom prompt in mine, but whether EMM will work - don't know.

    Just an FYI if you did not know about those files...and command.com

    You might try copying command.com from an XP box and see what gives...

    Leave a comment:


  • Mike Doty
    replied
    Yes, the end. It was a good run.
    i

    Leave a comment:


  • Michael Mattias
    replied
    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

    Leave a comment:


  • Mike Doty
    replied
    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.

    Leave a comment:


  • Mike Luther
    replied
    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 ..

    Leave a comment:


  • Davide Vecchi
    replied
    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]

    Leave a comment:


  • Michael Mattias
    replied
    >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.

    Leave a comment:


  • Buck Huffman
    replied
    Originally posted by Davide Vecchi View Post
    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

    Leave a comment:


  • Davide Vecchi
    replied
    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.

    Leave a comment:


  • Davide Vecchi
    replied
    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 !

    Leave a comment:


  • Michael Mattias
    replied
    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.

    Leave a comment:


  • Buck Huffman
    replied
    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
    Last edited by Buck Huffman; 16 Feb 2008, 09:57 PM.

    Leave a comment:


  • jcfuller
    replied
    Originally posted by Buck Huffman View Post
    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

    Leave a comment:


  • Buck Huffman
    replied
    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

    Leave a comment:


  • jcfuller
    replied
    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

    Leave a comment:


  • Knuth Konrad
    replied
    Originally posted by Buck Huffman View Post
    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.

    Leave a comment:


  • Buck Huffman
    replied
    Originally posted by Knuth Konrad View Post
    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

    Leave a comment:


  • Davide Vecchi
    replied
    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...

    Leave a comment:


  • Knuth Konrad
    replied
    VirtualPC seems overkill for that task, DOSBox should do just fine.

    Leave a comment:


  • Buck Huffman
    replied
    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

    Leave a comment:

Working...
X