Announcement

Collapse
No announcement yet.

Problem with Replace-command

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

  • Problem with Replace-command

    I have serious problem with Replace-command and WinNT4.
    In the code below i have emphesized the failing command.
    What happens is that very randomly this Replace is only
    partially performed.
    The resulting buffer (15000 bytes give and take 1024 bytes)
    is translated into EBCDIC rest remain in ASCII
    Sometimes 5000 bytes sometimes 14000 bytes are translated.
    It seems to me that NT4 is switching away from this code before
    the memory is completely updated (Replace is performed),
    and when it comes back again it seems not to carry on with Replace.
    This code is working on Win95 but it is in the main EXE-file
    Running without problem for a year.
    This code seems to be working on WIN2000
    (havent been able to prove otherwise) The code is in a DLL
    This code does not work in NT4 SP6a (code in DLL)
    My customer runs this code on both WIN95 and WINNT4
    The problem seems to occure when VNC a TCP/IP based remote-access
    program is run on the machine. But it also sometimes happens if I
    start Explorer or some other program.(with VNC unloaded)

    I need a very quick sulotion to this problem.
    Can someone help?
    Can I prevent context-switching around the relace-command?

    Code:
    '===[LOKAL VARASA2XFP-RUTIN]=====================
    Function ASAVar_TO_XFP()As Integer
    Local Cmd$,Rad$,CmdPos%
    Local rc%,Tmp$,Rl%,z1%,z2%,z3%
    On Error Resume Next
        Tmp$ ="":glbInBuff=""
        gIn.Refill = 1
    '..loopa genom filen.............................
        ErrClear:Seek gIn.FilNr, gIn.FilPos
        If ErrClear > 0 Then Function = 120: Exit Function
        Do
         apiSleep 0
         If gIn.BytesToRead > 0 And gIn.Refill <> 0 Then
          gIn.Refill = 0
          gIn.BuffSize = Min(gIn.BytesToRead,gIn.MaxBuff)
          ErrClear
          Get$ gIn.FilNr, gIn.BuffSize, glbInBuff
          If ErrClear > 0 Then rc%=102:GoSub DebugExit:Function = 102: Exit Function
          gIn.FilPos = Seek(gIn.FilNr)
          If ErrClear > 0 Then rc%=120:GoSub DebugExit:Function = 120: Exit Function
          gIn.BytesToRead = gIn.FilLen - (gIn.FilPos - 1)
        '..Avlägsna Trailing "1A" och NULL...........
          If gIn.BytesToRead < 1  Then
           glbInBuff = Rtrim$(glbInBuff,Any Chr$(0,&H1A))
           If Right$(glbInBuff,1)<>Chr$(10) Then glbInBuff = glbInBuff + Chr$(10)
          End If
    '--Översätt Ascii Till Ebcdic--------------------
          Select Case gIn.Charset
           Case %ASC2EBC
            z1%=&HCA:z2%=&HB3:z3%=&HFA
    'This is where the Error happens
            Replace Any glbAscii With glbEbcdic In glbInBuff
           Case %ANS2EBC
            z1%=&HDE:z2%=&HA1:z3%=&H8C
            Replace Any glbAnsi  With glbEbcdic In glbInBuff
           Case Else
            z1%=&HCA:z2%=&HFA:z3%=&HFC
          End Select
    '--Merge buffer----------------------------------
          glbInBuff = Tmp$ + glbInBuff
    '--Tabort CR och FF------------------------------
          glbInBuff = Remove$(glbInBuff$,Any Chr$(12,13))
    '--rätta till buffer-----------------------------
          gIn.BuffSize = Len(glbInBuff)
          gIn.BuffPos = 1
    '--rapportera filpos-----------------------------
          If ProgressReport(gIn.FilPos,gIn.FilLen)<> 0 Then rc%=200:GoSub DebugExit:Function = 200: Exit Function
         End If
    '--Konvertera raden------------------------------
         gIn.RadSlut = Instr(gIn.BuffPos,glbInBuff, Chr$(10))
         If gIn.RadSlut = 0 Then rc%=110:GoSub DebugExit:Function = 110: Exit Function
         Rad$ = Mid$(glbInBuff,gIn.BuffPos,gIn.RadSlut - gIn.BuffPos)
         gIn.BuffPos = gIn.RadSlut + 1
    '--Dags att fylla på buffer----------------------
         If gIn.BuffSize - gIn.BuffPos < 1024 Then
          Tmp$ = Mid$(glbInBuff,gIn.BuffPos)
          gIn.Refill = 1
         End If
    '--Validera Cmd/rad------------------------------
         Rad$=Rtrim$(Rad$,Any Chr$(0,64))
         Select Case Len(Rad$)
          Case > 1 : Cmd$ = Left$(Rad$,1):Rad$ = Mid$(Rad$,2)
          Case = 1 : Cmd$ = Rad$:Rad$ = Chr$(&H40)
          Case Else: Cmd$ = Chr$(&H40):Rad$ = Chr$(&H40)
         End Select
    '--Hantera NonAsa-kommandon----------------------
         Select Case Asc(Cmd$)
          Case &H5C :cmd$ = Chr$(&H40)
          Case &H4F,z1%,z2%,z3%:cmd$ = Chr$(&HC1): rad$ = Chr$(&H0E) + rad$
         End Select
    '--Returnera Normaliserat kommando---------------
         CmdPos% = Instr(Chr$(078,064,240,096,241,242,243,244, _
                              245,246,247,248,249,193,194,195),Cmd$)
    'This is where the program finds out about it
         If CmdPos% = 0 Then
          Replace Any glbEbcdic With glbAscii In Rad$
          gErr.FelRad = "ERROR 110 CMD = " + Hex$(Asc(Cmd$)) + " RAD = " + Rad$
          rc%=110:GoSub DebugExit:Function = 110: Exit Function
         End If 
    '--Skicka dem till PCC-buffer--------------------
         Cmd$ = Mid$(Chr$(001,009,017,025,137,145,153,161, _
                          169,177,185,193,201,209,217,225), CmdPos%, 1)
    '--Skapa PCC-rad---------------------------------
         Rl% = 1 + Len(Rad$)
         If Rl% > 255 Then rc%=111:GoSub DebugExit:Function = 111:Exit Function
         glbUtBuff = glbUtBuff + Mki$(Rl%) + Cmd$ + Rad$ + Mki$(Rl%)
    '--skriv ut buff---------------------------------
         If Len(glbUtBuff) > gUt.MaxBuff Then
          ErrClear:Put$ gUt.FilNr,glbUtBuff
          If ErrClear > 0 Then Function = 103:Exit Function
          glbUtBuff = ""
         End If
    '--är filen processad----------------------------
         If gIn.BytesToRead < 1 And gIn.BuffPos >= gIn.BuffSize Then Exit Do
        Loop
    '--Töm Utbuffer till disk------------------------
        If Len(glbUtBuff) > 0 Then
         ErrClear:Put$ gUt.FilNr,glbUtBuff
         If ErrClear > 0 Then Function = 103:Exit Function
         glbUtBuff = ""
        End If
        Function = 0
        Exit Function
    DebugExit:
    Local q%,DebugString$,CSet$
    CSet$ = " NONE " & " RC= " & Format$(Rc%) 
    If gIn.CharSet= %ASC2EBC Then CSet$ =" ASC2EBC " & " RC= " & Format$(Rc%)
    If gIn.CharSet= %ANS2EBC Then CSet$ =" ANS2EBC " & " RC= " & Format$(Rc%)
    ErrClear:q% = FreeFile
    ErrClear:Open gDebugFil For Binary As #q%
    ErrClear:Put$ q%,glbInBuff
    DebugString$ = "|CharSet= " & CSet$ & "|FilPos= " & Format$(gIn.FilPos) & " |BuffPos= " & Format$(gIn.BuffPos)
    Put$ q%,DebugString$
    Close q%
    Return    
    End Function

    -------------
    Fred
    mailto:[email protected][email protected]</A>
    http://www.oxenby.se

    Fred
    mailto:[email protected][email protected]</A>
    http://www.oxenby.se

  • #2
    I should perhaps add that DebugExit-sub saves the buffer to a file before exiting the program. This is how I can detect how
    much of the buffer that is translated.
    FileSize is not an issue, though bigger files have more oppertunities to fail.
    I can rerun the conversionprogram once and it works.
    sometimes It works after two, three or four retries.
    But fileSizes are in Gigabyte now and then....
    Originally the InBufferSize were 50kB and I have taken it down to 15 kB, perhaps I should take it down to 7kB..


    ------------------
    Fred
    mailto:[email protected][email protected]</A>
    http://www.oxenby.se

    Fred
    mailto:[email protected][email protected]</A>
    http://www.oxenby.se

    Comment


    • #3
      Fred,

      I have a sneaking suspicion that what you need to do is set the priority
      for the process that you are running. An API like SetPriorityClass() or
      SetThreadPriority() or others in that category may do the job for you.

      I run VNC between 2 win95 boxes and it sems to work fine but it sounds
      like one of the many quirks between Microsoft operating systems that your
      code runs fine on win 9x but not NT.

      The general notion that NT is more strict appears to be a cover for it
      being older and not as well developed as the more popular 9x OS. The OS
      should not effect the sequence of instructions in any running thread, even
      if it task switches in the middle of an operation but with the way some
      of this Microsoft code runs, I would not be surprised what happened.

      There is another consideration, I have a friend who runs an NT server
      for a hospital in Thailand and one of his programmers ran the SP6 on the
      main server which immediately trashed it. Blue screen on boot and it would
      not start.

      He had the main data backed up but the server had to be re-configured from
      scratch and after doing it, he reinstalled SP4 which had been working fine.

      What I am suggesting is that there may be no problem with you code at all,
      it may be the configuration of the NT box with the service pack that it
      has.

      Regards,

      [email protected]


      ------------------
      hutch at movsd dot com
      The MASM Forum

      www.masm32.com

      Comment


      • #4
        Fred;

        I think it might be good for you to rewrite your function to use a LOCAL string variable for the Buffer (make it Static if necessary). You are using a lot of Globals and maybe that is where the problem occurs with NT.

        If you need to use globals, use LOCALs to do all the processing of the Data and then when the data is processed, then move it to a Global variable.

        Since you didn't post all your code, I couldn't tell what the UDTs were like (what types used), but if any of the buffer variables are fixed len strings, make sure you change them to variable len (which means you can use a UDT for it), since fixed len have to be converted before any string functions will work on them.

        If you suspect the replace command is the problem, simply write your own replace function instead. Even if your own function is slower, it will allow you to determine if the problem is really with the replace command. If it is, then rewrite your own replace function using some inline assembler to speed it up.

        If your own replace function has the same problem, then the cause is elsewhere. Remember that PB uses the Windows OLE engine to handle variable len strings, so it is possible that NT has a problem in its version of the OLE DLLs. See if you can update the OLE DLLs with a latter version.

        Another question ,would be, have you tried the program on another computer (besides the current one with NT) that also has NT ?

        The problem could be PC specific and not just the OS.



        ------------------
        Chris Boss
        Computer Workshop
        Developer of "EZGUI"
        http://cwsof.com
        http://twitter.com/EZGUIProGuy

        Comment


        • #5
          Thans guys, I use highest possible priority in all my
          conversion-routines, and I check that tha Api returns
          correct result so AFAIU it has the highest priority
          Code:
                Pc& = SetPriorityClass(GetCurrentProcess(), %HIGH_PRIORITY_CLASS)
          This problem is on several NT-boxes in one location.
          But on two other locations this code run OK on NT4
          with same configuration.

          There is a BIG diffrence:
          The failing NT4 is running with the code in a DLL
          When this code is incorporated in the main EXE (no DLLs)
          it runs OK


          What I can see, and the saved buffer is proving this, is
          that only part of the buffer is translated.
          I was asking about this long time ago (PBDLL 5.0) and had som
          discussions with support,but then I did not have enough hard proof from the field what happens.

          (The DLL is accesed only from one single thread.)



          ------------------
          Fred
          mailto:[email protected][email protected]</A>
          http://www.oxenby.se

          Fred
          mailto:[email protected][email protected]</A>
          http://www.oxenby.se

          Comment


          • #6
            You say it is used within a single thread, but are you sure there is no chance of reenterant sub/function/callback occuring that may be able to alter your global?

            From your code snippet we have no way of knowing how/when this code is executed. If it is executed in response to a callback message you may want to consider adding a "Critical Section" around the code to lock out any reenterant execution.



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

            Comment


            • #7
              This code is called from ONE single point in the program.
              There is no callbacks, no reentrance
              This is the only code running EXEPT for a clock-(timer)interrupt
              and a thread scanning a loggfile for new entries(code in a seperate DLL) trigged by a timer-interrupt
              All my conversion-code is in seperate DLL-s.


              ------------------
              Fred
              mailto:[email protected][email protected]</A>
              http://www.oxenby.se

              Fred
              mailto:[email protected][email protected]</A>
              http://www.oxenby.se

              Comment


              • #8
                Fred;

                Debugging is an Art and I find the saying of Sherlock Holmes (fictional character) to hold true with debugging code:

                After eliminating everything that does not fit the facts, whatever is left over is culprit, no matter how improbable !


                While the answer is not yet apparent, look at the facts so far:


                This problem is on several NT-boxes in one location.
                But on two other locations this code run OK on NT4
                with same configuration.

                There is a BIG diffrence:
                The failing NT4 is running with the code in a DLL
                When this code is incorporated in the main EXE (no DLLs)
                it runs OK
                Note, that the code does work on "some" NT installations. This obviously means the problem "is PC specific".

                What is different between the different PCs running NT ?

                This would imply that the problem is associated with something particular installed on that one NT PC.

                Research this forum and I think there was a post sometime about "which" OS DLLs PB must use to work (ie. OLE DLLs). Write down all the OS DLLs must depend on to work and then compare all the NT PCs and see if they all have the same DLLs (size and date should match). While OS may the same, they may not have the exact same "programs" installed on each and it is possible that one of those programs "overwrote" a system DLL with an older version from a previous service pack. The OLE system uses a couple DLLs and if just one was overwritten with an older version it could cause havic for PB, since it depends on the OLE engine for variable len string handling.

                The fact that other NT PC's don't have this problem is very strong evidence, and must not be discounted. Likely the problem is NOT with the compiler and it may not even be with your code.

                Before tearing into your code trying to fix (what may not be broken), check out all the DLL dependencies for your DLL and check for problems with system DLLs.



                ------------------
                Chris Boss
                Computer Workshop
                Developer of "EZGUI"
                http://cwsof.com
                http://twitter.com/EZGUIProGuy

                Comment


                • #9
                  Fred,

                  > This code is called from ONE single point in the program.

                  Still, with NT you never know for sure, because NT will start a separate thread to perform tasks like writing to a file.

                  It's possible that a previous API call wasn't finished at the time the REPLACE command started. Once that thread gets the processor again, it continues, even in the middle of the REPLACE processing.
                  This would have to be an API call that can access your buffer. Did you call an API function with a pointer to it somewhere?

                  Peter


                  ------------------
                  [email protected]

                  Comment


                  • #10
                    Chris, I think you ought to look one more time.
                    The only diffrence beetween working/not working code
                    is how THE FUNCTION IS CALLED
                    1) Working : this function is the MAIN EXEfile (local function)
                    2) Not working: code is an EXPORTED FUNCTION in a DLL

                    Guys, this is a very simple function
                    it starts at the top, ends at the bottom,is not calling/doing
                    anything else than you can follow in the code
                    ------------------
                    Fred
                    mailto:[email protected][email protected]</A>
                    http://www.oxenby.se



                    [This message has been edited by Fred Oxenby (edited April 10, 2000).]
                    Fred
                    mailto:[email protected][email protected]</A>
                    http://www.oxenby.se

                    Comment


                    • #11
                      Fred,
                      Change your SELECT CASE to IF ELSEIF and see if this makes a difference???

                      James


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

                      Comment


                      • #12
                        Fred,
                        If you want to send me a data stream trace of this, ie, point out where it's failing, I can decode this....or decode it separately in EBCDIC in a text file, I may be able to help there.
                        My trace decode stuff is at work but I may be able to grab a copy of it from here...


                        Otherwise pull the word "Any" out and retest it, that's where my problem was, it HAS to be an exact matchh for ANY to work, otherwise you get a GPF....or something weird...

                        Scott

                        ------------------
                        Scott
                        mailto:[email protected][email protected]</A>

                        [This message has been edited by Scott Turchin (edited April 10, 2000).]
                        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


                        • #13
                          Originally posted by jcfuller:
                          Fred,
                          Change your SELECT CASE to IF ELSEIF and see if this makes a difference???

                          James


                          Thanks james, have been there already...
                          Scott, I know were it goes wrong, I have the failing part of
                          memory on a diskfile.
                          This code have been 'on the air' since 1998 and still is..
                          Dont be fooled by the global strings. I dont want them to
                          move around in memory, but they are VERY local to the function..
                          The CharSets (glbAscii,glbAnsi,glbEbcdic) are set once and are exactly 256 bytes long
                          The Any keyword is the 'key' here, as you want to translate every character in the character-set....
                          Thanks for the thougt though..




                          ------------------
                          Fred
                          mailto:[email protected][email protected]</A>
                          http://www.oxenby.se

                          Fred
                          mailto:[email protected][email protected]</A>
                          http://www.oxenby.se

                          Comment


                          • #14
                            Fred --

                            This doesn't "feel" like a priority or task-switching problem to me, it sounds more like an error is being encountered part-way through the REPLACE ANY operation and it is being aborted before it is finished. Have you checked the values of ERRAPI and GetLastError after the REPLACE ANY operation, to see if Windows is reporting an error?

                            Is there any consistency to the first character that is left un-replaced (or the last character that is replaced?) In other words, I'd be suspicious if the string was being converted correctly until it reached a CHR$(0) or CHR$(255) or something like that, or if the last character that was converted was changed to one of those characters.

                            Are you 100.00% certain that the search and replace strings are both exactly 256 characters long (measured with LEN, not manually counted in the source code) and that they are being initialized before the first REPLACE operation? (I'm sure you're sure, but mismatched string length is the most obvious cause of a REPLACE ANY error.) You wrote...

                            > The failing NT4 is running with the code in a DLL

                            ...so I assume that you are initializing the 256-byte strings in the LibMain %DLL_PROCESS_ATTACH block?

                            -- Eric

                            ------------------
                            Perfect Sync: Perfect Sync Development Tools
                            Email: mailto:[email protected][email protected]</A>

                            "Not my circus, not my monkeys."

                            Comment


                            • #15
                              Yes Eric, this strings are set up during %DLL_ATTACH
                              If it was a problem with the parameters to Replace-command
                              NONE of the buffer should be translated.
                              Try this:
                              Code:
                              a$="ABCDEFGHIJKLMNOPQRSTUVWXYXZ"
                              b$="ACEGIKMOQS"
                              c$="acegikmoqsuwyxazilk"
                              Replace any b$ with c$ in a$
                              Print ERRAPI
                              and you will see that thera are no errors but a$ is translated into "ACEGIKMOQS"
                              You see, it is not that kind of problem...
                              That woud have truncated the buffer......
                              An example:
                              I have a PC-file 250 MB is size, (ASCII,ASA printcodes,CRLF terminated)
                              I convert this file to IBM Mainframe-format soCalled PCC-format.
                              On my first try I get an error after 125 MB (buffer show that only part of the buffer is translated)
                              I try again
                              This time error occure after 2MB (same sort of error)
                              I try again
                              Error after 55MB (same partly converted buffer)
                              I try again
                              This time there is no error.
                              '--This is a short description-----------
                              First read 15 kb of data from file to a buffer
                              Then Translate (Replace Any) this buffer into EBCDIC
                              Then remove all CR and FF-s leaving only LF-s
                              '--
                              Starting from pos 1 in buffer I find the first LF
                              Extract this part of the buffer
                              Checks pos 1 in this part for a valid ASA-printcommand
                              This is done until less than 1 kB of data remain to examine in buffer.
                              Now its time to Refill the buffer, so I copy the reamining
                              part of buffer to temp storage
                              Reads another 15 kb of Data from file into the buffer
                              Translates this 15 kb into EBCDIC
                              Merges Temp Storage with the new buffer
                              Removes CR / FF-s
                              and start over again scanning for LF-s
                              ---------
                              I can see that the buffer is only partly translated,and there is no significance in how much is translated.
                              I have seem 5 kb, and I have seen 14.5 kb
                              But I have never seen a complete untranslated buffer.
                              ---------
                              I have investigated ERRAPI but I came to the conclusion it was
                              not relevant here.
                              ---------
                              The error is revealed because I check every line (pos 1) for a valid ASA/EBCDIC printcode. And if Translate is failed I will have a ASA/ASCII printcode in pos 1
                              ---------
                              It is also to be said that I have never seen a "Trashed buffer"
                              There is no missing part compared to the original file
                              ---------
                              Of course CR-s and LF-s because they are removed after the Replace and have same Char-code in both ASCII and EBCDIC
                              ---------
                              If you examine the DebugExit subroutine, you will see that
                              the file-pointer is pointing at the first byte after the last byte in the buffer so there is no problem to verify that there is
                              no problem in the original file
                              ---------


                              ------------------
                              Fred
                              mailto:[email protected][email protected]</A>
                              http://www.oxenby.se



                              [This message has been edited by Fred Oxenby (edited April 10, 2000).]
                              Fred
                              mailto:[email protected][email protected]</A>
                              http://www.oxenby.se

                              Comment


                              • #16
                                Fred,

                                I just had an idea from what you have posted as what you are doing involves
                                disk writes of very large quantities of sequential data. I have had a similar
                                problem when sequentially processing data in the 20 - 30 meg range which came
                                from the operating system cacheing of disk writes rather than any code problem.

                                It did not show up on a box with a lot of memory that was not low on resource
                                but on smaller machines or ones that were running a lot of processes, it would
                                crash part way through the processing. I wonder if there is a way in the code
                                of flushing the data to disk at a regular interval to avoid this problem.

                                This solved the mystery crashes I was having by flushing the disk writes at
                                a set amount of written data.

                                Regards,

                                [email protected]

                                ------------------
                                hutch at movsd dot com
                                The MASM Forum

                                www.masm32.com

                                Comment


                                • #17
                                  Fred --

                                  REPLACE does not use any API functions to perform its task, per se, but I suggested checking ERRAPI and GetLastError because I thought they might show an error during string memory allocation (or some such). But a test program reveals that REPLACE ANY modifies the string "in place", so I'm inclined to agree that you probably won't see any error values. But it never hurts to check! After all, if you are seeing an error, it is reasonable to ask ERR, ERRAPI, and GetLastError whether or not an error was detected.

                                  I don't know whether or not this helps, but I wrote a test program that reads a 300 MB binary file in 15k blocks, and uses REPLACE ANY to replace all 256 characters, and test the results. It seems to run perfectly on my NT4 machine... it ran in a loop all night long, with no failures.

                                  Maybe you can "boil down" your program to a reasonable size and post the source for a program that fails?

                                  BTW, have you tried adding $REGISTER NONE to your program? There are a small number of documented compiler bugs related to register variables... maybe this is a new one. (Grasping at straws here...)

                                  -- Eric

                                  ------------------
                                  Perfect Sync: Perfect Sync Development Tools
                                  Email: mailto:[email protected][email protected]</A>

                                  "Not my circus, not my monkeys."

                                  Comment


                                  • #18
                                    Thanks Eric,Hutch and everybody else for that matter.
                                    This is one of those situations where your easily loose
                                    either your customer and/or your reputation....
                                    Either way you loose mega-bucks in troubleshooting-costs.
                                    I know that there are no such thing as Error-free computing, but
                                    my customers have been lead to believe this as they have run my
                                    systems for the last eight to ten years without problem.
                                    I have always been able to catch the problems before it hit the
                                    market and take preventive steps..
                                    This time I find myself with the pants down and It is embarrassing.
                                    I cannot reproduce the problem in my network.
                                    In Win2000 I have even been able to completely break down the system
                                    so not even task manager worked. But in solely majestic my program was
                                    running on a black screen, impossible to stop, doing its job until I
                                    physically pulled the plug in the wall to stop it.
                                    Win2000 really impressed me at that time.
                                    -But it does not impress my customers.
                                    I got some unexpected help from our mighty lord last night.
                                    I spent 6 hours trying to copy 500 Mbyte of data from one remote location
                                    At same time it took 6 minutes to read a scriptfile (normally 5 seconds).
                                    This gave me the opportunity to throw out NT4 replacing it with Win98SE
                                    This did not solve the network congestion, but Win98 handled it better,
                                    and most important, my program runs without error.
                                    ---
                                    I kind of hoped that someone from the back room of Powerbasic R&D would
                                    step forward and say "HRM..... little boy, if you do like this you can
                                    prevent ....."
                                    And at that time I should not mind to be called little boy...
                                    ---


                                    ------------------
                                    Fred
                                    mailto:[email protected][email protected]</A>
                                    http://www.oxenby.se

                                    Fred
                                    mailto:[email protected][email protected]</A>
                                    http://www.oxenby.se

                                    Comment


                                    • #19
                                      Fred --
                                      If you are sure that problem exactly in Replace as it is, why not to change it to simple FOR If Then NEXT.
                                      If all will work, you can change this part by inline assembler code and willn't lose something in performance.
                                      In any case - if this is really compiler's bug, you can't expect to receive update in nearest future.
                                      And, like Eric, I want to ask also -- do you use #REGISTER NONE ?

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

                                      Comment


                                      • #20
                                        Hi,Semen
                                        I have not done any serious assembler-coding since 1975
                                        and not really (without help) for the x86 processor.
                                        On the other hand, Replace-macro is probably expanded by some
                                        very good assembler-programmer at powerbasic. As I understand it
                                        this macro does not need to reallocate memory at all, so my effort in
                                        this area would probably do more harm than good....
                                        Your second question is a valid one, as I have learned from recent experience with powerbasic.
                                        No I am not using #Register None.
                                        First of all that is not the default setting for the compiler
                                        Secondly, there is no variable in this function that would benefit or be hurt by being a
                                        'register'-variable .In that context I have never taken that under consideration.
                                        One of my trouble-shooting philosophies is this:
                                        "Never fill up gasoline in a car that needs higher pressure in the tires".
                                        Even if it doesn't hurt to give it a few more gallons.
                                        I saw a good variation on this theme somewhere else on this bard.
                                        You can make a cow into a hamburger, but not a hamburger into cow..
                                        I don't know about that, but if I tried, I surely should try to sort out the seasoning first.
                                        It is so good to have this forum, to put the question to.
                                        You will get new angels on old problems, and sometimes you even get the solution
                                        or encouragement to do the obvious thing.
                                        Thank you everybody


                                        ------------------
                                        Fred
                                        mailto:[email protected][email protected]</A>
                                        http://www.oxenby.se

                                        Fred
                                        mailto:[email protected][email protected]</A>
                                        http://www.oxenby.se

                                        Comment

                                        Working...
                                        X