Vista programming in C++?

[tweedsmuir]

New member. Got to this site by Googling "programming vista C++"; wild thread exchange from a couple of weeks ago with implications that some folks might have the answer I need.

Basic question is whether my partner & I can adapt a longstanding, robust C/C++ program we've been marketing so it'll run on Vista. We can install it on Vista and get most functionality, but one key function doesn't work reliably. What we need is a compiler we can run in Vista and that will compile our C/C++ code so we can debug. We've been working in Visual Studio 5 for years.

My guess is that this issue has been addressed many times in DaniWeb, so my first request is just to point me to some threads.

I've run a search on the site but got no hits; the Vista thread lists don't seem to apply.

I'd be greatly obliged for help.

[jbennet]

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

[tweedsmuir]

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.

[jbennet]

I will try your "administrator privileges" suggestion. The Vista machine has only one account, so we log in as the administrator

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

[tweedsmuir]

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??

[jbennet]

maybe your grammar checker doesnt support the hires fonts?

I know that some screen readers sometimes have issues with them

[tweedsmuir]

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.

[tweedsmuir]

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

[jbennet]

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

[tweedsmuir]

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

tweedsmuir

[anorman68]

Can't help with the compiler issue, but if you need debugging, take a look at 'debugging tools for windows' which is a very powerful debugger that microsoft provides free of charge. Just download the latest (32-bit or 64-bit) and you're in business. The best approach to seeing what's going on for a crash is to run the adplus.vbs script that's included (path is usually c:\Program Files\Debugging Tools for Windows). When you run it the first time (just type adplus.vbs) it will probably tell you that the default script engine is wscript and that it wants to switch to cscript -- just reply OK. Then, while your program is running but before it crashes, do the following:
adplus -crash -pn xxxx -o yyyy
where xxxx is the name of your executable (include the .exe) and yyy is a path to where dumps are to be written. I usually create a c:\dumps directory, which is where the output of the crash is written. To enhance your experience (:-)) you should set up windbg to use Microsoft's symbol server. I create a directory (c:\websymbols) and a system environment variable (_NT_SYMBOL_PATH) according to the directions given in the debugger.chm file in the windbg directory. Your environment variable will look like: _NT_SYMBOL_PATH=srv*c:\websymbols*http://msdl.microsoft.com/download/symbols

Then, for any operating system symbols, windbg will load them on your machine the first time and find them there subsequently.

When a crash occurs, you'll find a unique directory name in the c:\dumps directory, and in it will be a .log file and one or more .dmp files.

Alternatively, you can start windbg, and load your .exe and run it under the debugger. That way, you can watch any debug strings that get output.

hope this helps ...

al

[tweedsmuir]

Final post to this thread, in case anyone is interested in the problem. We figured out the problem. Somewhere in Vista's bowels, Microsoft silently changed the plain-text font to proportional, thus extending the lengths of the lines we were printing into a window so that some of them became too wide. With no provision from us or Microsoft for wrapping, the program crashed. We solved the problem by widening the target window a little, and we'll incorporate a precautionary routine that, in the case of a still-too-long line, exits gracefully rather than crashing.

tweedsmuir

[jbennet]

glad you got it sorted