You are not logged in. You can browse in the PowerBASIC Community, but you must click Login (top right) before you can post. If this is your first visit, check out the FAQ or Sign Up.
I tried it once with a PDA, that the same API calls were used, but could not find how to xfer a program to the PDA without M$ Sync, and since PB was not a M$ sync program, I could not get it to work.
My suspicions though are if the OS supports the call then the program will work, but if you can not xfer to test, then the answer is still truly unknown.
Engineer's Motto: If it aint broke take it apart and fix it
"If at 1st you don't succeed... call it version 1.0"
"Half of Programming is coding"....."The other 90% is DEBUGGING"
"Document my code????" .... "WHYYY??? do you think they call it CODE? "
The different OS is part of the problem. Another very big one is the completely different hardware (starting from the CPU...).
One option is running some kind emulator, like the very good PocketDOS. That will probably run most of the code compiled with PowerBASIC for DOS (I know it run a lot of software compiled with MS BASIC 7.x).
PB compiles for x86-type processors only (plus, I believe, an FPU in the Windows versions of PB). If the PDA in question does not have this processor, then the answer is 'no' unless you have some kind of emulator.
PS. The upshot of this is that you may be able to run PB programs on an Apple Mac in the near future, as they have switched to Intel from the old PowerPC CPUs (IIRC).
I tried it once with a PDA, that the same API calls were used, but could not find how to xfer a program to the PDA without M$ Sync, and since PB was not a M$ sync program, I could not get it to work.
The problem isn't getting the PB Exe onto the device Cliff (you can easily do that with ActiveSync - which works quite well as a file transfer program - just tell it to forget sychronization) ; as others have said (Marco, Kev), the problem with Windows CE is really much bigger - its the processors it runs on, i.e., MIPS, etc., which are non x86s.
Years ago I tried it, believe me.
Also, years ago, when Tom Hanlin was still with PowerBASIC, he mentioned that PB actually gets more requests to support Windows CE than Linux.
I'm not sure really what the future of Windows CE is. It seems to me that everything has gotten so small and powerful that most of these small devices could actually run desktop OSs.
For me personally there's no need to get a PB/Linux or a PB/Mac, because there are already enough possibilities to run PB/Win programs on the new MAC OS (Leopard Bootcamp ...) or on Linux (e.g. with Wine).
But I think in the future there's a increasing need (because it's an increasing market) for a PB functionality for mobile devices in two ways:
a) to build mobile "fat client" applications (e.g. for Windows Mobile)
b) to build "thin browser" applications for the mobile browsers (perhaps that is already possible with the Internet functionality of PB/CC...?)
Is there a plan for a PB edition for those mobile platforms?
I would immediately buy a PB Mobile Edition compiler even if much more limited in functionality of current PB Win.
I just recently tested VS2008 Pro and developed few simple applications for a Samsung Omnia i900 running Windows Mobile 6.1. Creating, testing and installing process were really very very simple.
Yes, this issue has affected me in a massive way. About half my work is spent developing/maintaining handheld data collector programs. Over the course of the past four years I have had to redevelop our entire system of programs from DOS to Windows CE. I first attempted to emulator route as mentioned by Marco to see if that would be a feasible alternative. Unfortunately, I had gotten pretty 'fancy' in the DOS code with unusual interrupt calls and the like, and I couldn't get my programs to work satisfactorily in any of the emulators. The emulators are quite good - but not perfect.
So the issue came down to massive rewrites of the programs so as to get them to run in an emulator, or rewrite from scratch in Windows CE. Since the latter seemed to me to be the more progressive solution, that is what I chose.
The next question then would be the programming languages/tools to use? Since I don't care for .NET stuff very much and MFC stuff even less, that pretty much left me with C/C++.
I could have been much more productive with a PowerBASIC compiler, but alas, that is not a possibility. I really don't think it is a possibility with the speed Microsoft is constantly changing the operating systems. You have Windows CE, Windows Mobile, etc. Then all these devices have different processors. I certainly can't speak for PowerBASIC, but I don't know if it would be possible to constantly create/modify compiler solutions for all these different platforms and maintain the high quality standards for which they are known. Every different OEM uses a Microsoft tool (I believe Platform Builder) to custom create the SDK for their particular device, whether it be a toaster, cell phone, gas pump or whatever. So, the situation is rather difficult.
I could have been much more productive with a PowerBASIC compiler, but alas, that is not a possibility. I really don't think it is a possibility with the speed Microsoft is constantly changing the operating systems.
Here Here
I have on occasion attempted to branch out to code for more than just M$ Intel systems, but often find I am one guy vs the M$ world of ("Hey look at what we got this week") concept
On the one hand I wish PB could branch out more (and PB9 has gone a LONG ways towards that), but they are just one entity amongst the many that are out there.....so what should they choose? or would want to choose? ("Flavor of the week? or tried and true "Get the programmer PRODUCTIVE???!!!!") given my druthers, I support the concept of the fine support, and keeping the programmer productive.
Although it would be cool to play with new toys...PB keeps me productive in over 90% of my customer base, so toys can wait, and I can earn a living till time to play with toys
Engineer's Motto: If it aint broke take it apart and fix it
"If at 1st you don't succeed... call it version 1.0"
"Half of Programming is coding"....."The other 90% is DEBUGGING"
"Document my code????" .... "WHYYY??? do you think they call it CODE? "
We process personal data about users of our site, through the use of cookies and other technologies, to deliver our services, and to analyze site activity. For additional details, refer to our Privacy Policy.
By clicking "I AGREE" below, you agree to our Privacy Policy and our personal data processing and cookie practices as described therein. You also acknowledge that this forum may be hosted outside your country and you consent to the collection, storage, and processing of your data in the country where this forum is hosted.
Tweet
Comment