Jim,
I see that your last post has been removed from another forum.
About 64-bit i am with you, and i am also one of those "half brain" guy, because i need it right now, five years after C programmers seems enough to me.
Should we wait more than 10 years like for COM?
>:(
...
I don't understand what the fuss is about. There are tools that allow you to develop for 64-bit platforms already...
The fuss, is for those of us who have written commercial addon with it.
That's a strange strategy for a commercial company to force some of us to move to another language, especialy in the case of the thread "you talk... and we listen".
...
I understand what you're saying, and can certainly appreciate the "investment" you've made. I was in the same boat myself.
You could also see it as overly optimistic to put all your "eggs in one basket" like this. Especially if you consider the company in question's reputation. They make great products but they are a little late out of the gate on some features. If you need bleeding edge then this may not have been the best choice for development tools.
I realize that doesn't help you but perhaps it may help someone else reading these forums.
It sure would be nice to own some exotic car but sometimes it's just easier and less frustrating if you just buy what ever one else is driving ;)
Mark
I do not put all my "eggs in one basket", for example i am also a WinDev and C# programmer, however i can't write true native DLL(s) with C# because of the extra dot.NET framework, that changes every three years or so. About WinDev, its syntax is very close to PB, making very easy for me to port my code between the two platforms, but WinDev is p-code, not a true compiler.
As for the portability i am using only pure SDK, thus i could convert GDImage and WinLIFT to plain C using VISUAL STUDIO, but this would take me monthes and monthes work. I would rather add new features than to perform the translation, because programming is also a hobby for me.
If it would be only for money, or for glory, i know i would have better to move to C, but basic was my first language, and when i go to bed i am dreaming in Basic not in C.
...
I never thought I would say this, but I agree with Patrice. At the end of the day, when running a 32-bit program on a 64-bit version of Windows, your 32-bit program will run under emulation. Unfortunately, the emulation is not 100% perfect.
The official "outlook" from PB is not surprising when you consider that they still sell a DOS compiler and cater to older versions of Windows with the newer compilers. Not everybody is in a position to be able to target a market where really old systems are in routine use. My target demographic certainly does not fit that category ;)
Quote from: Brice Manuel on June 02, 2010, 01:15:36 PM
...the emulation is not 100% perfect...
By all means, please show us this imperfect emulation? How about a demonstration?
Bob Zale
PowerBASIC Inc.
Bob,
Emulation or Wow64 is not the problem.
The address space being not the same between 32 and 64-bit, it is almost impossible to write 32-bit code that would deal directly with the underlaying OS.
And when you are a third party addon provider, being unable to provide a 64-bit version of your DLL is a serious limitation when people themselves are accustomed to use C, C++ or dot.NET in 64-bit, since several years.
This is my concern, and what i would express in a "listen to me" thread.
Now if i could make another request, that would be for "Android", because that's the way an increasing part of the programming market is going.
...
Quote from: Bob Zale on June 02, 2010, 01:52:54 PMBy all means, please show us this imperfect emulation? How about a demonstration?
Here is the official word from MS:
http://msdn.microsoft.com/en-us/library/ee418798(VS.85).aspx
Please note where it says:
Sixty-four-bit Windows operating systems are binary compatible with the IA32 architecture, and the majority of APIs that 32-bit applications use are available through the Windows 32-bit on Windows 64-bit Emulator, WOW64. Bolding is mine. Please note it says the majority of the APIs (not all, only the majority) used by 32-bit apps will work. Some APIs are simply not available under emulation. If something doesn't work 100% of the time, it is not 100% perfect. Even MS admits the emulation isn't 100% perfect, Bob. ;)
Windows on Windows 64 is just as problematic as Windows on Windows was when we were all trying to support our 16-bit software when people started running it under '95. Like WoW, WoW64 has got better with time. However, you need to remember that MS always targets compatibility instead of compliancy. Some things just do not work properly under the emulation layer. Yes, the instances are rare, but to pretend they do not exist is disingenuous.
Taking WoW/WoW64 out of the equation, there are always incompatibilities between OS versions and some software will not always work properly on the next OS that comes out no matter what compatibility settings are used.
MS isn't stupid and realizes the need for backward compatibility. MS's solution has been to do what they do best and buy up the companies and products that specialize in what they need so they can get the job done and make the changes/improvements needed. MS has been buying up virtualization-specific companies since 2003. I have lost count: Connectix, Kidaro, Calista (off the top of my head)
MS' problem has always been providing backwards support without bloating the OS. 7 was a huge step in the right direction. XP mode works great I firmly believe XP mode is MS's future for backward compatibility. Imagine how streamlined the OS could become if backwards compatibility is stripped from the core OS.
Back on topic... Bob, you realize the coming need for 64-bit. Yes, it isn't needed by the majority of PB users, but there is a small percentage of us who can't wait to get our hands on it and we are happy to know that PB will offer 64-bit support at some point in the future. ;)
Another point on Patrice's behalf (not that he needs my help) is he has a different target demographic than most PB users. When you are dealing with graphics and especially high-end graphics, spec-wise this is almost the same demographic as 3D video games.
This is a demographic that has largely outgrown the limitations of 32-bit architecture and routinely encounters problems. This is happening to the AAA developers as well as increasingly to indie developers and this has been a topic of discussion at the major conferences for a couple of years.
I can easily imagine that Patrice is dealing with similar issues due to the advanced nature of his graphics software.
A c#/.NET programmer is not interested in unmanaged code or libraries, his interest is to work with .NET.
Using an unmanaged part will bite him sooner or later.
> that changes every three years or so.
That's barely (to none) true since it's backawards compatible to v1.4 at this time (where at v4 now).
At least bw compatible with v2 which is the base for all but v4 frameworks.
(+ intermixing v2 compiled assemblies work just fine with v4 projects)
If you want to do graphics use your skills and do them as supposed to do.., in the language of the end-programmer.
With .NET the use of generic libraries as we know it has come to an end.
PInvoke support is only their to make existing things running, not for new development.
You'll have massive issues regarding security and compatibility like the problem mentioned here: 32bit and 64bit.
A .NET assembly compiled 'as any', runs on 32bit and 64bit unless you had unmanaged code to a 32bit generic dll.
You force the end programmer to stay on 32bits because of some generic dll.
If you wish to read what i foresee as the future read my (simple) topic about WPF:
WPF and Silverlight - The future?
http://www.hellobasic.com/cgi-bin/forum/YaBB.pl?board=general;action=display;num=1274473654
Edwin
I do not force anybody to use my DLL(s), that's the programmers responsability to ensure that they will fit their needs.
This is the reason why i provide unlimited trial versions and many examples showing how to use them.
http://www.csharpfr.com/codes/CAROUSEL-3D-ANIMATION_41278.aspx (http://www.csharpfr.com/codes/CAROUSEL-3D-ANIMATION_41278.aspx)
Anyway your remarks are out of topic.
...
>Anyway your remarks are out of topic.
Pfft, i was trying to give you an hint.
Good luck
"If something doesn't work 100% of the time, it is not 100% perfect."
Well, then, let's see if I really understand you...
1- There may be a few deprecated 32-bit API's in Win7/64. (Can you name just a couple of them without scouring the 'net first?)
2- I guess it follows that this has never happened before in another Windows release?
3- If true, that might be described as a "bug"?
4- I guess it follows that this has never happened before in another Windows release?
5- There have been zero (0) reports of PowerBASIC failures on Win7/64 (My personal statement of fact).
6- But you're content to suggest (or imply) publicly that 32-bit PowerBASIC programs won't run correctly on this imperfect platform?
7- But you are absolutely confident that all 64-bit code will execute perfectly on this 100% perfect 64-bit platform?
Best regards,
Bob Zale
Quote from: Patrice Terrier on June 02, 2010, 03:54:19 PM
Emulation or Wow64 is not the problem.
Of course not. Everyone has their own set of problems based upon their personal wants, needs, and desires. Some folks here think we are "less than perfect" because we offer a DOS compiler for those folks who need one. Others seem to think we have an imperfect reputation. You want to create 64-bit DLL's, yet you've never sent us a single email to discuss it. Maybe if we can get everybody riled up enough, they'll storm the PowerBASIC offices with torches at Midnight? {smile}
Seriously, I've confirmed several times that there will be a 64-bit version of PowerBASIC. You know that. But, at this point, I'm not prepared to make further public statements (other than the fact that only a tiny percentage of our customers need it, and would buy it, today).
Thanks for listening.
Best regards,
Bob Zale
PowerBASIC Inc.
Bob,
QuoteYou want to create 64-bit DLL's, yet you've never sent us a single email to discuss it.
I thought that expressing this need on the "PowerBASIC listen" thread, would be sufficient.
...
Quote1- There may be a few deprecated 32-bit API's in Win7/64. (Can you name just a couple of them without scouring the 'net first?)
I actually attended the XNA 2008 Conference which is where the info I linked to came from. I will take MS's word on this one.
Quote5- There have been zero (0) reports of PowerBASIC failures on Win7/64 (My personal statement of fact).
Nobody in this thread claimed there has been. I can't speak to what was said on the official forums as I am not a member there and do not read it much anymore. Personally, my 32-bit programs written with PowerB work flawlessly on 7 64-bit (which a very large percentage of my testers are using).
Quote6- But you're content to suggest (or imply) publicly that 32-bit PowerBASIC programs won't run correctly on this imperfect platform?
I did nothing of the sort. I have never said or implied that 32-bit PB programs will not function correctly under a 64-bit version of Windows. What I said is in paragraphs and each paragraph (as is standard in the English language) refers to something different. My first paragraph is agreeing with Patrice, and explaining why I agree with him. The second paragraph is agreeing with the "official" PB position on 64-bit and saying I understand it would NOT benefit the majority of PB users. You shouldn't read posts through jaundiced eyes.
Quote7- But you are absolutely confident that all 64-bit code will execute perfectly on this 100% perfect 64-bit platform?
That is a loaded (but rhetorical) question. The code would not be running under emulation. However, how well the code runs would depend on who made the compiler ;) I am sure PB 64 would be fine. Unfortunately, that may not hold true for some of your competition ;D
Quote from: Bob Zale on June 02, 2010, 06:54:06 PMMaybe if we can get everybody riled up enough, they'll storm the PowerBASIC offices with torches at Midnight? {smile}
With the amount of oil you have floating around down there, I wouldn't recommend torches ;)
Quote from: Bob Zale on June 02, 2010, 06:54:06 PM
... (other than the fact that only a tiny percentage of our customers need it, and would buy it, today) ...
I would buy it today !
Not because I need it but because it comes from PowerBASIC :)
Quote(other than the fact that only a tiny percentage of our customers need it, and would buy it, today)
Yep,
that is a very good question to ask on the PowerBASIC forum, why don't you start a poll to listen from us?
I would also buy it today!
...
Let them/us know.
The poll has been posted here (http://www.powerbasic.com/support/pbforums/showthread.php?t=43647)
...
I can't vote, but if I could, I would vote: Yes, I could spend $199 to have it today.
I would buy it. Not because I necessarily need it but because it comes from PowerBASIC. Power Basic products are very good and very stable! But really there is no sense. At least for the moment I see no point. But one should not deny the 64-bit technology!
Regards,
Peter
Peter,
All major compilers have it for several years now, for me this is a good reason especially when you sold commercial DLLs, or when you have code that must interract or bypass some of the underlaying operating system API (for example function hooking via detours/trampoline).
...
Hi Patrice,
I have to give you really right. There are now x64-bit Windows. And who do I write a DLL for 64 bit programs do I need just a 64-bit Basic compiler. And that is an important reason! Wen I do not have I must resort to another compiler. And so, Power Basic is dead!
Regards,
Peter
Quote from: Peter Weis on June 03, 2010, 10:27:20 PM
And so, Power Basic is dead!
What a nice, polite sentiment. Thank you.
Bob Zale
PowerBASIC Inc.
I am old enough to express my opinion with no thrill, and until my karma here get down to zero, i will keep doing so ;)
...
Quote from: Bob Zale on June 04, 2010, 12:52:17 AM
What a nice, polite sentiment. Thank you.
Perhaps something got lost in translation? In his previous post, he states that he doesn't
need 64-bit support, but would buy it just because PB made it. His last post appears to be a hypothetical statement that went awry. I am giving him the benefit of the doubt since English isn't his native language.
The thing will go much faster then with the step from 16 to 32 bit.
The reason is the high speed in the hardware market!
Look, the WOW64 is already going to be an optional part for windows servers.
QuoteWoW64 Is Now an Optional Feature for Server Core
http://msdn.microsoft.com/en-us/library/dd371790(VS.85).aspx
Microsoft also gives you the sollutions:
QuoteSolution
The preferred solution is to provide a 64-bit version of the code to enable it to run on Server Core without needing WoW64.
They always start with the servers.
Earlier or later there will be the first desktops without WOW64.As a commercial Softwre provider you will have to be ready for that.
From my german point of view, it doesn't make sense to still sell DOS Versions and not have something for x64 - at least in the pipe.
QuoteSeriously, I've confirmed several times that there will be a 64-bit version of PowerBASIC.
[/size]
Hey - great news!!!
Thanks Bob, count me in as customer, as always!
I have use Purebasic 64 for some smaller projects, but i am not really used to their syntax and style.
I'd really prefer the Powerbasic way.
Theo,
Yes, Bob has confirmed several times that there will be a 64-bit version, all those "half brain" are now well aware of that. ;)
The problem is when?
Six months for a limited or beta version would be acceptable, while two years would not.
It is my personnal opinion, that in the case of 64-bit, the application of the strict "no vapor ware policy" is a mistake.
Because it forces some of the most advanced PB's programmers to move to C, and this shall be of a big loss for the PB's community.
From the perspective of an addon provider, the market of "C" is so much larger, that once you jumped in, you consider everything else as peanuts.
This is already the case for my GDImage and WinLIFT, very few need them in the PB's world, while there are more and more outside of it.
That's one of the two reasons why i need a 64-bit compiler today.
...
QuoteThe problem is when?
We now have an answer, Tom Hanlin just wrote on the PB forum:
QuoteNot today, we have other projects under development that must clear first.
Those who do not need 64-bit yet, be happy, you will have some new "cool toy" first ...
Personnaly, i only need "tool". ;D
QuoteThere is still much to do in the 32-bit field, such native unicode support.
"Native Unicode support" this is what i would call "tool" not "toy" ;)
And why the heck, should we always be left behind.
...
Quote
@Jose: Do you think it will be possible for a smaller Company like PB.inc to develope at the same time two product lines for 32 and 64 bit?
I don't know.
Quote
I'd prefer if they just leave PB32 as it is, swll it like that, and develope new versions only for 64 bit with all needed unicode support.
I don't. Maybe in a couple of years, but not now.
Quote
And why the heck, should we always be left behind.
Because we are a minority. Granted, you don't need DDT and graphic statements, but the majority of PBer's will be lost without them and won't buy the compiler. When PB will release a 64 bit compiler it should be a full fledged one.
From what I've seen people post and talk about on the forums, for years they've written code with the assumption that pointers and integers (DWORDs in particular) are interchangable. That's inherently non-portable, and I'm not sure what the folks at PowerBasic can really to do mitigate that in any kind of transparent way. I'm sure the transition will be less painful for those who are largely using DDT, but for those who largely (or exclusively) use the Windows API, there'll be some work ahead to make sure they're calling things correctly.
I agree that it really wouldn't make sense for them to release a half-baked 64-bit compiler just to meet the needs of a handful of programmers. When they do provide one, people are going to rightfully expect it to have all of the functionality of the 32-bit version. Hopefully they'll also provide some kind of migration tool that can help programmers pinpoint areas in their source code where there's potential issues (e.g.: assigning the value from a function that returns a 64-bit value to a 32-bit variable, etc.)
José,
I am well aware that we are a minority ;D
But when i write "why the heck, should we always be left behind", i also mean "left behind C programmers" as they are living in the 21th century since 10 years...
I have moved to GDIPLUS 8 years ago, then DWM/GPU with VISTA, and now Direct2D with Seven, thats a mandatory for the niche market i have selected.
In today's programming the standards are not anymore those of the 20th, and modern compilers must comply with the new fundamentals.
When you are a small company, "comply", also means to take the good decisions and avoid to spend your limited resources with the past, and leave everything that is not the heart of your job to third party addon.
For example you have done a tremendous work with your "include files", you have written the excellent "TypeLib Browser", there is SED or UltraEdit, there are 3rd party form designers, etc.
However there is only one good basic compiler: PowerBASIC, and this is why i am so upset!
...
Quote from: José Roca on June 15, 2010, 01:28:15 AM
Quote
@Jose: Do you think it will be possible for a smaller Company like PB.inc to develope at the same time two product lines for 32 and 64 bit?
I don't know.
PureBasic does it:
- Windows 32bit and 64bit
- Linux 32bit and 64bit
- MacOSX both Intel and PowerPC
As far as I know PureBasic is a very small company.
Maybe it all depends on the development environment used to develop the compiler. Can it be?
While they *are* making really work about their compiler imo Purebasic introduces new bugs as well.
I mean i often read about things which 'break', imo that is a serious no-no, in fact i consider that the most important factor for reliability.
They do fix it but that's not really the point, that's just good but it seems to happen to often.
There's is another topic going on here about bare bones compiler.
To me, PureBasic and PowerBASIC both make the same mistake, especially PureBasic introduces a large amount of new features, there is no 'bare bones' to find here.
PowrBASIC's DDT is also a thing we better shouldn't have imo.
It distracts the soul purpose, being SDK..
If PowerBASIC simply added a default windowclass most stuff would be ready to go, simply the register windowclass parts was the annoying part.
CreateWindow() vs Dialog Create and an ordinary windowproc.
Hmm, maybe a wrapper for a default messagepump to help us a little would also nice but that's it!
I understand, it wouldn't be possible to get money from a compiler which has no need for updating, for us SDK fokes it would be the nicest thing to have.
Simple and only with very basic commands like Str$() and Maybe a Parse$(), don't know.
All the other nonsense can be done via api, once provided via an include.., everybody happy.
I can be with you but the point was:
"Do you think it will be possible for a smaller Company to develope at the same time two product lines for 32 and 64 bit?
The answer is yes if it wants. If I'm not wrong, Purebasic is developed nothing more than few persons (maybe one, Fred ???)
And the other consideration is: what compiler is used to compile my compiler? Can this influence the time to market?
I mean, if my compiler is 100% developed in ASM, I'm pretty sure my time to market cannot be that fast and I have to consider twice or even more before making such a huge move.
QuoteWe now have an answer, Tom Hanlin just wrote on the PB forum:
Thank you for the heads up. One can only hope that the long awaited Linux version is one of those "projects" that Tom is referring to.
QuoteAnd why the heck, should we always be left behind.
You can answer this yourself, Patrice. The answer is that
they managed to clone the sheep named "Dolly" but it didn't work with humans until now. Even then
they can not start programming right out of the box. ;D
QuotePureBasic does it:
Windows 32bit and 64bit
Linux 32bit and 64bit
MacOSX both Intel and PowerPC
As far as I know PureBasic is a very small company.
Maybe it all depends on the development environment used to develop the compiler. Can it be?
If i need to do something in x64, then
Purebasic 64 is actually what i take.
Its very moderate in price and after all works.And i would say its now much better then it was Years before.
But then ... no GOSUB .. see my articles on this topic here:
http://www.jose.it-berater.org/smfforum/index.php?board=381.0
Purebasic - for me - is only a time-sollution until i get the thing from Bob.
The Purebasic developer Fred, has many people to work with him and for him.
This leads to a high innovation rate.
My impression is, that they develope the thing a bit in direction of a "Game-Basic".
3D Engine and such stuff. I personally don't need this.
The Compiler has a 100% different structure compared with Powerbasic.
This enables it to be ported to LINUX, MAC-OS etc. in minutes.
Its quite something else.
As a result there is no real GOSUB, its just another structure inside.
I am sure there are people out there who will swear on Purebasic,
but once used to Powerbasic its a too big step into another philosophy for me.
QuoteMy impression is, that they develope the thing a bit in direction of a "Game-Basic".
3D Engine and such stuff. I personally don't need this.
The gaming side is mediocre at best. The 3D engine is pretty much useless. Ogre is a decent engine, but PureBasic's Ogre implementation lacks a lot of functionality. This is something that has supposedly been going to be addressed for several years, but like the GUI designer, it is something that never actually gets done. Although I always get flamed for saying this, PureBasic is extremely buggy and they never concentrate on only fixing bugs. Bug fixes always coincide with new features, which introduce new problems (and often break existing features which previously worked fine) and it turns into a never ending cycle.
I still maintain some PureB projects that use version 3.94 which was very stable (also the EXEs were much smaller back then) ;)
Anybody wanting an OS X supporting BASIC, should take a look at
Objective-Basic (http://objective-basic.com).
QuoteSystem Requirements
Objective-Basic requires Mac OS X Snow Leopard (10.6 or higher).
I don't have it at hand ;D
Reminds me that i just like Powerbasic because it works. With windows.
There are just some of these moments when i think "This time it must be the compiler - it can't be My code!"
But then after all it was my code.
PowerBasic is just BUGFREE. Whatever things i do with it.
Quote from: Theo Gottwald on June 25, 2010, 06:57:58 AM
QuoteSystem Requirements
Objective-Basic requires Mac OS X Snow Leopard (10.6 or higher).
I don't have it at hand ;D
Reminds me that i just like Powerbasic because it works. With windows.
There are just some of these moments when i think "This time it must be the compiler - it can't be My code!"
But then after all it was my code.
PowerBasic is just BUGFREE. Whatever things i do with it.
I agree Theo. While I do code with a number of basic languages in the Open Source community I would NEVER use any of them for a paying contract endeavor.
James
I think we all agree on this, and it is the reason why i am using it in my commercial addons. ;)
Nonobstant, it should not sleep on its laurel ;D
...
Quote from: Theo Gottwald on June 25, 2010, 06:57:58 AM
Reminds me that i just like Powerbasic because it works. With windows.
There are just some of these moments when i think "This time it must be the compiler - it can't be My code!"
But then after all it was my code.
PowerBasic is just BUGFREE. Whatever things i do with it.
I agree and is why I use it. The only bug I ever encountered with PB was fixed quickly. Although there are some features I wish PB had, I honestly have no complaints with PB itself. It is the best ;D
That said, I have been struggling with how to do two things in PB for the past few months and I just can't figure it out. It is to the point, I am considering moving these projects to another programming language. :-\
Quote from: Brice Manuel on June 25, 2010, 06:21:37 PM
That said, I have been struggling with how to do two things in PB for the past few months and I just can't figure it out. It is to the point, I am considering moving these projects to another programming language. :-\
Why not post them as questions on the PowerBASIC Forums or send an email to PowerBASIC support?
I want to stress that there is no problem with PB, the problem is 100% me not knowing/understanding how to do what I need to do with PB. Unfortunately, in programming for Windows since 3.1 the languages I used were VB, Delphi and C++ Builder. Anytime I used VC++ I was either using the Octopod IDE (which was very C++ Builder-like) or dealing with game engines like Legus3D, LithTech or Twilight3D. This means almost no experience dealing directly with Windows API which is what I need to do as DDT currently doesn't support two things I need for a couple of projects I have been working on and have now ground to a halt.
Anyway, I am one of those "half brain" guys so I guess the half of my brain that is missing is the half that has the solutions ;D
QuoteI think we all agree on this, and it is the reason why i am using it in my commercial addons.
In my spare time, I have been playing around with rewriting something in PB that I originally started in EB but never finished due to it being too slow. So far the results in PB are beyond amazing.