QB64.org Forum

Active Forums => QB64 Discussion => Topic started by: SMcNeill on December 22, 2018, 07:12:12 am

Title: QB64x64 (12-22-2018)
Post by: SMcNeill on December 22, 2018, 07:12:12 am
Updated the 64-bit version to include all the latest changes and enhancements to QB64.
Also swapped out the old c-compiler from 2014 for the latest version (v8.10, I believe.)
Did a little tinkering under the hood so both halves will play nicely together.

Feel free to grab a copy from here: DEBUGGING — GRAB NEWEST VERSION FROM “BEST ANSWER”

And most important:  MERRY CHRISTMAS!!
Title: Re: QB64x64 (12-22-2018)
Post by: bplus on December 22, 2018, 09:24:58 am
Thanks Steve, Merry Christmas to you as well!
Title: Re: QB64x64 (12-22-2018)
Post by: RhoSigma on December 22, 2018, 10:04:35 am
Well Steve, thanks for your efforts, but it seems to me that whatever you did in QB64 itself or maybe just the new compiler did broke regular and box line drawing. I noticed it by trying my latest GuiTools release (GuiAppDemo-GL.bas) with your new x64 version, and all object frames as well as rulers are either completely gone or drawn very pixelized. However, a quickly written test program shows that box fill drawing is not affected.

Will now test your x32 version with the new compiler...

Title: Re: QB64x64 (12-22-2018)
Post by: SMcNeill on December 22, 2018, 10:08:36 am
Do you have a sample of the broken code to test?  I’ll dig into it and see what’s going on.

EDIT:

LINE (100,100)-(200,200), color, BF — works.


LINE (100,100)-(200,200), color, B — doesn’t.  I’ll dig into it later and see why it doesn’t want to work as advertised with the newest compiler version.  Probably a simple syntax change somewhere.
Title: Re: QB64x64 (12-22-2018)
Post by: bplus on December 22, 2018, 10:51:19 am
Yes, I am getting a number of odd things. The download file wouldn't complete when I exited browser even though at 100% on display. Then Antimalware ran and ran activating fan. Then I couldn't delete the 7z file with 0 bytes in it for some time. When fan finally settled down and 7z deleted, I tested graphics programs and backgrounds weren't clearing. And you know about lines not working..

The IDE is red lining this line which is fine in previous version:
CONST polyAngle = pi / 6  'pi was dim shared = _PI
Title: Re: QB64x64 (12-22-2018)
Post by: FellippeHeitor on December 22, 2018, 11:01:12 am
Can't mix variables with CONST. Sure that was working before?
Title: Re: QB64x64 (12-22-2018)
Post by: SMcNeill on December 22, 2018, 11:05:36 am
Yes, I am getting a number of odd things. The download file wouldn't complete when I exited browser even though at 100% on display. Then Antimalware ran and ran activating fan. Then I couldn't delete the 7z file with 0 bytes in it for some time. When fan finally settled down and 7z deleted, I tested graphics programs and backgrounds weren't clearing. And you know about lines not working..

The IDE is red lining this line which is fine in previous version:
CONST polyAngle = pi / 6  'pi was dim shared = _PI

CONST polyAngle = _PI / 6 should work, but it's definitely not going to work with a shared variable with your CONST.

The glitch with lines and boxes has been corrected.

Can you share a program where the background isn't clearing?  I'll dig into it.
Title: Re: QB64x64 (12-22-2018)
Post by: bplus on December 22, 2018, 11:15:43 am
Can't mix variables with CONST. Sure that was working before?

No not anymore, when I added an ' to <<<<<<<<<<<<<<<<<<< to point to it, it red lined!!!

but before the comment, I was looking at OK in older QB64 X 64 IDE (see screen shot). This is not a big concern but still...
Title: Re: QB64x64 (12-22-2018)
Post by: bplus on December 22, 2018, 11:26:59 am
Quote
Can you share a program where the background isn't clearing?  I'll dig into it.

The background was drawn with Line, when I added , , BF to line the background "clearing" problem was fixed as it went from drawing nothing to coloring fill sections. So if you have that fixed then we should be good.

Title: Re: QB64x64 (12-22-2018)
Post by: bplus on December 22, 2018, 11:40:10 am
OH Steve, if you are going to repost update, can you provide more info in the Help > About window X64 (as Fifi suggested) and date.
Title: Re: QB64x64 (12-22-2018)
Post by: FellippeHeitor on December 22, 2018, 11:45:50 am
It's a puzzling screenshot. It's also irreproducible at my machine. CONST never accepts a variable.
Title: Re: QB64x64 (12-22-2018)
Post by: SMcNeill on December 22, 2018, 11:56:59 am
Give this version a shot, guys.  See if all isn't working as intended:

https://www.dropbox.com/s/56a267uav7cub9d/QB64x64%20%2812-22-2018%29.7z?dl=1

This should fix the line bug for us, and if so, I'll update the x32 version with the changes and repost it again in a few.

(Seems like there's always a few little tweaks which are required any time the compiler is swapped out for a replacement.  Let's hope this is all we need to get current, this time.  ;) )
Title: Re: QB64x64 (12-22-2018)
Post by: Qwerkey on December 22, 2018, 12:21:46 pm
Mine also crashed inside a FUNCTION

Code: QB64: [Select]
  1. FUNCTION ToHardware& (ImgName$, X1%, Y1%)
  2.     TempImg& = _NEWIMAGE(X1%, Y1%, 32)
  3.     _PUTIMAGE (0, 0)-(X1% - 1, Y1% - 1), _LOADIMAGE(ImgName$, 32), TempImg&
  4.     ToHardware& = _COPYIMAGE(TempImg&, 33)
  5.     _FREEIMAGE TempImg&

at the _PUTIMAGE line.
Title: Re: QB64x64 (12-22-2018)
Post by: SMcNeill on December 22, 2018, 12:29:44 pm
Can you guys share the full code of whatever crashes, please.  It’s a little difficult to debug from code snippets alone.  It’s much appreciated.  :)
Title: Re: QB64x64 (12-22-2018)
Post by: SMcNeill on December 22, 2018, 12:33:07 pm
Mine also crashed inside a FUNCTION

Code: QB64: [Select]
  1. FUNCTION ToHardware& (ImgName$, X1%, Y1%)
  2.     TempImg& = _NEWIMAGE(X1%, Y1%, 32)
  3.     _PUTIMAGE (0, 0)-(X1% - 1, Y1% - 1), _LOADIMAGE(ImgName$, 32), TempImg&
  4.     ToHardware& = _COPYIMAGE(TempImg&, 33)
  5.     _FREEIMAGE TempImg&

at the _PUTIMAGE line.

* might want to check this for a memory leak as well.  There’s no way to FREEIMAGE the _LOADIMAGE when _PUTIMAGE is done. 
Title: Re: QB64x64 (12-22-2018)
Post by: RhoSigma on December 22, 2018, 12:37:46 pm
Hi Steve, here some more info for you...

Your latest request to check the x64 version from 06-17-2015:
-> everything working just fine for me

Your previous x64 version from 07-21-2018:
-> still everything working just fine for me

Your latest x64 version from 12-22-2018 (after your LINE related fix):
-> LINE , LINE..., B, LINE..., BF seems ok now
-> but LINE with style% argument seems to ignore the given style%, lines are always fully drawn
Title: Re: QB64x64 (12-22-2018)
Post by: SMcNeill on December 22, 2018, 01:11:48 pm
I noticed the line style was off.  It should be fixed now.  (Or else I uploaded the wrong 7z file.)  I’ll recheck things on my end again.

********

Reply #11 (Best Answer) should have the fix for line and style both.  If it doesn’t, I’ll dig a little more.
Title: Re: QB64x64 (12-22-2018)
Post by: bplus on December 22, 2018, 05:34:49 pm
Steve, again problems with download of 7z file. I think it originates with browser (Opera) and your link from here but Windows is showing very new kind of Dialog window I've never seen before, maybe buggy or maybe extraction isn't working correctly?
Title: Re: QB64x64 (12-22-2018)
Post by: SMcNeill on December 23, 2018, 12:10:09 am
Steve, again problems with download of 7z file. I think it originates with browser (Opera) and your link from here but Windows is showing very new kind of Dialog window I've never seen before, maybe buggy or maybe extraction isn't working correctly?

Was compressed in Bzip instead of lhza2 (whatever the 2 exact abbreviations are, I didn't bother to go recheck)...   Try this version: it’s zipped in the other format — https://www.dropbox.com/s/56a267uav7cub9d/QB64x64%20%2812-22-2018%29.7z?dl=1
Title: Re: QB64x64 (12-22-2018)
Post by: Cobalt on December 23, 2018, 12:12:40 am
is this just Unzip and run? or do I need to do something first, getting "c++ compilation failed" trying to run the speed test code from the other post(why so slow)
Title: Re: QB64x64 (12-22-2018)
Post by: SMcNeill on December 23, 2018, 12:44:18 am
It should be unzip and run, unless I'm going old and crazy -- which is always a possibility.
Title: Re: QB64x64 (12-22-2018)
Post by: Qwerkey on December 23, 2018, 05:55:00 am
Mine also crashed inside a FUNCTION

Code: QB64: [Select]
  1. FUNCTION ToHardware& (ImgName$, X1%, Y1%)
  2.     TempImg& = _NEWIMAGE(X1%, Y1%, 32)
  3.     _PUTIMAGE (0, 0)-(X1% - 1, Y1% - 1), _LOADIMAGE(ImgName$, 32), TempImg&
  4.     ToHardware& = _COPYIMAGE(TempImg&, 33)
  5.     _FREEIMAGE TempImg&

at the _PUTIMAGE line.

* might want to check this for a memory leak as well.  There’s no way to FREEIMAGE the _LOADIMAGE when _PUTIMAGE is done. 

I think that I must be still be making elementary mistakes.

Code: QB64: [Select]
  1. FUNCTION ToHardware& (ImgName$, X1%, Y1%)
  2.     TempImg& = _NEWIMAGE(X1%, Y1%, 32)
  3.     _PUTIMAGE (0, 0)-(X1% - 1, Y1% - 1), _LOADIMAGE(ImgName$, 32), TempImg&
  4.     ToHardware& = _COPYIMAGE(TempImg&, 33)
  5.     _FREEIMAGE TempImg&
  6.  
  7. FUNCTION ToHardware1& (ImgName$, X1%, Y1%)
  8.     TempImg& = _NEWIMAGE(X1%, Y1%, 32)
  9.     Temp2mg& = _LOADIMAGE(ImgName$, 32)
  10.     _PUTIMAGE (0, 0)-(X1% - 1, Y1% - 1), Temp2mg&, TempImg&
  11.     ToHardware1& = _COPYIMAGE(TempImg&, 33)
  12.     _FREEIMAGE Temp2mg&
  13.     _FREEIMAGE TempImg&

Originally my FUNCTION was as in ToHardware1&, where Temp2mg& is explicitly freed after use.  But then I thought I'd optimise program lines and moved the _LOADIMAGE directly into the _PUTIMAGE, thinking that _FREEIMAGE would not then be required.  So you must always do _FREEIMAGE and never put _LOADIMAGE into a _PUTIMAGE?  I will use this method in future.
Title: Re: QB64x64 (12-22-2018)
Post by: Qwerkey on December 23, 2018, 06:54:01 am
With your latest version and _FREEIMAGE used everywhere, all works well.
Title: Re: QB64x64 (12-22-2018)
Post by: Qwerkey on December 23, 2018, 07:47:35 am
From Fellippe: Can't mix variables with CONST.

Is this not allowed:
Code: QB64: [Select]
  1. CONST XGrid%% = 24, YGrid%% = 16, BlockSize%% = 51, MidExit%% = XGrid%% \ 2

where the last CONST is defined as half the value of the first?

I've used it in my code and it gives the correct value.
Title: Re: QB64x64 (12-22-2018)
Post by: Qwerkey on December 23, 2018, 07:53:47 am
Steve, would you just remind me?  (Obviously, I wouldn't be so dim as to not actually know the answer!!).  What is the actual benefit of running the 64-bit version for those of us with 64-bit machines and OS?
Title: Re: QB64x64 (12-22-2018)
Post by: FellippeHeitor on December 23, 2018, 08:07:07 am
CONSTs can use CONSTs.

CONST FALSE = 0, TRUE = NOT FALSE

It's variables that can't get in the equation. CONSTs are fixed relacements, never changing and precalculated. Variables will change during execution.
Title: Re: QB64x64 (12-22-2018)
Post by: SMcNeill on December 23, 2018, 08:22:45 am
Steve, would you just remind me?  (Obviously, I wouldn't be so dim as to not actually know the answer!!).  What is the actual benefit of running the 64-bit version for those of us with 64-bit machines and OS?

Easiest answer is this one: https://www.qb64.org/forum/index.php?topic=895.0

64-bit OSes don’t natively run 32-bit programs.  They have an emulation layer called Windows-On-Windows (System WOW), which you can think of as being an automatic DOSbox working behind the scenes.  https://en.m.wikipedia.org/wiki/WoW64

When you run a 32-bit program, WoW64 basically translates it to 64-bit and then runs it for you.

So the advantages you find in creating 64-bit apps are:
1) Usually smaller compile sizes, from my experience
2) Faster run times and less overhead as WoW isn’t needed to “translate” your program.
3) Removed memory limits.  32-bit programs are limited to about 1.5GB memory; 64-bit and the sky’s the limit.
Title: Re: QB64x64 (12-22-2018)
Post by: SMcNeill on December 23, 2018, 08:42:44 am
Mine also crashed inside a FUNCTION

Code: QB64: [Select]
  1. FUNCTION ToHardware& (ImgName$, X1%, Y1%)
  2.     TempImg& = _NEWIMAGE(X1%, Y1%, 32)
  3.     _PUTIMAGE (0, 0)-(X1% - 1, Y1% - 1), _LOADIMAGE(ImgName$, 32), TempImg&
  4.     ToHardware& = _COPYIMAGE(TempImg&, 33)
  5.     _FREEIMAGE TempImg&

at the _PUTIMAGE line.

* might want to check this for a memory leak as well.  There’s no way to FREEIMAGE the _LOADIMAGE when _PUTIMAGE is done. 

I think that I must be still be making elementary mistakes.

Code: QB64: [Select]
  1. FUNCTION ToHardware& (ImgName$, X1%, Y1%)
  2.     TempImg& = _NEWIMAGE(X1%, Y1%, 32)
  3.     _PUTIMAGE (0, 0)-(X1% - 1, Y1% - 1), _LOADIMAGE(ImgName$, 32), TempImg&
  4.     ToHardware& = _COPYIMAGE(TempImg&, 33)
  5.     _FREEIMAGE TempImg&
  6.  
  7. FUNCTION ToHardware1& (ImgName$, X1%, Y1%)
  8.     TempImg& = _NEWIMAGE(X1%, Y1%, 32)
  9.     Temp2mg& = _LOADIMAGE(ImgName$, 32)
  10.     _PUTIMAGE (0, 0)-(X1% - 1, Y1% - 1), Temp2mg&, TempImg&
  11.     ToHardware1& = _COPYIMAGE(TempImg&, 33)
  12.     _FREEIMAGE Temp2mg&
  13.     _FREEIMAGE TempImg&

Originally my FUNCTION was as in ToHardware1&, where Temp2mg& is explicitly freed after use.  But then I thought I'd optimise program lines and moved the _LOADIMAGE directly into the _PUTIMAGE, thinking that _FREEIMAGE would not then be required.  So you must always do _FREEIMAGE and never put _LOADIMAGE into a _PUTIMAGE?  I will use this method in future.

Let’s change the example to something physical, to help illustrate the issue.

Instead of NEWIMAGE, let’s SawWood and make a plank.
Instead of LOADIMAGE, let’s PickUpPlank.
Instead of PUTIMAGE, let’s PaintPlank.
Instead of FREEIMAGE, let’s DropPlank

ThisBoard = SawWood(2,4,10) ‘saw wood to make a 2x4, 10 feet long.
PaintPlank (Top)-(Bottom), ThisBoard, PickUpPlank(“OffGround”)
DropPlank ThisBoard

Now, with this odd set of real world instructions, we:
1) Saw a new 2x4.
2) Paint the new 2x4 the same color as another plank we pick up off the ground.
3) Then we drop the new 2x4.

Now question:  How many times do you think you can repeat this process?  You never actually drop the board you picked up from the ground; you’re still holding it...

And compare my little example to your original code (FUNCTION ToHardware).  ;)



*ANY TIME* you load a resource in memory, you want to be able to free it when finished.  If not, you create a memory leak which will eventually doom your program.
Title: Re: QB64x64 (12-22-2018)
Post by: Qwerkey on December 23, 2018, 09:58:46 am
CONSTs can use CONSTs.

CONST FALSE = 0, TRUE = NOT FALSE

It's variables that can't get in the equation. CONSTs are fixed relacements, never changing and precalculated. Variables will change during execution.
Thanks for the confirmation, Fellippe.  From the Wiki, I wasn't totally sure.  I always think of a CONST as a variable whose value can't change, and therefore CONST is a subset of the type Variable.

Title: Re: QB64x64 (12-22-2018)
Post by: Qwerkey on December 23, 2018, 10:05:14 am
Steve, thanks for the clarifications.  Would I be correct in assuming that I should now be using QB64x64 (12-22-2018) instead of GL1.2(32-bit original release)?  I never use the daily builds.
Title: Re: QB64x64 (12-22-2018)
Post by: SMcNeill on December 23, 2018, 10:19:38 am
Steve, thanks for the clarifications.  Would I be correct in assuming that I should now be using QB64x64 (12-22-2018) instead of GL1.2(32-bit original release)?  I never use the daily builds.

If you don’t need your program to run on 32-bit machines, I’d use the 64-bit compiler.  Generally, it’s the only compiler which I normally use for my personal needs.
Title: Re: QB64x64 (12-22-2018)
Post by: bplus on December 23, 2018, 11:02:14 am
Steve, again problems with download of 7z file. I think it originates with browser (Opera) and your link from here but Windows is showing very new kind of Dialog window I've never seen before, maybe buggy or maybe extraction isn't working correctly?

Was compressed in Bzip instead of lhza2 (whatever the 2 exact abbreviations are, I didn't bother to go recheck)...   Try this version: it’s zipped in the other format — https://www.dropbox.com/s/56a267uav7cub9d/QB64x64%20%2812-22-2018%29.7z?dl=1

Not an extraction problem:

Same problem again with this link and compression. So I tried MS Edge browser and again the file gets 100% downloaded but when I go to close browser, it is still checking with Antimalware. This time I let it run, and run, and run, kicking on fan and using 50% CPU. What seems like 15 minutes later, I can finally close the browser without a file still "downloading" message. This time the 7z file deleted normally after I extracted the contents. So I guess my problem was the massive amount of files that were still being checked before Windows was done with download.

OK onto checking old files and seeing how they do with new version.
Title: Re: QB64x64 (12-22-2018)
Post by: FellippeHeitor on December 23, 2018, 11:46:29 am
I never use the daily builds.

Steve's package is based on the dev build. You do now.
Title: Re: QB64x64 (12-22-2018)
Post by: Qwerkey on December 23, 2018, 12:05:20 pm
I never use the daily builds.

Steve's package is based on the dev build. You do now.

Yep!  I did assume that, on this occasion.  (If it ever has problems then I'd just revert to 1.200, but it's looking good).
Title: Re: QB64x64 (12-22-2018)
Post by: Bert22306 on December 23, 2018, 01:51:17 pm
Not an extraction problem:

Same problem again with this link and compression. So I tried MS Edge browser and again the file gets 100% downloaded but when I go to close browser, it is still checking with Antimalware. This time I let it run, and run, and run, kicking on fan and using 50% CPU. What seems like 15 minutes later, I can finally close the browser without a file still "downloading" message. This time the 7z file deleted normally after I extracted the contents. So I guess my problem was the massive amount of files that were still being checked before Windows was done with download.

OK onto checking old files and seeing how they do with new version.

Ditto. Assuming you are using Defender antivirus/antimalware, this long delay, for scanning after the download is complete, started happening maybe 2 months ago, or so (don't remember exactly). Before that, the 7zip file downloaded in no time.

When using an enterprise version of McAfee, instead, that super long delay is at the beginning of the download. Download speed is initially very slow, predicting 12+ hour download time, and then finally, after maybe 10 minutes, takes off and finishes in maybe a minute.

There's something in the qb64 7zip file that really gives the latest virus software a run for its money.
Title: Re: QB64x64 (12-22-2018)
Post by: xra7en on December 24, 2018, 05:54:46 am
I am getting random compile "flukes",  nothing consistent to duplicate the error.

EXAMPLE
Quote
D:/QBASIC 64/internal/c/c_compiler/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: reopening D:\QBASIC 64\projects\testprj\testprj.exe: Permission denied

D:/QBASIC 64/internal/c/c_compiler/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: final link failed: Permission denied
collect2.exe: error: ld returned 1 exit status

A first you would think there is an instance of testprj.exe already running, but not true.

Problem: random compile errors
Fix: reopen the file, saving before you do and re-run it. Works ever time.

more of a nuisance, as I do not loose any code during the process



Title: Re: QB64x64 (12-22-2018)
Post by: SMcNeill on December 24, 2018, 05:57:23 am
Try running as admin; that looks like a system permission problem.
Title: Re: QB64x64 (12-22-2018)
Post by: Cobalt on December 24, 2018, 12:31:43 pm
for some reason it blocked every file when I unzipped it, so even running Admin doesn't cut it. thought I had that turned off. need to find how to turn that back off, does it every so often, caught me off guard cause it hasn't been doing it when I download the builds from .ORG. if it wasn't that there is over 8k files to individually have to turn off it wouldn't be a problem.
Title: Re: QB64x64 (12-22-2018)
Post by: SMcNeill on December 24, 2018, 12:54:32 pm
for some reason it blocked every file when I unzipped it, so even running Admin doesn't cut it. thought I had that turned off. need to find how to turn that back off, does it every so often, caught me off guard cause it hasn't been doing it when I download the builds from .ORG. if it wasn't that there is over 8k files to individually have to turn off it wouldn't be a problem.

Antivirus blocked the whole 7z extraction?  What antivirus are you using?  I don’t think I’ve ever had TXT and config files ever blocked before.  Something seems really off, but it isn’t anything QB64 related, I don’t think.
Title: Re: QB64x64 (12-22-2018)
Post by: xra7en on December 24, 2018, 02:43:04 pm
Try running as admin; that looks like a system permission problem.

will try that next.. have not had an issue since this morning... I am always on admin mode - (not a fan of the standard user mode ) :-)
However will try the rt-click admin tip
Title: Re: QB64x64 (12-22-2018)
Post by: xra7en on December 24, 2018, 02:44:54 pm
for some reason it blocked every file when I unzipped it, so even running Admin doesn't cut it. thought I had that turned off. need to find how to turn that back off, does it every so often, caught me off guard cause it hasn't been doing it when I download the builds from .ORG. if it wasn't that there is over 8k files to individually have to turn off it wouldn't be a problem.

Antivirus blocked the whole 7z extraction?  What antivirus are you using?  I don’t think I’ve ever had TXT and config files ever blocked before.  Something seems really off, but it isn’t anything QB64 related, I don’t think.

If it helps for research (?), I don't use AV's, so any error I produce in post, is raw. Just not sure why that denied error is random. I compile ever time I test run.
Title: Re: QB64x64 (12-22-2018)
Post by: Cobalt on December 25, 2018, 01:22:40 am
for some reason it blocked every file when I unzipped it, so even running Admin doesn't cut it. thought I had that turned off. need to find how to turn that back off, does it every so often, caught me off guard cause it hasn't been doing it when I download the builds from .ORG. if it wasn't that there is over 8k files to individually have to turn off it wouldn't be a problem.

Antivirus blocked the whole 7z extraction?  What antivirus are you using?  I don’t think I’ve ever had TXT and config files ever blocked before.  Something seems really off, but it isn’t anything QB64 related, I don’t think.

no not AV blocked, windows blocked. when I goto properties on a file there is a little button that says UNBLOCK and some text beside it saying to the effect "windows has blocked this program because it didn't originate on this computer blah blah"
yeah not QB64 at fault here, its a vista thing I guess. had issues with it before but could have sworn I disabled it, must have been an update that re-enabled it.
Title: Re: QB64x64 (12-22-2018)
Post by: Qwerkey on December 26, 2018, 06:53:49 am
Steve, I've just done a comparison of an .exe file created with 32-bit and 64-bit QB64, and the 64-bit program uses about 3/5 of the CPU, as you said it should.  I have previously assumed that a 64-bit machine would run a 32-bit program with equal ease compared to a 64-bit program (just using less bits at any one time).  Oh, how litttle I know!
Title: Re: QB64x64 (12-22-2018)
Post by: Bert22306 on December 27, 2018, 02:31:04 pm
Given the downloading problems experienced by some, to download the 64-bit version (my work PC seems to block that dropbox URL completely), is there a reason why the Windows 64-bit version can't be made available in the same location as the 32-bit version? Is it a space issue?

Looks like Steve did some very useful upgrades, e.g. even going to the latest compiler, and debugging the problems that created, so maybe it's time to start migrating to the 64-bit version? I know some people still need the 32-bit version, but my sense is that most do not. And the speed differences seem to have become substantial, of late, at least with Intel CPUs. (My guess was, because of the BIOS fixes to mitigate Spectre and Meltdown vulnerabilities.)

Thanks!
Title: Re: QB64x64 (12-22-2018)
Post by: SMcNeill on December 27, 2018, 03:52:56 pm
Given the downloading problems experienced by some, to download the 64-bit version (my work PC seems to block that dropbox URL completely), is there a reason why the Windows 64-bit version can't be made available in the same location as the 32-bit version? Is it a space issue?

Looks like Steve did some very useful upgrades, e.g. even going to the latest compiler, and debugging the problems that created, so maybe it's time to start migrating to the 64-bit version? I know some people still need the 32-bit version, but my sense is that most do not. And the speed differences seem to have become substantial, of late, at least with Intel CPUs. (My guess was, because of the BIOS fixes to mitigate Spectre and Meltdown vulnerabilities.)

Thanks!

Personally, I’d like to see both packaged with QB64, with an Option in the Menu for “Compile 32-bit” and “Compile 64-bit”.  Check both, and you create both EXEs at once! 
Title: Re: QB64x64 (12-22-2018)
Post by: Bert22306 on December 27, 2018, 08:56:30 pm
Personally, I’d like to see both packaged with QB64, with an Option in the Menu for “Compile 32-bit” and “Compile 64-bit”.  Check both, and you create both EXEs at once!

Even better. Is it the extra work required to debug such a scheme, that causes the "powers that be" to hesitate?