PowerBasic or Visual Basic?

[José Roca]

 
It's easy. The problem is that you can't use many of the .NET classes directly and you have to write wrapper assemblies.

[Edwin Knoppert]

That's not a big deal to me, i write those in visual studio and include (link) them in the PB code.
At the end we'll drop PB completely, it's just a transition phase.
MS C++ is the most powerful toy here since it allows the mix, never seen actual code but i know it allows mixing .NET with its own code.

[Chris Boss]

Powerbasic has grown over the years and in recent years I believe Third Party developers have made a big difference.

First, Powerbasic has seen many useful features in third party tools and then implimented similiar (albeit in their own way) features in the PB compiler.

Third party developers created visual design tools before PB did, but they jumped on the bandwagon and added DDT and even a Graphic control.

The PB language gets richer and richer in each new version and the third party developers just have to stay one step ahead of PB to keep their own tools relevant.

The key to using Powerbasic is taking advantage of reusable code, whether they be third party tools or your own library code. The key to fast development is code reusability.

Personally I prefer DLL's over COM components.

What I really like about PB is how reliable the compiler is. It generates fast executing apps and I don't have to worry about serious bugs in the compiler to mess things up.

I also like PB because it has a lot of low level stuff. I am using things like pointers all the time, to write mission critical code.

PB's string processing command set are by far the most powerful you will find in any language. I doubt there are any other compilers that come close to the power of Powerbasic when it comes to string processing.

BASIC itself as a language is far more readable than other languages IMO (makes code maintainance easier) and PB follows the Microsoft Basic language syntax which has been around a long time. I also feel that procedural coding is faster and better than Obect oriented coding, yet PB supports OOP for those who want it.

Microsoft languages have become bloated, IMO. As hardware improves, MS compilers get more bloated, so one tends to lose the benefits of the newer hardware.
PB is "lean and mean" so one really benefits from improved hardware.

[Edwin Knoppert]

>and the third party developers just have to stay one step ahead of PB to keep their own tools relevant.
To make sure we understand each other, many of these light-weight compilers (freebasic, bcx, PowerBASIC and PureBasic) implement features which are not finished or do not work as desired.
While DDT offers a pretty normal windowprocedure the rest of it is simply so-so from a technical point of view.
Unf. many many users like an easy route, this is in this case the PB helpfile presenting all the features and limits and seems enough for those people.
It's hard to explain why i find it just another poor implementation to the majority of the users.
I really don't care if PB brought us a supurb Visual Studio lookalike, i would have stopped right away if that was the case, i would not have mind it at all(!)

Other compilers offer similar or even worse implementations, it's then still expected by users to follow the native features and not some home-brewed feature.
PwrDev offers support for DDT and SDK but to make things work the same some code had to be adjusted towards DDT.

Therefore i say, just bring a bare bones compiler so end users using a third party tool don't have a choice.
If you purchase a designer (like PwrDev) a user should not have to make a choice, just bring him a single but good form engine.
Therefore all third party tools will at some point fail (and not because some native feature was that great, it wasn't).

The above is just an illusion, there is no money to earn if you bring out a bare bones compiler and forget about it.
It is most likely a poor market and you'll need to bring new features.
Problem is that for most of these tools you can not bring them as they are in their current state, you'll need a great IDE and debugger nowadays.
Better include support, static linking, ActiveX support, classes and so on.

Iow there is a moment a compiler simply has to many features or has to little features to become a real competitor for existing programming languages (like MS VS).

I truly like the current classes implementation but then, many things come so late..

[Frederick J. Harris]

Well, I guess its nice there is such a large assortment of programming languages and development languages out there for us folks to choose from!  

Your negativism Edwin made me wonder why I like PowerBASIC as much as I do.  And as an aside, I always seem to see folks screeming for static linking.  I can't imagine why that is thought to be such an advantage.  Obj files aren't even portable.

I've worked for years with fancy development environments.  Right now I have Visual Studio 2008 Professional, Visual Studio 2003 Enterprise Archetect, Visual Studio 6 Enterprise Edition, as well as lots of other fancy and modern development tools.  I use them frequently for my C, C++, and Visual Basic work in desktop Windows and Windows CE.  They have their good points and bad points (The latest Visual Studio is a resource hog and always wants to be connecting to the Mother Ship).  But in the end app development comes down to writting lines of code in a text editor, and for that a decent coder could even get by with Notepad.  So for me its the basics that really count.  For example the point Chris Boss made about string handling.  That is not a minor thing.  In fact, I consider strings to be one of the major hinderances in any of the C family languages.  Of course, the situation in C is simply disasterous.  C++ String classes have helped tremendously in that regard.  However, I wouldn't say they match PowerBASIC.  Its simply easier to have string handling built right into the programming language as opposed to adding it in through string class includes.  At least that's my opinion.

I also can't help thinking that the type of development one works on mostly might have some effect on what one thinks to be the best choice.  I don't do anything with internet programming, web pages, html, or anything like that.  I do a lot of database work and number crunching.  Also, like I said, high performance data entry screens for data recorder applications.  The console compiler is a real workhorse for me.  For my GUIs I don't need 'skins', OpenGL whatever that is (I've no idea!), fancy buttons (the regular, ordinary, standard ones that come at no extra cost are fine with me), or anything like that.  However, my code has to work.

Another possible take on the issue for me is I don't care anymore for 'throw away' type knowledge.  By 'throw away' knowledge I mean that which I had to do with Visual Basic 4 through 6 when Microsoft abandoned it.  All that knowledge was tied to the workings of an ide and a particular programming paradigm that has been abandoned.  And I'm not sure jumping on the .NET bandwagon is a great idea right now.

In 1981 Microsoft gave us DOS and BASIC.  In 1991 they killed DOS, deprecated BASIC, and gave us Visual Basic, in 2001 they deprecated Visual Basic and gave us .NET.  What do you think is going to happen to .NET in 2011?  Its just about had its 10 years, you know.  So if it takes a year and a half to totally master it as Edwin said if one would start now one could possibly be an expert at it when Microsoft finally deprecates IT.  I don't know and don't follow Microsoft's machinations very close, but I'd rather stick to more fundamental programming techniques that have a longer shelf life than what I've got from Microsoft's technologies and IDEs.  When I was younger struggling to learn difficult things then throwing away that knowledge came easier than now.  I'm 57 and have to be careful what I sink my time into.

[Edwin Knoppert]

Static linking makes it possible to avoid code to be debugged, when precompiled it doesn't need to be compiled again.
It's not really a matter of selling objects however, it is possible.

>our negativism Edwin made me wonder why I like PowerBASIC as much as I do.
You are right, since a year i am much more negative but somewhat unrealistic, can't handle certain behaviour anymore.
It must be me getting grumpy, i have to understand that while i may have a point i am the one being negative.
I guess i need to move on and leave the programming scene, my interest has changed and may be the reason abandoning PB as well (slowly though ).

>The latest Visual Studio is a resource hog and always wants to be connecting to the Mother Ship
Yes, all versions are, you'll need a good computer with ram to not get to frustrated
ASP.NET with over 10 pages is getting frustrating already.
Though the outcome is rather good but sometimes to slow as i mentioned before if not executed on a good server.
I believe winforms (an ordinary win32/64 executable) will work just fine.
.NET is not slow internally with it's objects, some MSIL overhead makes things slow.

>What do you think is going to happen to .NET in 2011?
I don't think so, this is currently a platform versus a VB run-time library situation.
Anyone can create code and compile it and does not need MS VS.
.NET appears very stable to me and is very large.
I even believe web will change towards 'WPF via browser' (a reliable binary which is supported by the browser and runs in a sandbox and is not html based).

>So if it takes a year and a half to totally master it
I am not a master, after that period i was lucky to get some colleagues to help me even more but after the first period i understood the more commonly used mechanisms.
Frankly, it's fun i understand the workings of ASP.NET on some parts better than my colleagues, they often ask me to work out a mix between javascript and ASP.NET/html code for example while i really dislike the html part of it (just funny)
I always have a technical interest for things, therefore...

>I'm 57 and have to be careful what I sink my time into.
Gee, i am 45 and had two burn-outs and thinking each day when to quit this programming job.
I like what i do but i need to see different things, it's hard to make a switch, especially when the pay is serving me well.
57 and 'worrying' about a language, i would not i guess when i am 57.
If i only knew what to do when i quit my job...

[Chris Boss]

Personally I think Powerbasic is one of the best compilers around.

There are two types of programmers IMO.

(1) Those who want to work at a low level and have a compiler which allows them to push their apps to the limits.
This requires one be an experienced API programmer though, but once you become experienced with the Windows API
there isn't much you can't do.

(2) Those who need as high level a programming tool as possible, so they can develop apps as quickly as possible.
While PowerBasic isn't that high level, especially its IDE, I think the current support by Third Party developers fills that void.
For those who prefer 100% code and a more SDK style of coding, FireFly is probably the best tool around. There are also some
other Visual tools that satisfy other PB users.

EZGUI tends to go against the common PB users concept of how to write PB apps, so it serves a smaller market, but for those who use it,
it pushed the limits of Windows development with some very high level (and low level too) features. For those users the combination of PB and
EZGUI is a powerful combination, but it would never have been possible without the PB compiler. EZGUI was written in PowerBasic 6.1.

You can't please everyone, so no one addon tool will solve everyones needs, but the more different addons to PB there is, the more choices there are
and PB gets more powerful.

The next generation of PB addons will offer even more possibilities. For example, EZGUI 5.0 is in development and one of the most exciting features is
an OpenGL Canvas control. I could never have written it with anything other than PowerBasic (at least not as well).

There are a number of aspects of Powerbasic which I find critical to quality software.

(1) Small executable size and fast execution speed.
Few languages can compared to PB in this area.

(2) PB is not only BASIC, but it has the perfect BASIC syntax, based on the core Microsoft Basic compilers from long ago.
When other languages treated things like GOTO or GOSUB obsolete, PB maintained such long time constructs.
PB concentrates on being a Procedural language, even though it has added OOP, one can still write a 100% procedural app.
BASIC is IMO, the most readable programming language there is. I have dabbled with other languages like Pascal, Fortan, C, LOGO, but I have never
gotten very far, because the language syntax never appealed to me. I would rather work with assembler, than have to learn a second language like C.

I strongly believe that it is better to work with just one language primarily, rather than work with multiple languages at one time (ie. Basic, C). IMO it is better
to learn just one high level language well and one low level language to support it, such as assembler.

(3) PB is sound as a rock (reliable)! One would be amazed at how shaky many compilers are. Some have criticized Powerbasic because they don't provide updates
on a regular basis, like say every few weeks. Want to know why ? IMO, its because unlike other compilers, PB is rock solid and there is not reason to update all the time.
Some compilers update every few weeks (ie. some of the less professional BASIC want to be's on the web) because they are fixing lots of bugs. Not so with Powerbasic.
I have a lot of confidence in the PB compiler.

(4) PB is likely the richest Basic language as far as command set, especially when it comes to things like strings.
Things like Code pointers, data pointers, register variables, variety of data types (ie. quads), While so called "moderns"
call commands like GOTO and GOSUB obsolete, I find commands like GOTO, GOSUB, ON GOSUB critical tools in my software
development. Anyone who has worked with assembler will appreciate how important such commands are.
Visual Basic always left me wanting. I liked the high level aspect of VB, but when I wanted to optimize something or do
something lowlevel, VB always left me wanting.

(5) COM is not the panacea of code reusability.
While COM has some nice aspects to it, it has failed IMO in its ultimate goal of the perfect method of code reusability.
The Windows registry is glutted with COM component registries, which may be one reason Windows slows to a snails pace after
a few years. The installation of apps with COM components is a pain. DLL's are just copy and run, but COM components can have a real down
side. Just compare the Windows API docs when it discusses API functions (DLL's) compared to the parts that discuss COM components in the
operating system. Without a Visual development environment which is atuned to COM components, a procedural coder is totally lost.
COM tends to add more code IMO, rather than decrease it. COM adds overhead, which slows it down a little.
This is one reason I chose OpenGL over DirectX. At least OpenGL is an API, rather than a bunch of COM classes.

If so called code reusability methods, like COM, are so great, why then does each new generation of compilers produce bigger and bigger (and more bloated)
executables ? Why are the latest runtimes, like dot.net, so huge ?

Even compilers like C++, have all sorts of runtimes with them supposedly to make programming easier.

Often the advances in new hardware (ie. faster CPUs) are lost because newer programming languages require faster CPUs and more memory.

Why was Vista such a big failure ? It was so slow (a memory hog) compared even with its own predecessor (Windows XP).

While PowerBasic may have a learning curve, it is well worth the investment of time to get the most out of it.

Rather than looking for more ways to make everything more Visual (meaning the programmer doesn't have to do anything anymore), it would be better
to start teaching programmers how to write real code.

How many programmers today could write a large and complex app by just hand coding without the benefit of a Visual Designer ?

Probably very few.

I am impressed when I see some of my own customers using EZGUI's runtime alone without its Visual Designer to write large and complex
applications. No drag and drop. Just hand coding the entire app. Take the visual designer away and see whats left of the programmer ?

Visual basic users (in the old days) were programmers, but with each new generation of VB, the dependency on Visual Design and drag
and drop components became the mainstay, to the point where anyone who could drag and drop a component felt they could program.

PowerBasic, puts the "programming, back into programming"!

[José Roca]

 

There are two types of programmers IMO.

(1) Those who want to work at a low level and have a compiler which allows them to push their apps to the limits.
This requires one be an experienced API programmer though, but once you become experienced with the Windows API
there isn't much you can't do.

I'm one of these. I don't need/like fancy IDEs, debuggers, intellisense, etc. I just need a decent editor.

(2) Those who need as high level a programming tool as possible, so they can develop apps as quickly as possible.

And instead of programmers, they become tool users, unable to write an application without them.

(5) COM is not the panacea of code reusability.
While COM has some nice aspects to it, it has failed IMO in its ultimate goal of the perfect method of code reusability.
The Windows registry is glutted with COM component registries, which may be one reason Windows slows to a snails pace after
a few years. The installation of apps with COM components is a pain. DLL's are just copy and run, but COM components can have a real down
side. Just compare the Windows API docs when it discusses API functions (DLL's) compared to the parts that discuss COM components in the
operating system.

You're still looking COM from a VB perspective. Low-level COM servers are as fast and lightweight as non COM DLLs. With a compiler like PB, that supports direct interface calls, you don't need to bloat the server with type libraries and property dialogs, you don't need to register it, and you can just copy it in your application folder, like any other DLL. A low-level COM server IS a standard dll, and it is loaded with LoadLibrary.

Just compare the Windows API docs when it discusses API functions (DLL's) compared to the parts that discuss COM components in the operating system.

Yes, do it. But choose the right documentation: the one that discusses the methods for C++ programmers, not the documentation for Visual Basic programmers. You will notice that there is not much difference from the ones that discuss procedural APIs.

Without a Visual development environment which is atuned to COM components, a procedural coder is totally lost.

No. Only those that intend to use COM without first learning COM programming are lost. I'm a procedural programmer and I don't have any problem to use COM without any visual designer.

COM tends to add more code IMO, rather than decrease it. COM adds overhead, which slows it down a little.

Again looking it from a VB perspective. Low-level COM servers don't have overhead, bloat or speed penalties. Forget for a moment all your previous experience with VB and all that Automation crap.

About two thirds of the Windows APIs are implemented as low-level COM servers.

COM classes nicely allow you to encapsulate code and data.

[Eros Olmi]

Some months ago I went into a famous library here in Milan (Italy) searching for some good books on low COM.
I was not able to find one even if that library has one complete floor (many squares meters) dedicated to Informatics.

So I asked to the desk about one or more COM books and I got this reply: "COM mmmm   ah aaaah ok: No. I'm sorry it is an old technology and we do not have anymore books on that"
I replied: "COM is an old technology???, Can you realize that at least half of the world is driven by COM technology in one way or the other? And this is not going to change other that increasing?"

Well, they looked at me like a was craxy and passed over to the next customer.
I went into another direction and ordered some Don Box books in Amazon.

[Frederick J. Harris]

A book on COM I like a lot Eros is "Inside Distributed COM" by Guy Eddon and Henry Eddon.  I think they are father and son.  Its really mostly a COM book in spite of its name.  It actually shows how to code the writing of type libraries and unusual stuff like that I havn't seen in other COM books.  Also good material in it on Connection Points; in fact right now I'm working on another one of my tutorials about connection points where I convert my custom control example I have posted here in Jose's forum into a visual COM control which implements the connection point interfaces.

There was about a ten year period of time from about the mid eighties to the mid nineties where I wasn't doing any programming at all.  Where I had left off was with QuickBasic 4.5 I think, then I got back into programming again real heavy in the mid nineties with VB 4, 5, and 6.  I just couldn't believe what had transpired in those ten years in the computer world!  Visual Basic really intimidated me at the time because I had to learn both Windows and Visual Basic itself.  It really didn't seem like programming even.  It seemed more like learning how to use an application rather than writting one.  One refreshing thing I've discovered in my forays into the Linux world is that programmers there still use C a lot and are mostly coders.

PowerBASIC seems to fill a gap or vacuum.  Programming right now seems to be dominated by big RAD application frameworks that create monsterous applications.  Naturally they have heavy dependencies on supporting binaries of various types.  The situation with C++ is something I know about because I use that language a lot.  As much as I love PowerBASIC, I have to admit that C++ seems to have a small edge on PowerBASIC both in speed and executable program size; however, they are real close, the difference in most cases isn't terribly big in my opinion.  However, when C++ programmers go to write applications they almost inevitably saddle themselves with so many binary dependencies (Windows Class Library Frameworks mostly, but also others) that they end up with bloatware products.  Kind of like using a Corvette Stingray to pull a trailer.  And most of the young kids learning C++ are brainwashed to the effect that procedural programming is bad and OOP is the only thing that is good. 

So when I discovered PowerBASIC in the late nineties it kind of represented a bringing together of my mid eighties programming world with the realities of modern Windows programming - a continuity, so to speak, that was lost to me due to the shock of Visual Basic.  Its a funny thing about Visual Basic; while I was using it (and I used it heavy for many years) I really had no idea what COM was.  Everything about Visual BASIC was COM - through and through, from the COM Control Container, which is essentially what the IDE was, to all the controls its users drag and drop on its forms.  Truth be told it was a tremendous and awesome achievement and testament to the power of the COM paradigm which formed its basis.  I never really learned anything about COM until I came into the PowerBASIC fold.  Now I'm glad I have the oportunity to learn and use it.  Its no longer 'magic' to me; but rather something I can learn and comprehend.  But like Chris said, if you fall in his second camp, i.e., those only interested in quick results, then the Visual Basic or other class framework approach is the one to take.

You know though, even if you fall in that second catagory Chris described, i.e., only interested in quick and dirty results, PowerBASIC still has the much maligned (at least by some here) DDT framework.  And if that is used you still won't end up with multi-megabyte sized executables.  It only adds a scanty few K to what an SDK coder would produce.  I don't use it myself, but newcommers find it a good starting point.  In fact, if it wasn't for DDT, PowerBASIC might not have been as successful as they have been.  It seems that a really significant number of new users come from the old DOS Basic background, and find it a good place to start if wanting to get into programming again.  I imagine for every new user that is an experienced or professional programmer coming from some language like assembler, VB, C, C++, or something else, there are probably 10 or 20 coming from the old DOS basic background I alluded to.  The amazing thing about PowerBASIC though (at least to me), is that it meets the needs of so many real hard core advanced programmers such as many here and in the PowerBASIC forums that could easily write advanced code in any language.       

[Chris Boss]

Eros,

The book you want for learning low level COM is:

"Inside OLE"
by Kraig Brockschmidt
Published by Microsoft Press

COM is the wrong term to use when looking for books on it.

COM is based on OLE and OLE is at the core of COM (and DCOM).

This book is suppose to be the best book on the subject from what I have read.

You should be able to find it "used" on the web, since it is not published any more.

Another book I found which may be useful is:

"The COM and COM+ Programming Primer"
by Alan Gordon
Published by Prentice hall

They are big books and I would expect that it would take a good year to dig deep into them to fully understand COM at its lowest levels.

[Chris Boss]

Just a comment about Visual Basic.

VB is not simply a Windows compiler (programming language).

It is in its own rights an engine , a "black box if you will", especially more so than say C++

For example it does not use native windows controls for its standard controls.
It uses its own Superclasses of the native controls (the class names all start with the word THUNDER).

Also VB does not always even follow the rules of the Windows API I have found.

For example, my EZSprite library can subclass any native windows static control and add a 2D sprite engine to it.
EZSprite depends upon the standard support of WM_PRINTCLIENT which natives Windows controls all support.

EZSprite won't work though with Visual basic!

Why ?

Because the VB static controls (Image, Picture, even a Frame) don't properly support WM_PRINTCLIENT !

Now if Microsoft who created Windows can't even follow their own rules when making a compiler (VB), then one must question how they design stuff.

EZSprite works fine even with Powerbasics Graphic control, since DDT does not modify the core workings of the ownerdraw static control. PB follows the rules.

To be fair, Visual Basic is really not a Windows compiler, but it is a "black box" protending to be a Windows compiler.

I have nothing against a "black box" approach, since even my own EZGUI is a "black box" of sorts, but one should make sure that such a "black box" follows the rules of the Windows API so one can easily integrate any standard SDK (API) technique with it.

I would venture to say that a lot of Microsoft technologies are simply "cludges" (fudging it) written on top of the Windows API, likely not always following the rules of the core API.

A good example of this is the "mismash" in the API itself of partly procedural API's and partly COM based API's. Some API's can only be accessed via COM.

Even the GDI+ stuff are a mess since they are classes not API functions.
When MS first documented the flat API, they still did not recommend using them and now documentation of the flat API appears to have vanished.

I have found that I have less problems by avoiding the more "leading edge" technologies in favor of the long time core API's in Windows.
One good example are DIBSections. They have been around for a long time, a number of higher level OS DLL's actually use them internally (so DIB's aren't going anywhere) and you can do amazing things with them. With Powerbasic is its low level command set (ie. pointers) I can write all sorts of complex graphic stuff using DIB's and it will work on Windows 95 all the way to Windows 7 with little fuss.

[José Roca]

Even the GDI+ stuff are a mess since they are classes not API functions.

GDI+ is a flat API. The classes are not part of it, but a collection of wrappers provided with source code to C++ programmers for convenience. The only messy part is the documentation, only provided for the C++ wrappers.

Microsoft has always developed its technologies as flat APIs or as low-level COM servers. Then, for convenience of VBers, it wrote ActiveX wrappers, e.g. CDO is a wrapper on top of MapiX (extended MAPI), ADO is a wrapper on top of OLEDB, etc. But you can use GDI+, MapiX, OLEDB, etc., directly with PB.

Now, they continue doing the same, but instead of ActiveXs for VB6, they provide wrapper assemblies for VB .NET and C#.

[Chris Boss]

Jose,

The interesting thing about the GDI+ flat API was that Microsoft strongly recommended "not to use it", but to use the C classes instead.

A normal API would be encouraged to be used.

Notice the current API docs about GDI+:

http://msdn.microsoft.com/en-us/library/ms533969(v=VS.85).aspx

MS recommends not to use the flat API, won't provide any support for it and don't provide any details about each API, except a very simple declaration for each and what class one should use instead.

MS refers to GDI+ as a "class based API" for C++ programmers.

That surely doesn't sound like a positive recommendation for non-C++ developers.

Fortunately PB'ers have been smart enough to figure it all out and take advantage of that flat API.

[José Roca]

The interesting thing about the GDI+ flat API was that Microsoft strongly recommended "not to use it", but to use the C classes instead.

Maybe it thinks that C++ programmers have been spoiled by OOP and are unable to safely use a flat API 

MS recommends not to use the flat API, won't provide any support for it and don't provide any details about each API, except a very simple declaration for each and what class one should use instead.

Who needs them? The reference guide that I compiled ( http://www.jose.it-berater.org/gdiplus/iframe/index.htm ) has been highly recommended in several forums and blogs. Non C++ programmers found it more useful that the M$ documentation. As I have included both the C and PB declares, even ansi C programmers have recommended it.

MS refers to GDI+ as a "class based API" for C++ programmers.

Nonsense. It is a flat API. The C++ classes are just wrappers.

If you have the SDK, you can ascertain it, since the classes come as source code. Almost all of the methods do little more than calling the appropriate flat API function, e.g.

Code Select Expand


inline UINT
Image::GetEncoderParameterListSize(
    IN const CLSID* clsidEncoder
    )
{
    UINT size = 0;

    SetStatus(DllExports::GdipGetEncoderParameterListSize(nativeImage,
                                                          clsidEncoder,
                                                          &size));
    return size;
}


The only adavantage to C++ programmers is that as C++ classes support overloading and default values,many of the methods are a little easier to use.

Fortunately PB'ers have been smart enough to figure it all out and take advantage of that flat API.

And programmers of any other language that can't use C++ classes.