QB664PE v3.10.0 is now live for X-Mas!!

[James D Jarvis]

I have a bone to pick with you QB64Phoenix Edition developers... I've had to change my dev folder structure and my behavior with how frequently you are pumping out these updates.    3 updates in 2 months? C'mon.   

[RhoSigma]

" Do the media files, etc. become smaller in their compiled/embedded form? "  <- Good question. Is it worth it creating compressed files before embedding them or do they get squished a little by the embedding?

We just overlapped , see post #9...

[RhoSigma]

I have a bone to pick with you QB64Phoenix Edition developers... I've had to change my dev folder structure and my behavior with how frequently you are pumping out these updates.    3 updates in 2 months? C'mon.   

Last release was Oct, 8 what updates do you mean?

[James D Jarvis]

October 8, was 2 months ago. (yes it was more than 8 weeks but it is still just 2 months  Oct<-Nov<-Dec).   I was just goofing about how impressive the update cycle has been. I am impressed.

[SMcNeill]

Thank you for this the QB64 PE team! Best new year's wishes.

Steve you might have to fix the topic title... there is one "6" too many. "What is QB-six-sixtyfour-pee-hee? Is it better or worse than something-six-sixty-six?" LOL.

QB664 is the secret Santa code!!  CONGRATS!! As you're the first to notice it and mention it, YOU GET TO PLAY SECRET SANTA and create a nice gift for everyone to enjoy on the 25th!   Shhhh.....  Don't tell anyone what you're creating, Santa!  It's got to be SECRET!!

[doppler]

I find the embed stuff very interesting.  I like the F5 fix #399 too.  I have been bitten by that one once or twice.

Edit:
I usually expand the qb64pe into a ram drive.  (just faster than HDD) Before copying my bas sources and other stuff.  (into ram drive copy). Then I rename original qb64pe to qb64pe-org.  Being very cautious.  Here is the thing.  There are a couple of files which are marked "Read-only" in the directory structure.  So when I move the new ram drive directory of qb64pe to my HDD.  I get warnings about deleting read-only files.

Do those files have to be "read-only" attributed ?
attached list of names n paths

  readonlynames.txt (Size: 67.42 KB / Downloads: 26)

[madscijr]

HIGHLIGHT::  #Implemented $EMBED metacommand and _EMBEDDED$ function. - @RhoSigma-QB64
Can be used to embed any files (images, sounds, fonts and other assets) into the compiled executable and recall it in the program when needed.
Read the respective Wiki pages: $EMBED and EMBEDDED$

I step away from QB64PE for a couple months and come back to find some really cool features! 
This one will be very useful. Great work, guys!

[RhoSigma]

I find the embed stuff very interesting.  I like the F5 fix #399 too.  I have been bitten by that one once or twice.

Edit:
I usually expand the qb64pe into a ram drive.  (just faster than HDD) Before copying my bas sources and other stuff.  (into ram drive copy). Then I rename original qb64pe to qb64pe-org.  Being very cautious.  Here is the thing.  There are a couple of files which are marked "Read-only" in the directory structure.  So when I move the new ram drive directory of qb64pe to my HDD.  I get warnings about deleting read-only files.

Do those files have to be "read-only" attributed ?
attached list of names n paths

There's no need to make any files read-only, so just change the attribute as needed.

More than that its all files in ......\opt\..... which are not required at all, the first thing I do after extracting a new qb64pe release is typically go into internal\c\c_compiler and completely delete the folders "licenses", "opt" and "share". It's about 3/4 of the entire windows package (some 15000 files) which are absolutely not required to compile any QB64 programs.

We could just strip out these from the package, if there wouldn't be the license requirement to distribute only the full unmodified MinGW package. However, you as the end user are under no obligation to keep all these "dead" unused files on your drive.

[doppler]

I find the embed stuff very interesting.  I like the F5 fix #399 too.  I have been bitten by that one once or twice.

Edit:
I usually expand the qb64pe into a ram drive.  (just faster than HDD) Before copying my bas sources and other stuff.  (into ram drive copy). Then I rename original qb64pe to qb64pe-org.  Being very cautious.  Here is the thing.  There are a couple of files which are marked "Read-only" in the directory structure.  So when I move the new ram drive directory of qb64pe to my HDD.  I get warnings about deleting read-only files.

Do those files have to be "read-only" attributed ?
attached list of names n paths

There's no need to make any files read-only, so just change the attribute as needed.

More than that its all files in ......\opt\..... which are not required at all, the first thing I do after extracting a new qb64pe release is typically go into internal\c\c_compiler and completely delete the folders "licenses", "opt" and "share". It's about 3/4 of the entire windows package (some 15000 files) which are absolutely not required to compile any QB64 programs.

We could just strip out these from the package, if there wouldn't be the license requirement to distribute only the full unmodified MinGW package. However, you as the end user are under no obligation to keep all these "dead" unused files on your drive.

The standard qb64pe release for windows has the attribute set prior to 7-zip doing it's thing.  How about we strip off the attribute on next release ?

[RhoSigma]

The standard qb64pe release for windows has the attribute set prior to 7-zip doing it's thing.  How about we strip off the attribute on next release ?

Won't work, the MinGW package is not part of our repository, it's just pulled in during build time from the actual MinGW package, which itself is a self-extarcting (.exe) archive.

Maybe @DSMan195276 could adapt the github build script(s) to remove the read-only state after it pulled in the MinGW package but befor packing it into our .7z release archive.