Delphi 2005 Update 1

Merry Christmas... or as my son likes to say, “Happy ChrismaHanniKwanzica” :-)... Anyway, the Delphi 2005 Update 1 is now out.  You can get it from the registered users site.  This should address a lot of the various memory consumption issues some folks were encountering.  We do potentially have a second update in the pipeline, however the timeline for that has not been established.  With the release of C++Builder open letter, a lot of our schedules are in a state of flux at this point.  Once the holidays are behind us, we will be able to truly begin to nail down the plans and schedules.  .NET 2.0 is on the horizon and is a very important release for us as well.  We can ill afford to derail that effort, so careful planning an consideration has to take place.

Delphi 8 Update 3 now available

It is listed as a “public beta” for now.  It is available by following this link to the Borland Developer Network.  Be sure to read the article as this is a breaking DCU change, which means that if you have components for D8 for which you have no source, you will need to go back to the supplier to get an updated set of binaries.

"Who's on first" and MS Support...

Seems my post about calling MS tech support has been compared with the old Abbott and Costello “Who's on first” comedy routine.  While that old comedy routine is certainly one of my all time favorite bits (in fact, I chuckle each time I even think about it ;-), I don't think that my post is even in the same league.  Abbott and Costello are true comedic legends.  I'm just some dude at a software company...with a mild sense of humor.

My take... The Borland C++Builder Open Letter

The Borland C++Builder Open Letter

It's here and was posted a day early.  So far the reaction seems to be one of guarded optimism.  Not surprising, really, given all that has transpired for the last couple of years on the C++ front.  For me, personally, this is exciting news.  This is an opportunity to once again work with some folks for which I have a ton of respect. 

Internally, we've all been lobbying (dare I say, pleading ;-) with management to take this step.  We, on the Delphi team, have always held a certain kinship with the C++Builder community, and for good reason;  We've gone through at least four release cycles together, wrestled with binary compatibility and even benefitted from each other's innovations.  In fact, the initial driving force behind the rearchitecting of the IDE into the Galileo codebase was because of the desire to eventually merge the Delphi and C++Builder products into a single, simultaneously shipped, unified environment.  It was not Delphi for .NET or C#Builder that sparked that effort, but C++Builder.

Of course I cannot comment with any more detail than was revealed in the open letter... mainly because, quite honestly, we don't actually know yet.  We are in the midst of planning, scoping, and scheduling the next release of Delphi, in conjuction with the C++Builder team to create a common roadmap.  Whether or not there is an off-ramp on that roapmap for a release of C++Builder sooner than the next Delphi release is currently an unknown.

Hmm... it's a good thing we kept all that C++Builder code warm and on “hot standby” within the Delphi codebase ;-)...  So bring out the fatted calf, prepare the feast!  The prodigal son has returned!

Cool Stuff.

Chris Hesik has some great information about using the debugger in Delphi.  Check out this post on how to manually walk the stack.  Great stuff.

Toronto conference...

Just ended day 1 of the Falafel Developers Conference here in Toronto, Ontario, Canada.  I outlined just a few of the new features in Delphi 2005, Danny covered the .NET fundementals and new language features in Delphi/.NET and Delphi/Win32 and Lino covered .NET remoting and component development for .NET WinForms.  So far, I've enjoyed talking with some of the folks here in Toronto.  I also enjoyed the dinner at Ruth's Chris Steakhouse in downtown Toronto :-).  Thanks, Lino!

Tomorrow will be a part 2 of the What's New in Delphi 2005.  Danny will cover some .NET security fundementals, and Lino will be covering ASP.NET.

Bean spillage..

Danny has finally relinquished some information regarding the upcoming Delphi 8 patch that will resolve the issue surrounding .NET 1.1 SP1.  Also, as Danny noted, he, Lino Tadros and I are here in Toronto, Ontario Canada and will be doing a “launch” style event at the Falafel Developers Conference.  We also did a small user group launch at a local Bay area .NET usergroup.

Toronto, Nov 29th & 30th

Just a quick note.. I presume that there is still time to sign up for the Falafel Developers Conference in Toronto on November 29th and 30th, 2004.  Danny Thorpe and I will both be speaking.  Also, our good friend, Lino Tadros, will be speaking as well.  If you've never heard Danny or Lino speak, now is your chance.  Both are excellent and will be certain to have a lot of great information.  I'll be presenting an overview of Delphi 2005.

MSAA and Delphi

Steve Trefethen has started looking closely at MS Active Accessibility. This is going to be some good stuff...

Demand-loaded component packages in Delphi 2005

Delphi 2005 introduced a new mechanism for handling design-time component packages that allows them to now be demand-loaded.  This allows the IDE to be more intelligent about when and what packages to load and only when actually needed, thus decreasing overall startup time (since D2005 is now three products in one, every little bit helps).  In general the qualifications for demand-loading a package, or a group of packages (which I'll explain in a moment), is very deterministic.  When loading a package the IDE is always analysing the package as it is registering its contents in order to best determine whether or not it is a candidate for demand-loading.  There are, however, a few gotchas that you may encounter that can lead to confusion.  There are a few rare cases where the IDE is unable to properly determine the eligibility of a set of packages.  I'll try and outline and describe the logic which the IDE uses to qualify or disqualify a package's demand-load-ability.

Let's start with a few assumptions.  In Delphi Win32, when you boil it all down, a class reference is nothing more than a pointer to that class' virtual method table.  That VMT is located in the “text” or “code” segment of a given module (.exe, .dll or package).  This is important to understand because it provides crucial information about the location of implementation of a given class.  By using VirtualQueryEx, you can easily determine the actual module in which a class is defined.  Simply pass the class reference to that function and one of the values returned in the MEMORY_BASIC_INFORMATION structure.  The AllocationBase field happens to correspond to that module's HMODULE.  You can pass this value to GetModuleFileName in order to get the fully qualified path to the module that was loaded.

Next, I need to define what a “package group” is.  This is simply a given package and all its dependencies, both direct and indirect.  Say package A requires packages B and C.  The package group for package A contains A, B, and C, with A being the “root” package (ie. the package that caused all the others to be loaded).  Now what's the group for package B?  It's just B.  That is because B doesn't require A, nor does it require C.  Had B required C, then B's group would hav contained B and C.  (of course B or C cannot require A since that would be circular and that is not a possible situation to have).  Of course A, B and C can also exist in another root package's group as well.  For instance, say package D also requires packages B and C.  So now there are two groups, one containg A, B and C and another containing D, B and C with the group roots being A and D.

Now that you understand these two basics, lets start in on how the IDE analyses the design-time packages for demand-load eligibility.  When the IDE loads a design-time package, it will typically “require” various run-time packages that contain *only* those bits needed for run-time use of the components. (you have separated your run-time bits from the design-time bits haven't you?... If not.. that is a discussion for another day ;-)..  The design-time only package is where the actual component and property/component/selection editors are registered.  This is done by calling RegisterComponents, RegisterPropertyEditor, RegisterComponentEditor, etc from within various global procedures called “Register”.  It is important that this always be done within the “Register” procedure in order for the demand-loading to properly function.  See this blog entry.  What the IDE is basically looking for in order to determine the eligibility for demand-loading is that all component/property editor/ etc... registrations are restricted to that package's group only.  If a propertly editor were to be registered that could apply to any component outside the currently loading group, then that group is disqualified from being demand-loaded.  This is an important point.

Internally the IDE creates some datastructures that are filled in while all this “registering” is going on.  So as each component and property/component/selection editor is registered they are cross-checked against the package group.  Remember the VirtualQueryEx trick above?  This is used to determine what packages contain a given component or property/component/selection editor.  If the package is in the group then all is well.  If a reference were allowed to “leak” outside the group, then it could be possible that a component/property/selection editor would not be properly loaded and used when needed.  For instance, say you register a new propertly editor for any property of type TStrings on any TPersistent.  This is a perfectly legal registration, however it would cause your package to be disqualified from being demand-loaded.  Disqualification isn't nessesarily a bad thing.  It may be that you actually wanted to override the Borland supplied TStrings property editor with one of your own design.  It simply means that your package will now always be loaded either at startup or when a project that has it enabled is loaded.

Now what if you want your package to be demand-loaded but it isn't?  How can you tell why it was disqualified?  When implementing this feature, I asked the same questions.  So in addition to the package analysis logic, I also added extensive logging and reporting.  This functionality is also available to you as well.  There are two ways you can turn this on.  One is to enable it on a per-package basis.  You can do this by calling EnableDemandLoadReport(Detailed: Boolean) inDesignIntf from one of the Register procedures in your design-time package.  Pass False to simply get a report of why your package was disqualified and True to get a fully detailed report of what your package registered (which may be useful for many other uses as well).  Once your package is loaded and fully registered, the IDE will create a text file that is the same base name as the design-time package being loaded with the extension .rpt in the same folder containing your package.  You can also enable reporting globally by going to HKCUSoftwareBorlandBDS3.0Package Cache and adding one or both of the following values:  Report=1 or DetailedReport=1.  They correspond to EnableDemandLoadReport(False) and EnableDemandLoadReport(True), respectively.  The cool thing is that you can enable reporting in this manner and see detailed reports for *all* design-time packages that the IDE loads, including all the Borland supplied packages.

There are some cases where the IDE can get confused about what to demand-load.  For instance, if you have a design-time package that requires a run-time/design-time package.  The run-time/design-time package registers some components and the design-time package registers some property or component editors for the components in the run-time/design-time package.  In this case you can do one of two things.  The preferred method is to simply make the run-time/design-time package into a run-time only package and move the component registration into the design-time only package.  The other technique is to call ForceDemandLoadState(dlDisable) from the design-time only package.  Which brings up another new global function, ForceDemandLoadState().  This allows you to circumvent and override the descisions made by the IDE's automatic analysis code.  There may be cases where the IDE, for whatever reason disqualified your package from being demand-loaded, but you feel that it really should be demand-loaded.  You can call ForceDemandLoadState(dlEnable) from a Register procedure in your design-time package.  For more information on this you can see the various comments in DesignIntf.pas.

So your packages are now being demand-loaded, how and when does it actually get loaded?  When an instance of a registered component is created, the IDE will notice that the component is from a demand-loaded package and then load the package “on-demand.”  This can happen by either manually dropping the component onto a design-surface or loading a form/datamodule/frame that contains that component.  What about property/component editors?  All the property/component/selection editors are “component centric” meaning that they always require a live component instance in order to be selected.  Since they are also registered when the demand-loaded package is finally loaded, they too become available.

There is more that the demand-loading logic does, both in what it tracks and how it manages the state and palette filtering logic, but that will be left for another blog entry.

Case Closed...

After speaking with “Bob” from Microsoft Developer Support, it seems that my supposition regarding the implementation of IOleCommandTarget on our ActiveX client site was spot on.  According to them, they were able to debug things from their side and look at the code path surrounding that call to IOleCommandTarget.Exec() and determined that it was in fact directly related to an S_OK return code from that method.  It was also confirmed that the command ID of 66 was in fact a new command ID introduced with the latest patch (KB834707).  What strikes me as odd about this whole thing is that the return code in this case seems backward.  I would have presumed that a return code of S_OK would mean “Sure, go ahead and download the file and don't ask the user.”  Obviously this was not the case as S_OK actually meant, “Ask the user if they want to open the file.”  Unfortunately, I was not able to get a resolution to this problem prior to releasing Delphi 2005 to manufacturing.  So look for a fix to this problem in a upcoming patch... soon.

I know that “Bob” reads this blog since in our last conversation he mentioned that he went to this site (since it was listed in my email sig).  So, “Bob”, if you're reading this, thanks for all your help.  I have to commend you and your support group for their reasonably quick and very proactive response.

IOleCommandTarget...

The IE web browser security dialog mystery may be solved.  I was able to convince “Bob” to take a Delphi build example for them to observe from their end of things.  After fighting with email filters and virus scanners (you know they *really* don't like it when you send a zip file containing an .exe ;-)... I finally got an example of the problem to “Bob.”  You can read about the problem here along with the very interesting conversation with MS Developer support.  Anyway, in my quest to build an example of the problem in C#, I came across the determination that an imported ActiveX control wrapped in a WinForm control is a sealed box.  I cannot add implementations of specific interfaces to the AX container in order to instrument the browser control to the level needed to faithfully reproduce the problem.  This is an area where Delphi/Win32 strips .NET and WinForms to its skivvies!  There is a night and day difference between the ease by which an imported ActiveX control can be enhanced in C# compared to native Delphi... but I digress. 

It seems that our specialized IE web browser wrapper implements IOleCommandTarget.  This was done to keep the control from popping up scripting error dialogs all the time.  Since this same control is also used for the integrated ASP.NET designer, this was a critcal item to control.  It also needed to trap the “New Window.”  Apparently there was a change in behaviour from XP/SP2 and XP/SP2+KB834707.  It seems that right before the security file download dialog is displayed, IE calls IOleCommandTarget.Exec with CmdGroup=CGID_Explorer and an nCmdId=66.  I cannot find *anyplace* where this command ID is documented.  Well, it seems that if we return S_OK from that call, the dialog is displayed.  However if we return either OLECMDERR_E_UNKNOWNGROUP or OLECMDERR_E_NOTSUPPORTED, then that dialog is not displayed.  Now of course, it can be argued that we should have returned the proper error codes for commands we don't support, however it is a change in behaviour exhibited by the control.  Who'da thought that IOleCommandTarget would be involved?

I just (while typing this) got an email from “Bob” so this may about to get wrapped up.

Voting day...

Just a quick note here for all of you that live here in the States... If you're 18 or older and registered to vote make sure you actually make an effort to get out and vote.  That's today, November 2, 2004, folks.  I don't care what your political leanings are, who you like or dislike, the important thing is that you vote.  I have never missed a presidential election since I've been able to vote, and rarely ever miss the lesser local and state elections.  The interesting thing is that this election is shaping up to be one of the most watched from the international community that I can remember.  There is no question that this is a pivitol point in our nation's history.  Voting your conscience is very personal thing, so I don't want folks to start posting comments for or against a certain candidate or issue.  This isn't a political forum, and I won't discuss my personal convictions regarding politics.  The issue here is voting.  Not for whom or against what issue.  If you don't vote you have no business complaining about the outcome.  'Nuf said.

(stepping down off my soapbox)

Just, FYI... I will delete any politically charged comments, whether or not I agree with that particular comment.

Past lives come a haunting...

My previous post reminded me of what I used to do before I worked for Borland.  I've been at Borland for nearly 13 years.  Prior to working for Borland, I designed access control and magnetic stripe reading/encoding equipment.  It was a very small company, Elcom Industries, based in St. Louis, Missouri.  Only about 15-20 employees.  I started as a technician repairing the equipment as it came in for repair and mantenance.  After a while started I learning the firmware code and also the microcontrollers we began using at the time (6801/6803/68701).  Previous systems were, I am not lying about this, based on a 6100 CPU.. For those of you who don't know what that was... it was a PDP8 on a chip!  A 12bit CPU.  What a nightmare!  Here's some more info.  Of course, the 6801/6803 microcontrollers are now considered antiques as well... C'mon... I'm not even 40 yet!

Thank goodness that cheaper, more mainstream microcontrollers were becoming popular. When I took the existing magnetic card encoder hardware and designed an RS232 controlled encoder using a single microcontroller (a 68701) and a couple of support chips, the boss took notice and quickly moved me into engineering.  I went on to do a ground-up redesign of the access control units.  Since this was such a small shop, the engineers did *all* the work for a particular product.  From schematic design and printed circuit board layout to case and enclosure design to the actual firmware.  I had fun and learned a lot.  What is frightening is that this company is still selling the products I designed over 15 years ago.  Here's a couple of links... I hope their site doesn't go down from a small “Slashdot” effect ;-)..

http://www.elcom-ind.com/Magnetic-Stripe-EncoderReaders-.asp

Scroll down a little. The A4ER is the first thing I designed.  It had a single MC68701

http://www.elcom-ind.com/Card-Access-Control.asp

This is the staple of this companies' products.  I had designed the mag-stripe and barcode version.  Looks like they finally added proximity readers... those were the subject of many debates about whether or not we should get into that market or not... looks like they did.  I wonder how much of the firware is still my code.  From the specs it certainly looks like the hardware hasn't changed too much.

Be careful what you title your blog entries..

Apparently metaphors and similes don't translate too well to the web.  When I titled an entry “Shotgun Fix for...” I got the following comment from Jay Cotter:

YOU SHOULD RENAME YOUR SITE BECAUSE WHEN US REDNECKS WANA KNOW HOW TO FIX OUR SHOTGUNS YOUR SITE DONT COME UP AS Shotgun fix for .NET 1.1 SP1 OK TAKE THAT UP INTO CONSIDERATION THANKS FOR YOUR TIME FOLKS

Now, I don't know if this person is actually being serious or not, but nonetheless it is still hilarious.  So, for all you folks looking to fix your shotguns, this ain't the place.  Sorry for the confusion since I was using the term “Shotgun” to refer to a very inexact method of fixing a software issue.  I used this term a lot when I was designing and programming security access control hardware.  When a repair would come in and we couldn't quite narrow the problem down to a specific component, we'd just start replacing all the usual suspects until the problem went away.  This was a “shotgun fix.”  Inaccurate and indiscriminate...  Just like a shotgun with bird-shot at, say, 25-50 yards..

Hello? Microsoft support?

Did you ever wonder if Borland ever has to call Microsoft Developer Support?  Short answer: Very, very rarely.  Not that we are unwilling to ask for help, but we do tend to have enough experience among all the engineers that usually we can figure it out on our end just fine.  A quick trip to visit other engineers down the hall is much more efficient.  Now recently I actually had to break down and have MS support contacted.  The good thing is that we actually have some support contracts in place and have a dedicated MS support “handler” that knows how to direct the calls to the appropriate support staff.  Even with all this in place, we are not immune from a humorous situation...

So here's the problem.  Ever since C#Builder the Galileo IDE (the IDE framework on which C#Builder, Delphi 8, and now Delphi 2005 are built) has had a module that implemented the “Welcome Page”  Admittedly the first couple of iterrations were a little lame and not quite to what I had envisioned.  That has changed for D2005... never mind that since that is neither here nor there... The problem is that I implemented a ASynchronous Pluggable Protocol, in order to “serve” the web pages from a specific local file storage instead of hitting local http server or what-not.  OK, all was fine and dandy up until around October 12, 2004.  This was about the time that Microsoft began pushing a “rollup“ patch of Internet Explorer (don't even go there... I'm not using Mozilla or Firefox folks, the IE WebBrowser is quite sufficient for the needs here), called KB834707, down the Windows Update service.  We started receiving reports from fieldtesters with the combination of Windows XP Service Pack 2 + KB834707 that they started getting a Windows security dialog popping up asking them to confirm the down load of the Welcome Page.  The same thing started happening with the HelpInsight stuff as well (You can find out about HelpInsight by following some of the links here).  This was confirmed by folks that uninstalled KB834707 patch and observed that those dialogs no longer appeared.  Of course reinstalling that patch caused them to reappear.

No problem, I figured I must not be doing quite the right stuff related to the APP.  So I spent a while trying to resolve this by refining how the APP responds to requests and what status codes it sends back.  Lots of Googling the newsgroups and web.  All boiled down to finally getting that security dialog to now have a checkbox on it which when unchecked would make that dialog not appear ever again.  Great. Fixed. Next...right?  Not quite... The problem is that by unchecking this checkbox, it is a global user setting!  We've just unwittingly led the user down a path of potentially opening a security hole in their system.

Now that I'd been wholly unsuccessful at resolving this issue in a satisfactory manner, it was finally decided to push the “contact MS support button.”  This is where it begins to play out like that old Bob Newhart one-sided phone conversation schtick or a George Carlin routine...  After a couple of email exchanges with the MS “handler” and sending my direct access office phone number, I got a call.  The names have been changed to protect the innocent (or guilty as the case may be ;-) and the dialog has been paraphrased.

MS Handler: “Hello, Allen?  This is Nancy from Microsoft support.  After your description of the problem I've gone ahead and contacted a member of our Developer Support Group.”
Me: “OK, Thanks!”
Nancy: “Please hold while I get them on the line.  I'll remain on the line during the call to help clarify any questions regarding your support contract.”
Me: “No problem.”
Click.  Silence. (at least they don't have that silly sleep inducing elevator or teeth griding bad hits from the 80's, music ;-).
Nancy: “Hi, Allen?  I have Bob on the line from developer support and he's already reviewed some of the description of the problem based on our previous emails.”
Me: “OK.”
Hmm... This might not be so bad after all...  famous last words..
Bob: “Hi, Allen.  What version of Visual Basic are you using?”
Warning! Warning! Danger Will Robinson! Ahhh!!!!
Me: “Uh... I'm not using Visual Basic.  This is written in Delphi.  In fact it is Delphi”
Bob: “Delphi? Isn't that a Borland product?”
Me: “Yes it is.”
Bob: “I think you're going to have to call Borland then”
Flag down!  Miscommunication on field. Restart play.
Me: “Uh...This is Borl...”
Nancy: “Bob, Allen is from Borland.  He is a member of the Delphi development team.”
Whew!  Saved... Thanks, Nancy!
Bob: “Oh, I see.  I don't know if I'm going to be able to help.”
Nancy: “Why don't we let Allen explain the problem and maybe we can at least figure out who can help?”
Obviously her bonus' are based on how happy her support contract customers are.. this is a good thing...
Bob: “OK, I'm listening.”
Nancy: “Go ahead, Allen.”
Me: I regail Bob on the finer points of the problem, Asynchronous Pluggable Protocols, WinXP/SP2 + KB834707, etc...
Bob: “Do you have any sample code that will demonstrate the problem?  I'm not familiar with the changes that went into that patch.”
Me: “Sure, I can put something together.”
Hopes raised....
Bob: “Is it in VB or VC++?”
Knot forming in stomach... sweat beading up on back of neck and forehead... throat constricting...  ok.. no numbness in hands... heart still beating...
Me: “Uh, no.  It's written in Delphi.”
Bob: “Well, we won't be able to work with that since we don't support Delphi.”
Me: “OK.. It's going to take a while and I have some serious deadlines coming up.  In fact we may have to release the product with this problem.”
Bob: “I understand, but there is no-one here that can read Delphi code.”
Nancy: “Allen, looks like the quickest course of action is to try and reproduce this is VB or VC++.  I wish there was another course of action.”
So do I.  Gee, can't you just take a binary Delphi application and observe its behaviour from your side?
Me: “OK.... I can guarantee that I won't have anything by the end of the week, though.  We will also probably have to 'readme' this in the actual release.”
Nancy: “I understand.  If there is anyway you can get a test-case in the next couple of days, we'll look at is ASAP.”
Me: “I'll try.  I don't even have VB or VC++ installed.”

The conversation went on for a little bit more....  You've all heard about the silly support calls that come from customers about magnets and floppy disks, folding 5.25” disks to fit into 3.5” drives, etc... but the shear hilarity of one dev tool company calling another dev tool company is the stuff from which legends are made.  I knew this was going to be great blog fodder once I heard the words, “What version of Visual Basic are you using?”

Stay tuned for another installment in this saga.  It ain't over yet as this is still an active support case.

Falafel Developers Conference, Toronto

I mentioned it in a little blurb last week, but I thought I'd bring it up under its own topic.  On November 29th and 30th, 2004, I'll be speaking in Toronto, Ontario, Canada at the Toronto Congress Center.  My “cohort in crime”, Danny Thorpe will also be speaking.  You can get the details here and how to sign-up for this two day event being presented by Falafel Software.

Delphi 8 .NET 1.1 SP1 Update...

I've been so busy with trying to get Diamondback/Delphi 2005 that I completely missed that Danny has posted a status update on the .NET 1.1 SP1 issue.

Breath in.. breath out...

In with the good air... out with the bad... In with the good code... out with the bad code... Since we've announced Borland Delphi 2005, I suppose getting it finalized and out the door would be a good thing. We're current erradicating as many creepy-crawlers as we can, and as quickly as we can.

On another note, I'll be in Toronto at the end of November, the 29th and 30th. I'll be speaking at the Falafel Developers Conference.

An Open Letter to Borland...

Paul Gustavson has posted this draft Open Letter to Borland regarding the future of Borland C++Builder.  It is an interesting read.

Earthquake!

Yep.. at around 10:15 am PDT, a 6.0 tembler hit about 150 miles south of where I am.  It was certainly a rockin' and a rollin'.  You can see more information here.  This is an automatically updated page so you'll need to hit it soon because the information will probably be cleared soon.

 

New Diamondback preview license posted

Michael Swindell just posted to BDN, this article regarding the NDA license that was shipped with the BorCon preview.  So for all you folks out there remaining tight-lipped about the content of your copy of the Diamondback preview, the floodgates are now open.  Sorry for the confusion, folks.  You can now post blog entries, articles, newsgroup messages, screenshots, whatever.  The preview was a whirl-wind last minute thing, so there was bound to be a few mistakes.  Just remember that this is a pre-release copy of Diamongback, so expect things to change considerably between the preview and the final public release.

 

 

Newsgroup leakage...

Looks like TOndrej has snagged a posting I made from the borland.public.delphi.non-technical newsgroup and made a blog entry about it.  I honestly thought that the “-r” command-line switch was actually documented.  Maybe Delphi 8?

Danny outlines reason for .NET 1.1 SP1 & D8 breakage

Danny has posted some information on our analysis of the problems that folks are having with the .NET 1.1 SP1 update that was just released a few weeks ago.  Now before you get your knickers in knot, we will at least release an interim patch to get folks back on track.  However it will take some time for us to fully regress any changes before releasing an “official” update.  The problem is, as Danny stated, we simply don't know at this point what the correct fix should be.  The worst thing we could do at this point is to bow to all that borland.public.delphi.non-technical pressure and rush a fix out the door.  We need to step back, take a deep breath, and attack the problem calmly.  We certainly don't want to make the situation worse.  I recommend to all those folks that seem to be using this as an excuse to break out the flame-throwers, to take that same tactic.  Slow down and take a deep breath.  There is truth in the old adage, “haste makes waste.”

 

Back at work..

Well I'm back at work now and have jumped head-long into pure “bug-fix” mode for Diamondback.  I guess we should make sure that we deliver it now that we've let the world in on the secret ;-)..  This year's conference was a pure blast!  I really enjoyed meeting with all the “regulars” and the familiar faces.  I appologize if I didn't remember your name, but I generally don't forget faces.  I'll try and keep this site updated as much as I can, but since we're nearing the end, “crunch mode” is nearly upon us.

Unofficial, unscientific, "just curious" survey.

For all those that attended Borcon, and esspecially those that attended the Diamondback Preview/Meet the Team session on Monday evening, what was your opinion of the format?  Did you like the “fair” style format where you could walk up directly to different areas where the team members were sitting and talk directly with them.  What about the “blip-vert” demos prior to the breakout?  As a data point, I've already gotten some feedback that it was very well received.  I think we'll probably keep that format for the next few years at BorCon (depending upon how many of the engineers we can drag to the conference and where it takes place).

Finished and winding down...

I just completed my second iterration of my What's New in Diamondback presentation.  I was pleased that a whole new crowd showed up.  That gave me a chance to cover all my favority bits of Diamondback (read: the bits I worked on ;-)..  I went over the resurrection of the VCL floating designer, true drag-n-drop development (you can now actually drag a component from the tool palette onto the form).  The IDE now again also supports multiple editor windows as before.  The ASP.NET and WinForms designers remain embedded.

One of my favorite features is called SyncEdit.  If you've ever used recent versions of JBuilder, you have probably seen this feature.  Basically you select a block of code and and a little button appears in the gutter indicating that SyncEdit mode is available.  When you press the button, the Editor changes modes by highlighting the block a little differently, parses the marked block and highlights all the common identifiers within the block. Now when you edit one of these identifiers, all the others are also changed simultaneously.  You can then press tab to move between each ident.

Then there is refactoring.  This works not only within the entire project (even throughout units that are not specifically part of the project), but across projects within the same project group.  For instance if you rename a public type or some other symbol in a C# assembly that is referenced by a Delphi for .NET project, and that Delphi project references that particular symbol, then it will also be refactored as well!

Lots-o-debugging ehhancements are also on the way.  Better stack tracing. Better breakpoint window; added a toolbar, inplace editing of the breakpoint condition and pass counts, and a checkbox to quickly enable/disable a breakpoint.  You can now also simultaneously debug a Win32 application and a .NET application within the same project group.  Through a bit of finagling, you can also debug both Win32 and .NET within the same process!  This is great for folks who are using a Win32 application in which the CLR is hosted.  Such as the Diamondback IDE itself.

I haven't even touched on all the new ASP.NET, VCL, database, DBWeb, etc.. enhancements.  For more information you can check out the various “live” bloggers that were covering the sessions as they were happening.  There's probably more, but Google and Technorati haven't discovered them yet.

Nick Hodges
Robert Love
Joe White
Dr. Bob
Jim McKeeth
Marco Cantu
Craig Stuntz
Paul Gustavson

Blogger requests

Danny has posted a good bit of information and request to all you “live” bloggers out there feverishly tapping away at your keyboard while in the middle of a presentation.  He make some very good points and a couple of requests as well.  Since Danny and I do actually talk quite a bit, we both agree that the “live” blogging that is taking place at this year's Borland Conference, is great and we don't want to discourage it at all.  We've both been “live” blogged at each of our sessions, so we'd like to be able to use some of the blogsphere tools out there to find out who's linking to our blogs.  So please make sure you include a link to the author's website or blog URL when you post your blog entry.  Keep up the information flowing!

Nick Hodges takes Spirit of Delphi award

Every year for the past several years, Borland has presented a special award to different Delphi users and luminaries for their outstanding support of Delphi.  They are well-respected within the Delphi community.  At this year's Diamondback preview and Meet the Delphi Team sesstions, the award was presented to non other than Nick Hodges.  Congratulations, Nick!  This is a very well-deserved award.

BorCon presentation..

Well the first installment of my talk is now over.  I'm now sitting in Danny's talk waiting for him to start.  He's going to go into the deeper details of what's new in the Delphi compiler.  This isn't just the .NET compiler, BTW.  I'm sure that there will be others doing the “live” blog thing.  Robert Love, who's sitting next to me in the front row right now, did a live blog of my talk.  You can read about it here.

Nick's Preconference Tutorial - Live

I'm sitting here in Nick Hodges' Preconference tutorial on Creating Custom ASP.NET Components in Delphi.  Nick is a very engaging presenter (somewhat of an odd statement since I am sitting here writing about his talk ;-).  Since I don't work directly with the ASP.NET stuff on a daily basis, I figured I could probably learn a thing or two.  So far Nick is able to draw some keen analogies to how the traditional Delphi developer can view custom component construction for ASP.NET.  The guts of ASP.NET component creation is quite complex, but Nick is able to break it down so that you're not overwhelmed with that complexity.  Good job, Nick!

Now for the obligatory Diamondback plug ;-).  Nick is using Diamondback in his presentation and so far I've only seen one case where he's had to restart the IDE, and one other case of an error dialog.  And he's almost done with the tutorial.  With four hours of heavy IDE usage, add in the attacking demo gremlins, it seems to be holding up quite well.

Pre-conference Day 1.

I just finished attending day one of the Preconference Tutorials at this year's Borland Conference.  I attended Danny's talk about .NET 2.0 and John Kaster's talk, Overview of Diamondback.  I like sitting in the back and work on my own presentation because I can also see what they've covered, guage the audience reaction so that I can get a feel for what I should concentrate on in my own talk.  Looks like the IDE stuff was one of the hottest tickets.  But then again maybe I'm a little biased ;-)..  If you want to know what was covered in Danny's talk this morning, Nick has a great summary of all the hot bits.  I'm almost done with my own slides and was able to pare them down to under 50.  I will probably do more demos in between a lot of the slides.  I still don't know if 1:15 is enough time.  John Kaster was unable to get through even half of his 218 or so slides in the four hours of his precon tutorial!  So if you're at the conference, I may have to split my one talk into a part I and a part II.  I'm scheduled for a repeat on Wednesday, but may have to use the Wednesday talk as a continuation.  This all depends on the how well things go Monday.  I'll try and post again tomorrow, once I decide who's talk to crash and heckle ;-)

BorCon prep.

We're currently scrambling to complete all those last minute details you always forget in preparation for this year's Borland Conference.  I'm finalizing the slides for my presentations, “What's New in Diamondback.”  By all counts this is going to be one memorable conference.  I hope to be giving some daily updates regarding the conference.  Maybe even post some photos.

Shotgun fix for .NET 1.1 SP1...

The following was posted by Roy Nelson as a way to get Delphi 8 back up and going with .NET 1.1 SP1.  Please note that this is a “shotgun” fix and has not been verified by Borland QA, so your mileage may vary:

1) delete all *.dc* (BUT just make a copy of your $(BDS)lib BEFORE deleting all the *.dc* files)in the $(BDS)lib dir and $(BDS)libdebug dir (do not touch the other files eg. .resource, .res and .nfm files)
2) go to the $(BDS)source dir and run the makefile file with "default" and "debug" options.
So from command prompt in the $(BDS)source dir you run

"make default debug" (without the quotes)

3) delete all old *.dc* in you project dir and re-build.
4) in VCL projects you might still see issues but all you need to do is remove the references to the VCL assemblies in the project pane and then do a re-build of the project.
5) if you still see any compiler error, either remove the offending assembley from the references and do a re-build.

 

More .NET 1.1 SP1 woes.

It seems that there are more reports coming in regarding SP1 for .NET 1.1.  For now, I would recommend holding off any deployments for SP1 on development systems.  There are several “shotgun” approaches to fixing this issue, but until we have a better understanding what the exact problem is, I cannot recommend these approaches just yet.

100% Defect free vs. Reality.

Is it possible to create 100% bug free software?  Theoretically, I suppose it is possible.  But then again, how would you know if you've actually acheived it?  Design, specs, pre-conditions, post-conditions, unit-testing, test cases, metrics, audits, are all designed to mitigate the introduction of software defects.  Unit-testing is designed to break down a problem into managable pieces with test cases that are tailored to that one little bit of code.  The idea is that if you have well designed test cases that thoroughly cover a particular domain and all those tests pass, when you begin putting all these pieces together, you run less risk of introducing more defects because each “unit” is solid.  This philiosophy is core to XP (Extreme Programming).

I'm not going to try and burst any bubble surrounding XP as I agree with many of its tenets. What I am going to do, however, is try and and least poke at the myth that it is possible to achieve 100% defect free software.  Given enough time and resources, I think you may be able to reach 99.999999...%, but there is no way to really know whether or not you've reached the panacea of 100%.  I'm talking on a macro level here folks.  Systems that are reasonably sized, not some dinky sized program that does nothing but spit out “Hello World” and terminate.  Let's say a normal application has upwards of 1000 “units” (I'm not talking “units” in the Delphi sense, but the minimum testable block of actual code).  Complex applications may be 100 times that size.  As you begin to assemble these “units“ you are multiplying the permutations of both input data and output results.  There are also the unforseen interactions that take place when two pieces are brought together.  Just like some chemicals react violently when mixed, you can have these various “units“ come together and create some pretty wierd and wonderful smells and colors.  Design and architecture is most definately needed in order to mitigate the chances of a meltdown.  But then again, it is those pesky humans who dream up these designs and architecture.  This is also where another recent methodology, patterns, is gaining favor... but that is a topic for another time...

What I think happens when folks tout the 100% defect free mantra, they completely miss the human factor that is involved.  Bottom line is this; Humans are not perfect and will make mistakes.  They also miss the practicality and marketability of such a system.  There is a delicate balancing act. The customer says, “I want the software I use to solve a problem and operate as specified or as I expect.”  Those same folks also want as many features as possible to make they're life easier when using the software.  Where the balancing act comes in is with that one thing all of us have the same amount of; Time.  The software producer wants to minimize the amount of time it takes to get their goods to market in order to gain or maintain a competitive advantage.  The customer also wants a timely release of the software because the sooner they can use it the sooner they themselves can begin to become competitive.  Schedules, Feature lists, deadlines, etc.. all serve to push a product out the door, whereas defects are the opposing forces that serves to push the delivery in the opposite direction.  The difficult part is knowing when to press harder on the accelerator and when to put on the brakes.

This is where experience, intuituin (yes, I said intuition...), and solid metrics all come together to help you make those critical descisions.  One factor in determining what defects to focus on fixing and which ones to let slide come from understanding your customers in a broad sense.  Given a particular defect, we can use the previous tools (experience, intuition, metrics, etc...) to determine a defect's “surface area.”  The “surface area” of a defect is a somewhat subjective combination of the severity of the defect, its location, frequency and a smattering of other metrics thrown in, including a subjective risk metric and the current point in the delivery cycle.  Suppose in your testing phase you encountered a defect that occured each time you open a file?  Suppose opening and processing files is one of the primary functions of this application.  It is very likely that nearly all users of the application will encounter this defect.  Suppose this defect is that it injects random data into the file when it is opened.  The location combined with the severity and the frequency all combine to create a very high “surface area” defect.  On the opposite end of the scale, suppose there is a defect that only occurs when certain rare operaions are performed on a file and ojly if that file contains a sequence that is encountered in a statistically miniscule number of files.  One could easily conclude that this defect, while it may have a very high severity (say, it causes file corruption), in all it has a relatively small “surface area.”  No, we don't actually grab our calculators and begin feeding values into some magic formula, but rather it is a mental excercise that usually takes place whithin a small group, ranging from two-ten people.  Making any change to the code also carries a certain degree of risk.  Changing a commonly used routine can carry a very high risk because of the potential for wide ranging destabilization.  This risk also increases in a somewhat inverse geometric proportion to the remaining time on the schedule.

“OK Bauer!  Where are you going with all this?”  There has been a lot of interesting discussions out on the borland.public.delphi.non-technical newsgroup about the disposition of all the defects reported in Quality Central. They range from “Just fix everything reported in QC” to “Let's vote on the ones that hurt us the most” to “Borland ignores QC”  First of all, we do frequently “mine“ Quality Central for defects.  Many of them are transferred to our internal database (yes, they remain tethered).  All this data is used to help us determine the relative “surface area” of a given defect.  If we notice that it came from QC, that metric is used in these mental calculations.  Believe it or not, we have even been known to factor in data gleened from just lurking through the various Borland newsgroups.  In fact this should be evidenced by the fact that Steve Trefethen, recently made a request for someone to gather together a list of defects from QC.  He even posted a detailed feedback message stating that some of the bugs have now been fixed and will be available in the next Delphi release (shameless BorCon plug here..). 

“You bozo!  That doesn't help me now!”  Sadly, you're right.  But then again, if you'd followed along to this point you'd have seen that there are a lot of factors that go into deciding what we fix and what we don't and why.  Then there is also the fact that we can't fix what we don't know about.  Also, QC is not the only metric we use in determining what features to implement and what defects to fix.  Those are the drawbacks to having a publically available database.  There also tends to be a mob-mentality.  The positive side of a publically available database, especially one that allows commenting and voting, is that it tends to self-regulate.  The community as a whole can help weed out all the random cruft that will inevitably fill the database.

“I don't want excuses, I just want my bug fixed!“  This may all sound like I'm standing on my soapbox and telling you all how rough we have it... OK may be I am a little, but hey, it's my blog after all ;-).  I just see that there seems to be a small vocal subset of people who like to cast stones. Perspective plays a huge role here.  To many folks, it is just this one little bug, it shouldn't take that long, right?  Many times a bug fix takes much more time to research its impact than the time it takes to apply the fix.  We have to evaulate a fix not just in terms of a given test-case, but also figure out if there are other similar cases that this fix can address, or if it will have a negative net effect on the product.

It has also been commented that the QC bugs should take a higher priority that internally reported bugs.  While it seems that would be the best move politcally, many times it would simply steal time away from other more critical, higher “surface area“ defects.  “Then just delay your ship dates.“  Here's a very sticky one...  While there have been releases in the past where ship dates are dictated to the team and we had to make those dates and clean up the bodies later, that hasn't been the case recently.  While we are still given guidelines and target quarters, we for the most part control our own schedule as a team.  Make no mistake, there is still a schedule that is communicated to many other teams.  They must know this information in order to align their groups' work to match our team's schedule as closely as possible.  Groups such as marketing and sales need to know with a high degree of certainty when we'll release the product.  All of these are factors that go into determining the “surface area“ of a defect.  We could argue for days on the relative weight of each factor in the “surface area“ calculation. But the bottom line is that we have a lot of very experienced people that understand and know the product down to the individual lines of code that know how to make these determinations.  Do we make mistakes? You bet we do.

You can take away what you will from the above meandering drivel, but I'd like to think that most developers who uses our products for producing market driven, (internally developed and used software also has a “market”) software has had to make these same determinations regarding a defect's “surface area.”  You've also had to factor in schedules and deadlines when determining this information.

Again, you should really try and attend this year's Borland Conference where you'll hear about the next Delphi release, codenamed, Diamondback.  You'll also begin hear about our [Borland's] roadmap.  You can bet that Delphi is going to be a critical part of Borland's roadmap.

.NET 1.1 SP1

We're beginning to hear reports that installing the newly released .NET 1.1 SP1 found here, http://tinyurl.com/679we, is causing some folks problems with C#Builder and Delphi 8.  We're aware of this issue and are currently researching the total scope of the problem.  In several cases so far, reinstalling of the products fixes the problem.  Not an ideal solution at this point I know, but until we have all the facts, we can't begin to suggest actual fixes or what the proper procedures should be.  Please stand by...

Yowzza!

This is very interesting... Apparently this person was fired from Friendster for blogging. http://troutgirl.com/blog/.  Danny wrote a nice little comment about the potential blogging ramifications over here.  Note that neither Danny nor myself actually provided a direct link to Friendster.  I, at least, don't want to drive any traffic to their site.  I suppose you could say that is what we think of that.

Great Hackers - huh?

Nick, http://www.lemanix.com/nick, posted a reference to this peice http://www.paulgraham.com/gh.html and I finally got a chance to read through it.  I'm sorry, Nick, but what a bunch of self serving clap-trap?  From the article...

Great hackers also generally insist on using open source software. Not just because it's better, but because it gives them more control. Good hackers insist on control. This is part of what makes them good hackers: when something's broken, they need to fix it. You want them to feel this way about the software they're writing for you. You shouldn't be surprised when they feel the same way about the operating system.

Huh? Why is this some generally accepted axiom?  I personally know a couple of engineers that one could classify using Paul's terminology of “Great Hacker.”  Chuck Jazdzewski and Anders Hejlsberg. Anyone who's been around the block at least once in the Delphi community has heard these names bantered about more than once.  Anders was the technical wizard behind Turbo Pascal and later the Delphi compiler. With Chuck they were geniuses behind the design and architecture of the Visual Component LIbrary.  I don't think either one of them chose any kind of open source because it gave them “more control“. Besides when Turbo Pascal and Delphi were being designed and architected, Open Source was an underground, backroom movement.

What do hackers want? Like all craftsmen, hackers like good tools. In fact, that's an understatement. Good hackers find it unbearable to use bad tools. They'll simply refuse to work on projects with the wrong infrastructure.

OK, I can agree with this one.  So, Chuck and Anders created their tool of choice.  Can you imagine Delphi being built out of something like Python (zing!)?  So we use the best tool at our disposal with which to build Delphi; we use Delphi.

For example, if your company wants to write some software, it might seem a prudent choice to write it in Java. But when you choose a language, you're also choosing a community. The programmers you'll be able to hire to work on a Java project won't be as smart as the ones you could get to work on a project written in Python.

Again, Huh?  Of course he tries to mitigate and backtrack on this statement a little if you follow the link, but the cat is out of the bag.  I'm sorry, but a “Good Hacker” is good no matter what language they use (OK, except maybe with Perl ;-).

Now of course if all Paul means by “Good Hacker” is a really good programmer, then I'm sorry I even compared Chuck and Anders to this hypothetical “Good Hacker.”  These two, I would place in the “Master Software Craftsman” category... sort of like the difference between a good carpenter framing out a room and a master cabinet/furniture-maker.  I do have to admit that some of Paul's article was interesting an intriquing, but it got muddled up in several sweeping generalities.

VCL Component registration.

How many of you have found that when you create a design-time package for Delphi, there are many things you can do in the unit initialization equally as well as using the “sanctioned” technique of providing a single global procedure called “Register”?  You may have discovered that things like the Open Tools API services are available, you can register property/component editors with some success as well.  Well... stop it!  Please make sure you are using the properly sanctioned technique of placing all this code into a “Register” procedure in one or more units in the design-time package. 

There are some new features and services that the next version of Delphi that heavily relies on the registration of wizard, components, property/component editors, and custom modules be done from within a Register procedure.  Let's just say that the next version of Delphi will “demand” that component developers are following the rules.  The good thing about this is that using the Register procedure will work for all versions of Delphi, so you shouldn't be breaking any backward compatibility, nor are you going to be required to introduce yet another IFDEF.  If you take a quick look over your code and make sure that this is the case, then you should be in very good shape and ready when we release the next version of Delphi.

What ALM is not

There seems to be a bit of confusion regarding what ALM (Application Lifecycle Management) is and isn't.  First of all, unless you create single one-off utilities, you need ALM.  Just because, “Management” is in the name, doesn't mean ALM is for managers.  ALM simply recognises that there are phases to development of an application, even informally.  What we are trying to do with ALM, is to simply provide tools whereby you can be just as productive in all phases in the production of software as you are in the development phase.  ALM's goal is also to not get in the way and force a whole shift in your process in order for it to become useful.

Personally, I feel that one's approach to ALM should be gradual while at the same time intentional.  Probably, the most common starting point in any ALM solution rollout would be to implement some form of source code control and archiving.  If you're idea of source code control is to copy your files to another machine or simply spool them off to a backup, then you are in need of a good archiving and configuration management tool.  Even if you are using a tool to provide these services, it may be worth your while to at least investigate StarTeam.  StarTeam is more that just a source code management tool.  It is an entry point into several broader areas of ALM.  Entry level requirements management, defect/change request tracking, tasks lists, which are all parts of the ALM story.

Many of the smaller consultant folks may scoff at the idea of the use of such a seemingly large tool to handle all these tasks.  However, even in these cases, clearly defined requirements are an absolute must.  Tracking defect and change requests in a formal manner is also something that every consultant or consultant shop needs to do as well.  Post-it notes, and text files are hard to track globally and don't scale very well.

At this years BorCon, you'll get to see how well the next version of Delphi, code named “Diamondback,” can help you, the small developer, actually begin to take advantage of these new ALM tools.

 

A good problem to have.

It is becoming increasingly clear that in my BorCon talk, 1174, I won't have enough time to cover all the new things in DiamondBack (the next version of Delphi).  For many things I will only lightly touch on because they will be covered by other sessions.  I, however, will be focusing on all the new IDE features, but even then there is so much, that in a single hour and 15 minute session I will not be able to cover all aspects of the product.  So, I'll either break it up into a Part I and Part II, or add a session, it they can find a reasonable time-slot.

Holy-moly...

Danny is starting to demostrate his “Chief Scientist” chops.  This post, http://www.lemanix.com/nick/archive/2004/08/08/1084.aspx, from Nick certainly got handily pounded upon by Danny in this, http://homepages.codegear.com/dthorpe/blog/delphi/2004_08_01_archive.php, post.  So, Nick, what's your response?  Just wait till I can pop some popcorn, and get comfortable... Ahhh, OK.. Ready, GO!

A Delphi case-study

From the annals of the news://forums.borland.com/borland.public.delphi.non-technical newsgroup another great post about the usage of Delphi 7 & 8 to move into .NET:

From: Sinan Karaca

I wanted to provide a "case study" based on my experiences using Delphi 7&8
in tandem.

1) Using Delphi.NET, I was able to start coding for the .NET platform
immediately. Without learning a single new thing about .NET. I used VCL.NET,
of course.
2) As the need arose, I started working with .NET classes and learning
them - the rest was handled by VCL and the other FX that Delphi provides.
This made the learning curve very, very smooth.
3) All my expertise and knowledge on the Win32 API, I leveraged with
P/Invoke. While it is a valid charge that my code won't run on Mono, I
really don't care. I am targeting .NET FX 1.1 on Windows. It will be years
before Mono and/or other .NET implementations come close to the
behavior/stability offered by M$ on the Windows .NET FX. Although M$
presents .NET as a new platform, I tend to see it as a new framework -
nothing more.

4) Maybe this is the best part - I was able to back-port the same
application to Win32 in a week or so. AND I have single source compiles for
Win32/.NET now. True, there are quite a few IFDEFs here and there, but that
is all it cost.

We all know the famous example - open the Delphi 1 fishfacts app, and it
compiles under D8. Now you have a single source app, compiling on Win16,
Win32, and .NET. This definitely says something!

I consider my knowledge of VCL an investment, one that will last well into
the future - Borland gives us reason to believe that even when M$ drops the
Win32 API, we will still be leveraging our VCL knowledge - and natively, at
that. While I have occasionally fallen in to the "oh what if Delphi gets
discontinued" panic, which seemed to be a real threat back in the Del Yocam
days - I think time has proven the choices I made.

What can I say - keep it up guys! We love ya.

Sinan

This is silly...and funny

From the news://forums.borland.com/borland.public.delphi.non-technical newsgroup:

From: Captain Jake

Has anyone else noticed that olympic gymnast Brett McClure looks a lot like
Allen Bauer? Could this be why D9 isn't going to be ready until the end of
the year? Hmmm?

--

Read Jake's Blog at http://blogs.slcdug.org/jjacobson/
Or Get the RSS Feed at http://blogs.slcdug.org/jjacobson/Rss.aspx

Quietly blogging

I happened across this blog http://gloriaho.blogspot.com/, from a young girl in Hong Kong who keeps a very close eye on Borland, Delphi, and the Delphi newsgroups.  She's a new Delphi programmer (since 2002) and certainly enjoys using it.  It's always great to see new, excited users of Delphi.  Unfortunately, she is not able to attend BorCon this year since she has to take care of her grandmother.  At least she has her priorities straight; family should always come first.

Corporate Roadmap

While Danny got to take part in all those most excellent team building excercises for the first two days of the offsite meeting, I was able to attend on the final day, yesterday (August 18, 2004).  It was a day full of buzzword bingo (I lost count of the number of full cards I got ;-), but one thing you can say for Boz (Sr. VP of Product Development), is that he's a doer not just a talker.  You know how there's those little survey cards you fill out at every conference?  I was pleasently surprised that he (Boz), took them very seriously.  After they were all collected, the data was compiled and in the closing session the results were presented.  It was very open, honest and sincere.  Also, at each session we were to identify specific “next steps” to take and actually assign action items to certain individuals with a real deadline to meet. 

I've been to several of these off-site meetings over the years thae I've been at Borland, and frankly, they've been nearly useless.  We didn't spend a lot of time actually discussing the business, or the processes, in concrete, directly applicable terms.  This one was a total blitz of corporate strategy, competitive analysis, customer feedback, true concrete next steps, etc...

I also have to give a few kudos to Pat Kerpan, the CTO.  He lead the technical track and all the CS's (and myself, the lone Principal Architect ;), went through several key development issues, future directions, competitive responses.  Pat did an excellent job of both keeping everyone on track and out of ratholes.  He also seemed to know when a few rabbit-chases might reveal something fruitful.

While I did, miss some of the opening day sessions, the recap was reasonably thorough, and with a few crib notes from Michael Swindell, I was able to navigate the ocean of TLAs. If you'd like to get a glimpse at what came from these meetings, you can attend BorCon this year and we'll be beginning to talk about some of these things.

Whew! I suppose I should get back to work on helping to get Delphi ready to show at BorCon... See you there!

Comment spam...

I'm sure that the readers of this site have noticed the sudden deluge of comment spam that seems to have been inflicted upon this site.  I've had to start a morning ritual of deleting these bogus posts (and, unfortunately, any post that replies to them).  Of course, now that I've commented on them, they'll probably start kickin' it up a notch and increase the traffic.  I'm going to request that we change the comment system to require that the commenter have a BDN account.  This way, if there are any abuses, we can simply turn off their account.  I hate to have to push for this, but this is yet another thing that is going to be ruined by a few jerks out there.  I haven't turned off allowing comments for now since the number of these messages hasn't become too burdensome... just annoying.

More Diamondback information

Looks like the proverbial cat is beginning to claw its way out of the bag.  If you want some more juicy tidbits about Diamondback, the next version of Delphi, check out Michael's blog entry here: http://homepages.codegear.com/mswindell/2004/08/diamondback-rumors.html

 

Whew.. Diamondback will be at Borcon

Finally... Stuff is starting to dribble out about the next version of Delphi, code-named Diamondback.  To get the real scoop, however, you really need to be at this year's Borland Conference in San Jose, California.  I'll be doing the general “What's new in Delphi” session.  This will cover all the new cool IDE features that won't be covered by other sessions.  So, if you look here http://bdn.borland.com/article/0,1410,32499,00.html, you can get a hint at what features you might expect to hear about and see at the conference.  Also, you certainly don't want to miss the Monday night “Meet the team” session... trust me, you want to be there.

For information on how to sign-up for the conference and the costs, check out http://info.borland.com/conf2004/.
For information on the various tracks and sessions that will be presented, go to http://info.borland.com/conf2004/tracks/allsessions.html

Again, Monday September 13th at 8:00pm  is the must see event of the conference... esspecially for the Delphi programmers.

Delphi Basics..

Sometimes perusing through the public newsgroups will reveal some real gems among the rough.  Take for instance, there is current a very civilized and informative discussion currently taking place in borland.public.delphi.non-technical regarding different ways to make it easier for the Visual Basic programmer to move to Delphi.  One such thing that came up was this web site, http://www.delphibasics.co.uk/.  If you're looking to start programming in Delphi, this is a fantastic starting point.

I am not Danny, nor is Danny, I

Danny has found an interesting link to a bit of satire regarding the “pollution” of the Pascal language by Borland and Delphi.  However, once again, this blog post has mentioned this blog, yet the link is to Delphi Compiler Core.  Of course Danny recognized this and even mentioned it in his post.  So I just can't let this one go by without a comment.. ;-)

Mark Edington is now blogging

Well it looks like another cohort in crime has come out of the woodwork to place their mark on the blogging world. Mark Edington is now up and running with this whole blogging thing. Mark is another one of the "old-timers" on the team. He's been around since before the initial development of Delphi. Welcome aboard Mark!

Message methods in Delphi for .NET

Just got bit by this little oddity in how Delphi for .NET handles message methods. What is wrong with the following because it will compile?

TBaseClass = class(TWinControl)
procedure WMLButtonDown(var Message: TWMLButtonDown); message WM_LBUTTONDOWN;
end;

TNewClass = class(TBaseClass)
procedure WMLButtonDown(var Message: TMessage); message WM_LBUTTONDOWN;
end;

...

procedure TBaseClass.WMLButtonDown(var Message: TWMLButtonDown);
begin
inherited;
{ special processing here }
end;

procedure TNewClass.WMLButtonDown(var Message: TWMLButtonDown);
begin
inherited;
{ more special procesing here }
end;

It seems that the compiler will generate a raw call to the inherited method when it sees the "inherited" keyword without doing anything with the paramter. The ancestor's message handler will now treat the TMessage parameter as if it were a TWMLButtonDown message cracker. This wreaks havoc on the .NET runtime, but not in the way one would expect. One would possibly expect exceptions like invalid casts. However there is actually no telling what might happen. It actually react just as randomly as if you'd taken a random Integer value and cast it to an object reference then proceeded to call methods or dereference it. Now, of course the above code doesn't pass PEVerify, and had I actually thought to do that I would have seen the problem. So for all you component developers out there moving your Delphi components to Delphi 8 for .NET, just keep this in mind. You should declare your descendant message methods to match the ancestor's declaration (even though it is not required in Delphi for Win32). Yes, Danny and I are going to be working on some solutions to this delima for a future Delphi for .NET release.

Busy days...

You have probably noticed that there has been a drop in the flow of posts. There are several reasons for this. Most noteably is the fact that there isn't too much new information at this point that I can talk about. Then there is the fact that we're currently in the midst of approaching some internal milestones and much of my focus has to be on meeting those goals. No, I can't tell you what the milestones are and what their for... Sorry. As soon as I have some new juicy bits of information, tips or tricks, I'll try and get them posted here. For now, however, there will be a dearth of posts...

To float or not.. redux..

The comments on my last post were all very good. There's a few, however, I figured I'd address with another entry since some folks don't nessesarily read the comments.

What I always wanted to know, but were afraid to ask: Why is the default Form position poDesigned and not poDefault?

This will take a bit of a history lesson. When we were designing Delphi (back in, oh, 1993), we had already chosen the "floating" designer as the design-time model. We had a specific design goal for the user experience that when they hit the "run" button, it simply felt like the application simply "switched" from design-mode to run mode. We used the high-speed compilation to our advantage. By defaulting to poDesigned, the application would simply have the appearance of simply "turning-on" since it didn't appear to physically move on the screen. There was a lot of internal debate on this very topic, but frankly, the product demoed *very* well with the poDesigned. In fact sometimes it was actually difficult to convince folks that we had actually compiled the application and that there is now a stand-alone .EXE on disk.

As Marc has written the argument of the out of screen forms is so simple to fix without an embedded form designer as I can't even believe you count that as an argument for the embedded designer

Sure. However, one thing you have to remember is that a design-form is a live instance of a VCL form. So, when you set the Left/Top properties, the form will physically move on the screen, and the module is marked as modified. We go to tremendous lengths to not modify any file as a side-effect of opening it in the IDE. Of course there are potential solutions, but few are minimal, or non-invasive.

a) A somewhat wider right text margin, (I keep worrying that I'm missing nonwrapping text)

b) Scalable text size...

Thanks for the feedback on the look of the blog. I'll still be tweaking it as I can get to it.

To float to not to float...

In other words, embedded designers or stand-alone top-level designers. This argument has certainly served to polarize the Delphi community more than anything else has in recent years. There are those that only accept a "pure" traditional Delphi style designer, there are those that don't seem to care one way or another, and then those that are perfectly fine and somewhat prefer an embedded designer. It seems, however that the Delphi "purists" are the most vocal and vehemently against what they would characterize as "messing with success," by adopting a modal/embedded approach to form design. Personally, I've adapted to using either style and can see some of the advantages that each side has to offer. You might come to the conclusion that since I'm the one that did all the work to embed the VCL designer, I have a vested interest in keeping the designers as purely embedded. This certainly would allow me to focus on making that one mode work the best that it can. However, there are a few items that the embedded designer simply isn't able to address.

The embedded designer makes for a cleaner, more controlled environment. You always know where the designers are located, you are insulated from your co-workers that have screens with laser-printer resolutions placing the design form at some location that is someplace off screen. The designer also can display the border style of the form in the actual style that it will end up being rendered as. And, there is just a feeling that everything is more organized and more "under-control" with the embedded designer. There isn't this haphazard arrangment of windows with all your other applications peeking at you from between the cracks.

In the other camp, there are some things that the top-level "floating" designer does that simply cannot be done as easily with the embedded designer (and by extension, a single-window docked IDE). You can design a form that is at or near the actual screen resolution much easier since there is no "frame-overhead" for each designer. You can arrange the forms in such a manner that you can see several at once, which in the case of inherited VCL forms, is very helpful when modifying an ancestor form so you can see the live-updates on all the descendants and determine if moving the "OK" button will obscure something on any of the descendants. While, personally I prefer to dynamically position the forms at run-time, you can set the form position to "poDesigned" and manually arrange all your forms in the locations in which you want them to appear at run-time. Then there are the issues regarding the more frequent use of multi-monitor systems where developers will use the primary display to position the design-time forms, and use the secondary display for the menus, code-editor, OI, and other design-time/editing support windows.

Now before you start warming up your flamethrowers and start indiscriminately spewing expletives regarding your disdain for one style or another, just understand, that this issue has been heard loud and clear and we are looking into ways to address the issue for a future Delphi product release.

New Skin...

OK... I finally spent a few moments and created a new .Text skin (that probably works only in Internet Explorer... :-) that resembles the skin I use on my original blog site. It's not perfect, but it at least has most of the elements I wanted. Did I mention that CSS w/ HTML is about as enjoyable as slamming my hand in a car door?

Welcome...

Welcome to my new home on the web. From now on I'll be posting to this server which is officially hosted by Borland. However, please be aware that the same disclaimer still applies. Any views expressed here are my own and not those of my employer, Borland Software Corp. As soon as you begin to think that my views are a direct reflection on Borland, then please seek professional help immediately for the condition known as lackofhumoritis.

Anders Hejlsberg still evokes all manners of awe..

Chris Sells' post, My First Presentation For A Distinguished Engineer, underscores the level of respect and awe that Anders Hejlsberg still commands as a Distinguished Engineer at Microsoft. It is just interesting when other folks seem to be thoroughly enthralled and "star-struck" about the fact that Anders requested a technical briefing. I worked very closely with Anders during the early days of Delphi (and TPW 1.5 and Borland Pascal 7.0), and I must say that he is certainly a very charismatic and approachable person. He has an uncanny knack of being able to tell you when an idea was complete bovine scatology, yet your ego and self esteem remained completely intact. In fact, while Danny and I were at the Windows 64-bit briefings back in March, Anders had specifically requested that we try and meet for lunch. Unfortunately, he is also a very busy man and we were unable to connect. Anders is certainly deserving of all the accolades he receives.

This ain't no one or two man show...

A little comment about Danny's post. While Danny and I have been elevated to new roles and responsibilities, I must also say that this doesn't by any stretch mean that we are the sole descision makers on technical matters. Quite the contrary in fact. In order for Danny and I to be effective at what we do, we also need a focused, dedicated, and talented team of engineers. Some of them you already know about some of them, like Steve, Corbin and Chris. Others are less visible, but every bit as important to the team. Then there are the managers and program managers, QA engineers, product management and marketing, regional product line sales managers and teams, even the administrative assistants. They are all crucial to the health of any team.

Moving day drawing near...

It looks like I'll be moving this blog to an official Borland hosted blogging site in the very near future. When that happens, everyone will need to update their links and RSS/Atom feed references. I also hope to be moving the existing content to the new server as well, however comments may be another issue entirely. We'll see..

Bootstrapping...

This is my first blog post to the new Borland blog server.   I'm now in the process of bootstrapping the new site... Stay tuned.  For how you can go to http://homepages.codegear.com/abauer.

 

Patent Trolls

Technology industry hits out at 'patent trolls'

This is an interesting article about the current state of the US Patent System. In general, I certainly think that there should be a government sanctioned method of granting exclusive rights to use a certain invention for a period of time. However, once the system starts to be abused, it ruins it for everyone. Patents for the mere purpose of using the legal system to bludgeon people or companies over the head, are certainly abuse in my book. This is of particular interest right now since I'm currently involved with several IP lawyers in order to submit a patent application.

I wish.

Danny posted this bit of information regarding his and my promotions to Chief Scientist and Principal Architect, respectively. Not much more I can say.

That which was old is new again...

This is going to rattle a few cages... I've been keeping a back issue of Byte magazine from August 1986 (yes, I said 1986) that has an interesting article about a brand new application framework for the Macintosh built with Apple's Object Pascal language, called MacApp. Here's the article as scanned from that issue of Byte:



The most interesing bit is diagram on the second page of the article. For those of you that remember Turbo Vision, you'll certainly see an interesting similarity. Also, the Delphi folks will probably see some familiar stuff as well.

I remember Anders Hejlsberg saying, "Good ideas just don't go away."