Powerbasic have a future?

[Michael Rice]

Steve,

I couldn’t tell who your comments were directed at. I’ll admit that I made the jump to 64 bits out of selfish and/or greedy needs. I made my own comments here because we seem to have people saying that they “need” 64 bit and my thought is... Okay go get you some 64 bit...the world is your oyster!! PowerBASIC can’t currently be your 64 bit solution...but there are 64 bit solutions available if you really have the need. And if you already know how to program, it frankly isn’t that difficult.

[George Bleck]

Anyone moved/moving to 64bit Office is in for a rude awakening as many (most?) apps/plugin's etc. won't have 64bit equivs.

I understand some HAVE to (especially poignant for large scale Excel users) but for the most part the market still isn't 64bit Office ready-for-primetime.

[Bud Durland]

I might add that if Adam pulled the plug on this forum and just used PB for his own company's internal development work, I would not blame him as it is an excellent tool in its own right and it would save the running costs of the forum and silence the detractors once and for all.

I have to say that I hope Mr. Drake continues to fund the forum. When I'm here, I'm in a great place -- surrounded by people smarter than me. The programs I write help run sales /inventory /shipping for a $150 million company. Some are tiny little utilities, some are very complex shop floor tools. 32 bit PB coupled with SQLTools, VPE, LibXL and SocketTools remains more than adequate, and when I have a challenge I can't resolve, I can usually find an answer or advice here.

And I'm of the opinion that if you truly need 64 bit, go find a tool that does that. No harm in having more than one tool in the box.

[Michael Rice]

After I was contacted by my application customer in 2015 about 64 bit, I was surprised that it hadn’t happened earlier. At that point I was the CTO/CIO at a decent sized bank. We had installed MS Office x64 probably 5 years sooner than my software customer had. I don’t recall us having any major issues with 64 bit MS Office rollout at the bank...but that was a lot of years ago.

Recently I purchased laptops for both of my kids for collage. Both of them had MS Office x64 pre-installed. But I don’t think either of them need apps/plugin’s

Anyone moved/moving to 64bit Office is in for a rude awakening as many (most?) apps/plugin's etc. won't have 64bit equivs.

I was one of them. It was my own application that was having 32 bit / 64 bit issues in 2015...but after about 2 weeks of work in the evenings it was 64 bit ready

[Mimmo Labate]

Dear Friends (ALL)

Excuse me for taking the liberty of making a brief analysis of your messages posted here, after I have written my last one.
The time has come to be serene, and to erase any negative perceptions or feelings that one may have within oneself.

1) I believe that no one here, among those of us remaining in the forum, has any intention of ferrying users of Powerbasic compilers to other platforms.

2) I believe the statement that we do not have enough information about the ex ante state of affairs, within Drake Software, inherited from the management of Mrs Vivian Zale, is correct. And so as Eric Pearson said, one cannot intelligently disquisition in the absence of some elements that are not known to us (at least to me).

3) Ascertained that to write a 64bit compiler, that obtains a working executable with a syntax compatible with the SDK style that can be written with PB32, implies compromises to be found in the interaction with the Windows operating system. One would have to proceed by accepting a loss of backward compatibility of software already written with 32-bit versions of PB's language.

4) It is evident from many messages that writing code that works correctly at 64 bit is not a simple matter. It is not enough to click aside to say compiler, please give me a working exe starting from this code that already works in 32bit.

5) Having ascertained that the work that Adam Drake has to do is really monstrous, for its difficulty and its considerable amount, it would be useful to at least know of each point what has been done and what remains to be done. Only from this information, from the Drake software side, we can think, discuss and decide actions to complete in the shortest time possible what remains to be done and that, I am convinced, each of us carries in our hearts. But we need more information on the state of the art, to be constructive and to give us all together a clear timeline. I was saying that we must be objective and constructive (nothing else is useful), out of Gratitude, Respect and Understanding of the personal style of the previous Actors, who for better or worse have made us and our lives what we still are today.

This is my personal thought, appreciating each person who has written at least one message here, the underlying meaning, even if latent or hidden behind the words he or she has used, but which all converge towards a single point: the lively desire to still be able to be proud to "Compile without compromise" and not feel inferior to anyone.

My best 10 cents
Good day and good work to All

[Knuth Konrad]

To me, this discussion - while interesting, is to compiler-centric.

Besides the question if PB (the language) has a future, I think it is mandatory to also include the available (3rd party?) tools into the mix. And I'm specifically talking about PB (the IDE). In my opinion, a PB programmer doing any kind of application with an UI currently has a major disadvantage compared to most other languages/IDEs out there. The amount of time it takes to "draw" a functioning and pleasing/intuitive (to the user) UI is quite substantial.

And as anyone working with other languages and thus other IDEs most likely will agree to, the amount of tools/addons meanwhile available (mostly for free) for other IDEs is breathtaking. The simple fact that every modern IDE (and I do include pure code editors like Visual Studio Code in this) is designed from the ground up to support plugins/addons (whatever you will call it), is a key factor for its success and continuity.

I know, we had a discussion about addons a few weeks ago in regards to "do tools help or hinder you to become a good/better programmer?" To which I say: it depends. But I'm not thinking of these kind of tools. I have tools in mind, that helps you to use your work time more efficient. Just to name 2 examples for addons I use with VS.NET, which don't do anything I could do myself, but save me quite some time by automating time-consuming manual tasks:

- Spell checking
There's an addon that spellchecks your code on the fly, only taking source code comments and strings into account, not actual code. The number of times that inevitable e.g. "teh" or "od" (instead of "of") creeps into your code in captions or user-consumed (for a lack of a better word) strings is astonishing. Sure, you still need to proof-read. But those easy ones are fixed immediately.

- (Class) properties to string
Another addon that greatly reduces an otherwise time-consuming manual task is an addon that gathers all properties of an object and creates a method that returns a string in the form of "<Property name>: <Property value>". I use this all the time for debugging and log creation.

These are the kind of tools that lets you spend more time for the actual coding. And yes, I'm well aware that you could code such tools as standalone addons for PB, too. But here's the catch: A programmer doing so must take all possible variations of how to create valid PB code into account, i.e. create a parser similar to PB's. These modern IDEs/code editors expose the source to the addon in a "structured" and easy to query way so that the addon programmer can do a "simple" ...

' Pseudo code, but you get the idea
For Each Property In Current Class
   Propertys &= Property.Name & ": " & Property.Value.ToString & " (" & Property.DataType & ")" & NewLine
Next

... to retrieve all properties of an object. Whereas a potential PB addon programmer actual has to parse the raw source code.

[Mimmo Labate]

Konrad this is extremely important, since the programmer after he has thought of (and found) a solution to a problem, spends almost all his time seeing if the code he has written produces (or not) the result he expects to see from the compilation product.

[Bud Durland]

In my opinion, a PB programmer doing any kind of application with an UI currently has a major disadvantage compared to most other languages/IDEs out there. The amount of time it takes to "draw" a functioning and pleasing/intuitive (to the user) UI is quite substantial.

I couldn't agree more. I still use Paul Squire's FireFly environment for development. So much of the functionality it provides are things I could do, but I don't want to be delayed by writing the code. Automatic repositioning of controls when a form is resized, and using the tab control are just two examples.

[Michael Mattias]

I

n my opinion, a PB programmer doing any kind of application with an UI currently has a major disadvantage compared to most other languages/IDEs out there.

All due respect to you and to Mr. Durland, who could not agree more...but 'tis a poor craftsman indeed who blames his tools.

MCM
Certifiable Old Fa^h^hSchool

[Chris Holbrook]

Will Powerbasic have a future?

Only if the coder has a PowerBasic past.

[Larry Chickola]

PowerBasic is a spectacular performer for technical computation and engineering simulations. I recommend it as a go-to for applications needing high speed combined with number crunching. I recently converted a program from another platform that took hours to run, PBCC completes it in 6 minutes. It is also pretty easy to generate sharp and precise graphics. Lastly I find myself using it to parse through big text files to clean them up, extract this or that, or put them into a certain format for use by some other 3rd party program.

These are pretty specific cases, but PB is a mighty sharp tool for them.

[Bernhard Fomm]

[George Bleck]

As long as Windows runs 32bit Apps ---> YES

Simplest answer now we can move on...

[Chris Boss]

There is another platform Powerbasic can be used on you may not be aware of:

RTOS-32

http://www.on-time.com/rtos-32.htm

RTOS-32 is a real time operating system which you can generate an app for and distribute royalty free (meaning the OS and your app). It supports a low level subset of the WIN32 API (no GUI) which is perfect for the PB Console compiler.

Ontime added a few extra API's it now supports which now allow the PB console compiler to work with it.

You simply compile a C DLL using any C compiler you like and add the RTOS-32 LIB to that. Then you only need to declare on call into the DLL from your PB app and it all gets linked together somehow.

I already have it working on SOC x86 boards.

Now RTOS-32 also has its own API you can use directly (which I do) to do a lot more with it. I have already implemented VESA (VGA) support using it and select a video mode which supports a linear frame buffer (there are modes in very high memory which can be accessed for very high res video modes). Currently I am using a VESA graphic mode of 1024 x 768, but I can go higher than that.

Anyone used to making calls to the WIN32 API can easily learn how to make calls into the RTOS-32 API.

RTOS-32 only comes in 32 bit. There is no 64 bit. Powerbasic can have a long life on it.

RTOS-32 can be used in robotics, embedded, etc. It is not cheap, but once you have a license you can generate a app which has its own OS which you can embed on any x86 board royalty free.

Also it is a true Real Time OS, unlike Windows which is not.

For your info: I am the first person to use Powerbasic with RTOS-32. Before I started using it (for a client), RTOS-32 could not run a PB app. Ontime added a few extra things (ie. OLE string API support) so my PB app could run on it and showed me how to compile their runtime in a C DLL and after that I was on my way. For more info read this codeproject article:

https://www.codeproject.com/Articles...c-with-RTOS-32

Another OS I am looking into for use with PB is Windows IOT. Not sure yet, but it may be able to work with PB console compiler (non-GUI).

Powerbasic still has a lot of life left in it. PB has the raw power of C (in performance and low level capabilities), but is still BASIC. Having access to the WIN32 is very powerful.

[Stuart McLachlan]

As long as Windows runs 32bit Apps ---> YES

Simplest answer now we can move on...

[Bud Durland]

All due respect to you and to Mr. Durland, who could not agree more...but 'tis a poor craftsman indeed who blames his tools.

As a craftsman (poor or otherwise), I need to get things done. This not me blaming the tool, but making a statement about how tools can be competitive. To my knowledge, all the major environments for program development include a competent GUI designer. The modern world has moved past the VT100 or 3270. Ideally, they also provide the ability to NOT use the built in functionality, to allow those old fa^h^h school guys to roll their own code if they like.

[Stuart McLachlan]

As a craftsman (poor or otherwise), I need to get things done. This not me blaming the tool, but making a statement about how tools can be competitive. To my knowledge, all the major environments for program development include a competent GUI designer. The modern world has moved past the VT100 or 3270. Ideally, they also provide the ability to NOT use the built in functionality, to allow those old fa^h^h school guys to roll their own code if they like.

Some people seem to believe that you can paint the side of a house with a pointillism brush as quickly and easily as you can with a 3" brush and/or a paint roller

[Steve Hutchesson]

He he, now we have the faithful subscribing to the need for a visual garbage generator. Contrary to popular opinion, dialog editors have been around for a very long time, I started using the Microsoft SDK one in about 1990. Over the last 30 years I have used a variety of dialog editors over time and the current one is Ketil Olsen's ResEd. I use it for 32 and 64 bit MASM, 32 and 64 bit Microsoft C and PowerBASIC and I can build an app using the same RC file in any of them. This means I can prototype in one language and write the app in another.

Now if you want the power and efficiency of a real CreateWindowEx() window, you write it in code, I have seen the tangled messes that visual designers produce to try and emulate the old Visual Basic but if you want the OS powered Real McCoy[TM] then produce it in code. Its not like its a big deal, use a template that you only have to get right once then you add toolbars and menus to it and you have a base app ready to let 'er rip with some decent code.

[Patrice Terrier]

Now if you want the power and efficiency of a real CreateWindowEx() window, you write it in code,

Absolutly!
and CreateWindowEx work the same for all compiled languages, and there are just a few minor changes to let it run in 64-bit.

Here is an example of SDK code written in WinDev, using almost the same syntax than in PB.

FUNCTION MainWindow()
wcx is WNDCLASSEXA
szClass is string ASCIIZ on 16 = "FLAT_API_POPUP" // The class name of our popup window.

wcx.cbSize = Dimension(wcx)
IsInitialized is int =  GetClassInfoEx(Instance, szClass, wcx)
IF IsInitialized = 0 THEN
	wcx.style         = CS_HREDRAW | CS_VREDRAW
	wcx.lpfnWndProc   = &WndProc
	wcx.cbClsExtra    = 0
	wcx.cbWndExtra    = 0 // Extend_cbWndExtra * 4
	wcx.hInstance     = Instance
	wcx.hIcon         = Null
	wcx.hCursor       = API(USER32, "LoadCursorA", Null, IDC_ARROW)
	wcx.hbrBackground = GetStockObject(WHITE_BRUSH)
	wcx.lpszMenuName  = Null
	wcx.lpszClassName = &szClass
	wcx.hIconSm       = Null
	IF RegisterClassEx(wcx) THEN IsInitialized = True
END

IF IsInitialized THEN
	nRet is unsigned int = 0
	r is RECT
	uMsg is TagMSG
	dwExStyle is unsigned int = WS_EX_APPWINDOW | WS_EX_WINDOWEDGE
	dwStyle is unsigned int = WS_POPUP | WS_CAPTION | WS_SYSMENU | WS_THICKFRAME | WS_MINIMIZEBOX | WS_MAXIMIZEBOX | WS_CLIPSIBLINGS | WS_CLIPCHILDREN;
	
	SetRect(r, 0, 0, ClientW, ClientH)
	AdjustWindowRectEx(r, dwStyle, False, dwExStyle)
	
	gP.MinTrackSizeW = r.nRight - r.nLeft
	gP.MinTrackSizeH = r.nBottom - r.nTop
	x is int = Max((GetSystemMetrics(SM_CXSCREEN) - gP.MinTrackSizeW) / 2, 0)
	y is int = Max((GetSystemMetrics(SM_CYSCREEN) - gP.MinTrackSizeH) / 2, 0)
	sCaption is string = "Popup window "
	IF In64bitMode() THEN sCaption += "64-bit" ELSE sCaption += "32-bit"
	gP.hMain = CreateWindowEx(0, szClass, sCaption, dwStyle, x, y, gP.MinTrackSizeW, gP.MinTrackSizeH, 0, 0, Instance, 0)
	
	IF gP.hMain THEN
		
		ShowWindow(gP.hMain, SW_SHOW)
		SetForegroundWindow(gP.hMain) // Slightly Higher Priority
		
		// Main message pump.		
		WHILE GetMessage(uMsg, Null, 0, 0)
			TranslateMessage(uMsg)
			DispatchMessage(uMsg)
		END

		nRet =uMsg.wParam
		
	END

END
RESULT nRet

[Mike Doty]

Thanks for mentioning windev.
After the initial sticker shock of $2417.00 there appear to be other ungoing costs.
Licensing and distribution. Without the server it may be ok.
Size of "hello, world". Size of runtimes.

Purchasing the 3-products     $2417.00
Server distribution per site   $363.00
Ongoing server updates          ???.00
Language updates                ???.00