QB64 Phoenix Edition v3.7.0 Released!

[JRace]

Depends. I have Windows in my work and my own PCs. In my work PC, perhaps because of McAfee Enterprise virus filter, it takes quite some time to delete the old QB64pe folder and then quite some more time to extract the 7zip files for the new QB64pe. Total time becomes closer to 20 minutes +. Used to be more like 30 minutes, but fortunately lately, deleting the old QB64pe folder became much faster than it used to be.

I agree that in my home PC, the process is much faster. Anyway, I'm not hard over on this. Just wondered.

Some A/V software can really drag file ops to a crawl.  If your A/V has a tray icon, bring up its menu and look for an option to disable file scanning for a few minutes.  I was able to do that on my work laptop and it made a big difference.

[mnrvovrfc]

Unfortunately `_Inflate$()` doesn't give an error if the decompression fails so you had no way to know. It really should error, but we probably can't make that change now so we're looking at a fix for `miniz` to give you the correct size. As an alternative to waiting, you code will work in v3.7.0 if you give `_Inflate$()` the size parameter, so `btemp$ = _Inflate$(btemp$, m.SIZE)`.

I was going to try "LEN(A$)" as second parameter to _INFLATE$ but wasn't sure if it would have worked. I would have needed to multiply it by something.

I think Dav has to make a modification to provide the compressed buffer length, so that it could be accessed with _INFLATE$ later, as an alternate edition to his picture-packing routine. Once I wrote a simple utility with Free Pascal to do GZipped compression. I was forced to include a base-36 code as part of the "thisfile.ext.base36number.gz" because I didn't know another way to include it, so it could be retrieved by the "Un-gee-zipper".

[RhoSigma]

Depends. I have Windows in my work and my own PCs. In my work PC, perhaps because of McAfee Enterprise virus filter, it takes quite some time to delete the old QB64pe folder and then quite some more time to extract the 7zip files for the new QB64pe. Total time becomes closer to 20 minutes +. Used to be more like 30 minutes, but fortunately lately, deleting the old QB64pe folder became much faster than it used to be.

I agree that in my home PC, the process is much faster. Anyway, I'm not hard over on this. Just wondered.

Question:
Does it also take long until the content appears in the explorer window, when you simply click through the folder structure of QB64 back and forth.

If disk accesses take that long, then it usually indicates a defect in the filesystem structure, which the system tries to work around and that consumes all the time. Had that too a couple of times already.
As Terry said, it shouldn't take longer than a couple seconds to delete a QB64 installation.

When you have a couple hours time, then you should schedule a DSKCHK via the Properties dialog of the affected drive, make sure you tick the "Automatically correct filesystem errors" checkbox.

[Kernelpanic]

@bert22306 - I would always remove program folders like the one from QB64pe from the virus filter.
Such "virus guards" like McAfee are not wrongly called snake oil, because they often cause a lot of problems. You can read about it here, for example: Trojaner Board It's in German, but one can use Google's translation.

The Windows Defender included with Windows has been so good since Win 8.0 that one do not need anything else.

To @mnrvovrfc - it really is not necessary to create a new folder every time you reinstall QB64 on Windows. Of course, every new version goes into the same folder for me. The fact that I put QB64 in the system path is only relevant if you want to invoke the compiler from the command line; for the IDE it doesn't matter.

[TempodiBasic]

Great improvements,
about _DEVICES, no news,
this code continue to fails...

Code: (Select All)

'minitest Joystic detection
DefInt I
Const False = 0, True = Not False
ReDim Shared iLBu(1 To 1), iLax(1 To 1), iLWh(1 To 1)
ReDim Shared iLB, iLA, iLW

While True
    Cls
    Color 1, 10
    Locate 2, 1: Print "Press Enter to detect joystick"
    Locate , 1: Print " Press Escape to quit program"
    Color 5, 12: Locate 10, 1: Print iLA, iLB, iLW
    Locate , 1: Print UBound(iLax), UBound(iLBu), UBound(iLWh)
    Color 6, 2: Locate 12, 1: Print iLA, iLB, iLW
    Locate , 1: Print UBound(iLax), UBound(iLBu), UBound(iLWh)

    iKB = _KeyHit
    If iKB = 13 Then
        'Color 5: Locate 10, 1: Print iLA, iLB, iLW
        'Locate , 1: Print UBound(iLax), UBound(iLBu), UBound(iLWh)
        If JoystickInit = True Then
            'Color 6: Locate 12, 1: Print iLA, iLB, iLW
            'Locate , 1: Print UBound(iLax), UBound(iLBu), UBound(iLWh)
        Else
            Color 4, 14
            Locate 22, 1: Print "Joystick NOT detected": Sleep 2
        End If
    ElseIf iKB = 27 Then
        Color 7, 0
        Exit While
    End If
    _Limit 10
Wend
End

Function JoystickInit%
    iDevice = _Devices
    If iDevice > 2 Then
        JoystickInit% = True
        iLA = _LastAxis(iDevice)
        iLB = _LastButton(iDevice)
        iLW = _LastWheel(iDevice)
        ReDim iLBu(1 To iLB), iLax(1 To iLA), iLWh(1 To iLW)
    Else
        JoystickInit% = False
        iLA = 0
        iLB = 0
        iLW = 0
        ReDim iLBu(1 To iLB), iLax(1 To iLA), iLWh(1 To iLW)

    End If
End Function

use an USB Jostick, first run the code, press Enter (you get the NO Joystick warning), then Plugin the Joystick and after some seconds press Enter again (you get the info of joystick plugged in) , now plug out the joystick (you desire to use another joystick or another USB) and after some seconds press Enter again...
for Operative System the joystick is again NO detected, for QB64pe it is still there in that USB!

waiting for when developers efforts will (peharps) be focused on this issue.
Thank you so much for all the time, the love and the energy spent for QB64pe development!

[TerryRitchie]

I'm having no issues with the updates to _DEVICES and related commands. Here is a test snippet of code that I wrote. It detects when new controllers have been added and when they have been disconnected.

Code: (Select All)

DIM Devices AS INTEGER
DIM Fcount AS INTEGER
DIM d AS INTEGER
DIM DeviceName AS STRING

Devices = _DEVICES
Fcount = 0

DO
    CLS
    _LIMIT 30
    Fcount = Fcount + 1
    IF Fcount = 30 THEN '                                        check for new devices once per second
        Fcount = 1
        IF _DEVICES <> Devices THEN Devices = _DEVICES '         if number of devices changes get new count
    END IF
    PRINT
    FOR d = 1 TO Devices '                                       print found devices
        COLOR 14, 1
        DeviceName = _DEVICE$(d)
        IF INSTR(DeviceName, "[DISCONNECTED]") THEN COLOR 7, 0 ' change color if disconnected
        PRINT " Found: "; _DEVICE$(d)
        COLOR 7, 0
    NEXT d
    _DISPLAY
LOOP UNTIL _KEYDOWN(27) '                                        press ESC to exit

[Steffan-68]

Agreed if I were on Windows. On Windows should always have a brand new directory for the latest version of QB64(PE); rename the old one or delete it (if disk space is getting short). Even if MinGW and its associates received no changes whatsoever.

But I haven't had problems with doing this on Linux because I make sure to be as updated as possible then run "setup_lnx.sh" right after unpacking the QB64PE archive.

Haven't had a problem yet Again, it may not cause any immediately obvious issues, but it's not a supported way to do updates and will eventually lead to a broken system, even on Linux.

Has something changed in the '_MEMPUT' command?

The IDE does not report an error, but the error 'Critical Error #300 Line:833 Memory region out of range' is output in the finished compiled program.

With QB64pe V 3.6 the program runs normally, now in V 3.7 this error occurs.

We're investigating It seems like an issue with the change from `zlib` to `miniz`. Your data doesn't successfully decompress with either library, but `zlib` would give you back the partially decompressed data and the correct length of it, where-as `miniz` doesn't give the length of the partially-decompressed data so `btemp$` has the wrong length.

Unfortunately `_Inflate$()` doesn't give an error if the decompression fails so you had no way to know. It really should error, but we probably can't make that change now so we're looking at a fix for `miniz` to give you the correct size. As an alternative to waiting, you code will work in v3.7.0 if you give `_Inflate$()` the size parameter, so `btemp$ = _Inflate$(btemp$, m.SIZE)`.

Great thank you ! Everything worked with 'btemp$ = _Inflate$(btemp$, m.SIZE)' .

Don't know what kind of problem some have to install a new version of QB64PE?
I simply created a BAT file that removed the old version for me, after which I only had to endpack the new one in the same folder.


Kill_QB64PE.BAT

del copying.txt
del makefile
del qb64pe.1
del qb64pe.exe
del readme.md
rd /s /q internal
rd /s /q licenses
rd /s /q source

[mnrvovrfc]

For someone who uses the IDE extensively, the trick above wipes out the "(qb64pepath)/internal/config.ini". Back that up regularly.

[bert22306]

Guys, the whole point of McAfee Enterprise is that the enterprise gets to decide what needs to be examined, not the user. I can't change the settings on the work PC.

When deleting a gymongous folder such as qb64pe, it seems to examine everything it is deleting. As I said, in the past few weeks, the process seems to have improved. It's still slow, but it's not as excruciatingly slow as it used to be. Just deleting the old folder took close to 20 minutes or so. I'd say today, it takes closer to 5 minutes. No telling what McAfee dreams up next, of course.

Extracting files from the 7zip download is still rather excruciating. Each and every single file shows up on the screen, briefly yes, but it still shows up. That process takes many minutes.

On my own PC, no big deal, but even there, I had to install the better zip utility. The original utility I had took, like, 30 minutes, for heaven's sake. I timed it. It was crazy slow. The new one takes just seconds.

[JRace]

When deleting a gymongous folder such as qb64pe, it seems to examine everything it is deleting.

That's exactly what it's doing, scanning all 20,000 or so files of QB64PE.

If you can live with it, cool.  We don't need to reinstall QB64 every time we use it, anyway. 

McAfee is one of those set-it-and-forget-it PC tools that corporate IT departments love.  Lock down the computer so tightly that the user can't do much more than check email and use approved pre-installed business apps.

but

Depending on the configuration chosen by the enterprise, even McAfee can offer an option to temporarily disable its endpoint scanners.  Those scanners will restart automatically after a preset time.



(Personal war story: In a previous field tech career, I worked for one company, under contract to another company, and had to live with absurdly clamped down laptops from both companies.
I had no use for their approved software, and they neither understood nor cared about my job's software needs.
After getting frustrated by jumping through hoops for IT to get my needed software tools cleared for installation, I gave up and brought in a netbook of my own to get work done.  It was never on either company's network, so they never cared.  From then on I only used the company laptops for filling out my time sheets, checking company email...  and to hold the Post-Its with all my company passwords, since password managers were strictly forbidden.)