When the release notes contain hundreds of notes, it's pretty easy to miss out on some interesting items. I tend to enumerate the big ticket stuff in a "what's new in XXX release", but I'd like to try pointing out some of the little fixes which slip into a release. Think of it as a condensed version of the release notes. It's also fun to expound on some of the bugs a little bit to make them more personal and less...well.. "marketing related." :-P
- SaveAsMactintoshPICT and SaveAsMactintoshRasterPICT are deprecated now. Can you guess why? No, it's not because I'm on a kick to destroy the Mac. It's because they're misspelled! For those who prefer to use a Macintosh instead of a Mactintosh, you can use the new variants instead. This isn't the first time we've spotted a typo many years after releasing an API. For a good, long while we had DisabledBallonHelp.
- You can now view most arrays within structures in the debugger. For instance, if you had a structure named Foo which contained i( 10 ) as Integer, you were never able to view any of the values of i, but now you can. This isn't perfect, since you cannot view arrays of structures or strings within a structure, but it's much better. The debugger's structure viewer is really complex code, and trying to view arrays of strings or other structures if actually extremely difficult. It'd be easier to just refactor the way structures are dealt with instead and start over.
- The ComboBox.TextChange event got some love on Windows in that it no longer causes infinite loops if you're messing with the ListIndex. Also, manually setting the Text of the ComboBox now fires the event on Windows so that it matches the behavior on other platforms.
- Serial handshake lines can now be read properly on x86 OS X and Linux. This was a goofy issue where the code was functional, but only on PPC Mac. You can probably guess that it was an endian related issue.
- Types within classes are now inherited properly. In layman's terms, this means that you can now define a type within one class, and use it within a subclass. This was a silly bug that didn't get caught until 2008r3.1 was already out the door, but was the last remaining bug (at least, that I know of!) related to the new types within classes functionality introduced in 2008r3.
- Variants and arithmetic operators now play nicely together. It used to be, if you pushed an integer into two variants, the And, Or, Not and XOr operators didn't behave intuitively with them. They would convert the variants to booleans and then perform boolean operations on them. Now, if both operands are integers, they perform an arithmetic operation instead. To make matters even more entertaining, the XOr operator for variant used to just call through to Or, so it didn't even get it right for boolean operations!
- Run Paused is now always on, instead of only being available if you knew the magic dance. I spoke about this feature before in the context of debugging plugins. But you can also use it as a way to copy support files into a folder or bundle in order to debug your application as well.
- You can use comparison operators with arrays, so that you can now compare an array to nil. This might not seem to interesting, but consider the following code:
Function Foo() as Integer() End Functiondim i() as Integer = Foo
In that case, i is actually Nil, not an empty array. So if you attempt to operate on i, you'll get NilObjectExceptions. Nothing else in the language forces you to use try/catch blocks to prevent NilObjectExceptions, and so arrays are no longer the odd-man-out. - Bob Delany's excellent Decimal Plugin now compiles again. Not much more to say on that one. :-P
- Loops had a very nasty memory leak, which appears to have been there for quite some time. If you used a Continue statement within a for loop, then any objects declared and allocated within the loop were leaked. Basically, the finalizers were never run for those objects because continue was jumping right over them. You would think that this would be easy to fix, but it was actually quite difficult. The flow control subsystem wasn't in charge of generating finalizers, but it was in charge of generating continue labels. The general statement subsystem was in charge of generating finalizers (but not continue labels). So there was a bit of dissonance there which needed to be rectified. The final result is that continue statements in loops no longer have nasty memory leaks.
- You can use codesign on OS X applications. It took several days worth of work to make that simple statement true. :-P Mach-O has the least amount of documentation of any executable link format on the planet. It's also a file format that was designed before I was born. In fact, I think the people who designed the file format died before I was born, that's how old it is. We didn't have enough magical padding in the files we created, and so the codesign utility couldn't do its job. What annoys me the most about this is that every Mach-O application is expected to have blank space on the off-chance that someone will want to sign it. Otherwise, the code signing application might have to do some extra work, and we wouldn't want that, now would we? :: sighs :: Oh well, it works and yay for that!
Of course, there are plenty more bug fixes that I didn't list today, all of which can be found in the release notes. If you go to the installation directory, in the Documentation\Read Me folder, you can check them out for yourselves. Enjoy!
I miss the days when the release notes told you what was new, deprecated, fixed, and what platform(s) it was for using the funky [notation]. It made some of this easier to spot. Yeah, I know I can ping each one in FogBugz but there were a FEW things about the old release notes that made them easier to use. During beta testing I used to search for [new] and test those things specifically ('cause QA at the time was pretty shaky).
Just my 2 cents worth. Gosh I'm starting to sound old. "Back when I was your age...."
Great update about the new release!
While I probably wasn't around when the Mach-O format was invented I just want to rant about the "Digital Signature" of Microsoft that also seems like a last minute add-on.
I recently got a user complaining about my application crashing when launching and I asked him to check the Digital Signature tab by going to properties dialogue of the EXE. I was a bit surprised to hear that tab wasn't there! Checking the file size I realized that half of the file wasn't downloaded and thus the signature was simply gone... While Microsoft EXE:s doesn't need any magic padding or placeholding, they simply add the signature to the end of the file and if truncating the last part of the file you don't have a signature. If there would have been a mandatory placeholder for this (as in Mach-O) it would have made my life simpler...
/msa
@Mattias -- actually, the digital signature in PE32 is part of the optional headers structure at the start of the file. It's not appended to the end of the file. When I take a signed file and chop half the file off, I still get the Digital Signatures tab, and when inspecting it, I see the signature isn't valid. Your application would have to be chopped off by a *lot* to lose the signature from the header.
For more information about how digital signatures work for PE32 files, check out this well-documented resource from Microsoft: http://www.microsoft.com/whdc/winlogo/drvsign/Authenticode_PE.mspx
@Aaron - - (with the risk of getting too far off-topic), my tests on Windows XP SP3 (might as well be that this is different in Vista) on my signed RB app (compiled with RB2007r5 and signed with signtool.exe from the Microsoft SDK) shows that the Digital Signature tab in Windows Explorer Properties window disappears when removing the last 6 kB of data from the file (the signature seems to be padded with lots of zeros after the end of the RB application) and at the very end of the file the signature is identifiable by the company names.
Testing with the RealBasic 2007r5 EXE and cutting everything off from pos $179E710 to the end of the file removed the signature tab but the application still works (showing the need of a good and cross-platform way to check the signature from within RB without the need of external DLL:s or chktrust.exe etc - maybe a good feature request...). However, Trend detects the DLL injection at startup and warns as the EXE is no longer digitally signed, but Windows XP does not complain.
Feel free to contact me "off-blog" to discuss further so your post does not go too much off-topic...
Cheers,
/msa