Announcement

Collapse
No announcement yet.

PB6.0 Compatible with Win2k, XP?

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

  • Lance Edmonds
    replied
    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>

    Leave a comment:


  • Mike Jenkins
    Guest replied
    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).]

    Leave a comment:


  • Lance Edmonds
    replied
    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>

    Leave a comment:


  • Mike Jenkins
    Guest replied
    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!


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

    Leave a comment:


  • Mike Jenkins
    Guest replied
    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!



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

    Leave a comment:


  • Fred Buffington
    replied
    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.



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

    Leave a comment:


  • Scott Turchin
    replied
    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

    Leave a comment:


  • Lance Edmonds
    replied
    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
     
     .....
     
    [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>

    Leave a comment:


  • Mike Jenkins
    Guest replied
    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.

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

    Leave a comment:


  • Mike Jenkins
    Guest replied
    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).]

    Leave a comment:


  • Mike Jenkins
    Guest replied
    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).]

    Leave a comment:


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

    Leave a comment:


  • Lance Edmonds
    replied
    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>

    Leave a comment:


  • Borje Hagsten
    replied
    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..


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

    Leave a comment:


  • Mike Jenkins
    Guest replied
    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).]

    Leave a comment:


  • Russ Srole
    replied
    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

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

    Leave a comment:


  • Lance Edmonds
    replied
    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>

    Leave a comment:


  • Gregery D Engle
    replied
    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

    Leave a comment:


  • Mike Jenkins
    Guest started a topic PB6.0 Compatible with Win2k, XP?

    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?


    ------------------
Working...
X
😀
🥰
🤢
😎
😡
👍
👎