Welcome to AddressOf.com Sign in | Join | Help

Front Page News

  • Checkers Solitaire is now OSS

    The source code for Checkers Solitaire is now available on http://GitHub.com/DualBrain/CheckersSolitaire; go check it out, fork it, play with it, contribute, share, give me a pull request!

    Lack of ideas as to what you can do to contribute... how about helping get it to work on Mono or separating the UI from the rest of the code in order to port to XAML and possibly WinRT.

    02-04-2015, 11:22 AM by CorySmith to AddressOf.com
    Filed under: , , ,
  • I'm Going Open Source!

    Hmmm... not sure I really ever thought that I'd ever be the person saying those words, however, the day has finally come... hell has frozen over... open source is now in my vocabulary and I am embracing it wholeheartedly.  I'm definitely still a newb in the OSS space, very unfamiliar with the vernacular, tools are foreign, approach is "odd"; but I'm sure I'll get the hang of it over time.  In order to get started, I've resurrected a project that I made available here almost a decade ago (really, it's been that long?!?!?!) and published it to GitHub.

    I have several other projects, some older, some newer that might be making their way to GitHub; most likely using the MIT license.  These include:

    I'm also still weighing the pros/cons of making my tribute to GW-BASIC available as OSS.

    Why the hesitation?  Well, you know, although it's not something new, it's new to me.  I'm going to start with things that I've already made available (with possible updates) since, ultimately, I've already "exposed my soul" with those projects anyway.  As for other projects, I'm definitely experiencing feelings of fear, uncertainty and doubt regarding how things will be received and responded to; however, it's something that I think it's time to do.  There are also huge upsides to going OSS, especially for "code sample" type of projects.  Key of those advantages are that people can collaborate and contribute, something that really isn't all that straight forward using any other approach.  Additionally, the potential for reach is pretty astounding (which is one of those things that also adds FUD).  So we'll see where this goes from here.

    I do have to admit that this move on my part is definitely inspired in no small part to Microsoft's recent move with .NET in general toward OSS... 

    02-03-2015, 8:44 PM by CorySmith to AddressOf.com
  • BASIC SIG (September 2nd, 2014)

    Arduino *AND* Raspberri Pi (Oh My!)

    After discussing with several people, I came to the realization that since the format of this group is different than the typical presentation style meeting, we can easily handle BOTH!  Remember, this is a BASIC-themed hackerspace. It's not really about "presentations", more about being hands on.  Instead of "watching", it's about doing.  The only "rule" (if you want to call it that), is "if it can be done with BASIC, it should be done basic BASIC". ;-)

    On one side of the room, we will be working on getting VB.NET through Mono working on a Raspberry Pi.

    On the other side of the room, we will be getting an introduction to BCX to build for the Arduino along with everything that needs to be done to get an environment setup to do so.  We will also be learning more about what the Arduino is, playing with some simple electronics projects (along with covering some of the basics of electronics). Even if you don't have an Arduino, we will be looking at ways that you can still experiment (and learn) even without actual hardware.  If you do have the hardware, be sure to bring it along.  If you don't, just bring a laptop and you can still be involved.

    There are also a few BASIC SIG group related things to discuss, so we'll knock those out at the start of the meeting so we can get to the fun.

    I'll be ordering pizza once everyone has arrived (or I know you are definitely coming), so please RSVP (location, date, time, etc. included in the RSVP link).

    See you there.

    08-31-2014, 8:00 PM by CorySmith to AddressOf.com
    Filed under: , , , , ,
  • Announcing the BASIC SIG.

    If you are in the Dallas/Fort Worth area...

    BASIC SIG

    This is not your typical "user group"; instead think of it as more of a BASIC themed "hackerspace".  This is a hands-on oriented and user-to-user sharing/collaboration event.

    To RSVP, https://www.eventbrite.com/e/basic-sig-july-23rd-2014-tickets-12353095441 

    07-22-2014, 9:17 AM by CorySmith to AddressOf.com
    Filed under: ,
  • Transition Physical Machine To Virtual

    I'm writing more so as a reminder to myself...

    What I am trying to do is transition an older machine, one that is "semi-retired" but still contains some stuff that I need every once and a while for work purposes and I'd rather not muck up my new installation with these tools.

    So enter virtualization technology... wouldn't it be nice to somehow convert the physical machine to a virtual machine that can be stored and utilized from any newer machine that I choose... when and if the need should arise?

    The tools that I've used thus far are:

    I used the Disk2vhd tool to convert the physical disk to a VHDX formatted virtual disk; the nice thing about this tool is it is designed to be run on an active system utilizing "Windows' Volume Snapshot" capabilities.  What this really means is that it's smart enough to be able to image the drive even though files are in-use.

    I then downloaded and installed VirtualBox on the target machine that I'd like to get this up and running on.  I then created a new virtual machine and hit my first problem... thanks to Visual Studio 2012+... Hyper-V is enabled by default in order to facilitate development and testing on Windows Phone devices.  Because of this, VirtualBox does not allow me to create a virtual machine that is 64-bit; which, of course, the original machine was.  The first step was to disable Hyper-V.  To do so, you could either go to Enable/Disable Windows Features and do it using a mouse... our, use the following command line (requires Administrator elevation)...

    bcdedit /set hypervisorlaunchtype off

    (Note: To enable later, use "bcdedit /set hypervisorlaunchtype auto".)

    Once you have successfully executed the above command line, a reboot is required.  Now that this has been completed... of course, as you can probably guess, yet another "speed bump"...

    In order for 64-bit virtualization technology to be leveraged, the BIOS (most likely culprit) needs to be entered and Intel Virtualization needs to be enabled.  On the target machine, a newer model Windows 8 Sony VAIO® Fit 15A / Flip PC, I had to press the "Assist" button pressing the "Power" button from a powered off state.  Now that this has been completed, YEAH!, I can finally create a 64-bit Windows 7 virtual machine in VirtualBox.

    OK, I create a new machine, set the memory to what the original was (4GB) and leave the HD until later... as it turns out, I was not yet prepared to "use an existing disk".

    Apparently the VHDX formatted virtual disk is not compatible with VirtualBox; here's where Windows PowerShell and Convert-VHD come into play.  The following command line can be executed to easily (albeit slowly depending on the size of the disk) convert between VHDX to VHD (or the other way around if you have the need)...

    Convert-VHD nameofdisk.vhdx nameofdisk.vhd -Passthru

    (and wait for this to complete)

    Once done, I can then modify the settings of the virtual machine and connect the disk image with success.  In my case, the original machine was SATA, so I chose the SATA path instead of IDE.

    I then started the virtual machine... after a bit of chugging along and several Windows updates... I now have a virtual machine that appears to match the original physical machine.

    06-27-2014, 6:32 PM by CorySmith to AddressOf.com
  • Async/Await in a Console Application

    Here's the situation, you want to be able to build a console application and still take advantage of the asynchronous programming model available in the latest versions of VB (2012/2013). 

     

    No matter the reason behind why you may want to do this, the answer I give will still be the same; however, I'll provide my real-world reasoning behind my desire to have Async/Await from a Console Application... TESTING.  Many times it is a lot easier to do testing of API's from a Console Application; however, if your API's are Async/Await... thus the problem. 

     

    To do so, you may be tempted to start by modifying the Sub Main() based on the tons of examples you've seen for several other types of projects. 

     

      Async Sub Main()   

        Dim result = Await WebUtilities.FetchUrlAsync("http://addressof.com")

        Console.WriteLine(result)

        Console.ReadLine()

      End Function

     

    This, however, will not work.  Visual Studio will quickly alert you to this situation and you are left scratching your head.  You then will proceed (most likely) to search the web for a possible solution.  There are several out there that state that you need to setup some sort of synchronization context or some such and that you'll need to either use one that someone else has made or build one yourself.  There sure seems like there's got to be a simpler solution... 

     

      Sub Main()   

        Task.Run(AddressOf MainAsync).Wait()

      End Sub

     

      Async Function MainAsync() As Task

        Dim result = Await WebUtilities.FetchUrlAsync("http://addressof.com")

        Console.WriteLine(result)

        Console.ReadLine()

      End Function

     

    Hmmm... that seems to do the trick.

     

    The Task.Run method has several overloads, one of which takes the address of an Async/Await style method.  This actually kicks off the process of running that method asynchronously; however, if left to just calling this Run() method, the application would then exit immediately as nothing is keeping the Main method from completing.  To work around this problem, the Wait() method is executed upon the return of the Run() method.

     

    To keep things straight, I named the target method MainAsync().  This is where I will place all of my code that would have normally been in the original Main() method.  From this point, anything I want to test; whether it be Async/Await or not, it "just works".

     

    A couple of side notes:

     

    It does have to be a function, but since I'm not actually needing to return a "result", we will be returning Task.  This is necessary for the Async/Await functionality to work.  The rule is either to return Task(Of [type]) or just Task.  Whenever you add the Async keyword to an existing Sub in other project types, this is only allowed on events and only in projects that have an understanding of this concept.  There is a ton of behind the scenes compiler magic that occurs and the only place where this should be done is where it's been "blessed" by the platform/compiler teams.  For all code that you write, stick to Function with either a result of Task or Task(Of [type]); keep it simple.

     

    The return of the Run method occurs as soon as the first Await is encountered in the target method; so in the above example, it happens immediately.  The Wait() method will pause the execution of the Main() method until the total completion of the target method. 

    04-13-2014, 10:01 PM by CorySmith to AddressOf.com
    Filed under: , ,
  • Further Adventures in WinRT - Part 1

    Working with WinRT, well, I'm just going to say it... sucks!  I'm past the "who moved my cheese" phase; so that's not why I'm making that statement.  It sucks because it is not completely thought out, requires that you have to jump through hoops that were solved by many other API stacks many years ago, and contains way too many conflicting stories, requires crossing too many API layers... in other words, it's either incomplete or not very well thought out.  With that said, there's not much I can do about it; if I want to target the Windows Store, I have no choice but to roll up my sleeves and attempt to trudge through the mess to accomplish the task at hand.

    These adventures will be done in a scenario(s) / solution format.  So let's get started.

    Background 

    It doesn't matter if we have a desktop, tablet, Intel machine, ARM machine or even a Windows Phone 8 device; storage space is limited.  As an application author, I want to be a good citizen.  It's bad form to write to the storage device(s) blindly without regard to the amount of storage space that is left.  Windows, as a whole, (to the best of my knowledge) does not work very well when it runs out of space (temp files anyone).  A Windows server is nearly impossible to log into remotely if the disk free space has reached 0.  This should never happen and the authors of software should play nice.

    Scenario

    So we want to write something to the storage device.  We want to be a good citizen; so let's see if we actually have enough storage space without risk of bringing the system to it's knees.  How do we do this?

    Adventure

    As a .NET developer using a framework that has been around for over a decade, the following "just works".

    Dim drive = New System.IO.DriveInfo(driveName)
    Dim available = drive.TotalFreeSpace

    Sorry... not available in WinRT.  After doing a bit of research, I was unable to determine any way of any kind to accomplish this task using the WinRT API.

    WinRT is also "sandboxed"; meaning that it does a tremendous (or hideous depending on your view) job of isolating what can and cannot be leveraged on your device without your permission.  Even given permission, there is only so much that a WinRT application can do; which means that there is a ton of things that it can't.

    So if it isn't in the WinRT API, your screwed... or are you?

    Solution

    As it turns out there appears to be a few "blessed" Windows API's that are allowed to be P/Invoked from a WinRT .NET application.  One of these is the Kernel32 GetDiskFreeSpaceEx function.  To utilize it, you'll need to create a "reference" to it by adding the following to a class.

    Declare Auto Function GetDiskFreeSpaceEx Lib "kernel32.dll" (
      ByVal lpDirectoryName As String,
      ByRef lpFreeBytesAvailable As ULong,
      ByRef lpTotalNumberOfBytes As ULong,
      ByRef lpTotalNumberOfFreeBytes As ULong) As Boolean

    So one way to get the free space is to use a reference to your application folder...

    Dim available, total, totalFree As ULong
    Dim appFolder = Windows.Storage.ApplicationData.Current.LocalFolder
    If GetDiskFreeSpaceEx(appFolder.Path, available, total, totalFree) Then
      Return available
    Else
      Dim err = Marshal.GetLastWin32Error
      If err = 5 Then
        ' Access Denied
      Else
        Stop
      End If
    End If

    Seems relatively straight forward and painless (once you figure out the Kernel32 declaration, understand how p/invoke, marshaling and the different method that "error handling" works in the Windows API --- or you just blindly copy/paste what someone else does and hope for the best).  Also, even though it's pretty obvious, you can see that it takes a few more lines of code to accomplish the same task compared to the .NET BCL (Base Class Libraries); appears to be one of those "one step forward, two steps back" kind of days.

    Here's the problem, what if your documents folder isn't on the same storage device as your application? Even if your application has been given permission to read/write to the documents location, you can not pass the path to the documents location to get a result.. instead, you get an Access Denied message.

    So I experimented further and found that passing "D:\" also fails.

    Hmmmm...

    I then attempted, as last ditch effort, "D:"... it works. WTF?!?!?! 

    Is this documented anywhere? Not that I could find.  What a wonderful (WinRT) time we live in.  At least I can get done what I need to get done, moving on.

    See you in the next adventure.

    02-03-2013, 10:44 AM by CorySmith to AddressOf.com
    Filed under: , , ,
  • Helpful WinRT Samples

    The following is a list of samples that I've found helpful as I continue to work on my first WinRT application:

    XAML AppBar control sample

    Demonstrates how to use the AppBar control to present navigation, commands and tools to users.  Of interest is the information on using Page.TopBar and Page.BottomBar (versus doing it as a Grid segment) and how to configure a global AppBar so you don't have to add these to every page.

     

    Sharing content source app sample

    Demonstrates how an app can share content with another app using classes from Windows.ApplicationModel.DataTransfer namespace.  This provides the ability to share Text, URIs, Files, Images and custom content between multiple applications through a common UI experience.

     

    I'll continue to add to this list as I find more...

     

    01-25-2013, 10:40 AM by CorySmith to AddressOf.com
    Filed under:
  • Cross-Platform Development with the .NET Framework ("VB Core")

    Disclaimer: Let me be clear in that I am ***not recommending*** doing what I'm about to discuss except for the specific scenarios where it is ***needed***.  With that said...

    When working with platforms that do not have full support for the Visual Basic .NET runtime; it can sometimes be difficult to get things working and you may even decide to purchase a tool to convert the project to C# and ditch VB.  (Again, ***not recommended***.)

    One way to get around this is to build your project in such a way that you are pretty much guaranteed that the code will execute regardless of the target platform.  This can be done, using VB (or C#), with relative ease in VS 2012 (and VS2010 SP1 with a free add-in) by leveraging Portable Class Libraries and choosing to target every platform on the list.  This will provide you an environment that comes pretty close to enforcing that you only use features and functionality that is available across all of the selected platforms.

    With regards to Portable Class Libraries and Microsoft specific platforms, this is a great solution.  However, if you want to target non-Microsoft related platforms (Android, iOS, Linux, etc.), these platforms may not have the same level of support.  However, all is not lost.  Microsoft, with the release of Visual Studio 2010 SP1, has accepted this to be the reality and provide for functionality to support these scenarios.

    There are three different features available to support these scenarios:

    1. Completely remove the Visual Basic runtime; forcing that you use only the functionality made available as part of the Framework. (/vbruntime-)

    2. The ability to reference a replacement version of the Visual Basic runtime; one from a third party or even one that you create in order to cover the functionality that you would typically utilize when the runtime is normally available. (/vbruntime path)

    3. Include the most basic functionality available through the Visual Basic runtime by embedding it within the assembly; thus removing the external reference. (/vbruntime*)

    Of these options, I believe that the 3rd option provides the best of both worlds.  All of the essential conversion functions, attributes, additional support for Try/Catch When, For Each, string comparison, Chr, Asc and a few "useful" (aka common) constants are included.

    This functionality is exposed through the command line compilers switches.  There is nothing in the Visual Studio IDE that provides access to this switch. 

    This is all fine except for one significant problem.  For any project of significant size, compiling your project from the command line to utilize these switches can be a very daunting task.  To complicate matters further, there is no way to specify this switch on the msbuild command line.  If only there was a way that this could be done.

    As it turns out, there is, in fact, no switch on the msbuild command line to handle this; however, you can modify the .proj file to include this support.  To do so, from within Visual Studio:

    1. Load your solution.
    2. Right click on the project in the Solution Explorer.
    3. Select the Unload Project menu item.
    4. Right click on the unloaded project and choose the Edit menu item.
    5. In the editor, find the first <PropertyGroup> section.
    6. Create a new line to this section and enter <VBRuntime>Embed</VBRuntime>.
    7. Save the file.
    8. Right click on the unloaded project and choose the Reload menu item.

    At this point, you may see a ton of errors related to functionality that is now missing. It appears that the IDE is also able to handle this flag; making it a bonus. (Disclaimer: I'm not sure as to how well it does this.)

    Now when you build your project, it will no longer include an external reference to the VB Runtime. This, of course, means that you will not be able to leverage many of the features that it provides; however, it does provide a means to use VB to target more platforms.

    12-17-2012, 11:25 AM by CorySmith to AddressOf.com
  • GW-BASIC 0.1.4

    I've made a few enhancements to the interpreter..

    • There is now a branding/navigation bar across the top.  This provides the ability to visit this website and access to additional functionality.
    • The files button (in the navigation bar) provides for a more modern UI over the 1980's era GW-BASIC commands FILES, CHDIR, RMDIR, LOAD, RUN and KILL.  Folders are in bold where files are normal.  The .. (period period) entry provides a means to easily CHDIR up one level.  This is essentially a direct port of the work I'm doing for the Window Phone version.
    • CTRL+V and CTRL+X in direct mode will interact with the OS clipboard for copy/paste support.  CTRL+V (paste) will pipe whatever is in the clipboard into the interactive interpreter; in other words, it will emulate typing in the characters into direct mode of the interpreter.  CTRL+X (transfer to clipboard) will take the in memory source code and copy it to the clipboard.
    • Thanks to feedback, someone has provided me with several key codes that are used on OSX; so I think I'm getting a lot closer to having the keybindings working correctly on Macintosh machines.
    • The SYSTEM keyword has been modified so that it will PRINT various environment information so that globalization and localization can be handled going forward.
    • On systems that have different keyboard scan codes, the interpreter will print acknowledge this key being pressed with the associated key code.  This is used to assist in creating the appropriate keybindings; so keep sending in the feedback.
    • Adam Zuckerman pointed out issues with RENUM and LINE INPUT.  LINE INPUT has been resolved and the RENUM one is "sort of" resolved.  It "works", however, I'd like to spend more time on this in the future.  He also brought up the copy/paste idea; which I thought about previously but set aside since it wasn't within scope.  However, he sent in several code snippets via email and lack of having the ability to copy from email and paste into the interpreter was a right royal pain... so problem had to be solved. ;-)

    Additionally, several people pointed out that couldn't find where to join this site; as it turns out, it was turned off.  Doh!  This has been corrected and you can join by using the link in the upper right hand corner of the screen.

    Thanks to the amazing number of emails; please keep the feedback going.  It's amazing how many people have had positive things to say.

    05-03-2012, 12:00 AM by CorySmith to AddressOf.com
    Filed under:
  • GW-BASIC

    I've been working hard since I got back from England on all aspects of the interpreter.

    Language

    For the most part, I think I have most of the language covered.  I've added a few extra keywords; however, the primary purpose is the have as much compatibility with the original as possible.  Most of these have been implemented using the documentation as a reference; however, it has become apparent that the documentation might not be as accurate as actually running the code in the original.  So I'm constantly finding cases where tweaks are having to be done to accomidate the differences between what the documentation states and what the original version actually does.  With that said, everyday there seems to be less and less of these differences. 

    Editor

    Spent a bit of time working on the "editor' in an effort to have it work similarly to the original; including a few quirks since some samples seem to rely on these in order to accomplish animations.  I hear what your thinking; animations and the editor?  Yes, the last line (line 25) is treated as a special case in not only in edit mode but at runtime.  I had to do a bit of rework in order to accomidate this quirky behavior; but I think I've got a handle on it.  Tests I've managed to put together are producing similar results. 

    DOS 1.1

    I have the majority of the samples included with DOS 1.1 working; without sound.  More on this in a moment. 

    Graphics

    I think I have full support for CGA and EGA level graphics nearly completed.  This includes colors, palette, pcopy, get, put, etc.

    File System

    I've stepped back from the web service based file system and have since replaced it with isolated storage and applied this to both the Silverlight and Windows Phone versions. 

    Improved Performance 

    Thanks in part to my visit to Redgate, I've been able to use the ANTS Performance Profiler to narrow in on where some of the performance issues exist in my interpreter.  Using this information, I was able to increase the overall performance by about 50% in the Silverlight version.  Experimenting with the Windows Phone version, I found that the majority of the performance issues were with how the screen is being refreshed; not necessarily in the actual interpreter.  After discussing the issue with Chris Koenig; he offered a suggesstion that, after a bit of research and experimentation, took everything to a whole new level by splitting the drawing between two different phases.  This model has also been applied to the Silverlight version and seems to work pretty well.  In the end, if you haven't looked at the ANTS Performance Profiler... take a moment to do so.  It's an awesome product!   I have nothing but nice things to say about the product, the team members that work on it and shared their insights with me and thanks to Redgate for playing host while I was in England.

    Windows Phone 7

    I've built a basic UI for the Windows Phone that works to make the DOS interface more user friendly in a thumb based device while still holding true to the original.  There is definately more that I can do; however, for now it seems to be a good start.  It now includes pinching and movement on the display surface, a special keys panel for keys not included on the phone interface, a basic UI that sits on top of the interpreters built in commands for file management that allows you to browse and manage through a more modern touch friendly interface and common commands available through the application bar and menus, basic support for tombstoning, prompting against accidental closure, isolated storage used for virtual file system, landscape or portrait layout and, as already mentioned, significant performance improvements.  I think I'm going to try to submit it for publication in the marketplace this coming week.

    Silverlight

    Still using Silverlight 4 at this point; however, given a few recent developments, I may be moving this to Silverlight 5 very soon.  I'm hoping that the sound api's included in v5 will go a long way to remedy the shortcomings that I've experienced previously.  I think these api's also are available on the phone, however haven't had a chance to reallly dig in.  I've also added the ability to drag and drop a .BAS file directly onto the surface and the interpreter will load the script into memory and execute it immediately.  A real time saver for files that you may have available already (or download).  I'd like to get copy/paste support working; however, my initial attempts are a little disappointing due to the security protections in place making the process a little clunky.  I'm also going to look into adding a "Save As" feature and a "Open" feature that allow you to import/export .BAS files using the standard windows most people are already accustomed to.  One last addition is, which most likely change, the addition of a "speed up" poke.  By default the interpreter processes a batch of statements per cycle; which right now is around 60.  Using this POKE, it's possible to modify how many are being processed each pass from 1 to a little over 1000.  So the default setting is POKE 0, 15 where the 0 is the address used and 15 is 1/4th of the processed statements per cycle.  POKE 0,0 will process 1 statement per pass.  Really, really slow; however, great for debugging the interpreter.  The current setting seems to be pretty close to what DosBox is running GW-BASIC.

    Sound

    I've already touched on this a little.  It seems that all of the best examples have sound to one degree or another.  I've got a lot of work in this aready to get done, which starts with the simple BEEP statement.  What is implemented at this point is close, but I need to modify it to be a square wave.  The SOUND statement plays sound; however, does not incude the blocking async behavior of the original which appears to be utilized by many samples as a means of CPU throttling in loops.  Finally, the last known issue is that sounds less than 2/10ths of a second appear to not produce any noise in Silverlight.  Once I solve these issues, I'll be able to work on implementing the Music Programming Language in order to finish the PLAY statement and the associated ON related functionality. 

    Where can you start playing with the work in progress?

    http://www.addressof.com/basic/

    Enjoy!

    04-29-2012, 1:32 AM by CorySmith to AddressOf.com
    Filed under:
  • Cambridge, England, UK

    Next Monday, I'll be headed to the UK (Cambridge) for a "vacation".  As it turns out, this is also the home of Red Gate software, makers of SQL Toolbelt, ANTS Profiler and .NET Reflector.

    I'll be spending some time with them while there; so if you have any questions / comments you'd like me to pass along, feel free to send them my direction.

    I'm not, in the slightest, embarrased to admit that I'm pretty excited to hang out with the team now responsible for .NET Reflector.

    03-19-2012, 9:57 AM by CorySmith to AddressOf.com
  • End of year wrap up (2011)

    BLOG

    I'm currently in the planning stages to rebuild this site.  I've delayed doing this for a long time since I didn't want to "break links"; however, one reason why I don't contribute as much as I used to is the fact that I enjoy the comment interaction.  Thanks to blog spam, I had to disable anonymous comments and, since that time, my posts have slowed way down.  (Yes, CAPTCHA controls exist; however, it's not that straight forward to implement on this now aging copy of community server.)  So, I've made the decision that it is time to do whatever is necessary to kick start things back into full gear and if this means that web links are broken in the process... so be it.  I'll investigate ways to accommodate the change; however, at the end, it's time to get'r'done.

    Movie Jukebox

    For those following along (for a while), I have another pet project that I built for my own purposes and have enjoyed the fruits of since that time.  I have four 400 disc DVD players connected to Media Center that allow me to choose among 1600 movies at the press of a button; and the overall cost of the hardware is amazingly small in comparison to other options.  I was recently approached by a long time friend regarding his desire to attempt to market the project and we made our first sale last week!  It's officially a product now!!!!  For full disclosure, I did have to address a few issues that I was ignoring (I knew what I was doing after all) and made a few enhancements to actually productize it for a v1.0 release.

    Fort Worth .NET Users Group

    I've been knee deep in working to get the FWDNUG on track now that I'm the acting president.  Let's just say that it's been an adventure up to this point; however, I think things are starting to really come together and 2012 is starting to look like a very good year for the members of the group!

    I also want to say how much fun the end-of-year party was; how often can one say that thanks to a .NET users group I got to shoot an AR-15, an AK-47 and a Colt .45! :-D

    VB6 -> VB10 Comparison

    Look for additional entries on this to come in the first part of January.  Additionally, once VB11 is made available, I'll be sure to do a follow up for any items that are appropriate.

    BASIC

    The pet project is still moving nicely along.

    Parser/Interpreter

    I think I've pretty much gotten the parsing and interpreter where I'd like to see it; at least for this project. The performance is pretty good and works pretty well on Windows Phone 7.

    Portable Library

    My decision to switch to the portable library project was, as far as I'm concerned, a very good one. It does force me to have to think through how I'm going to implement portions of the project so that implementation can be segmented across different platforms, which at times can be a bit daunting in the midst of "just getting it done". However, even with the additional work that is involved, I do believe that the results are paying off.

    Display

    The "IDE" portions is pretty much 100% as well as most of the ANSI style "graphics". Additionally, CGA mode is mostly complete (except for my new arch enemy... CIRCLE). As a follow up to the last post, the "last line issue" has been resolved by no longer trying to reproduce the behavior of the original GW-BASIC... which is something that seems to be impossible because two different versions of GW-BASIC did it two different ways... so I decided to "fix the bug" and move on.

    Keyboard

    Working pretty well; however, I think I'm going to re-address this at a later time so that it is based on "scan codes" at a lower level and works across the various keyword appropriately.

    File System

    The file system over web services idea is working pretty well; however, there are significant issues that I've encountered due to a budget host environment. Since my last post, I am now interested in attempting to build this over SkyDrive... so we'll see where this goes as we move into the new year.

    Sound

    Silverlight 5 has been released, so now I can see if the improvements to low-level sound will help solve some of the issues I was facing. I'll update once I know more.

    Keywords

    As of this writing, 176 keywords have been implemented. For the most part, the majority of these keywords is pretty complete.

    Compatibility

    All of the code that I've attempted to execute from the BASIC Computer Games - Microcomputer Edition book (c. 1979) works great.  I've been playing Hunt the Wumpus; that sure brings back a few memories. ;-) 

    One of my original stated goals was to get this to the point where the original, unmodified, DONKEY.BAS code would execute as close to the original as possible. As of this writing, the game can execute with only one minor modification to the original code; the culprit at this point is the SOUND statement, of which I've already mentioned I'm having to get a bit creative to solve. The issue is not whether or not it can play sound; the SOUND statement was used as a means to throttle the game loop, which means I need to get my sound statement working the same.  In a world (Silverlight) where everything seems to want to be async, it's proves to be a little bit of a problem but I think I've got a solution worked out.  Once done, the goal is to get all the original .BAS files included with DOS version 1.1 working. 

    Another interesting tidbit is that modifications had to be made to accommodate the actual sample code instead of relying 100% on the official documentation which neglects to mention a few quirks that I knew all those years ago but have since forgotten; such as the "optional" end quotation on string literals. If it's in the documentation, I couldn't find it by scanning over it.

    Summary

    I'm still having a blast working on this project and can't wait to see where it will lead. It's so much more fun now that it's to the the point where the original code comes to life.

    Conclusion

    Be sure, I have a few other tidbits that I'm working on and a ton of ideas that I'm working through with regards to this site; so stay tuned.  Let's just say if 2012 is the year the world comes to an end... I've got a lot of stuff on my plate that I want to accomplish before hand. ;-)  In all seriousness, I look forward to 2012 and hope that everyone enjoys success and prosperity in the new year.

  • BASIC - Status as of 2011-07-27

    Wow!  It's been a month since my last update regarding this pet project.  To be fair, I did go on vacation for a week, so it's really only been about 3 weeks of spare time effort on this.  With that said, I think it's moving along at a rather excellent pace.

    Parser 

    Additional work done to the parser.  Decided to remove a lot of the validation and treat this layer as more of a tokenizer that can then be further validated at the interpreter level.

    Portable Library

    After getting everything working in Silverlight and continuing the project for several weeks, I recently attempted to get the interpreter working in Windows Phone 7.  I created a new project and copied over the code.  Tons of errors.  Several VB language features not available, more .NET Framework elements MIA and slight differences with Silverlight implementation on both devices.  I remembered a discussion about a relatively new project call the Portable Library Project.  After getting the correct service packs and such, was able to create a Portable Library version of the interpreter which required that I split several pieces out (and up) to a platform specific layer.  The portions are labeled as Display, Keyboard, Sound and File System.  Once done, I now have a core assembly that is capable of being leveraged across .NET 4, Silverlight 4, Windows Phone 7 and Xbox 360 (in theory).

    Display

    A lot of work was still to be done since the last update in order to fully handle the "IDE" aspects; mostly related to what I'm calling "last line issues".

    Keyboard

    OK, I thought Silverlight was limited with regards to intercepting and working with the keyboard.  Wow!  Windows Phone 7... you're my new worst enemy.  Why do you have a KeyUp/KeyDown event yet never can tell me the state of the Shift key?  I had to work a serious hack that takes 50+ lines of code to do what should realistically be less than 3.

    I also had to handle the concept of a key buffer so that "type ahead" would work while a pending task was executing (file system).

    File System

    One goal that I had in mind was I wanted to support the file system functionality in such a way that it was not "local storage".  I'd like to make it so that people can share content among one another, so it was necessary to create a file system that would work over the wire.  All of the "IDE" functionality is fully supported.  Eventually this layer will have to handle random access file functionality necessary to implement various file I/O keywords (which are not completed as yet).

    Sound

    The 5th keyword in the GW-BASIC manual is BEEP.  Since BEEP is an 800 Hz for 1/4th of a second tone, it made sense to tackle two keywords at once since SOUND 800, 4.55 produces the same result.  A fortune would have it, Silverlight 3+ has the ability for me to fiddle with the PCM stream.  It does have it's problems and, apparently, Silverlight 5 might be able to provide some solutions to the "lag" that I'm experiencing.  I have not tried this code yet on WP7; however, what is coming to Silverlight 5 is already supported on the phone implementation of Silverlight.

    Keywords

    As of this writing, 114 keywords have been implemented.  This is not to say they are 100% completed, but they are implemented enought to start testing and tweaking.  Additionally, definable functions, arrays, nested for loops, etc. are all working.  I've also implemented a few useful keywords that are not part of GW-BASIC which include OLD, LBOUND, UBOUND, LCASE$, and UCASE$.  LBOUND and UBOUND have been very helpful in working with getting arrays working.

    Compatibility

    As you can see, a lot of work for three weeks of spare time.  To put things into perspective, I think I have all keywords implemented based on documentation for the Dartmouth Oct'64 version as well as all of the listed keywords necessary for both BASIC Computer Games - Microcomputer Edition books (c. 1979) which is based on Microsoft Basic, Revision 4.0.  I have not done any testing of the programs included as a lot of them are kind of long.  However, I've also been working my way through "A Bit of IBM BASIC" and all code samples up to page 90 are working.  There's still a potential for a lot of bugs, so testing...testing...testing...

    Summary

    So far this has been an awesome side project and there is still a ton of things to complete.  I'm having a lot of opportunity to experience several technologies that I have not been able to play with in my "day job"; so this alone is worth the time and energy going into this project.  Who knows where it will end up; however, I have to remind myself to not focus on the destination, otherwise I'll miss out on the splendor that is the journey.

    07-27-2011, 12:54 PM by CorySmith to AddressOf.com
    Filed under:
  • VB10 vs VB6: Variants are not supported.

    This is part of series of posts categorized under VB10 vs VB6.

    "Variants are not supported. Object is now the default data type."

    Wow!  Really?!?!?  Someone actually "defending" (or rather complaining) that Variants are not supported?  In any case...

    Based on the wording of the entry, it is completely false to say "Variants are not supported.".  They are completely supported.  However, it is also true that Object is now the default data type.  I know that seems a little confusing; so let me explain. 

    In VB6, the default "unknown" type was a Variant.  In VB10, the base type (since VB10 is a true object oriented language) is Object; of which all types derive.  It is also important to understand that Variant is *not* a native data type in VB10. 

    So how, you may ask, does VB10 have support for Variant if there isn't a data type of Variant?  Think about it for a moment.  Where is Variant needed?  VB4 (32-bit) through VB6 is a COM (aka ActiveX / OLE Automation) based product.  Because of this, Variant made sense since this is a "native" type of the COM world.  .NET has its own type system; of which Variant is not a "native" type.  However, .NET is great about interoperating with other technologies which includes COM.  Because of this, there is full support for the Variant data type when working with COM interfaces.

    Verdict:

    VB10 does have support for Variants; so you be the judge.

    07-27-2011, 12:31 PM by CorySmith to AddressOf.com
    Filed under:
  • VB10 vs VB6: Option Base

    This is part of series of posts categorized under VB10 vs VB6.

    "Option Base is not supported."

    OK, time for a little history (extremely shortened).  In the beginning, BASIC had 1 based arrays (May 1964).  The creators of BASIC realized that this had certain limitations to it so about five months later when version 2 of the language was released (October 1964), the arrays changed from being 1 based to 0 based.  Fast forward nearly 14 years (1978) and the language was going through the process of becoming a "standard" and the committee related to doing so fought among themselves until a compromise was made by creating OPTION BASE n so that the users of the language could decide for themselves what the base array number would be.  However, 0 was chosen as the default.  But wait, it gets more interesting when you fast forward another 6 years (1984) to yet another "standard" and they've changed the default from a 0 to a 1.

    So you can see this issue has existed LONG before VB and will probably continue for a very long time.  There are definately cases to support both arguments; however, one thing that is interesting to note is the following statement:

    "But there was still a major problem for beginners.  They shouldn't have to learn about the OPTION BASE statement, but they would be surprised when they used 'DIM X(10)' and got a list with eleven elements in it." -- Kemeny/Kurtz @ 1984.

    So where does this leave us.  First I have to state that this statement is, in fact, correct.  OPTION BASE does not exist in VB10.  However, I can somewhat see that since one of the major goals of .NET/CLS/CLR is to allow multiple languages to interoperate seemlessly with one another.  An array in each of the supported languages works the same across all supported languages.  OPTION BASE would require the VB compiler to have to do all sorts of translations, which I suspect would not be too much work to accomplish.  However, if someone documented a method in VB using OPTION BASE 1 and someone in C#, F#, Ruby, Python, etc. were to try to utilize the result; they'd be left in bit of a quandry as to why array(0) exists.

    However, let's say for argument sake that cross language isn't something a particular developer ever has to face.  Let's say that this developer is going to only "consume" the produce and never produce anything that will be reused by anyone else.  So in this case, it might be nice to have the ability to define the base of an array to be 0 or 1 depending on their specific needs.  The problem that I've found is that circumstances seem to be so varied regarding when 0 or 1 seems to be the more natural choice that, at least to me, I find it simpler to keep the foundation at one level so that I know where I stand.  Meaning, I know that an array always starts at 0 so all my code can be built as such.

    I do also have to say I understand, and even agree, that it'd be nice to have the ability to create an array that has a more natural feel to it depending on the circumstances at hand.  So....

    At the end of the day, OPTION BASE probably isn't needed.  The ability to define an array with a "custom" lower bound, on an array by array basis is what I would say would be a much more appropriate solution.  VB10 has plenty of ways to accomplish this, of which I've already covered.

    Verdict:

    This discussion has been going on for 47 years now... so who am I to sway it one way or the other.  With that said, technically VB10 does not have OPTION BASE, so it seems I have to give this one to VB6.  However, as covered in the lower bound array post, VB10 has an incredible amount of flexibility in creating "arrays" / classes to better handle the specific needs with regards to a collection of information.  So I leave this one as an excercise to the reader to draw thier own conclusion.

    06-29-2011, 8:55 AM by CorySmith to AddressOf.com
    Filed under:
  • BASIC - Status as of 2011-06-27.

    I still don't have a name for the BASIC project I'm working on; however, would like to share some of the progress I've made.

    Parser (technically a scanner/ validating parser) layer is far enough along that I think it will be pretty simple to continue to add additional keywords to it without any major redesigns involved.  This has taken the most amount of the overall projects time; as I'd hope everyone would suspect.  It's got to be right and it's got to be fast.

    Switched the project from Windows Forms to Silverlight and had to fix the 100+ errors introduced because of the limited nature of the Silverlight CLR.  Built a test harness that would allow interactive testing of the Parser.  This provided me a little bit of room to experiment with syntax highlighting using the Silverlight RichTextBox control as a proof of concept.  Once I got this working, on to the next phase.

    Built a Display object that would allow me to seperate the implementation of the display away from the actual implementation afforded by the platform.  The goal is to reproduce the experience of DOS within Silverlight with the possibility of doing the same through Windows Forms, "Windows8", WPF, XNA or whatever else may come along.  To do this, I'm doing a per-pixel implementation rather than leverage the ability to render Silverlight specific objects.  Yes, this even means that I'm drawing my own fonts. ;-)

    Once the initial Display object was done, moved on to creating an "IDE".  Initially, for nostalgia sake, I'm working on recreating the GW-BASIC experience.  Where I go from there is left to a future decision.  Pretty much got that working, now on to the Command Parser.

    The Command Interpreter (which leverages the Parser) is still in it's infancy; however, commands like LIST, KEY, NEW, etc. are working as well as the "editing" functions associated with the source list.

    So all in all, not bad progress; however, this is the point where I think things will begin to slow a bit since it's all about implementing the various keywords as well as beginning work on the actual interpreter.  I've already build a rough interpreter in the Windows Forms implementation; however, this time I'm putting a little more thought into it.

    The key thing I'm keeping in mind going forward is trying to keep separations of concern in mind as I design things.  I caught myself wanting to add validation logic in the scanner/parser for a range of a parameter... which should be done at the compiler/interpreter level since the purpose of the scanner/parser is to just "parse" the text into a token tree.  It's up to "something else" to verify that the parameters are correct.  (Some could probably argue this, however, at this time, this is the way that I'm designing it.  We'll have to see if I change going forward or not.)

    Thanks for following along, see you in the next update.

    06-27-2011, 11:53 AM by CorySmith to AddressOf.com
    Filed under:
  • Back to BASIC!

    Before I make an announcment, I have to make it ubundantly clear that I'm a huge fan of Microsoft Visual Basic and do not have any significant complaints on where Microsoft has travelled with the language and, without risk of violatinig NDA, where Microsoft is planning on going.  I also have to state that I do own stock in Microsoft (as it turns out, it's the only company at this time that I do own stock with); so kind of provides an idea of the faith that I have in the team at Microsoft working on the language and tools that make up Microsoft Visual Basic.

    With that said, I've been interested in some time about how compilers work and what is involved in building them.  I also have been, again for some time, very sad that BASIC is no longer shipping with the OS.  It just seems like something has been missing.  I've also had several people approach me recently proclaiming "I want to learn how to write software."  It got me to thinking, "where do they start?".  So my initial reaction was to think about what was already available on every persons computer.  The web browser!  So without meaning to insult those that make a living building HTML, I don't really consider that a "programming language"; to me, it's a document and I do have to tip my hat to those that can build beautiful pages working with HTML/CSS.  However, there is this thing called JavaScript (or JScript if you prefer).  The problem is that in order to write an "application", you will have to learn at least a little bit of HTML (concepts and tags), possibly some CSS (could skip, but hey, you'll know it'll be there eventually), the JavaScript language and all that entails as well as possibly having to learn something about the DOM.  Wow!  What ever happened to just being able to...

    10 PRINT "HELLO WORLD!"

    ... execute it and it provided immediate feedback?  Because of it's simplicity, you could experiment and "play".  What ever happened to "playing"?  I remember a time with writing code was ***fun***.  Now it seems to be a world of "if you don't write it this way, it's crap" and you have to learn several technologies, concepts, programming best practices, etc. before you can even begin to get the computer to bend to your will. 

    So it got me to thinking.  At this point, it was just thinking...

    Then I remembered the Microsoft Research project called SmallBasic.  Interesting concept.  Disappointed in a couple of respects; one in particular is the usage of square brackets as indexers on arrays.  I wouldn't have a huge problem with this if it wasn't for the fact that the environment has a pretty large button called "Graduate" that is supposed to convert the "project" to a Microsoft Visual Basic project; which, of course, VB does not use square brackets for array indexers.  So for the inconsistency and the fact that it also will not translate TextWindow.WriteLine("Hello World") to Console.WriteLine("Hello World"), I have to express a little bit of a level of disappointment.  I will say, regarding SmallBasic, I do like some of the intellisense-esque stuff they are doing. It is pretty simple to get started and, again, I love the concept. I suspect that it was built by someone that was not from a BASIC background, and for that, I might be a bit critical.

    Additionally, I have David Ahl's book circa 1978 called Basic Computer Games.  It appears that he updated the material for SmallBasic and has a sample chapter on his site that I could use to compare the new with the old.  The new game in the sample chapter is something like 790 lines of code while the original is something like 45.  Huh?  OK, after digging a little deaper, it appears that the code is not a literal translation and contains a few bonuses; but still... 45 lines to 790 lines? 

    So, again, it got me to thinking.

    What would it take to return back to my roots so to speak and have a very simple version of BASIC on top of the .NET Framework?  Would there be any value in doing so?  After a bit of research, experimentation and thought, I've decided that at least ***I*** would find this valuable if for nothing more than the learning experience that it would have.  So with that said, I'm officially working on BASIC for .NET.  There's not a whole lot of "Visual" and I am starting with the original Dartmouth documentation (circa October 1, 1964) as the "language spec".  Once I have this milestone done, who knows where I'll take it next.  Actually, for full disclosure, I already have a few ideas. ;-)

    As a side note, all I can say is WOW!  It's amazing to see where BASIC started and where it is today.  Just think, it's only a little over 3 years away from being a half a century of history.  BASIC has also kept the name intact throughout all of these years.  Contrast that with CPL, Basic CPL, B, C, C++, etc.  (No, BASIC isn't the oldest, longest running language, I think FORTRAN holds that title... and yes, there is a version of it for .NET (Fortran 95 spec I think.), but it does predate C by almost a decade.)

    So one day soon, you'll be able to build a source file with a .BAS extension, pipe it through a compiler and run an executable (.NET assembly) that consists of:

    10 PRINT "HELLO WORD!"
    20 GOTO 10

    I'll also be discussing topics related to this project as things progress.

    I will have to leave this with a note.  Some may wonder why I would choose to use BASIC as a basis for the language when building a compiler... the answer is... "Because." and leave it at that. It's my compiler and I can do it however I want. ;-)

    06-20-2011, 11:03 AM by CorySmith to AddressOf.com
    Filed under:
  • VB10 vs VB6: Dynamic Arrays Usage In Structures

    This is part of series of posts categorized under VB10 vs VB6.

    "Dynamic arrays are not allowed within structures (UDTs) "

    I'm kind of scratching my head by this statement as I'm not entirely sure what he means by "dynamic arrays".  I will assume that he means:

    Structure SomeType
      Public SomeArray() As Integer
    End Structure 

    The above is an array of integers that has no defined indexer.  Additionally, the above code does not present any sort of error within Visual Studio.

    Dim s As SomeType
    Redim s(20)

    Again, the above code appears to be syntactically correct within Visual Studio.  So we created a structure, defined an array and redimensioned the array. 

    However, with the advent of Generics and the flexibility that they bring to the table, I'd modify the structure so that it utilizes a Generic List as follows:

      Public SomeArray() As List(Of Integer) 

    You would, however, have to initialize the array as it would begin "life" as Nothing.  To do this:

    Dim s As SomeType
    s.SomeArray = New List(Of Integer) 

    From here, you could use the Add, Insert, Remove, etc. available on the Generic List to truly provide a "dynamic array" that is far above and beyond what was available with VB6 "native" arrays. 

    Verdict:

    So unless I'm misinterpreting the statement, VB does fully support "dynamic arrays" in user defined types (Structures).  With that said, I have to hand this one to VB10.

    Update(s):

    Well, technically not an update as it was in an email I got before I finished writing this entry, Bill McCarthy (MVP) points out that this "issue" may be related to usage of dynamic arrays in stuctures with regards to Win32 API and the "default marshalling" done.  This is a very good point and one that can be anwered by pointing to the previous entry where I point out that the .NET interop story is much better than the VB6 counterpart.  With that said, I'd like to point you to the complete list of ways that the .NET interop mechanism can do using the MarshalAs attribute.  See MSDN Unmanaged Type Enum.  As you can see, you have a plethora of choices specifically regarding arrays.  Thanks Bill for bringing this to my attention.

    06-20-2011, 10:42 AM by CorySmith to AddressOf.com
    Filed under:
  • VB10 vs VB6: Array Lower Bounds

    This is part of series of posts categorized under VB10 vs VB6.

    "Arrays may not have a lower bound other than zero."

    This, as it turns out, is absolutely true; however, with a twist.  Although VB10 does not allow the "native" array type (the one defined by the language), there are a ton of ways that this can be handled.  I would also argue that the multitude of ways that are available would also provide a solution that better suites the needs for circumstances where having a different lower bound is desired.

    Let's see how you could accomplish similar functionality without delving into the .NET Framework.  The most direct solution is to handle the lower bound yourself by determining the offset from 0 and access the array accordingly.

     Dim lbound As Integer = 10 
     Dim ubound As Integer = 20 
     Dim
     a(ubound - lbound) As Integer

     
    a(10 - lbound) = value
     

    So you could easily handle this by utilizing some simple math.  Let's say, however, that you'd like to have it programatically similar to VB6.  You could create a class that abstracts this math and provides a very similar experience to VB6. 

     Dim a As New VbIntegerArray(lbound, ubound)
     
    a(10) = value

     The code for the VbIntegerArray is as follows:

     Public Class VbIntegerArray

      Private m_lbound As Integer
      Private m_int() As Integer

      Public Sub New(ByVal lowerBound As Integer, ByVal upperBound As Integer)
        Me.ReDim(lowerBound, upperBound)
      End Sub

      Public Sub [ReDim](ByVal lowerBound As Integer, ByVal upperBound As Integer)
        m_lbound = lowerBound
        ReDim m_int(upperBound - lowerBound + 1)
      End Sub

      Default Public Property Item(ByVal index As Integer) As Integer
        Get
          Return m_int(index - m_lbound)
        End Get
        Set(ByVal Value As Integer)
          m_int(index - m_lbound) = Value
        End Set
      End Property

    End Class

    Not too difficult.  Note, this code is based off of a blog entry by Phil Weber.  I made a few minor changes to, so feel free to use this or his depending on your needs.  Using this method requires that you create a seperate class for each variable type you want to have an "array" with a different lower bounds than 0.  Another approach, as mentioned toward the end of Phil's blog entry is the possibility of using Generics.  I've re-wired the above class to create a generic version.  The internal implementation is not a 'native' language array, but instead is leveraging the Generic List object.  Because of this, I am having to prepopulate the "array" with items so that the indexer works as expected.  Furthermore, because it is a generic type, I'm populating each entry with Nothing (NULL).  Outside of that, everything is basically similar to the direct implementation.

    Public Class VbArrayGeneric(Of T)

      Private m_lbound As Integer
      Private m_array As List(Of T)

      Public Sub New(ByVal lowerBound As Integer, ByVal upperBound As Integer)
        Me.ReDim(lowerBound, upperBound)
      End Sub

      Public Sub [ReDim](ByVal lowerBound As Integer, ByVal upperBound As Integer)
        m_lbound = lowerBound
        m_array.Clear()
        For index As Integer = 0 To upperBound - lowerBound
          m_array.Add(Nothing)
        Next
      End Sub

      Default Public Property Item(ByVal index As Integer) As T
        Get
          Return m_array(index - m_lbound)
        End Get
        Set(ByVal Value As T)
          m_array(index - m_lbound) = Value
        End Set
      End Property

    End Class

    To utilize the above code, you can do the following:

    Dim a As New VbArrayGeneric(Of Integer)(10, 20)

    For index As Integer = 10 To 20
      a(index) = index
    Next

    For index As Integer = 10 To 20
      Console.WriteLine(a(index))
    Next

    In addition to the ways described, the Generic version of the Dictionary class might also be leveraged to provide similar capabilities.  By using a dictionary, you would no longer be bound (no pun intended) to a lower and upper bound since each entry has a unique key and can be of any value. If interested in seeing this approach, please let me know.

    Verdict: 

    This one's hard to provide a clear verdict.  On the one hand, it's clear that the 'native' language array does not support arrays with a lower bound other than 0.  On the other, there are a plethora of ways to implement "arrays" available in VB10.  Because of this, I'm going to call this one a wash.  (Note: I may come back and give this one to VB6 depending on how the rest of the list goes; only because of the way that the entry was stated, VB10 does not do exactly what it states.)

    Update(s)

    Bill McCarthy (MVP) writes in : "I'd add IEnumerable/IEnumerable(Of T) support to the classes passing it straight through to the array's GetEnumerator.  And this is actually where it gets interesting. If I recall correctly For Each with arrays in .NET is optimised; you'd probably lose a little bit with the custom class, but as long as it was IEnumerable(Of T) as opposed to the non-generic version there shouldn't be any boxing overhead. That said, I seem to recall (but don't quote me on this as it is a LONG time ago), that VB6 had perf problems with For Each (pCode versus native may have changed the outcome too), as I think it went all variant gooey stuff ;) Anyway, real world implementation in .NET, include IEnumerable(Of T)

    06-04-2011, 10:36 AM by CorySmith to AddressOf.com
    Filed under:
  • VB10 vs VB6: Private Class Variables

    This is part of series of posts categorized under VB10 vs VB6.

    "Private class variables are not private to the class instance."

    This is another one of those "huh?" responses.  However, I'll go ahead and discuss it anyway.

    As documented in the VB6 Programmers Guide on page 429,

    "It's just as easy to create private data for a class; simply declare a variable Private, and it will be accessible only from code within the class module."

    Private mstrMothersMaidenName As String

    This is what I can only assume Karl is referring to with the statement that private class variables are not private to the class instance.  Based on this, let's look at VB10:

    Class Class1
      Private m_mothersMaidenName As String
    End Class

    Class Class2
      Sub DoSomething()
        Dim c As New Class1
        c.m_mothersMaidenName = ""
      End Sub
    End Class

    I have to point out that this code will immediately draw your attention to it by draing a blue wavy line below it and in the Error List you'll see something similar to the following:

    'Class1.m_mothersMaidenName' is not accessible in this context because it is 'Private'. 

    At this point, you are not able compile the code until error has to be addressed.  Sure looks like the private variable is private to the class to me.

    Verdict:

    Not much to say, this one just isn't true. It was never true to the best of my knowledge so the nod, again, has to go to VB10.

    Update(s):

    Bill McCarthy (MVP) writes in : "I think this is referring to accessing private variables from *another* instance of the same class. Reason for its existence in .NET is two-fold:

    • first the addition of shared methods to a class: this is probably the heart of the technical reason why. 
    • it also comes in handy a LOT for operator overloading (equality operators), serialization etc."

    Interesting.  I can almost see this as being a possible point of contention. However, just because you can "see" it doesn't mean you can "use" it.   Serialization almost deserves it's own conversation; however, there are cases where you might need access to "member variables".  In any case, when they are set to private they are, in fact, scoped as such.  I may have to give this more thought.

    06-04-2011, 10:02 AM by CorySmith to AddressOf.com
    Filed under:
  • VB10 vs VB6: ByVal/ByRef within API calls.

    This is part of series of posts categorized under VB10 vs VB6.

    "Use of ByVal/ByRef directly within API calls is not supported."

    Huh?

    Declare Function SetEnvironmentVariable Lib "kernel32" Alias "SetEnvironmentVariableA" ( _
      ByVal lpName As String,
      ByVal lpValue As String) As Boolean

    The above code is syntactically correct in VB6 and VB10. Notice the inclusion of the word ByVal.  You could use ByRef as well.  Additionally, VB10 offers a plethora of additional options that allow you to further define how things are passed to various api implementations.  So the above statement could be written as:

    Declare Auto Function SetEnvironmentVariable Lib "kernel32" Alias "SetEnvironmentVariableA" (
      <
    MarshalAsAttribute(UnmanagedType.LPStr)> ByVal lpName As String,
     
    <MarshalAsAttribute(UnmanagedType.LPStr)> ByVal lpValue As String) As Boolean

    This will cause the strings to be passed as a long pointer to a string instead of a BStr.  Additionally, the Auto keyword will cause the interop process to use ANSI or Unicode strings depending on the target API.

    What I'm showing here just scratches the surface of what VB10 can do regarding interoperating with the Windows API's.  In any case, the ByVal keyword is definately there, so I'm not sure what Karl is trying to say with this one.

    Verdict:

    The statement that ByVal and ByRef are not supported is obviously false so I have to give this one to VB10.

    Update(s):

    Bill McCarthy (MVP) writes in: "Again my memory is getting rusty, but I think this refers to the use of As Any, then you could pass a variable out ByRef or ByVal.  Often the cause of many mistakes hard to track down as a variable address would be sent instead of the value etc."

    Bill apparently agrees with me regarding "As Any" being a "bad thing". ;-)  He does bring up a good point regarding ByRef/ByVal from the perspective of "how" interop works in .NET (thus VB10). Win32 API signatures as defined in VB most likely will not be identical in behavior with the move to VB10.  With that said, using a site such as http://pinvoke.net/ to verify your signatures is the first thing that I would suggest.  Yes, this means that the trusty Win32 API book by Dan Appleman is a little out of date; however, it's just the "signatures" that have to be dealt with since the .NET variety offers the granular level required to enable you to access **all** of the API available.

    06-02-2011, 10:54 AM by CorySmith to AddressOf.com
    Filed under:
  • VB10 vs VB6: As Any

    This is part of series of posts categorized under VB10 vs VB6. 

    Declare Sub ExternalMethodName Lib "SomeLibrary" (ByVal someValue As Any) 

    When working with Windows API's, you use the DECLARE statement to define the external method.  In VB6, you could use the As Any variable declaration; doing so would allow you to pass any variable type to the external method.  It's key to note, when I say any, I mean any.  VB6 would not protect you in any way against passing in something that you didn't mean to do so.  Sure, this puts the responsiblity on the developer to do the right thing; however, last I checked, I now have 4 cores in my machine that are hyperthreaded providing 8 processing pipelines along with 16GB of memory.  I want my development environment to do everything it can to help me write better software.  Leaving it up to me to write comments or remember what types can be passed is kind of, well, annoying.  Wouldn't it be great if there was some way that you could declare an external method that could support multiple valid appropriate variable types?  Oh wait, there is...

    Declare Sub ExternalMethodName Lib "SomeLibrary" (ByVal intValue As Integer)
    Declare Sub ExternalMethodName Lib "SomeLibrary" (ByVal stringValue As String)

    VB10 allows you to use overloaded method signatures.  As long as the parameters have a different signature, as defined by the number, order and type of parameters, you can create as many of these as you'd need.  By doing this, the IDE and compiler are able to protect you from passing in something you didn't mean to, thus helping you to write better applications.  And when using these externally defined methods, the correct one will be automatically utilized based on the variable type that you use.

    Verdict:

    So although VB10 does not support As Any, I'd say that this is a case where the language has evolved and it's a solid step in the right direction.  When moving to VB10, the IDE is really great about pointing out what variable type(s) you might be using and it takes only moments to rid yourself of the troublesome As Any pitfalls utilizing overloaded declares.  With that said, I'm going to give this one to VB10.

    05-31-2011, 12:13 AM by CorySmith to AddressOf.com
    Filed under:
  • VB10 vs VB6: VarPtr, StrPtr, ObjPtr

    This is part of series of posts categorized under VB10 vs VB6.

    As it turns out, I still have a copy of Microsoft Visual Basic 6.0 Programmer's Guide.  This was an excellent resource for learning VB6 and it's what I'll be using as a reference in these posts for comparison.

    With that said, I have to point immediately that VarPtr, StrPtr and ObjPtr are *NOT* mentioned in this Programmer's Guide.  These were functions that were "somewhat undocumented" and were only used by developers whom were pushing the limits of VB6 well beyond its original design and/or where they needed to work around the inherent limitations of the IDE, language and or runtime.

    Don't get me wrong, they were used in nearly every serious application ever developed in VB6; mainly by people who copied and pasted code they found elsewhere to work around the limitations in VB6 as time and technology marched beyond 1998.  Many of these developers had no fundamental idea of how these procedures they where utilizing actually worked under the hood, they were just trying to get their job done.

    When I was upgrading projects from VB6 to VB7, I encountered a ton of these with the highest encountered one being related to mouse/keyboard "hooking".  In every case, I found built in functionality either in VB, Windows Forms or .NET that completely removed the need to utilize these "hacks".

    With all that said, I find it interesting that Karl maintains the "Unofficial Documentation for VarPtr, StrPtr, and ObjPtr".  On this document, he states:

    "The VarPtr function has been in the BASIC language since long before it turned into QuickBasic and Visual Basic. VarPtr has been in the VB runtime since version 1.0."

    According to a post found here, VARPTR is one of the keywords that is specifically mentioned as being "keywords that are either not supported by VB or are being used in different context, or, have become properties/methods of some VB objects (and therefore could not stand as an independent statement)". It's been so long since I've used QB that I can't remember any of specifics one way or the other.

    I find it interesting that he points out that VarPtr was in QB; however, fails to mention that it worked a little bit differently... a complaint that he is making with the move to newer versions of VB.  I also suspect that there would have been some changes between its usage in in VB1 though VB4 when you transitioned from 16-bit to 32-bit.  What makes all the more interesting is actually reading his unofficial documentation where he points out that there are differences between VB4, VB5 and VB6 with this functionality and the work arounds you have to do to get it to be "right".  And he complains about the "duct tape" solution provided by VarPtr, et. al. being removed? 

    So what can one do when moving to VB10?

    I have to point out that many of the hacks that were required in VB6 that leveraged these keywords are no longer needed with specific regards to Windows development.  Additionally, for the times that this is not the case, the Win32 interop story in VB10 is much, much, much better.  Additionally, it's all 100% documented and 100% supported. ;-)

    Note: If someone would like to send me an small example of where these keywords were needed, I'd be happy to provide details about why they are no longer needed or how to leverage the Win32 API using VB10 in the cases where built in functionality does not already exist.   It'd be nice to have a specific example on this for future reference.

    Verdict:

    Given that these functions were for the elite of the elite VB developers; I'm going to go out on a limb here and state that if you could hack your way through things in this manner, leveraging the documented methods in .NET should make things a whole lot simpler.  For those that were just needing the results of these creative coders, a lot of this functionality is "included in the box".  Given those two factors, VB10 wins.

    Updates(s):

    Bill McCarthy (MVP) writes in: "StrPtr was often needed when calling Unicode API (assuming you pre-allocated the string) ObjPtr was sometimes used with windows subclassing calls: Was fraught with danger. I think Karl Peterson finally wrote an article for VSM a year or two ago admitting that using ObjPtr with subclassing could result in the wrong instance being called, and recommended to folks the use an external library for subclassing (one that ships with XP or later I think). Was kind-of funny to see it only took 10 years to admit it (lol)."

    My only reply: :-)

    05-29-2011, 6:12 PM by CorySmith to AddressOf.com
    Filed under:
  • VB10 vs VB6 (aka VFred vs Classic VB)

    A couple of weeks ago there was a rumor that was flying around regarding VB6 being made open source.  This was completely untrue; however, in the aftermath, the FUD machine has kicked back into gear.

    A lot of this FUD can be traced to a single source... Karl E. Peterson.  He created and "maintains" the VB.NOT l and can be credited with the term VFred.  This crusade of his, in my opinion, is directly or indirectly one of the main reasons why a lot of VB developers have decided stay with VB6, to find another platform altogether or, if they decided to move to .NET, decided to give C# a go "since it's a whole new language to learn anyway".  It's interesting to note that many of the features that VB has had all along are now being demanded by C# developers and my suspicion is that those whom are demanding these features are ex-VB developers.

    In any case, I still use VB and will continue to use it as long as I can possibly do so.  I think BASIC is one of the best languages out there and the fact that I've been able to utilize it for the past 30+ years stands as a testimant to that fact.

    I think that Karl should be following up on his list with each revision of VB and he, as best as I can tell, has not done so.  So he helped create the mess and is unwilling to do anything to repair the damage he's done.  With that said, I'm going to address his original list by comparing VB10 to VB6.

    To collect these together, I'll be using the VB6 tag.  This tag does not mean that I'll be switching back to VB6. ;-)  I've tried that a couple of times just for giggles and it's pure torture to work in that IDE after more recent version of VB.

    Before I get started, I have to point out a few things that he states on his site.

    On the list he states:

    "Before anyone spends hours writing "rebuttals" to the points below, it may help to understand the original purpose of this list. The points are not intended to highlight unintelligent design, in either Classic VB or VFred. Can that be said any clearer? The points are intended solely to demonstrate the enormity of incompatibility between Classic VB and VFred. That's it. In a nutshell, there is no backward- or forward-compatibility, between the two languages.

    Depending who you ask, each point below may be considered anywhere from "gratuitous" to "essential." Either way, if the feature in question is one you used in Classic VB, you will need to address this change, and determine what, if any, workaround may be available. But the point is, the fact a workaround is necessary indicates somethings broken. That something, in this case, is your code/investment."

    So basically he is saying, "Hey, all of this is broken and there's nothing you can do about it and Microsoft is going to do nothing about it.   And don't complain to me or try to correct me because, if any one item is different, it's all bad."

    Furthermore, he states:

    "So, without further ado, the bullets you will not see coming from Microsoft."

    Which, I think is irresponsible for the perspective that he obviously has not followed up on this list in the 5 versions (VB7.0, VB7.1, VB8.0, VB9.0 and VB10.0) that have been released since he created his original list. He created this list during the original VB7 BETA and updated it as of the second VB7 BETA. So his list doesn't even reflect a released product; yet he still maintains the list and many people still refer to this list. Bottom line, it's irresponsible to maintain such a list, evangelize such a list and read such a list without double checking the facts.

    So, fine, don't consider this a "rebuttal"; look at this as a "progress report".  It's been about 10 years since this list was put together.  My goal is not to point out how wrong it is.  I will just be using it to point out where we are TODAY.

    The following is a copy of his list as of 5/29/2011.

    1. VarPtr is not supported available.
    2. StrPtr is not supported available.
    3. ObjPtr is not supported available.
    4. As Any is not supported for API Declares.
    5. Use of ByVal/ByRef directly within API calls is not supported.
    6. Private class variables are not private to the class instance.
    7. Arrays may not have a lower bound other than zero.
    8. Dynamic arrays are not allowed within structures (UDTs)
    9. Arrays are not declared using the upper bound. (Addressed in Beta2)
    10. Option Base is not supported.
    11. Variants are not supported. Object is now the default data type.
    12. Currency is not supported.
    13. Dates are not stored internally as Double values.
    14. Longs are not 32-bits; they are 64-bits.
    15. Integers are not 16-bits; they are 32-bits.
    16. True, coerced to an Integer, is not -1, but is 1 instead. (Addressed in Beta2)
    17. The Imp and Eqv operators are not supported.
    18. Fixed-length Strings are not supported.
    19. DefInt, DefLong, et al., are not supported.
    20. Dim may not always create procedure-level variables.
    21. Redim will not create arrays not already declared.
    22. Local variables are not necessarily visible (in scope) throughout a procedure.
    23. VarType is not supported.
    24. Empty is not supported.
    25. Null is not supported.
    26. IsEmpty is not supported.
    27. IsMissing is not supported.
    28. IsNull is not supported.
    29. IsObject is not supported.
    30. Let is not supported.
    31. Core language constants do not have a "vb" prefix (vbRed becomes Red).
    32. Terminate will not fire when an object's last reference is released.
    33. Object finalization code will not execute in a predictable order.
    34. Implicit object creation is not delayed until first reference.
    35. Public object variables are not safe from alteration when passed as parameters.
    36. Can not expose Property procedures with mixed visibility (Friend Set/Public Get).
    37. Procedure parameters are not by default passed ByRef anymore.
    38. ParamArray arguments are not passed ByRef anymore.
    39. Property parameters may not be passed ByRef anymore.
    40. Implements is not implemented the same, so must be rewritten.
    41. Static is not supported as a procedure level modifier.
    42. Use of As New does not force auto-reinstantiation when an object is released.
    43. Parenthesis are not optional when calling procedures.
    44. Set is not supported for object assignment.
    45. Parameterless default properties are not supported.
    46. Default values for Optional parameters are not optional.
    47. Code is not compiled to native, thus making decompilation much easier.
    48. Resource files have changed format and old ones are not supported.
    49. LSet is not supported.
    50. RSet is not supported.
    51. UDTs are not Types, but are called Structures instead.
    52. UDTs are not by default contiguous blocks of memory, but are objects.
    53. Enums will not be recognized unless fully-qualified.
    54. While/Wend loops are not supported.
    55. GoSub/Return is not supported.
    56. On/GoTo is not supported.
    57. On/GoSub is not supported.
    58. Line numbers are not supported. Labels may be numeric.
    59. Erl is not supported.
    60. The MsgBox function is not supported.
    61. The DoEvents function is not supported.
    62. The Date statement is not supported.
    63. The Time statement is not supported.
    64. And, Or, XOr, and Not are not bitwise operators. (Addressed in Beta2)
    65. Comparison operators are not evaluated before logical operators. (Addressed in Beta2)
    66. Sqr is not supported.
    67. Sgn is not supported.
    68. Atn is not supported.
    69. The String function is not supported.
    70. Control arrays are not supported.
    71. The native Forms collection is not supported.
    72. UnloadMode detection is not offered, as QueryUnload is history.
    73. ListBox controls do not offer an ItemData property.
    74. ListBox controls do not offer an NewIndex property.
    75. Windowless controls are not supported.
    76. Image controls are not supported.
    77. Shape controls are not supported.
    78. Line controls are not supported.
    79. OLE Container controls are not supported.
    80. Label controls will not have a Caption property.
    81. The Tag property is not supported. (Addressed in Beta2)
    82. The ToolTipText property is not supported.
    83. The TextHeight property is not supported.
    84. The TextWidth property is not supported.
    85. Setting a Timer control's Interval to 0 does not disable it.
    86. Top-level menus may not be used as context menus.
    87. Old forms using vbPixels for Scalemode will not upgrade correctly.
    88. DDE is not supported.
    89. Circle is not supported.
    90. Cls is not supported.
    91. Line is not supported.
    92. PSet is not supported.
    93. Point is not supported.
    94. AutoRedraw is not supported.
    95. PrintForm is not supported.
    96. Scale is not supported.
    97. The Name property for forms and controls is not exposed at runtime. (Addressed in Beta2)
    98. Print will not include a linefeed at the end of a line.
    99. File I/O will not be compatible, at all, and must be rewritten.
    100. Printer object methods are not automatically upgraded and must be rewritten.
    101. Clipboard object methods are not automatically upgraded and must be rewritten.
    102. The Err object is not shared between managed (.NET) and unmanaged (ActiveX) code.
    103. The App object is not shared between managed (.NET) and unmanaged (ActiveX) code.
    104. Screen.MousePointer does not have a direct replacement.
    105. Webclasses are not supported.
    106. DHTML projects are not supported.
    107. UserControl projects are not supported.
    108. ActiveX Document projects are not supported.
    109. The IDE Extensibility Model is not backwardly compatible.
    110. Run->Break->Edit->Continue development is not supported.
    111. The Immediate window will not work in Design mode.
    112. SDI will not be an option in the IDE -- MDI or nothing.
    113. Debug.Print is not supported.
    114. Debug.Assert is not supported.
    115. Data binding with DAO is not supported.
    116. Data binding with RDO is not supported.

    This post will also serve as a table of contents; links will be updated on the list for items that are discussed.

    05-29-2011, 5:47 PM by CorySmith to AddressOf.com
    Filed under: