PB6.0 Compatible with Win2k, XP?

[Mike Jenkins]

I've just completed a year-long port of a DOS program I publish
to PB6.0, and have several people starting Beta testing today.
While it runs fine on Win 95/98 (I developed it on Win 98), I'm
getting scary feedback that it won't run properly under Win2k or
XP, doing things like generating Error #62 (input past end of
file), which never happens with the 5 sequential data files the
program uses, when running under Win 95/98.

Is the PB6.0 code I've been writing essentially incompatible with
Win2k and/or XP? I wouldn't have expected even fairly simple
functions like reading in a sequential file would not work under
XP or Win2k....

I expected there might be compatability problems with XP, but
not with Win2k. Anyone else experiencing similar problems? Mine
is a simple game program, which does nothing but read in some
data files, and then massage the data (stock market stuff) and
display it, in text boxes. No TCP, no graphics, etc. Real basic
stuff.

On Win2k it's also generating all kinds of out-of-bounds errors
that don't occur under 95/98. Sounds like some major
incompatability, that I wasn't aware of.

Any ideas, as to some sort of parameters I may need to add to
my code to get it to work with the newer O/S's?


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

[Gregery D Engle]

Mike,

Many people on this forum us Win2k including myself, I don't know
about XP but I'm sure there are a few.

That stated, I have NEVER had a problem with any of my compiled
exe's not running correctly in Win2k.

The only issue that I've ever had is when Nt klunks to 16 bit
to execute the compiler, I have had it lock up a couple times
while it was compiling but I simply end task on NTVDM.EXE and
it pops back. I've only had this happen maybe 5 or 6 times
since I've been programming with PBDLL and PBCC.

Win2k is an excellent programming environment, much more stable
than Win9x machines. If you stick the the standard API or
standard PB command you will have no problems running an
application on Win2k.

Install it, you might like it

------------------
-Greg

[Lance Edmonds]

Windows 2000, being a Windows NT-family member, is much more likly to find problems in your code that (more relaxed/lax) Windows 9x machine do not catch.

That is, the problems are almost certainly programming errors, array bounds being exceeded, bad use of pointers, poor inline assembler, or some other programming problem.

First, add #DEBUG ERROR ON to your code and retest. #DEBUG ERROR ON enabled array bounds and null-pointer testing, so while the code may not GPF, it may produce unexpected results since it ignores actions on arrays subscript errors.

Still, the idea is that it will give you the clues you need to track down your bugs.

Are you testing thoroughly for runtime errors in your code? ie, are you testing that each OPEN statement is successful? Using ON ERROR is a good way to trap disk I/O errors.

As Gregery says, Win2K is stable and popular. I'm running it here, and have been since RC2 (around 2 years ago now). It can run for days or weeks between reboots, even with my constant stream of GPF's!

Personally, I love the way it catches my sloppy programming out with a GPF that Win95 would not always catch - it makes me strive to be a better programmer! True.

XP should be no different... early reports indicate no problems with any PowerBASIC compilers.

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

[Russ Srole]

Mike,

I'm with Lance. Every time I run into this sort of thing, it's
because I did something dumb that 98 winked at, but NT hates. I'll
bet you have an array out of bounds or something like that.

Russ Srole

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

[Mike Jenkins]

Probably is something wrong in my code, Russ. However, after
months of rigorous debugging, my app now runs perfectly for
hours, even with error-checking turned off, under either Win2k
or Win98, EXCEPT when it's launched directly from a SETUP file,
under Win2k/XP,NT, so I'm beginning to harbor some suspicions
about the third-party software I'm using (I won't mention names)
that creates the SETUP file, in light of the following (after
getting a lot more specific feedback from my Beta testers):

1. My program ONLY malfunctions when, after completing the
installation, the user elects to launch the program for the
first time, directly from the SETUP.EXE file (third-party
software I mentioned). (And even then, only malfunctions
under Win2000, XP or NT; never under Win 95 or 98, which my
Beta testers on 4 continents report ZERO problems with after
several weeks of testing.)

2. Otherwise, if they choose not to launch from the SETUP.EXE
file, but instead launch from the desktop icon, Windows
Explorer, the Start Menu, or elsewhere, it always runs right
the first time it's run, and every time it is run afterward, as
well. (Hmmmm.... If I've got bad pointers, out-of-bounds
errors or the like, you'd think they would show up other
than when the program is launched from the SETUP.EXE...?)

Since all the problems have to do with file-handling (errors #55,
62, 70), it seems that when the errors occur, the app has
problems finding the disk files in question, although it never
generates an Error 53, for some reason. So I put in a MSGBOX
as a diagnostic in my PbMain, to display the full pathname of the
drive/directory in which the app and all the files are installed,
so the Beta version now displays that path name ("PathSpec$") the
instant the main program loads.

So far, the testers all say it always shows the correct path
where all the app's files are, even when the app is
launched from SETUP.EXE and generates all kinds of error
messages as noted above, and fails to read in data from the
config and other data files. DESPITE having the right pathname
and using the correct file names, it can't properly open or
write to any (!!) of the 5 data and config files, if it is
launched by the SETUP program.

Code borrowed from this Forum (and it works nicely) to extract
the drive/path location of the app is the function I use to get
and then display the pathname in my PbMain, with a MSGBOX.
The MSGBOX displays the path name properly in all cases, but for
some reason the path name it extracts shows the disk drive
letter (C in upper case when the app runs properly, but shows
it in lower case (c when the app is about to malfunction.
(I.e., when the app was launched from the SETUP.EXE file.)

Odd.

I don't see how a pathname which includes c: instead of C: could
cause any file problems under Win2k (this ain't Unix), but since
my app's function for extracting the pathname from Windows
generates the lowercase drive letter when the program has been
called by the SETUP.EXE file, and always generates the uppercase
drive letter when the app is started any other way or time, it
seems to me the SETUP.EXE is doing SOMETHING weird -- which
apparently includes mucking up all my file access routines, even
though I use the PathSpec$ (full pathname) in all cases, in every
part of my main program where it accesses or opens any files. I
never rely on the "default" directory when opening files, since
I assume Windows may whimsically change the default at any moment,
without my knowledge or concurrence.

Hence, my app extracts the (correct, as it turns out) pathname,
and uses that pathname with every file access, as in:


'********
GLOBAL PathSpec$

'********
SUB GetLastGame

LOCAL Fname$
LOCAL Filenum&, result&

Fname$=PathSpec$ & "LASTGAME.DAT"
result&=Exist&(Fname$)
IF result&=%FALSE THEN
' File does not yet exist, or not found, so ignore for now
LastGame&=0 'No "last game" to continue was found...
ELSE
Filenum=FREEFILE
OPEN Fname$ FOR INPUT AS Filenum
INPUT #Filenum, LastGame&
CLOSE Filenum
END IF

END SUB

FUNCTION Exist&(X$)
'..... 'Code borrowed from this Forum goes here

END FUNCTION

'**********

Anyone have any ideas as to how the SETUP.EXE (third-party
software) I'm using might be causing my program's file handling
to go completely haywire? (None of my file access routines
works when the app is called by the SETUP.EXE; all of them work
fine if the program is started any other way.) It's very
baffling. (And my main app doesn't require any COMMAND$
parameters to be sent to it, so it doesn't read in any screwy
COMMAND$ data that might be sent from the SETUP.EXE file that is
launching it.)

A cosmic mystery.... (Tentatively solved by simply changing a
setting in SETUP.EXE software so it no longer lets the user
launch directly from the SETUP program, after completing the
installation. So now my program runs fine on Win2k, XP, and NT,
since the user can no longer launch it from the SETUP.EXE
installation program. Hooray.)

But it would have been a nice feature, to allow the immediate
program launch upon finishing installation, if that feature had
worked, other than with Win 95/98....

I am wondering if anyone else had similar problems with installer
programs like the one I'm using (which I found thru PB)?

Is it possible the SETUP.EXE is still running when it launches
my app, and can somehow interfere with my app's ability to
read from or write to files? The circumstantial evidence
certainly points very strongly to that possibility.

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




[This message has been edited by Mike Jenkins (edited October 08, 2001).]

[Borje Hagsten]

Don't think so. If your program starts, it means the setup program have
succeded to start it. From there on, your program stands on own feet.
Maybe can help if you grab application path at start-up and do a CHDRIVE,
CHDIR app_path to make sure path is ok?

I mean, when a program is started from shortcut, working directory usually
is same as application directory. If started from command-line, this may
not be so? To test if this is the cause, maybe you can create a shortcut
for your program and change "Start in" to something else.

Notice many maybe's here. Once read recommendation from MS that a program
always must make sure working path is okay, but that was long ago, when
16-bits and Win3.1 ruled, so not sure it still applies. Maybe it still does,
after all..


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

[Lance Edmonds]

Mike, it sounds like you need to do some testing of this on a Win2K box yourself. Sure, it is possible it is the "installer" program, but since you have not named it, we can not even point you to the author(s) own tech support area to see if anyone else has had similar problems, or to ask them about any possible issues.

Are you 100% sure the current directory is correct when the SETUP app runs your program? I'm not sure how you can be certain an Error 53 is not occurring, since the code snippet you posted does no error testing on the file OPEN statement.




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

[Guest]

Mike, I have used this with several applications without a hitch!
http://www.gentee.com/

[Mike Jenkins]

Originally posted by Borje Hagsten:
If your program starts, it means the setup program have
succeded to start it. From there on, your program stands on own
feet.

Maybe can help if you grab application path at start-up and do a CHDRIVE,
CHDIR app_path to make sure path is ok?

Yes, my program has done that all along, though. It first grabs
the application path as the very first order of business, then
as a double-check (to make sure I've "grabbed" the correct path),
checks to see if PathSpec$ + Progname$ file is actually there,
in that directory. Once that is confirmed, before doing anything
else, it displays the PathSpec$ (path name) in a diagnostic
MSGBOX, and apparently has always displayed the right path, so
far.

It then does a CHDIR to that pathname (which really isn't necessary, since all
files it checks on or opens are called using the full pathnames).

The odd thing is that if the problem were an incorrect pathname,
my error code should show an Error 53 sometimes, which never
occurs. Only Error 55 (attempt to open or delete an already open
file -- Odd, since I always use FREEFILE to get an "unused"
file number); or Error 62 -- also odd, in a file where I not only
use "While NOT EOF(Filenum)" in reading it, but also have an
@END tag as the last line of the (sequential) file, and stop
reading at that point, which always works except, again, when
the program is called by the SETUP file. The other file error is
#70, "permission denied," also odd, since I don't use any special
file attributes in any of my data files, like read-only, or
attempt to lock/unlock any files.

Anyway, it doesn't appear to be a PB problem; I was just
wondering if other PB users had encountered a similar problem with
third-party SETUP files. I notice the FAQ's for the vendor of
the SETUP software mention this problem, but advise users that
they can solve the problem by determining and using full path
names for all file accesses, and not to rely on the "default"
directory being the correct path. Since my program already does
that, I would bet good money that not all the other users having
the same problem as I have were failing to use full pathnames...!




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


[This message has been edited by Mike Jenkins (edited October 09, 2001).]

[Mike Jenkins]

Originally posted by Lance Edmonds:
Mike, it sounds like you need to do some testing of this on a
Win2K box yourself. Sure, it is possible it is the "installer"
program, but since you have not named it, we can not even point
you to the author(s) own tech support area to see if anyone else
has had similar problems, or to ask them about any possible
issues.

I checked their support area, and noted that their first FAQ
dealt with this problem. They said the way to cure it was to
NOT assume the default directory was the correct one, but to
always use full pathnames for all file accesses in your app.
Since I already use full pathnames, and go through several steps
to verify that I have the right pathname, I suspect that not all
the complaints they've gotten are from users failing to use full
pathnames. I queried the author on this, and got a testy reply
that there is nothing wrong with his SETUP software, and that
I must not really be using full pathnames everywhere, or else
something else is wrong with my program. (While that could be
true, all 5 of the data files my program tries to open, using
full pathnames, go haywire and don't read or write properly when
my app is called from the SETUP.EXE, which would indicate I'm
not using full pathnames for ANY of them, which clearly
isn't the case.)

Are you 100% sure the current directory is correct when
the SETUP app runs your program?

Nope, but as sure as I can possibly be (nothing is ever 100%).

See my reply to Borje's post above -- I go to great lengths to
make sure I've got the right pathname, and display it in the
Beta as a diagnostic before the program attempts to do anything
else, and so far, the users say it gives the correct path where
the files are, even when run from the SETUP.EXE, just before the
problems hit the fan. Problems begin as the program tries to open
the various config and data files, and my error trapping code
shows Errors 55, 62, and 70 (but never #53) with the different
files.

I'm not sure how you can be certain an Error 53 is not
occurring, since the code snippet you posted does no error
testing on the file OPEN statement.

I left out the error-trapping code and other parts of the SUB,
which trap and display the Errors 55, 62, 70. Lance.

I was just posting an example of using the full pathname when
opening files, in case there was something I was doing wrong
in assigning Filenum or naming the path/file to be opened....

The error trapping code I use in SUBs that open files is simply:

SUB xxxx
.....
ON ERROR GOTO Errortrap

.....

EXIT SUB 'Avoid "falling" into ErrorTrap
ErrorTrap:
MSGBOX "Beta Test Diagnostic: Error # " & STR$(ERR) " in SUB xxxx"
IF ERR=62 THEN CLOSE Filenum 'Close open file if input past end error
END SUB

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




[This message has been edited by Mike Jenkins (edited October 09, 2001).]

[Mike Jenkins]

Originally posted by Ron Pierce:
Mike, I have used this with several applications without a hitch!
http://www.gentee.com/

Thanks a bunch, Ron, I'll give it a try. If my app doesn't start
right from it either (under Win2k), then I'll know the problem
lies in my code somewhere.

Which is probably the case, although I'm fast running out of
possibilities, like incorrect path names, files not found, etc.

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

[Lance Edmonds]

Posting overly-trimmed snippets can sometime bring up unexpected comments , however:
[quote]Originally posted by Mike Jenkins:

SUB xxxx
.....
ON ERROR GOTO Errortrap

 .....

EXIT SUB 'Avoid "falling" into ErrorTrap
ErrorTrap:
  MSGBOX "Beta Test Diagnostic:  Error # " & STR$(ERR) " in SUB xxxx" 
  IF ERR=62 THEN CLOSE Filenum 'Close open file if input past end error
END SUB
</font>

You should be terminating the error handler with a RESUME statement, for example:

SUB xxxx
 ON ERROR GOTO Errortrap
 
 .....
 
[b]Finishedxxxx:[/b]
 EXIT SUB 'Avoid "falling" into ErrorTrap
 
ErrorTrap:
 MSGBOX "Beta Test Diagnostic:  Error # " & STR$(ERR) " in SUB xxxx" 
 IF ERR=62 THEN CLOSE Filenum 'Close open file if input past end error
 [b]RESUME Finishedxxxx[/b]
END SUB

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

[Scott Turchin]

I've had that issue so many times....except I don't really check for that kind of error anymore (I do error checking), but if the file is there I'm usually OK..

However, use this to get you to your applications path, always a failsafe.
Because, as I've seen with some 3rd party courseware at work, just because Windows says "START IN", does not always mean it will..

Not sure if you can do a chdir AppPath but I think so, you may have to check for trailing backslash.

Function AppPath() Export As String
    Local zTmp As Asciiz * 256
    Local sTmp As String
    LenExeName& = GetModuleFileName(ByVal %NULL, zTmp, SizeOf(zTmp))
    If LenExeName& Then
       LenExeName& = Min&(LenExeName&, SizeOf(zTmp))
       sTmp = Left$(zTmp, LenExeName&)
       sTmp = Left$(sTmp,Instr(-1,sTmp,"\"))
       Function = sTmp
    End If
End Function

------------------
Scott Turchin
MCSE, MCP+I
Computer Creations Software
http://www.tngbbs.com/ccs

[Fred Buffington]

Mike, one thing i found kinda by accident from a customer was
that apparently a statement like the following (ported from
my QB code) was not liked. (I didnt read all the posts so this
might have been mentioned).

open filename$ for input as #1
IF LOF(1) ...whatever

i went through and changed all IF LOF()... statments to 2 statments.

open filename$ for input as #1
LOF1&=LOF1)
IF LOF1&...whatever


That seems to have helped. (of course the open for input is an
example only -- i did it for all the files whether input/random
/binary if there was an "IF LOF(filenum%)" statement used.



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

[Mike Jenkins]

Originally posted by Scott Turchin:
... However, use this to get you to your applications path, always
a failsafe. Because, as I've seen with some 3rd party
courseware at work, just because Windows says "START IN", does
not always mean it will..

Not sure if you can do a chdir AppPath but I think so, you may
have to check for trailing backslash.

Thanks, Scott. I'm using very similar code I picked up from
an excellent Forum topic this summer, also using the
GetModuleFileName() function. (Parts of the snippet I'm using
I don't understand, though -- your Function is a lot shorter and
more comprehensible to me -- but the one I've borrowed seems to
always get the path right, so far; it's just that, even with the
right path, my program is getting Error #70's and such when it
tries to open the files, inexplicably (under Win2k/NT only).

However, I may plug in your code instead and see if that cures
the problem, as it's scary to rely on code I don't entirely
understand. (The perils of being an amateur.) Thanks!



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

[Mike Jenkins]

Originally posted by Fred Buffington:
Mike, one thing i found kinda by accident from a customer was
that apparently a statement like the following (ported from
my QB code) was not liked. (I didnt read all the posts so this
might have been mentioned).

open filename$ for input as #1
IF LOF(1) ...whatever

i went through and changed all IF LOF()... statments to 2 statments.

open filename$ for input as #1
LOF1&=LOF1)
IF LOF1&...whatever


That seems to have helped. (of course the open for input is an
example only -- i did it for all the files whether input/random
/binary if there was an "IF LOF(filenum%)" statement used.

Very interesting, thanks, Fred. I had an "IF LOF(Filenum&)"
statement in my program, where I checked at startup to see if a
particular file was a short "dummy" file I include with the
program, or the full (large) data file it gets replaced with
the first time the program is run. Since that particular SUB
was causing much of the havoc, I just got rid of the LOF() part
of it today, as I was a bit suspicious of it, too. Will be
interesting to see if that cures the problem.

Do you happen to recall if your problem with the LOF() feature
arose only under newer platforms (NT, Win2k), or also with Win98?

Muchas gracias!


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

[Lance Edmonds]

You are wasting time here folks, grasping at straws with LOF.

Fred's anecdotal story based on QB code is hardly comparible or even likely to be related to the situation being investigated here. It may have been more interesting if he posted some code that actually failed unless LOF() was assigned to a variable...

To go further, LOF has had 0 (spelt Z-E-R-O) reports of problems in PowerBASIC. Or to put it another way, there are no LOF issues in PowerBASIC.

Just remember that in Win32, LOF() can return value in the QUAD-integer range, so Fred's assignment to a LONG integer is not 100% safe, but probably fixed the problem in his QB code. If you are going to go the the bother of assigning LOF() to a variable, make it as QUAD-integer variable.


Looking back at the discussions, here is what I see:

1. The problem shows up on Win2K (and maybe XP), but is OK on 9x.

2. The problem only occurs if the unnamed "SETUP" app runs the installed app directly.

3. The problem does not show up if the installed program is run from Explorer, etc.

4. There are apparently various forms of disk/file I/O error testing being done in the code.

5. The "testers" say the various messages about the paths are correct.


Conclusions:

1. No first-hand verification of the problem has been done, leaving a lot of guesswork.

2. The testers feedback is not accurate and could be misleading as to the real cause.

3. Win2K and XP enforce access (security) and policy rights. What access rights do the Win2K/XP testers have?


Suggestions:

Modify the installed app so that it writes to a disk file with key facts such as CURDIR$, and a DIR$-loop of the current directoty, etc, and ask the testers to send the file back to you by email.

At that stage, you may be able to start making headway...

Good luck!


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

[Mike Jenkins]

Originally posted by Lance Edmonds:

Suggestions:

Modify the installed app so that it writes to a disk file
with key facts such as CURDIR$, and a DIR$-loop of the
current directory, etc, and ask the testers to send the
file back to you by email.

At that stage, you may be able to start making headway...

Good luck!

Great suggestion, Lance. Thanks, I'll try that!

(Although, on second thought, I'm not sure my app will write
ANYthing to a disk file when the problem is occurring.
Bummer. But it's worth a try.)

In any case, time to close this topic, as I'm wasting a lot of
people's time, and my app has far too much code to post it here,
so this is one I'll have to figure out myself by trying anything
and everything suggested here, and more, until the problem is
fixed.


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


[This message has been edited by Mike Jenkins (edited October 09, 2001).]

[Lance Edmonds]

Stop guessing and worrying about what may or may not work and just try it.

Also, consider writing this LOG file to a floppy disk in Drive A:.

That way it can be found readily enough for sending back to you, rather than if the current directory turns out to be 'C:\Documents and Settings\Administrator\Local Settings\Temp' instead of the expected 'C:\My Fantastic Game"

Just tell the testers to stick one of those old-fashioned 3.5" square flat things in before running the "SETUP" program.


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