Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Sunday May 06 2018, @11:35AM   Printer-friendly
from the what's-in-a-name? dept.

The signs are undeniable at this point.

The very first sign was when Microsoft refused to port Visual Studio (VS) to 64 bit. While VS is indeed a large codebase, MS had no qualms doing the same for Microsoft Office. The fact that they no longer want to invest too much resources into it should point to the fact Visual Studio is very much in maintenance mode now.

Visual Studio was always paid software. But in 2014 MS introduced the Community Edition. The only real difference between it and the Pro (paid) version is the 'Code Lens' feature. Another sign that MS no longer sees Visual Studio as driving any meaningful revenue.

[...] Visual Studio Code continues to release enhancements every single month, moving at a fast pace. Compare that to Visual Studio Pro, whose development seems pretty much only about updating its integration of the various Language Services to the latest version.

With Microsoft's focus shifting from Windows to Azure, it is but natural that they no longer want an IDE that runs only on Windows. Thus comes in VS Code, a free, cross platform IDE that supports all modern languages.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by TheRaven on Monday May 07 2018, @12:40PM (1 child)

    by TheRaven (270) on Monday May 07 2018, @12:40PM (#676623) Journal

    You are misremembering. The source code was stored in plain text files and the GUI layouts were stored in a fairly simple text serialisation (which was easy to modify). The GUI libraries did not; however, make it easy to maintain MVC-style abstractions and so it was very common to have model state stored in the GUI, which led to not very maintainable code beyond a certain level of complexity.

    VB6 had a lot of aspects of a modern programming language, but unfortunately everything was structured to avoid forcing you to use them. If was great for knocking up a quick prototype in a couple of hours, but terrible for anything more complex.

    --
    sudo mod me up
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 2) by vux984 on Monday May 07 2018, @04:13PM

    by vux984 (5045) on Monday May 07 2018, @04:13PM (#676678)

    Your comment induced me to try and look it up, and you are right the forms themselves defined in .frm files are plaintext. But I'm not entirely remembering either; turns out I was remembering the .frx files, which are a proprietary binary format used by VB6 for various form resources including icons, images, long text resources, non-ansi strings (e.g. localization strings, unicode strings etc), and anything stored in a form property with a type of Variant.

    And to my knowledge there was no way to alter or update any of that information except through the VB IDE, as the format was binary and undocumented. This also made the .frm files (which were plaintext) sometimes difficult to update by hand since they contained references to the frx file resources using offsets into the frx file, which you had no visibility to.

    So for example you couldn't swap an icon on a menubar by dropping in a new icon file and updating the form to reference it. Instead you needed to put it into the form via the IDE which put it into the binary .frx file, and updated the .frm defintion with the new frx/offset. There was no way to do that without the IDE. Or even correct a typo in a longish string resource that had been stashed in the frx file.

    Therefore although you could make some basic forms by editing the .frm directly, there was simply a lot you couldn't do without the IDE.
    There were similar binary files associated with user controls (.ctx), property pages (.pgx) etc too.