Support for Ascii compilation ends after the next LTS cycle

[WilliamL]

Wow, talk about not being able to please everybody!

I'll tell you what... Since Fred wants to do unicode then I suggest he make a new version and charge $100 for it. Those that don't want unicode can use the old version and the rest of us can make the donation we should have been making over the last 10 years.

[Rescator]

Are you addressing Fred and Freak here too? C'mon already, they admitted it was a large piece of work to convert the IDE recently to Unicode and there is not full acceptance from some of the UTF8 fans.

If I where addressing them I would address them directly, and I did not, so I did not.

Why Freak waited so long to change the IDE you have to ask him about, maybe they'll do a blog post talking about that and sharing some of the experience so that other programmers know what to keep an eye on when updating their code from Ascii to Unicode etc.

I am accepting of the Unicode compile only, but please stop the dismissal of its impact to users with lots of code to convert and debug.

How can I dismiss something I've dealt with myself at various points?
Besides, nobody are forcing them to "convert or debug lots of code", they only need to do that if they want to compile using future releases of PureBasic.

As long as v5.30 (and most likely 5.40 now too it seems) is able to compile programs and run on Windows 9 and Windows 10 and probably Windows 11 (but I doubt x86 will work any more on windows by then including the x86 IDE).
v5.30 will etc will work for many many years until MicroSoft does things that causes PB 5.30 to no longer work.
Now if people are nice about it, who knows, Fred might be bribed with enogh beer one day to re-compile PB 5.30 to work with Windows 12 when that day comes (5 years from now?) so that the ascii folks can keep trying to fix the bugs in their old ascii enterprise software that runs on erm, Windows XP still?

There are still people out there programming with Visual Basic 6, even though MicroSoft abandoned that years ago, but that doesn't prevent people from programming in VB6.
It's the same with PureBasic, use the current/ascii version, it will work fine. And now with a possible extra LTS and thus a lot of polishing (but no new features obviously) it will be super solid. It will probably work fine for another 10 years on it's own. (provided MicroSoft doesn't prevent it, you know x64 only Windows is on the horizon, it has already happen with the Server editions.)

Does certain people here have an axe to grind? It certainly seems that way.

I can only suspect it is you given the depth of your posts on this subject.

Yes and no. If there is a bus heading for somebody and I shake their shoulders and dasy "look out a bus is coming towards you" and they laugh and wave me away, then fine, I'll walk away, but don't blame me when that bus hits you (unicode).
Because x86 may not be the only thing MicroSoft may drop support for in future Windows releases. They too have a shit-ton (that's a metric ton of shit BTW) of double code (unicode and ascii wrappers to that unicode) I'm pretty sure they'd love to get rid of the ascii fat. And that may actually happen sooner than we might think. It won't matter if PB x.xx supports ascii compiling or not then as the compiled ascii programs won't run on latest Windows anyway then. (by that I mean that all the API calls that have the A at the end will go poofelipoof.)

Just like with the old 16bit stuff. Anyone ever run into 16bit installers (for x86/32bit software) that failed to run because 16bit exe was no longer supported? That was a huge pain to deal with, bunch of old no longer maintained software used 16bit installers for some odd reason.

[Rescator]

Wow, talk about not being able to please everybody!

I'll tell you what... Since Fred wants to do unicode then I suggest he make a new version and charge $100 for it. Those that don't want unicode can use the old version and the rest of us can make the donation we should have been making over the last 10 years.

Outch a tad steep pricewise for me (I'm halfway living on the street these days so...)
But the idea is not that horrible. But maybe bump the version number to 6 instead and let 5.x be the end of the ascii era.
So maybe turn 5.30 into 5.30 LTS, then change 5.40 version into 6.00. (maybe add in SSE2 and SSE3 code for x64 as well)

If the price is right I would probably pay for that privilege indeed.

[WilliamL]

Well, $100 is just off the top of my head but if you figure it's worth $10 a year then that is about right. How about $10 off for every year you DIDN'T own it over the last 10 years? (if you see my point)

Yeah, version 6. It's time Fred got some real love ($).

[luis]

And I mentioned this before but I think wxWidgets on Linux uses 32bit characters

Yes, UTF-32, didn't know that.

So yes, I think it's a good idea to keep the code still flexible and to not make assumptions about the sizes involved.

Thanks for the reply.

[LuCiFeR[SD]]

@heartbone <deep breath> hahahahahahahahhahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahhahahahahahahahahahaha.............. </deep breath> and in the words of Forrest Gump "that's all I have to say about that!"

[ozzie]

I didn't contribute to the previous discussion re dropping Ascii compilation, but I'd like to record that for me this is no issue. I was 'forced' into converting my program to unicode some time ago so I could support text and file names that contained non-Ascii characters. That conversion was fairly straightforward. Apart from setting the 'create unicode executable' compilation flag, I mainly just had to search for all PeekS, PokeS and ReadString commands and examine what I was doing to determine whether or not they needed the #PB_Ascii flag.

[marroh]

Odd logic, i need the feature to build ASCII exe, this is fact for me. Pointless to to discuss it, that you and other should accept.

Then keep using 5.2. Or 5.3. Or 5.4, all of which will support it. And possibly even more versions.

No thanks, sometimes it is better to pull the ripcord, I'm doing this here and now.

[staringfrog]

Personally, I don't see much trouble in leaving ASCII compiler behind as time goes by, especially if this would mean Fred and team concentrating on the general language development (and not only on promoting its 3D Gaming aspects). Enhancement of built-in data collections and sorting procedures for non-Latin languages, for one. Really, Fred, I still believe you are not ignoring such requests and nix ASCII compiler primarily for the sake of improving the language productivity and flexibility, and not just because you can't be arsed to support it any longer.

However, I must beg to differ on many of your arguments here, guys. First, ASCII isn't petering out soon (just consider the bulk of information that is being stored in pure ASCII around the globe), let alone x86 processors themselves, no matter what Microsoft announces or might announce in the nearest future. What is more likely, the 32bit systems are taking their hardware niche, and are there to stay for years to come. It's like many still choose to install 32bit Windows XP or Seven on weaker portable PCs, for speed, hardware\software compatibility, and all. Second, PureBasic is still 'a great language for small applications' (as someone had described it years ago), and many of such applications (including those communicating with serial ports etc) need nothing but the good old ASCII compiler. And third, taking extra charges for a new blend of PB, as some suggest here, would definitely contravene the PB license. Thus, developing various brands of PB (like, for example, for windowed and full-screen applications separately, or something like PureBasic3D, or some special release with legacy ASCII compiler, or whatever) might be of certain convenience, but it imposes an unnecessary juridical complexity, at the same time.

[Foz]

This makes good sense - we all have 3 years! to change and update our software.

Introducing Unicode at the next LTS would be too big a change too soon for some people, so this decision is a very wise move.

This means that gives Fred & Co a lot of time to resolve bugs, as well as a community, we can help solve issues with each other.

Instead of quibbling, lets all show some solidarity here. If something is complex, harder or worse when in Unicode lets combine our strengths and resolve these niggles.

Lets work towards helping PureBasic be the best it can be.

[PMV]

Why confuse things?
I acknowledge that you think it is wrong to have different concepts, and the betas are better nowadays.

I think there is a misunderstanding. I mean in the past, for maybe 3
years and more. For example the first 4.00 ... and even 4.01 ... for
me they where near to unusable. New features where always unstable
in the first "final" release. That was ok as not enought people had
there hands on it to get all bugs reported. But now, for example 4.30.
You can use the new serialization stuff (JSON, XML) and there is just
a small chance that there is a bug ... that will prevent you from using
it. That counts for windows, linux and mac.

Yes. And they are good in keeping the Windows® version fixed.

And still there are many bugs on windows.

What you have posted here is certainly true, especially if you exclusively program in Windows®.

The problem for linux is, that there aren't so many people using it.
I don't mean the overall number of people that has linux installed.
I mean the small amout of people who are using linux with pb.
As more people are reporting bugs as more stable it will be.

And i plan for the future, to get my hands on linux, too.
... so it is not that i don't care about linux.

MFG PMV

[infratec]

Maybe a stupid question:

Why not UTF-8 instead of unicode

On 2 of 3 platforms UTF-8 is the 'standard' if I'm right.
And with UTF-8 you have no problems with ASCII (below 128).

Bernd

[wilbert]

Why not UTF-8 instead of unicode

UTF as an internal representation would be slow I guess.
When you need for example the Mid procedure, you always have to go over the entire string to find the start position of a substring even if the length of the string is known.
With UCS-2, you quickly can calculate the starting position since every character occupies the same amount of memory.

[Rescator]

Per wikipedia Linux moved to UTF32 (not exactly the same as UCS-4) some time ago.
And Windows moved to UTF16 which Windows 2000 (not the same as UCS-2 which NT4 and earlier supported).

Just in theory UTF-8 and UTF-16 have similar overhead, the advantage though is that with UTF-16 the majority of the most common characters fit within 2 code points.

In unicode you have unicode points and then you have code points (how they are stored) on Windows UTF-16 code points are 2 bytes, but 4 bytes may be needed for more obscure characters. (Unicode even has Klingon O.o)
By this I assume that a UTF-16 string will never be 3 bytes on Windows for a character, but 2 or 4.
On Linux it may be 1, 2, 3 or 4 bytes (even for UTF-32) as some implementations may strip unneeded leading 0's.

[Lebostein]

In my opinion the 3D engine can be removed from PB! This means that less code has to be maintained.
What reason is there to provide the commands for ONE of many 3D engines?