>>Roxanne,
>>
>>I suspected as much. SYS(2020) in FPW 2.6 reported my 2.1GB hard drive correctly. Here's a little something for the AT&t folks to munch on, and tell them bon appetite: C|
>>
>>If something is hard coded into the EXE, don't forget about the HexEditor that comes with VFP 5.0.
>>
>>Good Luck,
>>
>>George
>
>
>Hey George Guess What... seems SYS(2020) is reporting correctly for 2.1 GB drives and smaller. But with anything bigger is defaulting to 10.2 regardless of what the real size is. I cant see how that matters though, something weird must be hardcoded and this HexEditor thing doesnt look like too munch fun because theres too many generically named *.app files & I dont know where to begin. And sure enough the stand-alone machine did the same thing once all data files were copied over. But still, how in the world could they have programmatically set a disk size limitation that keeps the app from seeing all available space?
>
>;-) Forgive me but I've thrown in the virtual towel and have begun the old braindead process of reformat/re-partition/re-install. If AT&T says the drives cant be bigger than a GB then so be it. Bet I'll be writing my own version of this package someday over the rainbow. How about a virtual pizza since we've ruled out a fedora?

Roxanne,

I hope you've made progress with the problem. I didn't mean to bail by not replying earlier, but I had other stuff to take care of. Anyway, just a thought and/or comment or two.

Gee whiz, there's not much difference between 1 GB and 2.1 is there? I wonder if AT&T would let me pay my long distance bill using that kind of logic. (Well, paying half the bill is just about like paying the whole thing, isn't it? And where is Candice Bergen when we really need her?)

It's not surprising though that FPW can't see beyond 2.1. That's just about the limit of the value the ROM BIOS can report (I think, I havaen't done the math). Of course, in Win95 and probably NT as well there's an API call for this sort of thing.

I don't think Edward's suggestion regarding TITLE = (These apps suck) can be reliably used here. If the desktop was redefined in the app using DEFINE WINDOW...TITLE, then the behavior you saw would occur. I think it would be better to set TMPFILES to an entirely new directory and monitor it and the old location. Depending on the outcome of that test you could better draw a conclusion regarding whether or not CONFIG.FPW was built in.

From what I've read, I'm sure that you would write a much better app than the one that's currently being used. From the sound of things, however, I'm sure you've got better ways to spend your time.

Finally, I'm game for the virtual (Chicago style?) pizza, washed down with a few virtual beers after this is over. I also hope (for your sake) that this is virtually the end of both this thread and your problem.

Good Luck and Keep the Faith,

George