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.
_________________ has-been wanna-be (You may not agree with what I say, but it will make you think).
|