PureBasic 6.00 released !

Developed or developing a new product in PureBasic? Tell the world about it.
User avatar
Shardik
Addict
Addict
Posts: 1989
Joined: Thu Apr 21, 2005 2:38 pm
Location: Germany

Re: PureBasic 6.00 Alpha 3 released !

Post by Shardik »

GPI wrote: Tue Jul 13, 2021 6:07 am as far as i know: Handles in PB are *ALWAYS* in Integer. so ".l" is not correct and when it work, it is pure luck.
No! According to Microsoft a 32-bit handle works in 32-bit and 64-bit applications:
Microsoft wrote:64-bit versions of Windows use 32-bit handles for interoperability. When sharing a handle between 32-bit and 64-bit applications, only the lower 32 bits are significant, so it is safe to truncate the handle (when passing it from 64-bit to 32-bit) or sign-extend the handle (when passing it from 32-bit to 64-bit). Handles that can be shared include handles to user objects such as windows (HWND), handles to GDI objects such as pens and brushes (HBRUSH and HPEN), and handles to named objects such as mutexes, semaphores, and file handles.
But you have to take care of special cases like "handles" which are 64-bit wrapped pointers and should not be truncated:
Microsoft wrote:Handles—Because kernel32 and user32 handles are only 32-bit significant in both 32-bit and 64-bit processes, they can be transferred between processes without a problem. However, some items that Windows defines as handles are really just wrapped pointers (for example, HTREEITEM). These "handles" will be truncated if they are passed from a 64-bit process to a 32-bit process.
User avatar
STARGÅTE
Addict
Addict
Posts: 2067
Joined: Thu Jan 10, 2008 1:30 pm
Location: Germany, Glienicke
Contact:

Re: PureBasic 6.00 Alpha 3 released !

Post by STARGÅTE »

DeanH wrote: Tue Jul 13, 2021 7:12 amMy point is that the size and range of the values returned by OpenWindow(#PB_Any and other functions are hugely different for the two 64-bit compiler versions.
I observed the same. It shows how significant it is to use integers in most of all cases instead of longs.
Probably in older PB versions also the 64 bit version uses something like a virtual memory address per process.
In PB 6.00 is now uses the "real" memory position which is most often above a size of a long due to the huge RAM of 8 GB to 64 GB of typical PC systems.
But this is just speculation, I'm not familiar with this topic. Perhaps Fred can answer this question.
PB 6.01 ― Win 10, 21H2 ― Ryzen 9 3900X, 32 GB ― NVIDIA GeForce RTX 3080 ― Vivaldi 6.0 ― www.unionbytes.de
Lizard - Script language for symbolic calculations and moreTypeface - Sprite-based font include/module
GPI
PureBasic Expert
PureBasic Expert
Posts: 1394
Joined: Fri Apr 25, 2003 6:41 pm

Re: PureBasic 6.00 Alpha 3 released !

Post by GPI »

which is ok, since it is not definied what kind of handles they return, it is only definied, that it return a "number" in Integer-range.

it is also possible, that you will have with the asm-backend strange bugs, because you used the wrong type, for example on large memory-usage it could use memory "above 4GB" and then your handles become invalid.

When your "librarys" use the wrong type, you must rework them or use others libraries.
GPI
PureBasic Expert
PureBasic Expert
Posts: 1394
Joined: Fri Apr 25, 2003 6:41 pm

Re: PureBasic 6.00 Alpha 3 released !

Post by GPI »

Shardik wrote: Tue Jul 13, 2021 10:29 am No! According to Microsoft a 32-bit handle works in 32-bit and 64-bit applications:
Your mistake is, that this is only valid for WIN32-API-Handles. BUT we talk about PureBasic-Handles! Handles in Purebasic are more like an ID. And this ID can be 64BIt on a 64-bit System.

OpenWindow for example doesn't return a windows-API-Handle, when you need this, you must use WindowID()
Axolotl
Enthusiast
Enthusiast
Posts: 435
Joined: Wed Dec 31, 2008 3:36 pm

Re: PureBasic 6.00 Alpha 3 released !

Post by Axolotl »

GPI wrote:
OpenWindow for example doesn't return a windows-API-Handle, when you need this, you must use WindowID()

I cannot confirm this statement. It is the same value if you use a valid constant as #Window. if you use #PB_Any than you have to use WindowID()
From my point of view it is like this.

Code: Select all

Define hwnd 
  hwnd = OpenWindow(0, 0, 0, 230, 90, "Event handling example...", #PB_Window_SystemMenu | #PB_Window_ScreenCentered)
Debug "hwnd = " + hwnd + " == WindowID = " + WindowID(0) 

One exception where integer is not the right choice under a 64 bit windows system is the following:
The direct return values of GetSystemMetrics_() are wrong when negative X, Y coordinates are used because of the monitor situation. :oops:

Code: Select all

Procedure.l VirtualScreenX() ;' returns .l x position of the screen (entire screen) 
  ProcedureReturn GetSystemMetrics_(#SM_XVIRTUALSCREEN)
EndProcedure ;() 
Procedure.l VirtualScreenY() ;' returns .l y position of the screen (entire screen) 
  ProcedureReturn GetSystemMetrics_(#SM_YVIRTUALSCREEN)
EndProcedure ;() 
Procedure.l VirtualScreenWidth() ;' returns .l width of the screen (entire screen) 
  ProcedureReturn GetSystemMetrics_(#SM_CXVIRTUALSCREEN) 
EndProcedure ;() 
Procedure.l VirtualScreenHeight() ;' returns .l height of the screen (entire screen) 
  ProcedureReturn GetSystemMetrics_(#SM_CYVIRTUALSCREEN) 
EndProcedure ;() 
Mostly running PureBasic <latest stable version and current alpha/beta> (x64) on Windows 11 Home
GPI
PureBasic Expert
PureBasic Expert
Posts: 1394
Joined: Fri Apr 25, 2003 6:41 pm

Re: PureBasic 6.00 Alpha 3 released !

Post by GPI »

Code: Select all

Define hwnd 
  hwnd = OpenWindow(0, 0, 0, 230, 90, "Event handling example...", #PB_Window_SystemMenu | #PB_Window_ScreenCentered)
Debug "hwnd = " + hwnd + " == WindowID = " + WindowID(0) 
This is a really bad code.

https://www.purebasic.com/documentation ... indow.html
Return value
Nonzero if the window was successfully created, zero otherwise. If #PB_Any was used for the #Window parameter then the generated number is returned on success.
OpenWindow does NOT return the window-api-Handle! You can only check if it was a success (<>0) or a fail (=0).
Maybe it returns simple the handle, but it can changed anytime with every update. When you need the WIndow-API-Handle, ALWAYS use WindowID()!

Only because something works, it does not mean that it is good code or it should be done this way.

GetSystemMetrics_() is by the way a win32-API-Call, not a Pure-Basic call and it does not return a handle.
https://docs.microsoft.com/en-us/window ... temmetrics
the function return a c int-value. a Int in C (on Windows-PCs) are always 32 Bit = Long in Purebasic.
Armoured
Enthusiast
Enthusiast
Posts: 346
Joined: Mon Jan 26, 2004 11:39 am
Location: ITALY
Contact:

Re: PureBasic 6.00 Alpha 3 released !

Post by Armoured »

I know that this is the question that should never be asked but approximately when will Purebasic 6 be released?
Thanks
nsstudios
Enthusiast
Enthusiast
Posts: 274
Joined: Wed Aug 28, 2019 1:01 pm
Location: Serbia
Contact:

Re: PureBasic 6.00 Alpha 3 released !

Post by nsstudios »

Awesome! I absolutely love the optimizations and the inline C possibilities! :)
One thing, though: when trying to output the commented c code with /OPTIMIZER flag, it doesn't seem to be any different than without it?
Executable size is larger and smaller based on if optimization is turned on, but the commented code output doesn't seem to use optimization?
Here's how I do it (from the pb tool):
C:\PureBasicAlpha\Compilers\pbcompilerC.exe /EXE %TEMPFILE /COMMENTED /OPTIMIZER %TEMPFILE
Thanks Fred and the team so very much!
cas
Enthusiast
Enthusiast
Posts: 597
Joined: Mon Nov 03, 2008 9:56 pm

Re: PureBasic 6.00 Alpha 3 released !

Post by cas »

Optimization is not for source code but for a compiled binary file. It is just a gcc flag (/Ox). PureBasic just translates pb code to c code and then gcc does optimizations.
User avatar
skywalk
Addict
Addict
Posts: 3972
Joined: Wed Dec 23, 2009 10:14 pm
Location: Boston, MA

Re: PureBasic 6.00 Alpha 3 released !

Post by skywalk »

What granularity is available for the optimizer switches?
The nice thing about standards is there are so many to choose from. ~ Andrew Tanenbaum
cas
Enthusiast
Enthusiast
Posts: 597
Joined: Mon Nov 03, 2008 9:56 pm

Re: PureBasic 6.00 Alpha 3 released !

Post by cas »

https://gcc.gnu.org/onlinedocs/gcc/Opti ... tions.html
Looks like purebasic passes -O2 parameter to gcc when you enable optimizations (i see -O0 and -O2 strings inside pbcompilerc.exe).
User avatar
skywalk
Addict
Addict
Posts: 3972
Joined: Wed Dec 23, 2009 10:14 pm
Location: Boston, MA

Re: PureBasic 6.00 Alpha 3 released !

Post by skywalk »

Thanks, can we set the other switches somehow in a command line compile?
The nice thing about standards is there are so many to choose from. ~ Andrew Tanenbaum
User avatar
marcoagpinto
Addict
Addict
Posts: 939
Joined: Sun Mar 10, 2013 3:01 pm
Location: Portugal
Contact:

Re: PureBasic 6.00 Alpha 3 released !

Post by marcoagpinto »

These optimisation parameters, could a way to activate them all be implemented?

Alpha 3 almost doubles the speed of my PhD app, maybe if I could turn on all parameters for GCC it could gain even more speed?

Thanks!
User avatar
DeanH
Enthusiast
Enthusiast
Posts: 223
Joined: Wed May 07, 2008 4:57 am
Location: Adelaide, South Australia
Contact:

Re: PureBasic 6.00 Alpha 3 released !

Post by DeanH »

I have done a bit more investigation with regard to the value returned by OpenWindow(#PB_Any

Values returned by the asm and C-backend compilers are very different in size. Here is a small test program:

Code: Select all

w.i=OpenWindow(#PB_Any,#PB_Ignore,#PB_Ignore,640,480,"Test",#PB_Window_SystemMenu | #PB_Window_ScreenCentered)
Debug w
Debug WindowID(w)
Repeat
Until WaitWindowEvent()=#PB_Event_CloseWindow
If I run this in PB 5.73, 64-bit I get values like:
36780352
5180402

If I run it in PB6.00 alpha 3 using the C backend compiler:
4536640
4197196

When I run the same program in PB6.00 alpha3 using the asm compiler:
2665121528128
3606486

The first value appears to be an identification number generated by PB. It is not the handle.
The second value is the actual handle.

The problem is the huge difference in the values between the asm and C-backend compilers and the previous versions of PB which use ASM. I can compensate the integer type in my own code but I am also using code libraries developed by others here on the forum.

This change (?) could affect other libraries and software graciously offered on this forum. In particular PurePDF. I have not been able to get this to work in PB6. It compiles but run-time memory errors are generated when trying to produce a pdf. This happens for both the asm and c compilers. I'm not bright enough to work out the solution. Works perfectly in PB5.73 and earlier. I am sure others on the forum use this excellent library. Maybe someone else here could solve it?
User avatar
HeX0R
Addict
Addict
Posts: 980
Joined: Mon Sep 20, 2004 7:12 am
Location: Hell

Re: PureBasic 6.00 Alpha 3 released !

Post by HeX0R »

GPI wrote: Tue Jul 13, 2021 8:10 pm

Code: Select all

Define hwnd 
  hwnd = OpenWindow(0, 0, 0, 230, 90, "Event handling example...", #PB_Window_SystemMenu | #PB_Window_ScreenCentered)
Debug "hwnd = " + hwnd + " == WindowID = " + WindowID(0) 
This is a really bad code.

https://www.purebasic.com/documentation ... indow.html
Return value
Nonzero if the window was successfully created, zero otherwise. If #PB_Any was used for the #Window parameter then the generated number is returned on success.
OpenWindow does NOT return the window-api-Handle! You can only check if it was a success (<>0) or a fail (=0).
Maybe it returns simple the handle, but it can changed anytime with every update. When you need the WIndow-API-Handle, ALWAYS use WindowID()!

Only because something works, it does not mean that it is good code or it should be done this way.
First of all, this is no "really bad code".
This is how OpenWindow() worked since ... the beginning(?), it returned the OS handle.
You are right, that wasn't mentioned anwhere, so the team could decide to change that.
But from my point of view that would be a bad idea, you never should change things that worked since decades without a good reason.
Many people used that, and due to the fact it is an OS handle, it might lead to difficult to track down phenomenons.

@DeanH:
I think the main problem is, you are using a quite outdated library.
You can't blame PB for a custom library which might have been created at a time, where there were no integers!
Why not switch to pbPDF, here you also get the source, which is much more future proof.

Most of us stopped using third party libraries, because you always run against a wall with them in future.
Post Reply