does it use MFC at all?

If it does then dont try the free Visual c++ express as it doesnt support it, but i think the full Visual Studio.NET 2005 does.

what is the function?

try running the program under vista using administrator priviliges (not the same as having an administrator account, google it, it works, i use it for games on vista) and also have a play with the program compatibility wizard

Thanks for the response, jb.

No, we don't use the MFC. Actually (blush), our code is almost all straight C--never had a need to orient objects in C++ because we've been doing everything we want without it. The software is a text checker that can catch maybe 100,000 writing problems that Word's spelling and "grammar" checkers miss or ignore. It's very sophisticated internally, but the interface is straightforward rather than flashy. Runs in W98, 2000, XP. If you're interested (no reason you should be) google "Serenity Software." We have satisfied customers in 44 states and 34 foreign countries, but we're a small, 2-person shop of English Teachers Who Program--been at it since about 1982, first version in assembly language for the old Trash-80 before IBM had a PC--but we're only experienced, not sophisticated, as you can probably tell.

I've just downloaded the VS 2008 light freebie but haven't yet installed it on our Vista laptop; not sure at this point whether it'll load and compile our code--it'll take a day or so to find out.

I misspoke--the erratic "function" is actually a feature, not a code function. The many other features work in Vista and the entire interface is functional, so we're optimistic that we can fix the recalcitrant one once we have an IDE.

I've tried the Vista compatibility wizard. As with XP's earlier, it isn't worth much. Doesn't solve our problem, and from the scathing comments I've seen on the Web, others have had similar experiences.

I will try your "administrator privileges" suggestion. The Vista machine has only one account, so we log in as the administrator. It would be a temp solution at best because we can't ask all our customers to be administrators in order to run our program. We're beginning to get anxious requests from customers who're switching to Vista and we hope to be able to compile a version that speaks native Vista.

Sorry for the wordy intro. I'll post back after trying VC 2008-minus and the privileges.

thats not the same thing. Vista is wierd. The administrator doesnt usually run apps as the administrator (for security)

Even if you are an admin user, programs will not be allowed to do certain things (usually registry related)

To get round this, you have to right click on the .exe and choose run as administraor. This is the way i get games to run on vista

Weird is right. I tried "run as administrator." Didn't make any difference. BUT changing the screen display res from 120 dpi (which I think I set initially to avoid eyestrain) back to the default 96 dpi FIXED THE PROBLEM! Now our software runs perfectly, the feature that was causing blowups now doesn't.

Changed the res back to 120 as a test: program blew up. Reset to 96, program runs fine.

Any ideas??

maybe your grammar checker doesnt support the hires fonts?

I know that some screen readers sometimes have issues with them

Sorry, don't know what "hires fonts" are. Our fixed screens--basically, Help screens--are preformatted and programmed to use the Windows System font. Should be safe.

My dumb. Of course hires means hi-res. I must be thinking of changing jobs.

Our software interrogates the local computer at bootup and silently adjusts for screen-width and dpi settings (96 / 120 only, no custom jobs). All standard Windows API coding.

There are 6 analyses performed on a user's text file; output from each is listed in plain text on an output screen in the order run; they all seem to run fine in 120 dpi but when user asks to view the results, the program blows up. Tests indicate that it's the first analysis at fault. The other 5 can be run in any order one at a time or all together, and can be viewed without difficulty. The first, run with others or by itself, blows up on a Vista 12- dpi screen. Doesn't seem to blow up on a 96 dpi screen (so at least we can give customers a workaround) or in XP in either dpi resolution.

So it's an output problem--easily solved, no doubt, in a debugger the way we solve all other coding problems. BUT we don't have an IDE with debugger that will compile our code on a Vista machine. First inspection of Windows C++ 2008 indicates that they've abandoned us C programmers completely, and we don't have time, staff, or money to port hundreds of thousands of lines of mature, mostly robust, and many-many-times-tested code into a whole nother programming language. Learning a new platform is challenge enough for a couple of English teachers!

We're hoping that someone out (in?) there has some insight into why a dpi change on a plenty-of-resolution screen should blow up a program doing only plain-text output in only 1 of 6 identical cases (the analyses are different, but the output is always and only plain-text messages--not even any odd fonts).

Sigh.

tweedsmuir

Try something called Bloodshed Dev C++. Its free and opensource, and uses a windows port of the GNU compiler. It handles both C and C++

On their site make sure you download the Beta version, the stable one is old

Yes, I've seen refs to Bloodshed. Thanks. Will look it up.

tweedsmuir