PureBasic Forums - English

Once again it's that time of the year; time to share! Here is a link to my gift to you.

https://drive.google.com/file/d/0B2sTe1 ... sp=sharing

It's a pdf document that serves as a framework/reference to translate programs from PowerBasic to PureBasic.
Feel no fear in the process, it can be done successfully. Download the pdf and start from there.
With a warm Caribbean hug, from Puerto Rico; I wish you a very happy holidays to all!

Great , thx for writing and sharing.

I do not need this myself, since I've dropped PowerBasic many many years ago.

However, this is a great idea, and it is well done!
I think this is very useful

And many thanks for the warm Caribbean hug. That is something which everyone can certainly use.
Very happy holidays to you, too!

Hi again, Amilcar!

As we know, PowerBasic has some keywords and functions, which are not directly supported by PureBasic.
Maybe in a future version of your reference aid, you'd like to add some PureBasic code for working around those shortcomings.

For instance, in section 1.2.2 you mention that PureBasic's LTrim(), RTrim(), and Trim() do not support the ANY keyword.
Here is some fast running code that provides this functionality:
Just an idea.

Thank you Little John, your suggestion is welcomed. Also I appreciate your code example (is faster than my first try at it). The macro implementation is very nice and useful. The use of the constant #whitespace$ (as default value) sure ease the use of these procedures. Thank you very much!

Made sticky as it can help new comers from PowerBasic.

Here are a couple for you guys/gals coming from PowerBasic.

In PowerBasic, you could:

Mid$(PART1$, 4, 10) = PART2

In PureBasic, you can do the below. Note that specifying
a "0" (zero) in the fourth parameter will cause all of B$
that will fit into the remaining lengh of the string
pointed to by A to be utilized. This routine could be
reworked as a funcion but I suspect the below is faster
because of its use of pointers. This is for ASCII only.

Usage: INS(@PART1$, PART2$, 4, 10) In PowerBasic, you could:

A$ = "C:\SOMEDIR\SOMEFILE.*": If Dir$(A$) <> "" Then KILL A$

In PureBasic you can do the below.

Usage: A$ = "C:\SOMEDIR\SOMEFILE.*": DeleteMask(A$)

Here are a couple more routines which will turn your data streams
into random access files. they replace the GET and PUT commands
of PowerBasic. Note that PutS will always insure that the output
record is of the specified length even if the output string is not.
Also note that these routines are for ASCII.

Really interesting!
Great job and thanks for this great help!

PB forever!!

I have several versions of PowerBasic, but haven't used it in years. It went when I decided to leave Windows in favor of a Linux Distro. I picked Ubuntu, and still use it. I did try several other Linux distros, but what was the point, really? I mean it is just that much more to learn if you go with more than one.

What I hang on to is the PowerBasic conversion of Microsoft's SDK information files on how to call the various Window's APIs. Someone with PowerBasic did a real fine job on it, and even though the data structures and types aren't all the same as used in PureBasic. it's a great starting point to getting into the Win32 APIs.

It covers up through Windows 2000, which dates before Windows XP. Fundamentally, the APIs in Win2K are all shared with XP, but XP kept advancing and had more library modules added and existing ones expanded to provide more features to the OS and applications. Still, the lion's share of XP programs would also work on Windows 2000, they were that close.

It's becoming a different game now, as after XP, Microsoft introduced WinRT. which serves as the new base for all its higher level languages. But there has to be some compatibility there, as I've read that you can run legacy apps on Win7 and Win8 by having them emulate XP for that application. Thus, the Win32APIs are not quite dead yet. And wine, the emulator to Windows for use with Linux, uses XP as its target for what it does. But it's not perfect, and there are other choices.

One being to install a VM Manager and set up a client under it that is a reinstall of Windows XP, or some other version of Windows (or DOS, or a different operating system altogether). I personally use Oracle's Virtualbox as my VM Manager, and it is really great. I have Win2kPro, WinXP, and Win7 all set up as clients under it. Everything I install on a client just works, right out of the box. And no elaborate umbrella of protective software needed to shield it either, meaning as a client, Windows can perform better than it could do on its own.

Just giving others some idea of what can be done. What I really want to do is see if there is a way to share the Win32API folder and informational files with others. It use to be available for free from PowerBasic.com, but I guess they pulled it, because I can't find it there now. I don't think these forums let me upload the files here, because I don't see a way to do it. I do have a couple of sites where I can post it for others to download from, but let's see if there is any real interest first.

It may be that somebody already has something similar that they are willing to share, and it may be that it is already in PureBasic syntax, or it may be that it is inclusive of all the add-ons that XP brought into the game. Let's just see how it plays out in future posts first.

The other thing is, that the idea of static and dynamic link libraries, along with documented APIs for calling them, is a shared concept. It isn't just Windows that has them, but other operating systems as well. But as far as I know, Microsoft did the best job documenting theirs. I can't find any good sources for covering the Linux kernel APIs or possibly the MacOS APIs. These will all be different from each other as to what they are, where they are, what they are named, what they do, and so on. And you will also find that libraries can be added to a system, and those libraries have APIs, and they will all be documented separately.

But on the other side, some libraries are created to work with different operating systems, and even different hardware. These libraries have APIs that are enough like each other that you can write applications that can compile and run on each operating system separately. Graphics libraries and engines that are ported to different OSes have this in common. Printers and Scanners may work as well, if they hold to some standard. You see the PureBasic editor, which is much the same in every release of a compiler. PureBasic also supports the same statements and functions, so that the same source code can be used, although the compilers themselves produce different executable file formats.

The big thing is, what is common and uncommon between the different operating systems? File and folder naming conventions for one. How path statements are structured. How the file system is organized in terms of folder names and parent/child relationships. Whether folder and file names include spaces or have extensions. File details, like ownership, read/write status. date-times, and whether it is an executable or not. What internal file structure is used.

But you also run into system-level matters, like accessing USB devices, mounting and unmounting drives, dealing with a webcam, accessing the network, even just finding out the current setting for the screen resolution, putting up a console/terminal window, employing shell commands from within a program, setting a different font, size, or color for the Console/Terminal window, and so on.
It's all being done somewhere, but you need documented APIs to get access to any of it from within your own programs. Or it has to be built into the compiler and available as a statement or function. In other words, it is available as part of the programming language.

If a parent process with a GUI invokes a child process that creates a dialog and
then waits, when the dialog is ended (but not the child process), you are left
with a rectangular hole in the parent GUI. This is because the parent program
which is in a wait state cannot refresh its screen.

In PowerBasic, I used the Windows OpenProcess/GetExitCodeProcess/CloseHandle API's
to address this problem but in PureBasic you can do this:

Usage:

I know this is quite old, but I still think it would be a fascinating read. I never learned PowerBasic. FreeBasic and a few others, but never powerBasic. I'll be curious to see how different it was from PB. It was much more expensive after all...
Does anyone have a copy of this document? The link doesn't work, prompting me to request access.

Powerbasic was 32-bit only and very wordy. Not too bad but didn't check all my boxes like purebasic.
The powerbasic code inventory is a good resource for win32 app's.

Quin wrote: ↑Mon Nov 28, 2022 12:56 pm I know this is quite old, but I still think it would be a fascinating read. I never learned PowerBasic. FreeBasic and a few others, but never powerBasic. I'll be curious to see how different it was from PB. It was much more expensive after all...
Does anyone have a copy of this document? The link doesn't work, prompting me to request access.

I have access to it, dunno why you can't. I put a copy here so you can download it: https://www.purebasic.com/download/Powe ... eBasic.pdf . It's a good doc to migrate from PowerBasic to PureBasic.

Got it, thanks Fred!