Thanks for your extensive reply.
We were exactly the same in some beginning, but at some time it became too complicated or so (we have this ERP package). And as I understand, you just know more about it all {s}
One more thing though : however in the world would it be possible that our apps ran/run in FPDos 2.5 without EMS ? Now since it all is over 10 years ago when it was setup (for 2.5) I can't recall exactly what the problems were, but they were there, that's a fact. So maybe we applied some tricks (without knowing) ?

Peter



>>Ed, I just assume that you're right anyway, but the problem is that the times we mingle with IO areas for network cards and video are over. I mean, do we ? can we still ? of course we can, but it IMO is too hard with the plug and pray story. IMHO (though not sure) the Dos-extender was designed for extended memory, and not for expanded memory. Further, I'd say that the EMS stuff is to much about software (mapping of memory), so you'd just ask for trouble when using it. And, it is slower.
>
>FWIW, FPDOS 2.5 Extended Edition needed EMS (at least that's what Watcom, the people who wrote the DOS Extender, said - otherwise, they specifically didn't properly support release 1 of XMS, and instructed you not to run under HIMEM.SYS and offer XMS, and it had problems with the HMA.
>
>FPDOS 2.6 Extended used either XMS or DPMI. Both versions Standard edition could only use EMS.
>
>>Never mind, you are right in the end, but how to deal with all your users far away ? I mean, when there is this package, you can't control you users at all, but for having the word : better don't use EMS.
>
>Easy; I tell them what will work and is supportable, and what isn't, and then they decide if they want me to support it. I support a couple of packages developed in conjunction with a client that has an install base of nearly 10K units. If the customer calls and says "It won't work", the first thing the support engineer does is survey their operating environment; if it's out-of-spec, we tell them what makes it out-of-spec, and then give them the choice of letting us bring it into a supportable configuration, paying a whole lot of money to have a senior engineer research the problem they've introduced, or let them handle the problem themselves; we've told them what we need to do in order to support their system. The same applies to custom apps I've developed directly ls, several of which are deployed internationally; they drop me an email to ask whewther I think there's going to be a problem if they add some piece of software, and are well-aware that in order for me to do phone
>support or remote diagnostics, they may need to unload some little widget, and need to have the necessary connectivity for their site.
>
>My clients tend not to hire me to write a single app for them, but rather to advise them on many aspects of their automation environment. If they don't trust my judgement in the matters at hand, then they're probably dealing with the wrong guy - I'm very up-front about brands, vendors and aspects of their business beyond the scope of the single target app. The majority of my client base has been working with me for several years.
>
>>To my experience once upon a time you'll have something strange happening, but which is rare (I mean, once in 6 months or so). In all such cases (unexplainable stuff) the user had EMS On, and in all cases with no EMS, all "strangenesses" (ever happening obviously) could be explained in the end.
>>That's why I said it. ;))
>
>I think I tend to dig a little deeper under the covers.