Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Comments

Escamillo Escamillo
  • Looking at XNA - Part Two

    I read yesterday's entry at the XNA blog, and it looks like XNA Game Studio Express won a couple of awards at last week's DEMMX Awards:
    Game Innovation of the Year
    and
    Best of Show: Innovator of the Year

    Congrats to the XNA team!!

    Here's a link to the DEMMX awards:
    http://www.demmx.com/demmx/awards/2006.jsp

  • Looking at XNA - Part Two

    This is definitely one of my favorite channel9 vids.  One that I'll download for my archive.  Smiley
  • IE7: CSS Support?

    mwirth wrote:
    well.. i need to express my thoughts on this one.
    i don't mean to be rude and i certainly do not want to criticize or even offend any person working on the project. but to me celebrating the (partial) css compliance of the browser is like anouncing that the new product won't be as problematic as much as the last version. now again, i 'm certainly not saying that i think IE 7 is not an important and much improved release that's going to be one of the main browsers out there. but the "hype" around getting it right is something i don't like. i always feel that 's like being happy about stuff that should work correct in the first place. that's something a user takes for granted. it's not a feature, it's the basic foundation on which stuff may be built. i wouldn't brag with saying i got something right "this time".
    i know that in a company the release schedule and time/money/personell constraints are in conflict with getting stuff right the first time. that's the way it works in reality. it's just that in theory this doesn't justify incomplete implementations or implementations that are known to be suboptimal. "we'll get there". yes, but in what version, one might ask rethorically.
    somehow the c++ team is a bit on the same path (or at least has been). Yes we screwed up a lot last time with managed extensions for c++. but look at the product now! well... it should have been that way in the first place. yes, failures happen (to put it politely). it's way better than never getting it right. just don't celebrate it like a break through.

    again, no offence to any of the people involved with the products mentioned above. i do use IE on a regular basis (and vc++ a lot), so i'm not all about microsoft bashing at all. i was just expressing my views on new features that are to me - in a way - essentially a bug fix. even if the bug is so gigantic that people got very accustomed to it and some even liked it.

    cheers,
    martin.


    Your "we screwed up a lot last time with managed extensions for c++" is not comparable to CSS support in IE, as there was no standard for managed extensions in c++ when VS.NET 2002 came out.

    And I see nothing wrong with devs taking pride in fixing something that should have been fixed by others long ago.  What, you want the devs in this video to be in tears and wearing ash-cloth because their predecessors let IE development stagnate?  And I saw no "hype" regarding this.  They clearly admitted that IE6 has been lacking (they demo'ed IE6's deficiencies) and they're showing how IE7 has addressed those problems.  I guess you'd rather not have this video at all.  Well, you might just want to skip watching any further videos, because you can be sure that the people that participate in these videos will be happy to show their work, and so will do so with enthusiasm.
  • Windows Shell Architecture

    sparky wrote:
    PatriotB wrote: With the DOJ settlement, a number of new shell interfaces and functions were "documented."  But this documentation is essentially useless: it basically amounts to function signatures, and leaves any idea of how to use it up to the developers' imaginations.
    Function signatures and/or interface definitions would have been immensely helpful. Looking over my notes on shell extensions, I see that some of the interfaces that were undocumented at the time (around 2001) are now documented. But the interface "abcb3a00-1b2b-11cf-a49f-444553540000" still isn't documented at all. It has something to do with IShellFolder and/or IPersistFolder.

    The DirectShow stuff I've done recently uncovered an interface "94bc0598-c3d2-11d3-bedf-00c04f612986" that is only mentioned on the web in a post where someone else ran into it previously. There is no documentation of any kind.
    Maybe those interfaces are strictly for internal use.  I did a lot of COM library programming in the 90's and we used plenty of private interfaces, even on objects that were publicly available to client code via public interfaces.  Sure, if a client happened to pass one of our private GUIDs to a QueryInterface call on one of our objects, then the client would receive a pointer to the object's corresponding private interface, but that doesn't mean that we meant for the client to be able to use that interface as if it were one of our public interfaces.

    I've never understood the argument that a programmer should be able to use any private internal function, class, method, structure, interface, etc, just like one would use public functions, classes, methods, structures, interfaces, etc.  The difference between private code and public API is fundamental to programming, even if one has access to the source code. 

    I personally don't think Microsoft should've been forced to document ANY internal code constructs in Windows, except those that may have been used by MS apps or MS "middleware" that has third party competitors (e.g. Internet Explorer).  For example, if different parts of the OS talk with each other through private COM interfaces, then those interfaces need not be documented (even if access to those private interfaces can be obtained by passing undocumented GUIDs to QueryInterface).  But if InternetExplorer ("middleware" whose OS-independence disputed), made use of internal COM interfaces to talk with the OS, then those interfaces should be documented so competitors to IE could use them.

    Taking your example, if interface abcb3a00-1b2b-11cf-a49f-444553540000 isn't being used by "middleware", then it need not, and moreover should not, be publicly documented.  I'd say the same regarding the DirectShow interface 94bc0598-c3d2-11d3-bedf-00c04f612986.  You say that this has been "mentioned" on the web, but how is one to know that it's behavior won't change in future versions of DirectShow, or even if it will remain as part of DirectShow altogether?  There's a reason that interfaces meant for internal use aren't documented.
  • Richard Anderson - Interactive teaching with Tablet PCs at University of Washington

    Manip wrote:
    Zeo wrote:
    Manip wrote:

    I would expect to see grades go down...

    I really would like to hear the advantages over paper and pen? ...



    One big plus is spell check on the ink you write, that was a killer feature that helped me when I took tests with my tablet and made my essays more readable for my profs...which I'd argue made their lives easier and helped me get better grades.


    It might have been a long time since you were at University but today they don't accept hand written essays at all and you aren't expected to write them in class either.

    Some exams are computerised, some aren't... But either way that isn't graded as long as they can understand what your trying to say.

    You've taken no classes that used essay exams???
  • Rob Franco and team - IE 7 Security

    nektar, I believe that the evil ActiveX control didn't execute the "format c:" command, it installed into the user's startup folder a batch file that executed "format c:".  The demo showed how the ActiveX control was blocked from installing the batch file.