Announcement

**Lance Edmonds** · 29 Sep 2001, 02:59 AM

1/ How would you word the general minimum system requirements for a PBDLL6 compiled program?

It obviously depends on what your program does.
For example, if you have non-resizable windows/dialogs, you should test it with all common resolutions, color modes, and system font sizes. If the program makes any assumptions about the PC it runs on (say, that a modem is always expected on COM1 or a printer is always attached to LPT1), etc.

ALso, if your program uses some of the more advanced common dialog or common controls, then early versions of Windows (ie, 95 or 95a) may not have all the Windows updates installed and this could affect your programs GUI operation.

Further, if you use TCP/UDP, then you need to be sure that at least Winsock 2.0 is installed.

Also, if you use large data files (>2Gb) then your program will need to handle the cases where the 2Gb barrier may be reached if FAT16 is in use on a given drive.

2/ How would you estimate the RAM requirements of a running program and is there an accepted safety margin/rule of thumb for coexistence with other running programs?

This one is harder to accurately determine, since dynamic allocation may need ot be considered. Lets say that your program uses 64Mb or more of memory when running may still run fine (albeit slowly) on a 8Mb Win95 box (making heavy use of virtual memory).

Also, if you have an string variable that is holding, say, 32Mb of text, and you add one character to that string, then the OS needs to allocate another 32.001 ('approx') MB to copy the concatentated string into, before releasing the original string storage. This dynamic memory usage may set your minimum RAM spec higher than you may think.

3/ How would you state the minimum printer specification for GDI graphics commands sent to the HDC returned by PrintDlg.

This one is quite easy to answer - the answer lies on what you are printing, and what GetDeviceCaps operations that must be supported for those GDI functions to operate.

If your code uses block transfer API's (BitBlt, StretchBlt, etc), then the printer must support these kind of operations. Of course, these printer attributes can be tested with GetDeviceCaps() at run-time, but in general, you could set the minimum program spec to say that the printer must at least support RASTERCAPS operations.

If you draw graphic "lines" or "curves", then you may need to specify LINECAPS or CURVECAPS support.

Basically, compare your printing code to the attributes listed in the GetDeviceCaps() topic in Win32.hlp.

Finally, most people (read: non-savvy end users) will not understand many of these spec's anyway, so you may be better to keep the spec simple and say that the printer must be at least an Ink or laser printer (but not Dot-matrix), and must have a Microsoft certified Win32 printer driver (or wording along those lines).

Oh, one more thing. Programs like BoundsChecker from NuMega (much $$$) can examine your compiled program and determine which O/S platforms it will run on depending on the choice of API functions it calls. This only works for implicitly linked {system} DLL's though - if your code uses LoadLibrary/GetProcAddress/CALL DWORD/FreeLibrary for run-time linking, then BoundsChecker will not pick up on these nuances so it is not a fool-proof test (ie, it could just give you indicative results).

There is no substitute for 'hard' compatibility testing...

I hope this helps.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]basic.com</A>

**Borje Hagsten** · 29 Sep 2001, 06:33 AM

Easy answer - test minimum requirements yourself. I keep a bunch of
486's for this myself, each one with clean 95/98 systems installed.
Aside from being cheap/free to get today and are excellent test machines,
they also do good work as disk copy machines. Not even a GHz pentium
can beat disk copying in a 386/486, in DOS mode..

I agree with Lance - most people don't read/understand specs. Depends on
type of app's, of course. If vertical market, then maybe more specific
specs are needed. Else, simple "For PC, Windows95/98 or later" is enough.
Something like that..

------------------

**Simon Morgan** · 1 Oct 2001, 01:44 AM

Keith
With the entry-level spec of new PCs now approaching 1GHz, it would be an enormous PBDLL prog which didnt run well on even the cheapest new PC. The problem is therefore: what legacy PCs might your clients want to use?

Without giving users a flow chart, its difficult to specify what memory, etc they need, because it depends on their operating system. Your prog might run under Win 95 on a 486 with 16Mb (which is what I use for testing, on the assumption that no-one will want to use anything older), but with NT, 2000, etc that would clearly be totally insufficient.

Its also very subjective: what is an acceptable speed for your app to run at? If its a once-per-day operation, a much slower speed is acceptable than for continuous use.

Graphics cards are also important - I have a PBDLL app that runs much slower on a Pentium 350 with 32Mb than on a Pentium 120 with 16Mb due to a slower graphics card.

There's no substitute for testing. I'd be happy to try your app on my 486/100 if that would help.

Regards, Simon

**Edwin Knoppert** · 1 Oct 2001, 03:41 AM

In doubt: always use depends.exe in 'run' mode.

------------------
http://www.hellobasic.com

**Keith Waters** · 2 Oct 2001, 06:56 AM

I've been away from computer work for a few days and have just read these replies. What excellent advice you people have given me. Thank you all very much.

Simon - thanks for your kind offer. I will email the app to you shortly.

Keith

------------------

Announcement

Deployment requirements

Deployment requirements

Comment

Comment

Comment

Comment

Comment