Visual Studio 2008 Licensing WTF



  • So I'm pretty sure that I'm The Real WTF here, but here goes...

    For a little while now, we've been buying Visual Studio Standard, one license at a time. They're cheap ($299), come with a cool box, and the higher-end ones like Pro ($549) and  Pro+MSDN ($1119) don't add that much more value, especially with an Action Pack subscription.

    Anyway, it was time to buy a new license so I went to Amazon and added it to my cart. Before checking out, I thought, hey,I have an unused 2005 license, maybe i can upgrade and save some cash? I went back, did another search, and found that there was an Upgrade edition version that cost $100 less. Neat, what do I need to be eligible?

    To qualify for upgrade pricing, you must be a licensed user of one of the following products:

    • An earlier version of Microsoft Visual Studio
    • Any other developer tool (including free developer tools, such as Visual Studio Express Editions or Eclipse)

    See: http://msdn.microsoft.com/it-it/vs2008/products/cc263904(en-us).aspx

    That's right. Every one is eligible for the upgrade, no questions asked. If your computer has something like, say notepad.exe as the primary development tool, then you're good to go! In other words, the only people who buy the full version are suckers.

    Now don't I feel like a sucker. Well, at least I saved on one license...



  •  Welcome to the real world of suckers, sucker!

    :-)



  • But isn't going from notepad to visual studio 2008 a downgrade?
    (ducks)



  • @Daid said:

    But isn't going from notepad to visual studio 2008 a downgrade?
    (ducks)
     

    Certainly not: VS has line numbers, NotePad hasn't. And (presumably) proper UTF-8 support and recognition of \n line-endings (tho I can't be sure on the last two, it's been years since I worked with either NotePad or VS). See? There's really no reason not to upgrade to the latest version of VS right now!



  • @Monomelodies said:

    @Daid said:

    But isn't going from notepad to visual studio 2008 a downgrade?
    (ducks)
     

    Certainly not: VS has line numbers, NotePad hasn't. 

    Not so, Notepad has had line numbers since the XP version:

    Notepad on XP

    It even handles utf-8 and -16

    XP notepad 'save as' dialog



  • Those licensing terms have been around for a while. It used to say 'any other developer tool' but they clarified it more recently.

    If you buy Visual Studio 2008 you can also run every previous version on your PC at the same time. I believe it is also licensed per user so you can install it on both your work and home machine (which is useful when you occasionally work from home).

     



  • @DaveK said:

    It even handles utf-8 and -16

    Sort of, that is. It adds some switch character in front of every file it saves as UTF-8. That way, it can recognize whether the file had been saved in ANSI or UTF-8 format.

    Unfortunately, this character is not known by many other editors, or the PHP parser. It took me a while to figure out why all pages emitted by my php script started with some weird character after I had converted the script into UTF-8 using Notepad...



  • @derula said:

    @DaveK said:
    It even handles utf-8 and -16
    Sort of, that is. It adds some switch character in front of every file it saves as UTF-8. That way, it can recognize whether the file had been saved in ANSI or UTF-8 format.

    Unfortunately, this character is not known by many other editors, or the PHP parser. It took me a while to figure out why all pages emitted by my php script started with some weird character after I had converted the script into UTF-8 using Notepad...

    That's BOM - byte order mark, which is a zero-width whitespace. Every UTF-supporting program should be able to understand it. Or that will be a UUTF.



  • @alegr said:

    Every UTF-supporting program should be able to understand it. Or that will be a UUTF.

     

    I wasn't aware you could write a sentence that qualifies as both leetspeak AND a pun at the same time. You sir, win an internet!



  • @PSWorx said:

     

    I wasn't aware you could write a sentence that qualifies as both leetspeak AND a pun at the same time. You sir, win an internet!

    Don't accept that internet.  It's probably filled with malware and people accusing one another of homosexuality.



  • @bstorer said:

    Don't accept that internet.  It's probably filled with malware and people accusing one another of homosexuality.

     

    Well, your mom is accused of homosexuality... er, wait ...



  • @derula said:

    @DaveK said:
    It even handles utf-8 and -16

    Sort of, that is. It adds some switch character in front of every file it saves as UTF-8. That way, it can recognize whether the file had been saved in ANSI or UTF-8 format.

    Unfortunately, this character is not known by many other editors, or the PHP parser. It took me a while to figure out why all pages emitted by my php script started with some weird character after I had converted the script into UTF-8 using Notepad...

    I don't think the PHP interpreter will handle UTF-8 sources.  In fact, I'm pretty sure most languages only accept ASCII sources.



  • @derula said:

    @DaveK said:
    It even handles utf-8 and -16

    Sort of, that is. It adds some switch character in front of every file it saves as UTF-8. That way, it can recognize whether the file had been saved in ANSI or UTF-8 format.

    Unfortunately, this character is not known by many other editors, or the PHP parser. It took me a while to figure out why all pages emitted by my php script started with some weird character after I had converted the script into UTF-8 using Notepad...

     

    I had that exact problem, and it was causing my RSS feed to not validate. Gigantic pain-in-the-ass, and took me ages to figure out that error. (Even worse: I hadn't even used Notepad to edit the file, some other editor did it. Either the one on my .net hosting account, or the one built-in to WinSCP.)



  • @morbiuswilters said:

    I don't think the PHP interpreter will handle UTF-8 sources.  In fact, I'm pretty sure most languages only accept ASCII sources.

     

    On Linux at least, PHP doesn't blink when fed UTF-8 files. Yes, that includes files with strings or HTML blocks containing non-ASCII characters, encoded UTF-8.



  •  @derula said:

    @DaveK said:
    It even handles utf-8 and -16

    Sort of, that is. It adds some switch character in front of every file it saves as UTF-8. That way, it can recognize whether the file had been saved in ANSI or UTF-8 format.

    Unfortunately, this character is not known by many other editors, or the PHP parser. It took me a while to figure out why all pages emitted by my php script started with some weird character after I had converted the script into UTF-8 using Notepad...

    BOM - Byte Order Mark. Any decent editor will detect that and accommodate it, and usually also allow you to save files with or without BOM as you desire. (plug: Notepad++ on Windows, Geany on Linux or Windows)



  • @rosko said:

    On Linux at least, PHP doesn't blink when fed UTF-8 files. Yes, that includes files with strings or HTML blocks containing non-ASCII characters, encoded UTF-8.
     

    It'll include them in the output, so if your include()d files have the BOM you'll get the BOM on the output, sending headers, which you may not expect. (AFAICT anyway)

     



  • @Zemm said:

    @rosko said:

    On Linux at least, PHP doesn't blink when fed UTF-8 files. Yes, that includes files with strings or HTML blocks containing non-ASCII characters, encoded UTF-8.
     

    It'll include them in the output, so if your include()d files have the BOM you'll get the BOM on the output, sending headers, which you may not expect. (AFAICT anyway)

     

    Yes, but you can feed UTF-8 files without a BOM to PHP and it won't bother it. Morb's seemed to think otherwise.



  • @alegr said:

    @derula said:

    @DaveK said:
    It even handles utf-8 and -16
    Sort of, that is. It adds some switch character in front of every file it saves as UTF-8. That way, it can recognize whether the file had been saved in ANSI or UTF-8 format.

    Unfortunately, this character is not known by many other editors, or the PHP parser. It took me a while to figure out why all pages emitted by my php script started with some weird character after I had converted the script into UTF-8 using Notepad...

    That's BOM - byte order mark, which is a zero-width whitespace. Every UTF-supporting program should be able to understand it. Or that will be a UUTF.

     

    Actually, it's uneccissary garbage. Technically it's the UTF-8 encoding of the UTF-16 BOM, which is completely pointless and meaningless since UTF-8 only has one byte-order. The reason that notepad puts it there is because Win32's "support" of UTF-8 extends only to converting it to UTF-16 and back, and of course the UTF16 -> UTF-8 conversion code is not smart enough to realise that the BOM is uneccissary garbage in UTF-8.

    It's a silly Microsoft-ism that makes working with UTF-8 files that may have been generated with Microsoft tools that bit more painful. It is not something that other editors should try to imitate, nor is it something that "every UTF-supporting program should be able to understand" - only those that expect input to have come from these poorly behaved Windows applications.



  • @rosko said:

    @Zemm said:

    @rosko said:

    On Linux at least, PHP doesn't blink when fed UTF-8 files. Yes, that includes files with strings or HTML blocks containing non-ASCII characters, encoded UTF-8.
     

    It'll include them in the output, so if your include()d files have the BOM you'll get the BOM on the output, sending headers, which you may not expect. (AFAICT anyway)

     

    Yes, but you can feed UTF-8 files without a BOM to PHP and it won't bother it. Morb's seemed to think otherwise.

    Re-reading my post, I'm not sure WTF I was thinking.  I think I got it in my head derula was talking about using multi-byte UTF-8 characters for variable names, etc. and then ran with it.  Since UTF-8 is essentially compatible with ASCII, most programs that operate on text will work with it.  That doesn't mean the interpreter will comprehend the characters themselves (a problem with Ruby and PHP < 6), but it just looks like control character garbage in that case which is still fine in string literals in most languages.



  • @mallard said:

    Actually, it's uneccissary garbage. Technically it's the UTF-8 encoding of the UTF-16 BOM, which is completely pointless and meaningless since UTF-8 only has one byte-order.

    Without BOM, the files are considered encoded in the current codepage (that for legacy reasons is called "ANSI code page"). UTF-8 can't be set as a current codepage, although MultiByteToWideChar and WideCharToMultiByte support CP_UTF8).

     



  • @mallard said:

    Actually, it's uneccissary garbage. Technically it's the UTF-8 encoding of the UTF-16 BOM, which is completely pointless and meaningless since UTF-8 only has one byte-order. The reason that notepad puts it there is because Win32's "support" of UTF-8 extends only to converting it to UTF-16 and back, and of course the UTF16 -> UTF-8 conversion code is not smart enough to realise that the BOM is uneccissary garbage in UTF-8.

    Disagreed. BOM can be used with any UTF: [url]http://www.unicode.org/faq/utf_bom.html#BOM[/url].



  • @Spectre said:

    @mallard said:
    Actually, it's uneccissary garbage. Technically it's the UTF-8 encoding of the UTF-16 BOM, which is completely pointless and meaningless since UTF-8 only has one byte-order. The reason that notepad puts it there is because Win32's "support" of UTF-8 extends only to converting it to UTF-16 and back, and of course the UTF16 -> UTF-8 conversion code is not smart enough to realise that the BOM is uneccissary garbage in UTF-8.
    Disagreed. BOM can be used with any UTF: http://www.unicode.org/faq/utf_bom.html#BOM.
     

    Of course it can be used, but that doesn't make it a good idea. As the linked FAQ says:

    @http://www.unicode.org/faq/utf_bom.html said:

    Q: Can a UTF-8 data stream contain the BOM character (in UTF-8 form)? If yes, then can I still assume the remaining UTF-8 bytes are in big-endian order?

    A: Yes, UTF-8 can contain a BOM. However, it makes no difference as to the endianness of the byte stream. UTF-8 always has the same byte order. An initial BOM is only used as a signature — an indication that an otherwise unmarked text file is in UTF-8. Note that some recipients of UTF-8 encoded data do not expect a BOM. Where UTF-8 is used transparently in 8-bit environments, the use of a BOM will interfere with any protocol or file format that expects specific ASCII characters at the beginning, such as the use of "#!" of at the beginning of Unix shell scripts.

    It's often a bad idea, which is why nobody outside Windows does it.


Log in to reply

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.