About Powerbasic

[Frederick J. Harris]

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.

[Theo Gottwald]

"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.

[Edwin Knoppert]

>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.

[Theo Gottwald]

@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  :-).

[Christopher Boss]

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

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 .

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.

[José Roca]

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

[Patrice Terrier]

José,

Did you ever checked high DPI with WinLIFT or BassBox ?

...

[José Roca]

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.

[Patrice Terrier]

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.

...

[José Roca]

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?

[Theo Gottwald]

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.

[José Roca]

 
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.

[Christopher Boss]

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.

[José Roca]

 
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.

[Christopher Boss]

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.