Theos PowerBasic Museum 2017

Hi All,

I have had PowerBasic compilers and Perfect Sync Tools for years now. And I have studied SDK-based programming. I like Basic even though serious programmers don't even think it is a programming language. I have been on and off with Powerbasic and studied C, C++ and Java which are considered industry languages. I have not studied .NET because I think it must be slow because it is interpreted and it involves a huge runtime. I would like to stick with powerbasic but I am worried about the resources of the company. It is small. It seems it does not have much in staff - I really miss Lance. PerfectSync tools have not been updated since I bought them - at least I have not been informed and when I compared the version numbers they were same. Also as I have learned powerbasic compilers are done with assembler - that is not goog because they are not portable and maintenance must be difficult. Also they are 32-bits and produce 32-bits code which is not good when the whole world is moving to 64-bit. If they were written for example with C the porting to 64-bit would probably have happened already. Also companies are so blinded with Microsoft .NET-platform that they probably don't consider Powerbasic as contender.

Don't get me wrong I really love Powerbasic and most of the little programs I have made I have done with PB/CC-compiler. I have not done much PB/WIN programming because of the difficulty. I bought Chriss Boss GUI-development environment and I am going to learn it when I have time. I am also going to purchase the other GUI-development tools and compare. They are not very expensive and really make GUI-programming a lot easier. With them it is closer to VB6 which I have used. I think that hand coding GUI-applications with SDK is probably waste of time in most cases. I think Powerbasic should purchase one of the products and include it in the PB/WIN compiler.

What if PowerBasic goes out of business? There should be escrow that if PowerBasic goes out of business the source of compilers would be public domain or GPL or some other license which would allow someone to pick up the pieces. Otherwise it is risky to commit yourself to Powerbasic because it is so little player among big sharks :-)

Just my rampling - have been up 20 hours trying to install solaris 10 on Sparc....

Best Regards
Kari Laine

Quote
I like Basic even though serious programmers don't even think it is a programming language.

Many of us are serious programmers and we are using Basic.

Quote
PerfectSync tools have not been updated since I bought them - at least I have not been informed and when I compared the version numbers they were same.

There have been no new versions of the ODBC drivers, so there is not need for updates. If you miss a feature, then you should send a suggestion to Perfect Sync.

Quote
[...] it is risky to commit yourself to Powerbasic because it is so little player among big sharks.

So far, the ones that have been abandoned are the users of VB6.

In the late 1990s I used Microsoft QuickBasic 4.5 to write all the handheld data collection software for a very large state goverment organization that collects massive amounts of data.  These programs are still in very, very wide use even though QuickBasic 4.5 hasn't been updated since I'm guessing around 1988.  And its now 2009!

My point is, even if the next tornado (God forbid) should take PowerBASIC out, the compiler still works and is very close to bug free.  And if Mr. Zale (PowerBASIC president/owner) should fully retire, I expect he would sell the company to someone with whom he could entrust its future.  For reasons such as this I don't worry much about such issues.  I personally write as much as I can of what I do in PowerBASIC because it allows me to be more productive than in other languages.  I can tell you for a fact that there are a lot of tremendously skilled mainframe, C, C++, and asm coders who don't consider PowerBASIC a second rate sort of thing.   

QuoteI think that hand coding GUI-applications with SDK is probably waste of time in most cases

Just amazing!

Coding in SDK makes you free, and protect your investment on the long run.
Once you know what is going on behind the hood, then you can switch to another compiler in a a few monthes, because the low level API is always the same whatever the language being used.
And once you have written your own set of tools, it doesn't take any longer to produce working application than using third party addons  :)

...

Hey Guys,

I have to share my comments here.

While I really like PowerBASIC and will continue to purchase updates I also think it's getting a little "old". Sure you can always fall back to the SDK but who really does that now a days. I've been keeping an eye on the job postings for some time and not once have I even seen PowerBASIC as a desired or required skill. Fact is on a percentage basis, nobody is using it. It's a shame because it really is a fantastic product but I have yet to see it printed on a job/contract posting. Especially now with Mac OS X and Linux gaining market share you have to wonder how long they can compete. There are FREE and very capable development tools for just about every platform so cost really isn't an issue anymore.

The recent COM support was nice to see but it's about 10 years to late in my opinion. The reality remains that if you want to be competitive in this field you need to have multiple skills sets available. Relying on PowerBASIC alone simply won't cut it no matter how great it is. We all need to learn new languages and keep up with this fast paced industry to continue our careers.

:D

I second what Patrice just wrote.  You might find this hard to believe, but I don't believe its any faster to use GUI generation tools to produce applications.  I used Visual Basic very, very heavily throughout the 90s with the drag and drop control placement, and all that does is provide a way for folks to get apps done who don't know how to hand code things.  Anymore, for example, if I need to put a button on a Dialog/Form, I just copy another CreateWindow() call from somewhere else, modify the locations, add an equate to an inc file, and I'm done in probably less time than it would take to fool around with sizing handles, locate properties in some other window, etc.  

And here's another one to think about.  Charles Petzold makes this point in his Windows 95 book.  The software development kit for Windows 1.0 that became available in 1985 is quite similiar to what we are using now, at least in terms of the smaller subset of functions that were available at that early date.  So what you have in the SDK programming technique is a method of programming that hadn't changed in its fundamentals for 24 years!  Considering how rapidly things change in the computer world, anyone who would have made the investment necessary to learn that technique at that time could have spent the ensuing 24 years furthering his/her knowledge of this one programming paradigm, rather than constantly learning new programming paradigms every few years as old things are thrown away (and with that all the hundreds or thousands of hours you've invested in them) and new tools come into vogue (VB, VB.net, MFC, OWL, etc.).  

And if for some reason you don't or can't use PowerBASIC, if you do it the SDK route, the transition to C or C++ SDK coding is relatively painless.    

I would like to ellaborate a little more about my personnal case.


I am usig different programming tools, each one being targeted to a specific task.

I would never used PowerBASIC, nor C#, nor C++ to write complex ERP or buisiness application using hundreds of windows.

Instead i am using a modern L5G that allows me to have the job done 10 time faster than using VISUAL STUDIO.

And when i need to speed up things here and there, then i am using one of of my PB/DLL booster to put the main L5G shuttle application on orbit.

What i want to say here, is that one single language can't cover all the modern programming paradigm, we must have a limited arsenal at our finger tip, and select the best tool to solve a specific problem.

See my WinDev section, and ask yourself, how long it would take you to produce such application with your "classic" tools?

...

Copying an existing CreateWindow() statement wasn't good enough for me.
It took ages to get the form right.
I sometimes still use WM_COMMAND stuff even if i have event procedures.
It's a matter of perspective, what would your boss think if he finds out your are wasting time with things which are obvious in other languages?
(Like form design)

All the current designers seem the provide a low-level mechanism so you can program in SDK style.
This was not true in VB6 (and earlier) and required hooks and other non-sense to make things work.
We, ide builders, know what you want but there are limits, so what, i can still manage with my tool from ~1995

About the latest com stuff, it's late but it is a great thing to have.

QuoteWhat if PowerBasic goes out of business?

In real bussiness life you can't count on Player size.

Where is the Support for VB5 in Vista?
It was not only dropped, its even buggy.

There incompatibilities between the VB 5 Runtime and Windows Vista.
It just says "There are known problems". Does it help you much?

And both products are even from the same "Big player".
Both have a lot of bussiness users!

Still that doesn't halp Users with VB 5 Programms if they want to use them in Vista,
they may become trouble at this or another point.

We had the same experience with a Company I am working for: WinRobots.
People used to buy for a lot of money a product from Symantec called "CCM ON Command".
Because its the big player.

I hear them how they tell me how important it was to be with the big player.

And now Symantec just dropped the product. It was dropped because of marketing-strategic decisions.

While the product was never technically as good as WinRobots, it also wasn't that bad.
It was just a "strategical marketing decision".

They just wanted to sell the customers something new.
The same like with VB and DOTNET.

Comparing two players, one thats just big and a small one.
Both are long time in the market. Then experience teaches me:

Rather stay with the small players, they can't afford to drop  you.

Especially if these players are for long time in the market, the risk with the big player is higher.

Hi,

thanks for good insight. I am not professional developer. It just a hobby. So whether Powerbasic goes out of business or not is not that important to my hobby programming. But PB/CC and PB/Win are so good compilers that it is pity they are not used wider. It is stupid that Microsoft has cornered the development tools market with it's visual studio series, which cost a lot of money.

Thank you for Jose Roca for this very good service - you should really have PayPal to donate your money. Even I which have very limited funds could donate your some.

Best Regards
Kari

How can you possibly go on and on about "PowerBASIC going out of business".  You have absolutely no knowledge of my company and no basis to make such allegations.  Why would you wish to start such unfounded rumors?  PowerBASIC is NOT going out of business.  This is in very poor taste.

Best regards,

Bob Zale, President
PowerBASIC Inc.

Bob,

Thank god for that!

Although you do have me worried with the prospect of your eventual retirement ;)

As always keep up the great work!

<smile>  You made my day.  I'm going nowhere!

Quote
It is stupid that Microsoft has cornered the development tools market with it's visual studio series, which cost a lot of money.

MS provides Visual Studio for C#/C++/VB for free in Express editions, some of my friends make money with it.

But I still prefer PowerBASIC for high performance applications. I think with PB/WIN 9, PowerBASIC became very close to ideal for game developement.
It is fast, it supports inline assembler with SSE ( great for interpolating complex 3D shapes to achieve animation ), José provides headers for DirectX 9/10 and OpenGL 1.0-3.0. All of these are latest technologies. I see nothing missing here :)

I also appreciate no run times, no .NET dependency and rock stability. All ( few ) issues I discovered and reported were fixed in maintenance update.

I think it is a bit question of what you expect from your tool, for ultracomplex UIs you might save time by purchasing PBForms/PwrDev/FireFly or others helpers. It is true writing code to create dialog will be always more time consuming than dragging controls on the screen visually.

For developement of modules and libraries I found PB to be ideal for the job.

For future I would appreciate some expansion on general purpose ( not "just" COM ) OOP side, but it is not something I couldn't live without. I know PB can do OOP fast after experiments with PB9, so I am fully confident they could provide solid general purpose OOP in future. Better take time and do it right.


Petr

@Bob:

What Mr. Laine writes is an unspoken idea some people have in their mind.
Even bussines people sometimes think like that.

They believe that the safety is only on their side if they stay with the "big players".

They do not realize that the software market has changed a lot in the last years.
There is no safety with big players, you can't count the big software companies who closed their product line in the last years.

These big players are investment objects. The new owner is not interested in keeping product lines.

Safety is with those who can use "what they have".

You know that I am already waiting for the next PB release, whenever it will be ready, count me in as you customer. Besides from that, I can still take even my Powerbasic 7 and use this year and next year and even under Windows 7.

This is safety. The product I have is reliable and works. You can't do that with VB 5.

Having the new PB 9, i can kust take the same source and just compile it.
And it works like a clockwork. This is safety.

You can't do that with VB or many other languages - especially not from big players who took the DOTNET train.

There are reasons for that:
The organisation of a big company does not really help to develope a bugfree programming Environment.

Imagine, The boss of such a big company comes from holiday, he has a great idea.
He doesn't know from programming, he knows only about marketing. He calls the technical director and orders "we do now this and such".
This is the first step to get bugs in a product, if those who decide which features come in are too far from the programmers.

For no software you have the safety that it will still exist in any year to come.

.

While it may be necessary to exchange some components  (http://www.jose.it-berater.org/smfforum/index.php?topic=3125.0) which are not orginally from PB but from MS to really get the Windows 7 Logo.

Good points Theo.  I agree with you.

Safty is a really hard thing to come by.  I work for a large goverment organization that several years ago contracted out for a really major Enterprise scale application to be built.  I'm not 'in' with the folks who are paying the bills, but I imagine millions have been spent on it so far, and my understanding of the situation is that things are going very, very, very poorly.  Like many large software development companies this outfit subcontracts out the actual coding work and just more or less manages things.  Last winter their subcontractor walked out on them, and that brought things to a complete halt for a very long time.  I'm not even sure they've gotten started again.

I recall when the specifications for the 'Request For Proposals' was put out that .NET was a requirement for the project.  I can just imagine the fun it is building an application the complexity of which is such that it takes a team of coders several years to build, when .NET itself changes every year or two.

Exactly,Fred.
This way to go is not a way to solve problems.

Its just a modern way to spent huge amounts of money in a friends big company.

IT Projects are the best way to move money to somebody. Because of the complexity, most people can never understand what was really paid for, and if there had been other alternatives.

Actually I would not say that DOTNET is far from a state that makes it usable for Longterm Projects.
This may change at a later time, when it becomes a bit more stable.

A PB-64 would be an intersting Alternative to me. While for Long Term Projects, something with -64 will be important.
Just looking at the Prices of RAM, the time will come in some Years that -64 will be definitely Standard.

>when .NET itself changes every year or two.

>Actually I would not say that DOTNET is far from a state that makes it usable for Longterm Projects.
This may change at a later time, when it becomes a bit more stable.

Waah!
Did you actually used it or just tested it a little.
I see remarks like these on several boards and most of it is simply not true.

There was a change from v1.x to v2 but all the others are extensions and underneat still use v2.
The change between 1 and 2 may not even notacible, this depends on the parts used.

'a bit more stable' what on earth are you talking about.
I do (ASP).NET for several years now, it's rather steep to learn and maybe it's therefore easier to say it's not your taste.
Ok, the IDE may produce some idiotic behaviour but that may be once a day or not at all.
Code compiled never behaves odd, frankly i have never seen such a stable behaviour, no crashes etc..

Admit it, the 'run-time' size, being Microsoft, the steeper learning curve as expected are the cause of these remarks ain't it?

The market for custom controls... i suspect it is never been larger (vs VBX and OCX)

I am not saying you all should use .NET but .NET is a serious thing for some programmers, it's paying me each month.
Hey, i prefer coding in PowerBASIC but that doesn't mean .NET is a loser.

Edwin,

I didn't make the effort to upgrade my VS2005 to VS2008, do you think it is worth to do it?

Perhaps better integration with VISTA?

...

I had trouble with this IDE.
Note that compiled output is stable but the 2005 IDE was better.
(I may have had a beta of 2008?? and i went back to 2005)

The .NET frameworks 3.0 and up are v2 but extended, the basic v2 part is stable but i don't have any experiance with the extended features, like wpf, for 3.0 and 3.5 and so.
These distro's are getting incr. large, i stick with coding for v2 anyway.
Vista has v3.0
Soon v4.0 will be released.

Did you experiance trouble with the 2005 IDE's under Vista?
I use XP all the time.

QuoteDid you experiance trouble with the 2005 IDE's under Vista?

I had to download a patch to use VS2005 on VISTA.

QuoteThis application present known compatibilty isues...  ask your vendor for a new version that is VISTA compatible

Microsoft speaking of the Microsoft flag ship development platform.  ;D

QuoteThis may change at a later time, when it becomes a bit more stable.

I am doing projects in a very large german company, which actually moves bussiness software from VB6 to DOTNET.

The result is:
- Lots of bugs and problems,
- for example with the system resources.

So i can say that I am watching it from a supporters standpoint, buti believe that this company is big enough to have good programmers, to not blame them.

What i am talking from are not those small applications, one person makes, Edwin - you may have different experiences.
I am talking from enterprise Applications, managed by a lot of people.

>for example with the system resources
Which are?
I hope you'll ever come back and eleborate the situation, even if it was a programmers error (Dispose() comes to my mind :) )?

QuoteWhich are?

This Application has a lot of Menü Points and many of them open Forms.
If you open and close them often, System Resources go down and never come back until you completely restart the whole program.
If you miss doing so, you may end up in an Error-Message that dosn't say much to the User (Can't tell you compamny secrets here, its a control that can't be initialized).

Besides that Users report us that the overall speed of the application is significantly lower, then it was before in VB 6.

Therefore this i not my personal opinion, its what i hear from al ot of users usiong the program since 10 Years.
Knowing this i can not recommend to make a migration to DOTNET in Enterprise Applications at this time.

Ok, but i was not discussing the overall speed at first.
Speed issues may be there yes, but also.. there is no trivial conversion from VB6 to VB.NET imo.
VB.NET has a few easy wrappers (like shell afaik) but that's about it.
Like i said, i found the learning curve steep but that is related to the enormous amount of objects in the runtime.
One has to learn quiet a few before you can do something with .NET

We experiance serious speed draw-backs with ASP.NET, it's rather slow imo.
At the other hand it is now a rapid development tool for us.
If it ain't such a large collection of functionalities we better thought about a different programming language.
Still, the (working) speed isn't undoable but it ain't great.
Slow startup mostly.

We avoided VB.NET and program in C# only, this is of course not speed related but it may force you to learn more and to gain more at the end.
This will take time.

>I am talking from enterprise Applications, managed by a lot of people.
Your resources issues, i can not verify this, it may equally be poor programming.
A large bunch of programmers does not say much, i have encountered a few scenarios where the whole team where depending on one (clever) programmer..

I am not the programmer of this application, and i am also not the one who decided for the conversion.
But the experiences I tell you are first hand.

I assume, that they use the normal DOTNET Tools, so i can't tell you where the resource problems come from, but it should be from the DOTNET runtime.

Maybe you take your application an just open and close the Masks 1000 times using a Testing software.
Do you get resource problems on the way?

Many people do not test their applications really extensively - like in batch usage.
If you do this, you'll often expereinece other sides of your program. I'd say its a DOTNET problem.

We have only a few windows .net apps for internal use, there is no testing done.
We host ~ 8 a 10 ASP.NET websites on one server.
Only SQL server produces an issue in a rare occasion and eats all the mem.
This seems to depend on a specific query, i am not informed what the cause was.

The windows apps appear rather slow but then, i didn't write them and i suspect a query to our remote server is executed while the form is partially visible.
I hate that and i never would like to do it this way.
But then, this is for internal use (and i don't write them).

Our ASP.NET apps appear slow when some time not used, after that it's ok but not all pages are instant.
This may depend on the database queries i guess.

Just to explain, what it means "Resource problems".

If you open a lot of graphical windows resources, at the end your IE will start without Toolbar, programms that have always worked fine will not come up anymore or bring silly error-messages.

At the end your screens turns into a white color and is not more redrawn, this is the final state of "resource problems"  the moment you can most often not escape until you reboot.

Important to know that this is not primarily a Memory (RAM) problem, but a problem of an overflow in internal windows tables, holding pointers to windows data like Regions, etc..

Good tested pProgramms return their resources at runtime. Means you open a form, then you fill it, and the resources are returned when you close the form.

Those DOTNET Enterprise stuff i have seen there, seems to return all resources when you close the programm totally.

Means you can not use it for a longtime without restarting it.

A behavior that makes some of the power-users quite angry.

The main issue i had myself with Dot.NET, was with the "Garbage Collector" when mixing managed code and unmanaged Win32 DLL (pointer were getting lost) forcing me to do extra acrobatic to preserve my pointers.

...
 

>Just to explain, what it means "Resource problems".
Ok, your story seems to have the old fashion GDI and USR stuff problems.

With sysinternals - process explorer you can add these two columns and detect if what you are saying applies to all forms.
Supose i write me a simple app having a single form and add some code to open and close this form countless times, this would introduce the problem?

It's just.., a good programmer is sceptic, i made so much diagnostic errors in my life...
So far i really think MS does not introduce such an error imo.

:)

My problems with .NET were really very fundamental and philosophical.  Around 2003-2004 I decided it was time to really study .NET hard and master it because at that time I accepted with blind faith that Microsoft knew what was best for all of us programmers including me.  So I bought piles of tomes on .NET, including all Petzold's books on both VB & C#.  I spent many, many months doing almost nothing but working with either VB.NET or C#.  So great was my determination to thoroughly explore and understand the fundamentals that most of the compiling I did from the command line using Notepad and even Edit.com (yes, believe it or not - and I do have Visual Studio too).  After quite a few months during which time I seemed to be becomming more & more dismayed, I finally decided to tackle a real world problem involving my work. 

First thing I had to do was set up a grid on a Form and adjust the column widths.  I remember with VB4 it took me a couple hours in the documentation to figure out how to do that the 1st time I had to do it.  Well, with .NET, after a couple hours I was still in the dark.  So I did a search on some .NET websites and found quite a few folks were having that very same problem.  But there is a way to do it.  I don't have the code offhand to show it, but the solution involved collections nested about five levels deep.  In other words, one started with the grid object and drilled down through collection after collection until one had a string going across the whole text editor with four or five 'dots' connecting text.  The lesson I took from that was that with .NET my programming style was really going to change in a fundamental manner.  Instead of writting code I'll be spending all my time searching websites for the right combination of 'dots' to get my 'object' to do whatever it is that I need it to do.  No need to write much code anymore - just get good at connecting 'dots'. 

By that time I truely realized how absolutely fundamental the change was between the way I like to do things and the .NET way.  I saw how massive the .NET framework was - including the documentation - especially the documentation.  And all the time in the back of my mind was this little question nagging at me... "Fred, after you make this monumental investment of time learning this thing called the .NET framework, how long will it be before Microsoft unravels its next massive programming paradigm shift that will immediately render obsolete .NET and all the intimate details of it that took years to master? (kind of like what they did with VB1 - VB6)".

This was a very difficult decision for me to make and I'm not absolutely sure I made te right decision.  Fact is, I'm not absolutely sure of very much at all.  I believe many years ago Socrates came to the same conclusion after a lifetime of searching for the 'Truth'.  But my decision was to 'fall back'. 

All through the nineties I fooled around with SDK style programming in C 'Petzold style'.  However, I used Visual Basic for all my real work.  I decided to 'fall back' to a more fundamental low level programming style rather than keep relearning new class frameworks that - while they may seemingly make doing routine tasks such as designing forms go quicker than hand coding - in the end require more labor from the programmer because their life expectancy is only a few years until they are obsoleted/deprecated by the next new ultimate programming paradigm shift from Microsoft. 

I'm in my mid fifties now and am not so eager as I was in my 20s & 30s to spend massive amounts of my remaining time learning things that will be shortly thrown away.  So PowerBASIC SDK style programming for Windows desktops and C++ Sdk style for my data collector Win CE projects works for me.   It is for reasons such as this that I take real exception to the idea that it is harder to use low level techniques (Windows Sdk) to write applications than higher level techniques such as .NET or MFC in the C++ world - for that matter any 'class framework'.  Class frameworks come and go.  The underlying Api tends to change less.

Quote"Fred, after you make this monumental investment of time learning this thing called the .NET framework, how long will it be before Microsoft unravels its next massive programming paradigm shift that will immediately render obsolete .NET and all the intimate details of it that took years to master? (kind of like what they did with VB1 - VB6)".

Fred, the answer is easy. MS is a Corporation who needs to make large amount of money.
They will not earn it if you can constitently use the same tools.

You will need to get:
- New informations
- New Developement-Tools
- New Courses
- New abbonnements, MSDN, books
a whole industriy waits for everything to be new.

New, new, new everything will always be made new.

If such a large company will not make an sufficient amount of money throughput,
the boss has to go.

He doesn't want. He rather sells somethign new, new new to you.

DOTNET itself is a system that is new with each version.
Means: You may need the runtime of each version to run all DOTNET programms.

While this calculation is generally on some level mistaken, in case of MS it seems to work out and they earn a lot of money with it.

If you try to master it really, you can keep yourself as busy,
as some monks learning each line of the bible.

The only difference is, that when you are ready - the bible ist still there.
And DOTNET in the version that you know is long time gone.

Back to Powerbasic. I can still complie my PB 6 Software - ok, some small changes are needed.
But as a programmer thats just a good feeling.

And last week Bob said that he'll go nowhere.

If MS would say the same, I'd believe the opposite.
In case of Bob, I believe him because I see the past.

>DOTNET itself is a system that is new with each version.
Means: You may need the runtime of each version to run all DOTNET programms.

I have explained this before, there is some difference between 1.x and 2 but 3 and 3.5 are v2 based and thus still compatible.
If you use 3.0 or 3.5 features you'll need this version or up yes.

@Edwin, exactly.

After all, DOTNET has its advantages for those who believe in it, no doubt.

If an Enterprise Application needs a lot of support can be a very good bussiness for the supplier  :-).

Interesting discussion !

The problem with any programming is whether the operating system maintains backward compatibility. Despite some problems with Windows over the years, Microsoft has gone to great lengths to provide backward compatibility.

But things are changing at Microsoft so in the future one may expect even more problems with backward compatibility.
Read this article:  http://www.joelonsoftware.com/articles/APIWar.html (http://www.joelonsoftware.com/articles/APIWar.html)

My impression of Windows development is that many programmers feel they need to stay on the "bleeding edge" of development since it will at least guarantee their software will run well on the latest computers. Backward compatibility isn't important. What some may not realize is that attitude causes problems because in the future your current software also may suffer from lack of backward compatibility, so there is little longevity in ones code.

After about 10 years of experience with the Windows API I have found something interesting. Native coding (aka. the Windows API) if done carefully (pick your API's carefully) can produce software which is not only backward compatible, but also will stay the test of time in the future. Why ?

Because no matter what changes Microsoft makes to Windows in the future, I really doubt they are prepared for a total rewrite of Windows from scratch. Remember they too have to be able to reuse their own code in the future. Windows is a "huge" piece of software and even with all of Microsofts resources a totally rewrite of Windows would be disasterous and probably unfeasable. This means there will always be a core subset of the Windows API which will stand the test of time and be around for a long time.

Is this true ?

I did some testing recently with my EZxxx software (I know, everyone hates to hear that name) and created a Windows 8 Backward compatibility test app. I threw in a significant amount of tasks so it checked to see how well they worked on Windows 8, such as subclassing, superclassing, memory DC's, DIB's, ownerdraw, customdraw, regions, custom controls, MCI, GDI graphics, OpenGL and trust me a lot more than may meet the eye. I installed Windows 8 Preview (32 bit and 64 bit) and ran the app on Windows 8.

It ran flawlessly.

About the only thing I have found so far that Windows has broken was another test app which used a layered window with transparency so I could emulate free floating animation on the desktop. The animation failed to display. I will have to track down that problem, but that is something rarely used by programmers anyway so not critical.

Well the other day I tried another test, but in reverse. I took a computer which I had installed the earliest version of Windows 95 (version a) (500 mhz cpu, 128 meg ram) and copied the Windows 8 test program to it. I had to download a software only OpenGl driver so the opengl would work. I ran the app and guess what. The majority of it worked quite well. Actually the only problem I had, was the video the MCI displayed didn't have the codec on Windows 95 (and I didn't have any speakers on the computer so I couldn't tell if the MIDI played) and one system color was a little different (some ownerdraw got a grayish color rather than white), but all in all it ran amazing well. The OpenGl 3D ran perfectly (albeit slower), the 2D proprietary sprite engine ran perfectly, custom controls worked perfectly, drag and drop worked perfectly, visual design engine worked perfectly.

From Windows 95 to Windows 8 Preview ? Amazing !

Even my Visual Designer (5.0) ran perfectly on the Windows 95 machine (and it runs well on Windows 8).

Now I have to admit I go to great lengths when chosing API's to use (I stay away from some which have changed too much over time or are too bleeding edge) and I have gotten dynamic loading of later API's down to a science (rather tha use an include declare, I poll Windows to see if the API exists, get its address and then call it using CALL DWORD), so I can use more current API's when I want to and still maintain backward compatibility in the runtime (meaning I can use the same runtime on Windows 95 and not get any API not found error messages). Also it is important to note changes in API structures and to test to see what operating system the app is running on and use the appropriate structure for the appropriate version of Windows.

The point is that using PowerBasic and carefully using the Windows API can product applications with far more range and longevity than with some other programming languages.

To appreciate this, consider how many people are still using Windows XP (especially businesses). It is frustrating when you download a demo of an app on the web and when you try to install it, it is requesting some missing framework. You get dot.net 1 installed and then new apps want dot.net 2. You get dot.net 2 installed and now current apps want version 3.0. You get 3.0 installed and then current apps want dot.net 3.5. You get that installed and then current apps say, "sorry, you need Windows 7". It never ends.

Well at least for now it looks like Windows 8 should be a decent platform for PB programmers, since the Windows API is alive and well.

1.- If you want to keep backward compatibility at all cost, you can't use new APIs.

2.- All legacy software is going to have problems when used with high resolution monitors and High DPI. See attached pictures for a couple of examples. In the first one, the text does not fit in the controls; in the second one, part of the top is not visible.

For other kind of problems you may experience, see: http://msdn.microsoft.com/en-us/library/windows/desktop/dd464660%28v=vs.85%29.aspx

José,

Did you ever checked high DPI with WinLIFT or BassBox ?

...

With Aero mode using virtualization, it doesn't take into account the size of the tray window (see capture 1)

Forcing DPI awarenness, it becomes very small (see capture 2). This is expected with applications that are not High DPI compliant. The scrollbars are also a bit oversized.

José,

BassBox Radio is a Windev application (with minimal size of 800x600), while the standard BassBox and WinLIFT are plain Win32 applications.

By me, the standard BassBox and WinLIFT applications are looking good at 150% on my full HD (1920 x1080) display.

Anyway, it is my opinion that DPI is not well suited for LCD display because the best aspect is always get using the native hardware screen resolution.

I would suggest to people with eye disability to use a large TV LCD display with a WMI cable, because nowdays you can get a good one for less than 400 €.

For example, when i want to enjoy a full HD MKV movie, i am always connecting my computer using a WMI cable, then i can also use "home cinema speakers" instead of the small audio speaker of my laptop.

The other alternative to compensate eye disability is to use the VISTA/SEVEN magnifying glass.

...

Quote
By me, the standard BassBox and WinLIFT applications are looking good at 150% on my full HD (1920 x1080) display.

Running in Aero virtualized mode. Have you tried checking the "Use Windows XP DPI style scaling" or using Aero Windows 7 Basic theme?

I am most often using XP for development because the newer WIndows OS (since 2000 - that was my favourite OS) are going in a toy-like direction.
I have less Icons and text on the screen and alltogether is less readable under Vista and Win7.

For me working with XP is easier then working with WIn Vista or 7 because there are to many toy functions built in that i do not need as a programmer.

Having said this, I'd had prefered, if WIndowswould go in a more professiona ldirection, but marketing says "make everything easier and funnier".
And thats what happens.

 
I don't care about other people preferences. It's not my business. I simply have demonstrated in post #35 that the rhetoric in post #34 is flawed.

In my system, all High DPI compliant applications work fine no matter which settings I use, and most non High DPI applications have some kind of problems.

Jose,

My 3D model viewer scales based on the end users system font setting. The app was designed for small fonts, so if your other PC is set to large fonts then the text won't fit.

I could have selected fixed scaling, where EZGUI will force all fonts to a fixed size no matter the end users system font setting.

EZGUI allows multiple ways to handle scaling (or no scaling).

Don't be too picky. Its just a freeware app I created to test the OpenGL stuff. The opengl (3D) works quite well not matter what system is used.

It would be different if the app was a commercial app, but I literally threw it together in a short time primarily to test the new 3D OpenGL based control and its scripting language.

 
Fixed size fonts aren't a solution at all. High DPI compliant applications must scale both windows/controls and fonts, and use ClearType fonts. The point size of the font must be calculated as lPointSize = (lPointSize * 96) \ GetDeviceCaps(hDC, %LOGPIXELSY). The system font is of no use.

There are other problems such toolbar icons. They become smaller. Therefore, you need either to have several sizes and choose the most suitable size at runtime or have one and stretch it (less bloat, but less quality).

So, my point is that it is not enough to just choose the API calls supported by all Windows versions. I wish it was so easy.

EZGUI uses the standard font point calculation that the APi docs recommend.

-(MulDiv(PointSize&,GetDeviceCaps(hDC, %LOGPIXELSY) , 72)

It also scales the Dialogs based on the DPI.

I need to do some more testing on different systems with much higher DPI's to see the results.

 
Indeed. But before -(MulDiv(PointSize&,GetDeviceCaps(hDC, %LOGPIXELSY) , 72), PointSize must be adjusted with PointSize = (PointSize * 96) \ GetDeviceCaps(hDC, %LOGPIXELSY) if the DPI is not 96.