Announcement

Collapse
No announcement yet.

Useful guidelines for new users of FREE PB 9 compiler

Collapse
This is a sticky topic.
X
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Useful guidelines for new users of FREE PB 9 compiler

    The new FREE versions of PowerBasic hopefully will encourage many more new programmers to get a taste for programming using PowerBasic. In this thread I will post some useful information about the compiler (PB 9), the benefits of it and how to get the most from it.

    Having been one of the longer existing Third Party Developers for PB addons (EZGUI) and being experienced with many of the deeper things of the WIN32 API, hopefully I have something beneficial to share.

    So where do I start ?


    First, let's consider why PB can be so powerful.

    Bob Zale, the creator of Powerbasic had a long history in compiler development. He was coding in assembler possibly longer than some young programmers have lived. Back in the "old days" when Bob started out, computers were very limited in power, so a compiler had to get every tiny bit of raw power out of the computer, unlike today where much of the software tends to be bloated and require too much resources.


    Powerbasic is quite unique in many ways. For example, the compiler is written in assembler. NO, not written in C and generating assembler, but actually written in assembler. I doubt anybody else does that today. This benefits the compiler it two ways. The generated code is lean and fast and the speed of compiling is lightning fast.

    In my case, when I compile EZGUI which is about 40,000 lines of code it compiles in just a couple seconds, which is almost instaneous. Compilers written in higher level languages, which may even generate secondary code (ie. BASIC to assembler) and then have to run a second backend compiler, tend ot be much slower in compile speeds. The faster your code compiles, the faster to can test it and get back to coding. It really makes a difference.

    In the programming language world, particularly independent developers, it is quite common for a programming lanuage to be dependent upon some backend open or free source compiler and thye programming language is more of a translator than a true compiler (direct to machine code). Purebasic, Freebasic, etc use someone elses backend. Some languages use a backend assembler or maybe an open source C compiler. Some use LLVM (which is a sort of low level language which compiles to machine code). Even the standard libraries of such languages often are open source libraries which already exist.

    Not so with Powerbasic. Powerbasic and its embeded library code were designed and developed by Powerbasic (the company) and mostly by Bob Zale himself.

    For example, PureBasic is impressive and one may wonder, why doesn't Powerbasic have a 3D engine in it ? Well, the Purebasic 3D engine is an open source library which was simply integrated into Purebasic. It was not developed by them. The 3D engine is OGRE from I have read. It is not easy to write a 3D engine from scratch. What is in Powerbasic, was developed by Bob zale and his company.

    What does this matter anyways ?

    Well, when you develop a compiler and integrate a number of open source libraries into it, one in essense if building a product which was developed by many different people with different ways of doing things. How one library could even another is not know. In the software industry, writing 100% bug free software is challenging and not easy. Now Powerbasic may not have some of the "bells and whistles" of other languages, but what it does have is very sound and reliable. It was all designed by Powerbasic. True, bugs may creep in, but hopefully a compiler like Powerbasic will be less riddled with bugs because of its design. For me that is important. I write programming libraries. That means my end users are programmers who are writing software for many other people, so quality and reliability are a must.


    Where PowerBasic may seem to be lacking can also be its strength. Powerbasic may not have all the "bells and whistles", but on the other hand it is very low level and one can use it to write almost anything high level one needs. I built an entire GUI framework using Powerbasic (and the WIN32) API. These forums provide some of the best resources around for working with the WIN32 API.


    Powerbasic also has the benefit of sticking closely to the long standard of BASIC. Unlike some BASIC programming languages which lean towards C like syntax or worse something quite foreign to BASIC, Powerbasic sticks to the long history of BASIC, particularly that started by Microsoft back in the QuickBasic days of DOS.

    So welcome to Powerbasic and please follow this thread as I add more tidbits about Powerbasic over the coming weeks.
    Chris Boss
    Computer Workshop
    Developer of "EZGUI"
    http://cwsof.com
    http://twitter.com/EZGUIProGuy

  • #2
    #DIM ALL


    If there is one strong recommendation for new users of Powerbasic it is, always use the #DIM ALL compiler directive. Why ?

    Old time BASIC allowed one to not have to predefine variables and one could simply just start using a new variable name in code and the compiler would figure it out. Sadly, while this made coding a bit easier and faster, it also was the cause of a lot of bugs in code. This compiler directive forces Powerbasic to require all variables to be predefined using either the GLOBAL, LOCAL or STATIC commands. In my experience #DIM ALL is a must use command. It may slow you down a bit at first, but it will make your code more reliable and prevent a lot of errors from sneeking in.

    Global Variables

    Now many of todays programmers have suggested that the use of Global variables is bad programming practice. I disagree. Global are very useful and can speed up programming and solve many problems. The key though is to make Globals more apparent in ones code so they don't cause problems with local variables (ie. name a global and local same name). What I like to do is add a prefix to my global variables so they stand out better. I like to use a prefixe like App_ in front of all Globals.

    ie.

    Code:
    GLOBAL App_MYLong AS LONG
    GLOBAL App_MYString AS STRING
    This really helps prevent confusion between Globals and locals and makes the Globals stand out in your code.

    The use of prefixes for variables names is a good practice for writing readable code. You can use what prefixes you like, but just use something. For example, when I have a variable which is a pointer, I like to make sure it stands out as a pointer and not a normal variable, so I like to use the prefix lp (small case) in front of all pointer variables, which is something the WIN32 docs do.

    ie.

    Code:
    LOCAL MyLong AS LONG
    LOCAL lpMyLong AS LONG PTR
    Variable name prefixes are very useful for writing clean, readable code.

    GOTO

    GOTO is often derided as a bad coding practice. While one should warn that GOTO can be problematic if used incorrectly (aka. forever loop) and one should be careful when using it, this does not mean it should never be used. I use GOTO. Not a lot, but I do use it at times when it makes sense. Along with GOTO is the old time BASIC command GOSUB. Now GOSUB, IMO is very useful and I use it a lot more often than I use GOTO. GOSUB is an excellent way to make code within a subroutine modular. In my EZGUI runtime code I use GOTO at least 13 times (plus ON ERROR GOTO a few times as well). Now in my EZGUI runtime I use GOSUB over 300 times. GOSUB is a tool which produces modular code. I significanly decreases the overall code size of an application.





    Chris Boss
    Computer Workshop
    Developer of "EZGUI"
    http://cwsof.com
    http://twitter.com/EZGUIProGuy

    Comment


    • #3
      SUB and FUNCTION

      The key to modular code is knowing when to move code to a subroutine or function. One of the most important additions to BASIC during its history was when it borrowed from Pascal the use of subroutines and functions. In short, use them. Modular code design is important for not only readable code, but is allows code reuse which significantly decreases app size. Don't follow the old time BASIC style of trying to write everything in the main routine or even just a few giant subroutines. Break your code up into smaller pieces. Now too small of a code block in subroutine can often be replaced with a GOSUB routine and that is much faster (no parameters to pass). But don't be afraid to write many subroutines or functions when it makes sense to do so. Try not to alllow code blocks to get huge. Even if code reuse is accomplished, breaking code up into more managable sized blocks (SUBs) makes it more readable and easier to debug. Now when code reuse is possible, then SUBs and FUNCTIONs make a huge difference. One key though when a procedure is called often is to keep the number of parameters down to a minimum. This speeds up code execution significantly. When a very large number of parameters need to be shared with a SUB or FUNCTION, you can keep parameters down to a minimum by passing a structure instead. When speed is critical passing parameters BYREF (ie. strings) can speed things up. The use of GLOBAL variables (which are shared) can also solve some problems.

      What ever technique you chose, the goal is to make your code as modular as possible. It really does make a difference.

      PBMAIN (or WinMain)

      So where does my program start ? Always in PBMain (or the WIN32 counterpart Winmain). Your app starts in PBMain and ends when PBMain ends. Same goes for WinMain. In Powerbasic, PBMain is simply a simpler way of defining the Winmain of an application. I is almost the same, except it does not get the parameters normally passed to WinMain (see API docs).


      DDT or SDK ?

      New users will notice there are two primary approaches to coding styles for Powerbasic. One is the use of the built in DDT (Dynamic Dialog Tools) command set for GUI stuff. The second is the SDK style which simply means using the WIN32 API alone and no DDT commands. I would suggest DDT at first, just to allow you to get up to speed. Then dabble in the SDK style. In the long run, learn both. SDK style coding will provide insights into DDT later on.

      There is a third way and that is to use a third party GUI framework instead. That is what my EZGUI is. It replaces the need for either DDT or the SDK. Only minority chose this route because it requires a commitment to learn the framework, but it can lead to more powerful apps if the framework provides features not easily accomplished in the other two styles.



      Chris Boss
      Computer Workshop
      Developer of "EZGUI"
      http://cwsof.com
      http://twitter.com/EZGUIProGuy

      Comment


      • #4
        What is the Windows SDK (software development kit) ?

        While many PB users can write an app without using the WIN32 API (or at least much of it), the real power in Windows programming comes from accessing the Windows API. In the dot.net world, programmers don't often deal with the WIN32 API, since dot.net is a framework on top of it. Actually when using dot.net (ie. C# or VB dot.net) when a programmer accesses the WIN32 API directly it is called unmanaged code (aka. not encouraged) and when one avoids using the API and only what the dot.net language provides it is called managed code (aka. prefered in the dot.net world).

        But for PowerBasic programmers, it is all about the WIN32 in one form or fashion. Powerbasic does a good job in providing many features so one need not call API's directly (ie. PB Graphic control, reasonable support for more commonly used controls, printing, etc.). But if you want to do more than just the basics, you will need to delve into the WIN32 API (plus other apis likes OpenGL, etc.).


        You can download the latest Windows SDK here: https://developer.microsoft.com/en-u...windows-10-sdk

        Be warned though, that using the latest SDK limits you to coding for the latest version of Windows if you accessing any API calls which only exist in the latest version of Windows. There is a way around this (using LoadLibrary and calling API's via a pointer using call dword) but it requires a little bit of experience first to make sure you know how to do it correctly.

        Now for PB 9 (free) users I would recommend downloading an earlier version of the Windows SDK, so you will make sure you are coding for multiple versions of Windows.

        You can download the Windows 7 SDK here: https://www.microsoft.com/en-us/down...s.aspx?id=3138

        Even if you stick to using only the DDT command set in Powerbasic, there will likely be many instances where what you need to accomplish can't be done using DDT alone, but will require accessing the Windows API directly.

        These forums are an excellent resource in learning about the Windows API and to ask questions about it. The PowerBasic forums is probably one of the most extensive and knowlegable forums for WIN32 programming, which is actually become a lost art today.

        To learn the basics of programming using the WIN32 API, one really is not going to accomplish that simply by reading these forums. I would strongly recommend getting a good book on the basics of WIN32 programming and read it cover to cover (that is how I learned).

        While may would recommend the Charles Petzold books, the following book IMO is an excellent one for learning the Windows API basics:

        "Windows 98 programming from the ground up!"
        By Herbert Schildt

        https://www.amazon.com/Windows-98-Pr...round+Up%21%22

        You can pick it up for only a few dollars (used) on Amazon.

        The Petzold books , be careful to only get an older one which does not deal with MFC (Microsoft Foundation Classes). Don't get the dot.net books.

        For more info about Petzold books: http://www.charlespetzold.com/books.html

        To learn about OpenGL (which is not a Windows API but a separate one) the book to get is the OpenGL SuperBible. There are multiple editions, so I would start with an earlier one which you can also get on amazon (used) for a few dollars:

        OpenGL SuperBible 4th edition: https://www.amazon.com/OpenGL-SuperB...+superbible%22

        Last edited by Chris Boss; 8 Dec 2016, 12:01 PM.
        Chris Boss
        Computer Workshop
        Developer of "EZGUI"
        http://cwsof.com
        http://twitter.com/EZGUIProGuy

        Comment


        • #5
          What is a GUI Framework ?

          To be frank, coding using the WIN32 API can be challenging. To say otherwise is not being totally honest. It took me years to get the basics down and even longer to learn more advanced stuff. Now you can learn a good bit of the basics in a few months, but IMO only if you commit yourself to reading a good book (like mentioned in previous post) from cover to cover and experiment with the code.

          The older WIN32 books are mostly written using C code, which is the easiest to port to Powerbasic IMO. Don't get caught up with later books which deal with MFC (Microsoft Foundation Classes) and C++. You will have a tough time with that. Coding the WIN32 API is more procedural in nature and not object oriented. C++ only adds to the complexity and is not a good place to start learning the API.

          So lesson #1: Avoid MFC books and code. Stick with old time C code using the pure WIN32 API

          So what is MFC anyway ?

          Well, again to be honest and frank, good old fashioned WIN32 coding using C (or Powerbasic today) was never easy. Microsoft obviously felt so, so they created two useful GUI frameworks to make life easier. One was MFC or Microsoft Foundation Classes ( https://en.wikipedia.org/wiki/Micros..._Class_Library ). Now notice a clue to the problem in the name. The word classes! yes, Microsoft went object oriented with their framework and MFC is class based. Not well suited to the needs of a Powerbasic programmer.

          They also added ATL which again is another class based library.

          Both MFC and ATL require making calls to those libraries. Fortunately all computer today come with those runtimes.

          Why a GUI framework in the first place ?

          Because WIN32 coding is more complex and slower. One has to deal with a lot more details. It is not impossible, just simply more work. Programmers want to get apps built quickly and not spend weeks just trying to figure out how to code something low level.

          Microsoft is not the only one to create a GUI framework for the WIN32. Borland created something called OWL ( https://en.wikipedia.org/wiki/Object_Windows_Library ).

          Microsofts eventual solution was to drop MFC in favor of dot.net. Today it is all about dot.net. But dot.net, while quite effective , is also a bit bloated and this explains why modern PC's still seem slow at times. The hardware has advanced gretaly, but the current software development techniques (aka. dot.net) require much greater resources and so one loses some of the benefit of the faster hardware.


          IMO the downfall of current development is OOP. Yes, there are some opinions from a minority of programmers that OOP has not actually brought us the benefits it once touted. If this is true, then procedural style programming (aka. like with PowerBasic and even most of the WIN32) should be able to produce smaller, faster apps. The "proof is in the pudding" as they say. Yes, PowerBasic apps are tiny (and possibly faster) in comparison to their dot.net counterparts.


          Having been a third party developer of PB addons for close to 20 years now, I haven't see much of an effort in the PB community for building GUI frameworks. There has been excellent progress in a number of third party visual designers (code generators), but a code generator is not a GUI framework. It simply is a RAD tool.

          This is why I built, probably the only, full fledges GUI framework for PowerBasic. EZGUI, a GUI framework, is not for everyone. Most PB'ers are happy with just DDT alone. Others more experienced with the WIN32 API have benefited greatly from the Visual Designer front ends some have greated. There is a small minority though which needed more, a GUI framework. The downside to a GUI framework is that you have to take the time to learn the framework and there is a runtime DLL. The upside is that if the framework is easier to work with than the WIN32 API and provides high level features, then it speeds up development significantly and helps programmers add more advanced features.


          I won't go much further into the benefits of EZGUI here, since I want to keep this thread more general in nature, but to see the difference a GUI framework can make it is best to see one in action. You can download a simple test app I created to demonstrate some of the features of my framework and to test them on Windows 8 (and now 10). Download and try the app and see what I mean.

          Windows 8 API test app: http://cwsof.com/download/testwin8.zip

          Now not quite a GUI framework, some PB addons are extensive libraries for advance features that most of us PB programmers might find very difficult to accomplish ourselves. There are a few such tools, but one I think needs to be highlighted:

          Patrice Terriers GDImage: http://zapsolution.com/DW/US/gdimage.html

          All I can say about it is that it is impressive. If you want advanced graphics then check it out.
          Last edited by Chris Boss; 8 Dec 2016, 12:02 PM.
          Chris Boss
          Computer Workshop
          Developer of "EZGUI"
          http://cwsof.com
          http://twitter.com/EZGUIProGuy

          Comment


          • #6
            How best to use the source code posted on forums!

            One lesson it is best to learn is this: Don't just copy and paste.

            Why ?

            For the extended reasons why I say this, read my article on Codeproject: https://www.codeproject.com/articles...mers-nightmare

            The better way is this:

            Copy (or download) source code examples from the forums simply for learning purposes. First compile the samples and see what they do. Make a copy of the original and then experiment a bit by changing the code in places to see the effects (make sure you know what you are doring first though).

            Now here is the next proper step.

            Make notes of the API calls the code uses. Then using the SDK docs (see previous posts) read in the API docs about each and every API used in the code. See how the API function works. Notice the different parameters and what they mean. Notice any warnings in the API docs about what should always be done or avoided when using the calls.

            Take the time to learn what the API's are and they are properly used.

            In the course of doing this, do not be surprised if you find bugs or errors in the posted source code. It happens often. Just because works, does not mean it has no bugs. One common bug when using the WIN32 API is what is called a "Resource Leak". Code amy work fine, even with a resource leak. It is what a resouce leak does over time which is the problem. A bad resource leak can even bring Windows itself crashing down. A resource leak in programming can be like a real leak in a house roof. It may be tolerated for awhile, but it eventually can cause serious harm.

            Also it should be noted that WIndows may tolerate errors in how some APIs are called, but this toleration may not be the same on different versions of Windows. Ever wonder why some apps written say for Windows XP and ran fine, come crashing down on later versions of Windows ? The reason is likely an error in calling some WIN32 API's. The older version of Windows may have tolerated the error so all seemed alright. But when the app is run say on Windows 7 or 8, that API may have been improved or fixed and it may no longer tolerate the error. The error now can cause the app to crash or even GPF.

            So don't underestimate the damage caused by seemingly small errors in WIN32 code.

            This is one reason "copy and paste" can do so much damage over the long haul. Many PB'ers who post code examples may be simply be in a hurry and just don't have the time to double check the code for errors. Simply use the posted code as a learning experience, but avoid using it for working code. Better to learn from the code and the API docs and then code it yourself from scratch. Takes longer, but you learn more and likely will have less problems with bad code.

            But you say, "I still can't code it myself after doing all this!"

            Don't view copy and paste as the easy solution. Take the time to learn what you need.
            Last edited by Chris Boss; 8 Dec 2016, 12:02 PM.
            Chris Boss
            Computer Workshop
            Developer of "EZGUI"
            http://cwsof.com
            http://twitter.com/EZGUIProGuy

            Comment


            • #7
              Any good books on programming in Powerbasic ?

              Not that I know of. But you may find good tutorials online here and there. These forums have a number of tutorials in them.

              Here are some tutorials I have written which are on CodeProject:

              Getting started with Powerbasic (part 1 and 2)

              https://www.codeproject.com/articles...-compiler-part

              https://www.codeproject.com/articles...c-compiler-par

              Some WIN32 topic articles of mine of CodeProject:

              https://www.codeproject.com/Articles...ing-PowerBASIC

              https://www.codeproject.com/Articles...ing-in-Windows

              https://www.codeproject.com/Articles...ing-Processing

              https://www.codeproject.com/Articles/90105/Subclassing

              Last edited by Chris Boss; 8 Dec 2016, 12:02 PM.
              Chris Boss
              Computer Workshop
              Developer of "EZGUI"
              http://cwsof.com
              http://twitter.com/EZGUIProGuy

              Comment


              • #8
                How to decide upon a development strategy ?

                Should I concentrate on using DDT with PB Forms, try one of the SDK style visual designers or consider a GUI framework like EZGUI ?

                A lot depends upon what kind of apps you are trying to develop. If your UI needs are minimal and the basic controls (plus a few common controls) are all you require, then definitely go the route of using DDT (Dynamic Dialog Tools) and PB Forms. Your app will have no runtimes, will be tiny in size and easy to maintain. Most utility style apps and many larger business style apps can be written using DDT.

                But DDT has limits and if your UI needs need to be greater, then consider an SDK style visual designer. In this case you get the raw power of Windows, but make sure you can handle coding many things using the Windows API. A code generation visual designer front end can only do so much for you. At some point you will need to code and some tasks may require a decent knowledge of the Windows API.

                A GUI framework, like EZGUI is the last choice. The downside, a GUI framework requires a certain commitment to learning the framework. Instead of learning the Windows API, you need to learn the GUI framework. In the case of EZGUI though, it is much easier to work with than the Windows API. A well written GUI framework though can provide features not easily accomplished using either of the other development methods. For example, EZGUI has a 2D Sprite engine (animated graphics) and a 3D scripting language (OpenGL based), which are not things easily accomplished yourself. The Windows API does not provide simple commands to accomplish such things.
                Chris Boss
                Computer Workshop
                Developer of "EZGUI"
                http://cwsof.com
                http://twitter.com/EZGUIProGuy

                Comment


                • #9
                  Chosing whether to use a specific Windows API call:

                  One may think, as long as an API is listed in the WIN32 docs, one should feel free to use it. Not so though and here is why. Always read the end part of the API explanation in the API docs. Microsoft will note what the minimum operating system is for the API and at times it may only exist in the most current version of Windows. So if an API only exists in say Windows 10 and you plan on your app being able to be run on Windows 7 and above, then you just can't go and use the API call. Your app will be tied to only the version of Windows which supports that API and if run on another version of Windows will give an error message and won't run.

                  There is a workaround which is to call the API dynamically (use LoadLibrary if needed and GetProcAddress to get the address of the API function and then call using CALL DWORD), but the problem here is if the API does not exist, what do you do then in replacement for it. You need an alternative for it (or simply turn off a feature in your app).

                  So be careful about which API's you use.

                  Second, make sure that even if an API exists that you have followed all directions about how to prepare to use the API. The API docs explain any preparation calls which may need to be called first (ie. get a handle for something first which is to be passed to the API call). Maybe something needs to be initialized first.

                  Lastly, make sure you fully understand how the API is used and what control classes or window types support the API. Window messages are one good example. A number of times on there forums I have seen new PB users try to use an API message (or process a notification message) which is only for one control class with another control class. Many API constants and message constants start with a prefix, which indicates it only works for specific window class. For example, button controls support unique window styles which start with the prefix %BS_. Don't use a style for button controls with another control type, like an edit control. Make sure you know what an API function, message or notification is used for and what window classes support it first.

                  Chris Boss
                  Computer Workshop
                  Developer of "EZGUI"
                  http://cwsof.com
                  http://twitter.com/EZGUIProGuy

                  Comment

                  Working...
                  X