Announcement

**Joe Byrne** · 7 Apr 2008, 10:57 AM

Originally posted by Ralph Brereton View Post

...So I pressed the nuclear button, and switched to PB.

Good move

... Also, for my main application, PB turned out to be no faster than VB6 (that was a disappointment).

I'm sure that's possible, but I'm willing to bet that the process can be re-written to make the PB version much faster. Possibly not, but this type of thing happens a lot.

So, I'm getting uneasy about PB and fixed length strings. How long before the Microsoft operation system somehow prevents them ? Does anyone out there understand operating systems enough to know whether that would be feasible ? Could MS put the skids under PB ?

MS can do a lot of things, but the chance that you'll wake up one day and find PB has abandoned fixed length strings is minuscule at best. Of course, only PB can say with certainty, but my 25+ years around PB proves to me that they are very careful to keep backward compatibility a high-point of their design. Even small changes that could effect existing code is rarely, if ever done, and then not without some pretty clean methods of dealing with it.

**John Strasser** · 7 Apr 2008, 11:02 AM

I don't see how they can. Especially since *every* variable type is technically a fixed length of a specific # of bytes.

Somewhere under the hood they have to allocate a block of memory for everything.

I'm curious about the lack of speed difference though. If you don't mind - were you using lots of external (non-pb) dlls? Or working across a network (which could slow things down) or doing lots of hardware related (such as screen graphics/refreshes) work?

**Fred Harris** · 7 Apr 2008, 11:09 AM

As far as I know the original Windows Api still uses fixed length strings, i.e., string buffers. They are the lowest common denominator in many types of programming in C, C++, and assembler. Unless the entire operating system is re-written in .net (and I can't understand how that could be), I expect fixed length strings are here to stay.

But in terms of the programming world being taken over by .NET and 'managed code', I always assumed that would happen. Surprisingly though, 'unmanaged' code still seems to be around yet. Just the other day I got a notice from anazon.com about a new book by (I believe) Jeffrey Richter that was about straight Win32 systems programming using the Api. In my field (forestry) we just recently received the Forest Service's new version of an important program we use and I believe it is a MFC C++ written program. So I guess there are still some holdouts besides you and me.

**Kev Peel** · 7 Apr 2008, 11:23 AM

Fixed length strings are language-defined, so the OS has no bearing. Nada.

Not sure about fixed strings in .NET, I thought they were supported? I can see why though - it would prevent most of those buffer overruns that hackers like to exploit with worms and such.

**Michael Mattias** · 7 Apr 2008, 12:24 PM

The only difference between a PB fixed length string and a PB ASCIIZ string is where the valid data end. With an "ASCIIZ" it ends at the first $NUL, with a "STRING * nn" it ends exactly 'nn' bytes after it starts regardless of content.

Plus you can specify ambiguous-length ASCIIZ, but mostly when working with the WinAPI you have to pass a separate 'max length' parameter anyway.

MCM

**Marco Pontello** · 7 Apr 2008, 12:34 PM

Originally posted by Ralph Brereton View Post

Then suddenly, and without consultation (as far as I know), Microsoft screws up my entire industry, and probably most others, by abandoning fixed length strings. Their suggested alternatives (e.g classes with the instance adapted to fixed) are without exception just plain messy.

Can you explain better?
I mean, I'm pretty sure I have coded things in bot PB & VB.NET/C# that accessed the same files, that "PB speaking" where based on a Type with various fixed len strings, without encountering any serious issue.

Bye!

**Fred Harris** · 7 Apr 2008, 01:00 PM

I mean, I'm pretty sure I have coded things in bot PB & VB.NET/C# that accessed the same files, that "PB speaking" where based on a Type with various fix

You're right Marco. There is some strange attribute that has to be set though in the .net structure declaration, but I can't remember it exactly, and I just looked for it in some of my vb code but can't find it. Its something like...

<attribute fixed>

or something like that, and one can access the strings like in PB/VB6, etc. I'll keep looking for it.

Just found it in .NET help...

Code:

Structure Person
   Public ID As Integer
   Public MonthlySalary As Decimal
   Public LastReviewDate As Long
   <VBFixedString(15)> Public FirstName As String
   <VBFixedString(15)> Public LastName As String
   <VBFixedString(15)> Public Title As String
   <VBFixedString(150)> Public ReviewComments As String
End Structure

and one from a program of mine...

Module modGrid
  Structure TimberSale
    Public iDist As Int32
    Public iYr As Int32
    Public iNum As Int32
    Public iType As Int32
    <VBFixedString(48)> Public strBuyer As String
  End Structure
End Module

These structures should let you interoperate .net with pb.

**Cliff Nichols** · 7 Apr 2008, 04:44 PM

Does anyone out there understand operating systems enough to know whether that would be feasible ? Could MS put the skids under PB ?

I think I know enough about operating systems (and I am just barely scratching the surface) to respond with a resounding NO

Unless M$ re-writes from the ground up (and I do not mean Vista style of "ground-up") then the core dll's will always remain. (Now how the dll's are accessed may be a bit different, but not the core)

M$ putting the skids on any programming language would be like re-inventing binary, and forcing everyone to use 1's and 2's instead of 0's and 1's and would be out of business in 6 months from the lack of software programmers changing, not to mention EVERY Hardware programmer I could think of. (Imagine not programming hardware in assembly and binary?????)
Turning on your TV would take 5 minutes to turn on, because all the bloated code to process the signal instead of instantaneous power-up

**Ralph Brereton** · 8 Apr 2008, 05:26 AM

Yes, I know you can handle fixedlen strings in VB.Net using code like this.
<code>
<VBFixedString(48)> Public strBuyer As String
</code>
But I'm pretty sure that is just a temporary arrangement to help us keep code running. I guess "VBFixedString" will be removed when MS thinks we've all had enough time to learn how to program "properly" - which means classes and instances as I said before. If you look at MS pages teaching newbies how to program you'll find "VBFixedString" is never mentioned. It turns up only in pages on migrating from VB6, and even those pages are becoming increasingly hard to find.

Perhaps Kevin Peel's logic is the reason why MS seems to be turning its back on fixedlen strings. Does it follow, Kevin, that PB can get away with fixedlen strings simply because hackers will not bother with a minority interest like PB ? To escape hackers I tried the minority interest Firefox, but went back to IE7 because too much purchased software didn't want to know about Firefox. So you see that's another area where I tried to buck the trend - and failed.

John Strasser is curious about me finding no speed improvement with PB. As he guessed, I'm using a lot of graphics (stock market charts with plenty of indicators), and, before you all ask, yes, I'm using REDRAW. In addition, I work quite hard, AJAX style, at recalculating and redrawing the absolute minimum when the user changes an indicator. To be fair, even in VB6 the charts refreshed so fast that if PB is indeed quicker it may be hard to detect visually. Even so, I'm pretty sure there is not "an order of magnitude" improvement in speed. You get a feel for these things when you live with a program for years. When I have nothing more urgent to do I shall set timers in VB6 and PB to establish the percentage improvement.

In conclusion, you have all convinced me that PB fixedlen strings are here to stay. That being so I shall stick with PB because in my field of work fixedlen strings occur naturally over and over again. You can incorporate them into fixedlen records and they, too, make life easy. Programming is fiddly enough without complicating it unnecessarily. Thank you all for sharing your opinions. It helped.

**Michael Mattias** · 8 Apr 2008, 08:17 AM

>John Strasser is curious about me finding no speed improvement with PB.

But what was done to the program to take advantage of the new compiler?

While you "may" get some improvement in generated code with 'verb-for-verb' translation... that is, changing the program only enough to get it to compile and run, that cuts both ways: e.g., there have been multiple posts here over the years re how some Microsoft-compiled program 'out-performs' the same code when compiled with PB. (I believe this happens with doing lots of stuff with either really long or really short dynamic strings? Or maybe it was with 'do-nothing' loops adding single-precision variables? It was something totally dopey, anyway)

The two competing publishers optimize their compilers for what they believe to be the most common situations, resulting in the best performance "overall." With different assumptions about what is the "most common" circumstances, you'd have to expect that under some conditions one compiler will generate faster code, under other circumstances the other compiler will do so.

All optimization is application-specific. (I think I've heard that before).

MCM

**Bob Zale** · 8 Apr 2008, 11:09 AM

Ralph--

You weren't promised that PowerBASIC graphics would run an order of magnitude faster than VB or anything else. We would never make such an outlandish claim.

All graphics in Windows are processed through the Win API. That means that 98% of the elapsed time is spent in Windows, regardless of the programming language.

Best regards,

Bob Zale
PowerBASIC Inc.

**Kev Peel** · 8 Apr 2008, 11:27 AM

Perhaps Kevin Peel's logic is the reason why MS seems to be turning its back on fixedlen strings. Does it follow, Kevin, that PB can get away with fixedlen strings simply because hackers will not bother with a minority interest like PB ? To escape hackers I tried the minority interest Firefox, but went back to IE7 because too much purchased software didn't want to know about Firefox. So you see that's another area where I tried to buck the trend - and failed.

Wow you sound like a judge, or a lawyer

I was talking about .NET which is a Microsoft product, and yes they ARE "shying away" from fixed length strings in .NET. Another thing that is made harder to support is memory buffers - you longer have (easy) access to create a pointer to a memory block (there is another layer of "vitualization") so you need to use "marshalling" or other methods to pass a memory (byte) pointer.

Even with Visual Studio, in recent versions the standard C libraries were changed so a length parameter must also be passed when working with strings (example: strcpy_s), this is to prevent the overruns commonly exploited. In my PB code, I also use this approach.

**Ralph Brereton** · 8 Apr 2008, 01:52 PM

Sure, Bob, you never promised anything about PB speed, and I wouldn't expect you to. It's everyone else. Lots of people talk about PB speed, so you get to expect something surprising, then feel disappointed when you don't get it. That's human nature. Even judges and lawyers suffer from it. Your point about graphics spending 98% of their time in Windows explains why I didn't see much difference. Thank you for that.

Michael, nothing was done to take advantage of the new compiler. Just for now it's enough to get the program running at all. Perhaps, though, you'll be interested to know that for the last week or so I've been turning things over in my mind. Already I can think of things to do. I'm not sure which to do first. There are two main areas. Data structure could be improved to read as little as possible from disk, and a fair amount of data manipulation could be changed from SINGLE to LONG. Unfortunately both lines of attack will complicate the code, and I like straightforward code because it's robust, and because ten years later you can still understand it. Anyway, no one ever complained about the speed of the VB6 version. It is one of the fastest stock market charting programs I've ever seen. (But if you go to www.prorealtime.com and get yourself free access you'll see what must be the fastest web based version. I have no idea how they do it, and I'd love to know.)

**Knuth Konrad** · 9 Apr 2008, 06:39 AM

Originally posted by Ralph Brereton View Post

Yes, I know you can handle fixedlen strings in VB.Net using code like this.
<code>
<VBFixedString(48)> Public strBuyer As String
</code>
But I'm pretty sure that is just a temporary arrangement to help us keep code running. I guess "VBFixedString" will be removed when MS thinks we've all had enough time to learn how to program "properly" - which means classes and instances as I said before.

Now, isn't that basically identical with

Code:

Public strBuyer As Char(47)

In a lot of languages, a string is often also an implicit character array. I'm not too experienced with the .NET Framework, but I'm sure there's an UNION equivalent as well and/or easy methods for casting a string to a char array and vs.

**Gary Barnes** · 9 Apr 2008, 08:06 AM

Hi Ralph,
I don't know how relevant this might be to your application, but I have found that using a memory based bitmap ie "GRAPHIC BITMAP NEW ...", drawing to that, then copying it to the screen after updates can offer a speed improvement in some cases.
When I have a screen that is composed of several distinct elements, say various views of a graph, it is often convenient to update them all as separate off screen bitmaps, copy them to the display then perform a graphic redraw.
It is a similar technique to what is often used in game programming where you draw the entire screen in an off screen buffer, then flip it into view.
I hope that this was helpful.
Regards

**Brian Chirgwin** · 9 Apr 2008, 08:21 AM

Originally posted by Ralph Brereton View Post

So, I'm getting uneasy about PB and fixed length strings. How long before the Microsoft operation system somehow prevents them ? Does anyone out there understand operating systems enough to know whether that would be feasible ? Could MS put the skids under PB ?

I wouldn't worry about it. If nothing else string could contain trailing spaces.

Dim s as String
s = s + Space (30 - len(s))

There would be a performance penalty having to do this, but MS can't prevent it. Well, I guess they could force removal of trailing spaces, but this would change the intent and results of the program. Even if MS did do this, there would always be a way around it.

**Paul Dixon** · 9 Apr 2008, 08:44 AM

I'm getting uneasy about PB and fixed length strings. How long before the Microsoft operation system somehow prevents them ?

Operating systems will always be required to allocate memory to applications that ask for it otherwise you could never write applications. What the application then uses that block of memory for internally is entirely up to the application programmer, not the OS programmer. A block of memory could be used to store an array of numbers, a fixed length string, a bitmap, a buffer for COM port data or many other things. If PB decides that fixed length strings should be maintained, then they will be.

Paul.

**Michael Mattias** · 9 Apr 2008, 08:53 AM

> wouldn't worry about it. If nothing else string could contain trailing spaces

IIRC, PB compilers a treat simple assignment to a fixed-length string as "LSET USING $SPC"
i.e.....

Code:

  LOCAL  X AS STRING * %SOMENUMBER
  LOCAL  Y AS STRING * %SOMENUMBER
  X        = "X"   ' simple assignment
  LSET Y = "X" [USING $SPC] '  "USING $SPC" is the LSET default

.. will result in X and Y both equal to "X" & SPACE$(%SOMENUMBER - 1)

MCM

Announcement

Fixed length strings; their future

Fixed length strings; their future

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment