Announcement

Collapse
No announcement yet.

PB6.0 Compatible with Win2k, XP?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • PB6.0 Compatible with Win2k, XP?

    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?


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

  • #2
    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
    -Greg
    [email protected]
    MCP,MCSA,MCSE,MCSD

    Comment


    • #3
      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>
      Lance
      mailto:[email protected]

      Comment


      • #4
        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

        ------------------
        "There are two novels that can change a bookish fourteen-year old's life: The Lord of the Rings and Atlas Shrugged. One is a childish fantasy that often engenders a lifelong obsession with its unbelievable heroes, leading to an emotionally stunted, socially crippled adulthood, unable to deal with the real world. The other, of course, involves orcs." - John Rogers

        Comment


        • #5
          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).]

          Comment


          • #6
            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..


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

            Comment


            • #7
              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>
              Lance
              mailto:[email protected]

              Comment


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

                Comment


                • #9
                  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).]

                  Comment


                  • #10
                    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).]

                    Comment


                    • #11
                      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.

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

                      Comment


                      • #12
                        Posting overly-trimmed snippets can sometime bring up unexpected comments , however:
                        [quote]Originally posted by Mike Jenkins:
                        Code:
                        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:
                        Code:
                        SUB xxxx
                         ON ERROR GOTO Errortrap
                         
                         .....
                         
                        Finishedxxxx:
                         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
                         RESUME Finishedxxxx
                        END SUB
                        ------------------
                        Lance
                        PowerBASIC Support
                        mailto:[email protected][email protected]</A>
                        Lance
                        mailto:[email protected]

                        Comment


                        • #13
                          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.

                          Code:
                          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
                          Scott Turchin
                          MCSE, MCP+I
                          http://www.tngbbs.com
                          ----------------------
                          True Karate-do is this: that in daily life, one's mind and body be trained and developed in a spirit of humility; and that in critical times, one be devoted utterly to the cause of justice. -Gichin Funakoshi

                          Comment


                          • #14
                            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.



                            ------------------
                            Client Writeup for the CPA

                            buffs.proboards2.com

                            Links Page

                            Comment


                            • #15
                              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!



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

                              Comment


                              • #16
                                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!


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

                                Comment


                                • #17
                                  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>
                                  Lance
                                  mailto:[email protected]

                                  Comment


                                  • #18
                                    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).]

                                    Comment


                                    • #19
                                      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>
                                      Lance
                                      mailto:[email protected]

                                      Comment

                                      Working...
                                      X