Finished Filming: Whidbey Overview

Ooops, we filmed our last episode on the 17th, and I still haven’t gotten around to “blogging” about it yet. This episode focused on “Whidbey”, which is the next version of “Visual Studio”, and it will include a lot of features, technologies, as well as a whole new set of tools focused on providing advanced architectural design features for applications. There’s far too much in Whidbey to cover everything in one episode, so in this one I tried to provide a decent overview of what the main focus points were.

Over this last weekend we “shipped” Beta1, based on all of the e-mail I saw from the team, there was a lot of work being done to make sure that this was a high quality beta. I haven’t installed it yet, but I plan on doing that as soon as I can.

If you’ve installed, and started using the beta, why don’t you drop a comment here and just quickly let us know what you think about it.

You can click here to view my shared album up on Shutterfly with pictures that I took behind the scenes.

Comments (10)

  1. Ron says:

    Having been on the VB4 beta 10 years ago (Jon Roskill, etc), I’m a little cynical about Microsoft’s attitude to improving their products.

    It all seems to be a case of adding hundreds of HeyWowManSuperCoolDude32() API’s (closely followed by the HeyWowManSuperCoolDude32_X() API because someone forgot something) that only one in a thousand programmers might use once a year, when there are some screamingly obvious and simple things that should be resolved because they affect everyone, every day.

    For example, in VB1 through VB6 there was the ever present boring and time-consuming labour of ensuring "Screen.MousePointer" is always set at the correct time (and no other) so that it is always correct but never flickers.

    Yet VB is/was a semi-interpreted environment… so it KNOWS when it’s busy or idle. A simple "App.AutoMousePointer" property with optional Idle/Busy pointer parameters would save hours of grief for everyone.

    OTOH, when I first got hold of .NET Betas 1 and 2 with the VB6 conversion tool, it almost frightened me off ever using .NET again. Simple lines like "Screen.MousePointer = vbDefault" were turned into 200+ character lines that needed the screen scrolled twice to see the whole line.

    Likewise, a Debug.Clear method was suggested in the VB4 beta forums on Compuserve in 1994/5 and applauded as a good idea by the Chris the MS forum moderator – but was never implemented (how few lines of code would that have taken)?

    Worst of all was the programming "editor" that was introduced for VB4-VB6, which was basically a tarted up version of Notepad. Anyone who has ever used a proper editor that supports programmable key-macros, cut/copy/paste of columns or blocks cried in frustration. I always carried a floppy disk in my pocket with an editor called QEdit – total stand-alone executable size of 44K, yet it did all the above and more.

    Basic operational faults in the VB4-VB6 editors like folding the cursor to the beginning of the next line if you press "cursor right" at the end of a line (instead of doing what it’s told like the VB2 or VB3 editors did) makes the implementation of key-macros impossible anyway.

    As a contractor in the City of London, I still find that no-one wants .NET for anything other than a differentiator between CV’s for the agencies – I guess they assume that if you have learnt .NET you must still have an active and teachable mind. If you don’t have a degree, an MCSE/MCSD and .NET you don’t get called – even if it’s only a VB6/Excel97 job.

    The only other place you find .NET is where the engineers are driving the projects and want to play with programming novelties – instead of the business exercising and enforcing any budgetary control.

    The reality is that while C# is a massive step forwards from the incessant memory overwrites and bad garbage collection that plagues large multi-programmer C++ projects, there really is no commercial reason to replace VB6, given the hundreds of cheap third-party tools and add-ins plus the commoditisation effect of the hundreds of thousands of programmers worldwide who can do VB "good enough" – which is what matters in the real world.

  2. Ron says:

    Following on from my previous post, the ONE most effective programmer productivity feature EVER introduced by MS was the auto-syntax-checking of each line when Return is pressed. (This was first added to QuickBasic 4 in the 1980’s.)

    Since then, VB development became a case of "researching which Windows APIs are directly called the most (for the current VB version), and implementing the top 90% as simple built-in keywords".

    This was good – but it took attention away from resolving the (often huge) time spent debugging programs, particularly if a large team with a significant number of inexperienced programmers is at work.

    This bothered me when I was contributing to the private VB4 beta forums on Compuserve in 1995, and I posted a summary of issues often found in debugging that would be very simple for the VB/Visual Studio environment to find, because it has direct access to all the internal symbol tables and parsed code.

    I thought that these issues were far more important for improving developer productivity than yet another few hundred obscure APIs and keywords.

    Essentially, I was asking for VB to have the equivalent of /W4 ("Warning Level 4") that the C compilers have.

    Here’s the list again (without the explanations and examples). I know that some are only applicable to obsolete versions of Windows and VB – but most are still applicable in one way or another:

    1. Variables given Global scope unnecessarily?

    2. Accelerator (Shortcut) Key-letter clashes?

    3. Error Handling on all FormEvents, preferably on all other Sub/Functions too?

    4. Check for Recursion!

    5. Do all referenced .DLL calls actually exist in the .DLLs?

    6. Consistent variable naming enforced?

    7. Option Explicit in all forms/modules?

    8. Is Tab Order logical to the user?

    9. Use named Constants instead of hard-coded numbers!

    10. Spell Check all strings!

    11. Variables used before they are set?

    12. Do all File Handles use FreeFile?

    13. Types/Structures sensitive to packing (for C/C++ .DLL calls)?

    14. Constant expressions within loops?

    15. Local variables given same names as Globals?

    16. Does .FontName exist on the target PC?

    17. If a var ends in ‘l’ or ‘1’ is this a typo?

    18. Windows Resource (ie GDI/Usr) Usage Profiling

    19. Speed Profiling

    20. Any unnecessarily loaded forms?

    21. Use of Integers maximised?

    22. Beware of date order conventions!

    23. All return codes from functions are checked?

    24. Help implemented fully? All HelpContextIDs exist in .HLP?

    25. Controls that are never visible/enabled?

    26. Related code kept in same module?

    27. Global vars set in more than one place?

    28. More than 1 (non-error) exit point from Sub/Function?

    29. If…Then constructs should usually cover all possibilities

    30. Preferential usage of certain controls to save Windows resources?

    31. Default Properties and "With…End With" used?

    32. Any single-letter-named variables?

    33. Adequate Usage of DoEvents?

    34. Sub/Function size not excessive?

    35. "Dim Var1, Var2 As String" – only Var2 is a string!

    36. Maximised Use of ByVals on function calls?

    37. Any variable length strings in User-Defined Types?

    38. Explicitly referenced object properties within loops?

    39. All VB Specifications and Limitations are adhered to?

    40. No GoTo/GoSubs.

    41. Line length not excessive?

    42. Not too many depths of brackets?

    43. Inlining possible?

    44. Single line If…Then constructs?

    45. Beware of UNICODE text conventions…

    46. Too many controls on the same form?

    47. "ClipControls = False" usable?

    48. Me.Show in Form_Load for improved start-up impressions?

    49. VB3/VBA/VBDOS portability

    50. Internal Name/Symbol/DLL tables not overloaded?

  3. Java was a dream come true, and especially the Servlets.

    But “write once run anywhere” isn’t any good if it is “write once run slow and hard to setup on Windows”.

    SUN had many years of perfecting Java, also for the Windows users – I am thinking of speed and just click execution (no class path). But nothing happened, until after the introduction of .NET.

    Perhaps with the Mono project, .NET will become what Java was intended from the beginning. Probably not, but it was a thought.

    It is obvious that corners were cut in the 1.0/1.1 versions of the .NET Framework – just think of the DataGrid without cell controls like ComboBox – nice to see that that is in the 2.0 Framework.

    I would have liked it if Microsoft had released new .NET Framework versions more often, especially here in the beginning. No need to wait two or more years on things that just didn’t make into the previous release.

    Instead of releasing a new Framework version with a new Visual Studio version, Microsoft should make Visual Studio able to use different/several Framework versions, including future Framework versions.

    The Visual C# 2005 Express Edition Beta looks nice, with Windows XP look and feel without the manifest file. It is a long waiting opportunity to see what will be fixed and added in the upcoming (too late) 2.0 version of the .NET Framework.

    The future with Longhorn and .NET looks bright, but don’t let us die of old age before we get there 🙂

  4. Ron says:

    The page

    is very informative – but is there anywhere we can download the beta from, instead of ordering the CD?

  5. Ron says:

    OK, I’ve found where to download the Beta from:

  6. Compugab says:

    I can’t wait to see this new episode. I use Visual C# 2005 express beta 1 and until now it work just fine. I love the new Intellisence, work juste better than in VS2003. Hope the show will be there really soon


  7. Serdar Kilic says:

    What is the release schedule for the show? I’m impatient, I know, but its late July and its been a good while since the previous screening 🙂

  8. Sven Aelterman says:

    Did the post say "last show"? I hope he meant "latest show"…

  9. Robert Hess says:

    Were messing around with changing the process for building out the show, and we’ve run into some process snags that are making it take a little longer then normal. We hope to get the next episode out in a few days.