DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 1 of 23 12311 ... LastLast
Results 1 to 15 of 334

Thread: I have seen the light and it starts with B?

  1. #1
    Garry Mc Guest

    I have seen the light and it starts with B?


    Greetings All

    As this is a high traffic group I haven't read everything, however it all
    seems to be around the VB.NET issue of 'code compatability' vs 'language
    compatability' that is you want your old stuff to compile, but you also want
    all the new wiz bang stuff. I don't believe you can do both, under the current
    situation. So, I thought of this as an alternative...

    Core Issue
    1. VB.NET implies that old code should compile
    2. VB.NET wants to be a modern langauge like C#
    3. There's a bleep of new changes in a traditionally 'easy' langauge

    Possible solution
    1. Make VB.NET as compatable as possible for older code, and possibly leave
    out more advanced bits if it can't be easily added for compatability reasons.
    (I'm sure this is a hard thing to do, given the way .NET works, but hey its
    an idea)
    2. Create a NEW language which is functionally identical to C#, but has the
    semantics of VB. I call it B# (should I register this? )

    I have looked at VB.NET and C#, I like both, but am worried about possible
    changes to the VB.NET product. I also don't like the fact it has a few things
    missing that C# can do. I can understand the VB.NOT people, and I think
    splitting the language (lets face it, its already a new language) will allow
    both VB.NOT and VB.NET people to be happy (Oh utopia!).

    Main reasons for B#:
    1. ELIMATATE 'my code won't compile' issue, becaue its a NEW language you
    don't have ANY CODE!
    2. Allow VB developers a FAST track to a modern powerful language
    3. All C# source could be translated to B# (its the same really just looks
    different), and vis versa. Ie we already have the samples!
    4. Allow VB.NET to remain core to its origin of being easy to use.
    5. Allow more advanced/experienced VBers to finally get the power they have
    been wanting since VB4.
    6. Allows a kind of migration path between beginners (VB.NET) to advanced
    (B#)
    7. HOPEFULLY ELIMATE THIS DIVIDE BETWEEN THE VB COMMUNITY!!
    8. Pick the language of choice, ie migrate old code=VB.NET (if possible)
    new project=B# or VB.NET or both!

    In the end, I like C# I just don't like its syntax (ie Java/C++). If it
    were in a VB style, I'd love it!

    As this is a hot topic, I'm expects some to love the idea, and others to
    hate it. This is to be expected, all I ask is that you take it on as an
    idea and maybe think about it for a bit before you flame me too much

    Let the debate begin.....

    Garry Mc



  2. #2
    Kunle Odutola Guest

    Re: I have seen the light and it starts with B?


    "Garry Mc" <gmcglenon@parity.co.uk> wrote in message
    news:3b050e50$1@news.devx.com...
    >
    > Greetings All
    >
    > As this is a high traffic group I haven't read everything, however it all
    > seems to be around the VB.NET issue of 'code compatability' vs 'language
    > compatability' that is you want your old stuff to compile, but you also

    want
    > all the new wiz bang stuff. I don't believe you can do both, under the

    current
    > situation. So, I thought of this as an alternative...


    <SNIP>

    How is this different from the Option VB6Compatibility proposals ?

    Kunle




  3. #3
    Garry Mc Guest

    Re: I have seen the light and it starts with B?


    "Kunle Odutola" <kunle.odutola@<REMOVETHIS>okocha.freeserve.co.uk> wrote:
    >
    >"Garry Mc" <gmcglenon@parity.co.uk> wrote in message
    >news:3b050e50$1@news.devx.com...
    >>
    >> Greetings All
    >>
    >> As this is a high traffic group I haven't read everything, however it

    all
    >> seems to be around the VB.NET issue of 'code compatability' vs 'language
    >> compatability' that is you want your old stuff to compile, but you also

    >want
    >> all the new wiz bang stuff. I don't believe you can do both, under the

    >current
    >> situation. So, I thought of this as an alternative...

    >
    ><SNIP>
    >
    >How is this different from the Option VB6Compatibility proposals ?
    >
    >Kunle
    >
    >
    >


    Well, for starters we get MORE in that we get ALL the functionality of C#,
    which VB.NET is lacking. Next, I'd feel more comfortable knowing that I
    was in a different language, rather than a 'switched' environment. It also
    allows the two to develop independantly from each other. Thereby allowing
    each set of users to be catered for. I think having a 'switch' would confuse
    the situation to no end. If that's the best we can get, I'll take it, but
    a cleaner way is to have a seperate language.

    Also, to keep the 'I want my stuff to run!!' VBer's happy you have to make
    substantial changes to the current VB.NET. So the 'switch' would be a rather
    confusing element in such an environment. Better to break free, then you
    atleast know what your coding in.

    Comments...

    Garry Mc

  4. #4
    Jonathan West Guest

    Re: I have seen the light and it starts with B?


    "Kunle Odutola okocha.freeserve.co.uk>" <kunle.odutola@<REMOVETHIS> wrote in
    message news:3b052647$1@news.devx.com...
    >
    > "Garry Mc" <gmcglenon@parity.co.uk> wrote in message
    > news:3b050e50$1@news.devx.com...
    > >
    > > Greetings All
    > >
    > > As this is a high traffic group I haven't read everything, however it

    all
    > > seems to be around the VB.NET issue of 'code compatability' vs 'language
    > > compatability' that is you want your old stuff to compile, but you also

    > want
    > > all the new wiz bang stuff. I don't believe you can do both, under the

    > current
    > > situation. So, I thought of this as an alternative...

    >
    > <SNIP>
    >
    > How is this different from the Option VB6Compatibility proposals ?


    The VB6Compatibility would have two noticeably different sets of semantics
    within the same language, and you would not be able to tell from a first
    glance how a piece of code was meant to work. For instance, if Option
    VB6Compatibility determined the meaning and precedence of the logical
    operators, either following VB6 or beta 1 rules, then there would be many
    cases where you could not tell how a piece of code is supposed to work
    without checking the Option statement.

    One of the reasons many places insist on using Dim a(x to y) as a coding
    standard is that it removes any dependence on the Option Base statement.
    That is relatively minor compared to the things you would have to define and
    restrict to make code behave the same irrespective of an Option VB6
    statement. It would be better to have two languages. As it happens, this is
    exactly what Garry suggested, and what Rob Bovey suggested in his VBPJ guest
    opinion. To quote your words from one of your posts here today, "Kunle, you
    should learn to read..."


    --
    Regards
    Jonathan West


  5. #5
    Bob Butler Guest

    Re: I have seen the light and it starts with B?

    "Jonathan West" <jwest@mvps.org> wrote in message
    news:3b052b0b@news.devx.com...
    <cut>
    > It would be better to have two languages. As it happens, this is
    > exactly what Garry suggested, and what Rob Bovey suggested in his VBPJ

    guest
    > opinion.


    The problem I see is that I find it hard to believe that MS will continue to
    devote resources to maintaining both VB.Net and C# when they are billed as
    being functionally equivalent. (When VB and C++ were targeted at different
    developer groups and for different purposes it made sense to have two
    languages but now I just don't see a justification for supporting both).
    Adding a third language to the mix in the form of an extended "classic" VB
    stretches things even further. Any way I look at it I see a short potential
    lifespan for VB.Net.

    In trying to read between the lines what I'm coming up with is that VB.Net
    exists only as a migration path to move current VB developers to C# -- move
    to the dotnet platform using relatively familiar syntax first, then
    substitute curly braces and insert semicolons.... then VB.Net gets dropped.

    I definitely don't see MS going back and pouring resources into a VB7
    product unless the whole dotnet platform turns out to be a total failure
    (which would surprise me greatly).




  6. #6
    Kunle Odutola Guest

    Re: I have seen the light and it starts with B?


    "Bob Butler" <butlerbob@earthlink.net> wrote in message
    news:3b052fa6$1@news.devx.com...
    > "Jonathan West" <jwest@mvps.org> wrote in message
    > news:3b052b0b@news.devx.com...


    > The problem I see is that I find it hard to believe that MS will continue

    to
    > devote resources to maintaining both VB.Net and C# when they are billed as
    > being functionally equivalent. (When VB and C++ were targeted at different
    > developer groups and for different purposes it made sense to have two
    > languages but now I just don't see a justification for supporting both).


    C# and VB.NET cater for different groups too. One is for VB migration and
    the other for C/C++/Java migration. The real question is what happens after
    the migration in a few years?

    > Adding a third language to the mix in the form of an extended "classic" VB
    > stretches things even further. Any way I look at it I see a short

    potential
    > lifespan for VB.Net.
    >
    > In trying to read between the lines what I'm coming up with is that VB.Net
    > exists only as a migration path to move current VB developers to C# --

    move
    > to the dotnet platform using relatively familiar syntax first, then
    > substitute curly braces and insert semicolons.... then VB.Net gets

    dropped.

    It's only a niggle but I get to thinking the same way every now and then....

    Ultimately though, if the ECMA CLR/C# idea takes off, any language with a
    dedicated enough userbase will survive. Open source projects would ensure
    that....

    Kunle



  7. #7
    Daniel Pratt Guest

    Re: I have seen the light and it starts with B?

    Hi Garry,

    If Microsoft continues to support and update (via service packs) VB6,
    how far does this go in meeting your proposal?
    Even though Microsoft _has_ said that there will be at least one more
    service pack for VB6, I understand that some people are skeptical about how
    much _actual_ support VB6 users will get. The answer, of course, is that MS
    will support VB6 so long as they think it's in their best interests. In my
    judgement, so long as there is a significant number of VB6 developers who
    haven't moved on to another platform, it is in MS's best interests to bring
    them along at their own pace.

    Regards,
    Dan

    "Garry Mc" <gmcglenon@parity.co.uk> wrote in message
    news:3b050e50$1@news.devx.com...
    >
    > Greetings All
    >
    > As this is a high traffic group I haven't read everything, however it all
    > seems to be around the VB.NET issue of 'code compatability' vs 'language
    > compatability' that is you want your old stuff to compile, but you also

    want
    > all the new wiz bang stuff. I don't believe you can do both, under the

    current
    > situation. So, I thought of this as an alternative...
    >
    > Core Issue
    > 1. VB.NET implies that old code should compile
    > 2. VB.NET wants to be a modern langauge like C#
    > 3. There's a bleep of new changes in a traditionally 'easy' langauge
    >
    > Possible solution
    > 1. Make VB.NET as compatable as possible for older code, and possibly

    leave
    > out more advanced bits if it can't be easily added for compatability

    reasons.
    > (I'm sure this is a hard thing to do, given the way .NET works, but hey

    its
    > an idea)
    > 2. Create a NEW language which is functionally identical to C#, but has

    the
    > semantics of VB. I call it B# (should I register this? )





  8. #8
    Zane Thomas Guest

    Re: I have seen the light and it starts with B?

    On Fri, 18 May 2001 10:38:59 -0400, "Daniel Pratt"
    <dprREMOVETHISatt71@hotmail.com> wrote:

    >The answer, of course, is that MS
    >will support VB6 so long as they think it's in their best interests.


    Yep, look at how long they've supported VFP. <gd&r>


    ---
    Ice Z - Straight Outta Redmond

  9. #9
    Kunle Odutola Guest

    Re: I have seen the light and it starts with B?


    "Jonathan West" <jwest@mvps.org> wrote in message
    news:3b052b0b@news.devx.com...
    >
    > "Kunle Odutola okocha.freeserve.co.uk>" <kunle.odutola@<REMOVETHIS> wrote

    in
    > message news:3b052647$1@news.devx.com...
    > >
    > > "Garry Mc" <gmcglenon@parity.co.uk> wrote in message
    > > news:3b050e50$1@news.devx.com...
    > > >


    > > How is this different from the Option VB6Compatibility proposals ?

    >
    > The VB6Compatibility would have two noticeably different sets of semantics
    > within the same language, and you would not be able to tell from a first
    > glance how a piece of code was meant to work.


    Whether in the same product or not, you still end up with two set of
    semantics. Neither situation is any less confusing IMO.

    > For instance, if Option
    > VB6Compatibility determined the meaning and precedence of the logical
    > operators, either following VB6 or beta 1 rules, then there would be many
    > cases where you could not tell how a piece of code is supposed to work
    > without checking the Option statement.


    Didn't you just argue about how reading the manual, understanding how
    something works and then using it (however counter-intuitive it may be) is
    the mark of a skillful programmer?. Now you complain about an itzy-bitzy
    Option statement messing with your skills ?
    <bg>

    > One of the reasons many places insist on using Dim a(x to y) as a coding
    > standard is that it removes any dependence on the Option Base statement.
    > That is relatively minor compared to the things you would have to define

    and
    > restrict to make code behave the same irrespective of an Option VB6


    No, it is because it is good practice to be explicit when there is
    opportunity for confusion. Without Option Base, it is still good practice to
    specify upper and lower array bounds explicitly (ANYONE FROM THE VB.NET TEAM
    AT MS READING THIS???).

    The rationale for "Option VB6Compatibility" is that we *can't* write code
    that works in both so, we get to choose which we are writing our code for on
    a per-file or per-project basis.

    > It would be better to have two languages. As it happens, this is
    > exactly what Garry suggested, and what Rob Bovey suggested in his VBPJ

    guest
    > opinion. To quote your words from one of your posts here today, "Kunle,

    you
    > should learn to read..."


    I read, I understood and I still don't agree that a separate language
    provides any benefits viz-a-viz semantic confusion/incompatibilities...
    If you believe it does, then please consider VB6 a separate [frozen?]
    language and we can all move on....

    Kunle




  10. #10
    Jonathan West Guest

    Re: I have seen the light and it starts with B?


    "Kunle Odutola okocha.freeserve.co.uk>" <kunle.odutola@<REMOVETHIS> wrote in
    message news:3b0535ba@news.devx.com...
    >
    > > One of the reasons many places insist on using Dim a(x to y) as a coding
    > > standard is that it removes any dependence on the Option Base statement.
    > > That is relatively minor compared to the things you would have to define

    > and
    > > restrict to make code behave the same irrespective of an Option VB6

    >
    > No, it is because it is good practice to be explicit when there is
    > opportunity for confusion.


    Exactly. The opportunity for confusion arises primarily from the different
    possible values of the Option Base statement, with the resulting variation
    in the meaning of Dim a(x).

    Dim a(x) or its equivalent is fine for those languages where no such
    confusion exists, either because there is a fixed lower bound, or possibly
    where there is a variable lower bound but always with a default of zero. In
    the latter case, I would still prefer Dim a(x to y), to guard against the
    possibility that some idiot will decide to "correct a past mistake" and
    change the default lower bound in a future version of the language.

    > Without Option Base, it is still good practice to
    > specify upper and lower array bounds explicitly (ANYONE FROM THE VB.NET

    TEAM
    > AT MS READING THIS???).


    Where variable bounds are available, I quite agree.

    >
    > The rationale for "Option VB6Compatibility" is that we *can't* write code
    > that works in both so, we get to choose which we are writing our code for

    on
    > a per-file or per-project basis.


    The problem with that is that you just made a very good case for writing
    code so that it is not affected by any kind of default behaviour that might
    be changed between projects, between modules, or even between versions of
    VB. If VB.NET had "Option VB6Compatibility" it would be remarkably difficult
    to write code that was not affected by the Option VB6Compatibility
    statement. However, good coding practise (as you just defined it) would
    require that you made the effort. I think that might bring about major
    restrictions in what constructions you could safely use. Of course, it would
    depend on how many differences there were between the two modes. If there
    were only minor differences, then it probably wouldn't be worth having the
    option in the first place. If there were major differences, it might be very
    difficult to code around them.

    >
    > > It would be better to have two languages. As it happens, this is
    > > exactly what Garry suggested, and what Rob Bovey suggested in his VBPJ

    > guest
    > > opinion. To quote your words from one of your posts here today, "Kunle,

    > you
    > > should learn to read..."

    >
    > I read, I understood and I still don't agree that a separate language
    > provides any benefits viz-a-viz semantic confusion/incompatibilities...
    > If you believe it does, then please consider VB6 a separate [frozen?]
    > language and we can all move on....


    The issue here is whether *Microsoft* is going to "consider VB6 a separate
    language". After all, they are the ones developing the language!


    --
    Regards
    Jonathan West


  11. #11
    Kunle Odutola Guest

    Re: I have seen the light and it starts with B?


    "Jonathan West" <jwest@mvps.org> wrote in message
    news:3b054517$1@news.devx.com...
    >
    > "Kunle Odutola okocha.freeserve.co.uk>" <kunle.odutola@<REMOVETHIS> wrote

    in
    > message news:3b0535ba@news.devx.com...


    > Exactly. The opportunity for confusion arises primarily from the different
    > possible values of the Option Base statement, with the resulting variation
    > in the meaning of Dim a(x).


    So now that VB.NET is constrained to have a fixed 0 base, you feel the Dim(x
    To X) syntax is redundant?

    > Dim a(x) or its equivalent is fine for those languages where no such
    > confusion exists, either because there is a fixed lower bound, or possibly
    > where there is a variable lower bound but always with a default of zero.

    In
    > the latter case, I would still prefer Dim a(x to y), to guard against the
    > possibility that some idiot will decide to "correct a past mistake" and
    > change the default lower bound in a future version of the language.


    Correcting a past mistake only becomes an idiotic decision if the new base
    is not 0 ;-)

    > > Without Option Base, it is still good practice to
    > > specify upper and lower array bounds explicitly (ANYONE FROM THE VB.NET

    > TEAM
    > > AT MS READING THIS???).

    >
    > Where variable bounds are available, I quite agree.


    They *should* be available.

    > > The rationale for "Option VB6Compatibility" is that we *can't* write

    code
    > > that works in both so, we get to choose which we are writing our code

    for
    > on
    > > a per-file or per-project basis.

    >
    > The problem with that is that you just made a very good case for writing
    > code so that it is not affected by any kind of default behaviour that

    might
    > be changed between projects, between modules, or even between versions of
    > VB. If VB.NET had "Option VB6Compatibility" it would be remarkably

    difficult
    > to write code that was not affected by the Option VB6Compatibility
    > statement.


    That would be the intention. If VB6 is restrictive, VB.NET is radical. You
    get to decide which parser should handle the code.

    > However, good coding practise (as you just defined it) would
    > require that you made the effort. I think that might bring about major
    > restrictions in what constructions you could safely use. Of course, it

    would
    > depend on how many differences there were between the two modes. If there
    > were only minor differences, then it probably wouldn't be worth having the
    > option in the first place. If there were major differences, it might be

    very
    > difficult to code around them.


    No. I did not define it as writing code that works across versions. I said
    be explicit when there's opportunity for confusion. When I program, I would
    explicitly specify VB6 or VB.NET compatibility. If I could write substantial
    code that ran identically in both (can't mostly due to platform changes),
    there would be no need for the Option VB6...


    > The issue here is whether *Microsoft* is going to "consider VB6 a separate
    > language". After all, they are the ones developing the language!


    More like two dialects of the VB language. VB.NET is just the latest.....

    Kunle




  12. #12
    Jonathan West Guest

    Re: I have seen the light and it starts with B?


    "Kunle Odutola okocha.freeserve.co.uk>" <kunle.odutola@<REMOVETHIS> wrote in
    message news:3b055aaf@news.devx.com...
    >
    >
    > So now that VB.NET is constrained to have a fixed 0 base, you feel the

    Dim(x
    > To X) syntax is redundant?


    Yes I do. However, I hope that this state of affairs won't last very long,
    and that we will soon get variable lower bounds back. I think that is
    something we might even be able to agree on!

    >
    > > Dim a(x) or its equivalent is fine for those languages where no such
    > > confusion exists, either because there is a fixed lower bound, or

    possibly
    > > where there is a variable lower bound but always with a default of zero.

    > In
    > > the latter case, I would still prefer Dim a(x to y), to guard against

    the
    > > possibility that some idiot will decide to "correct a past mistake" and
    > > change the default lower bound in a future version of the language.

    >
    > Correcting a past mistake only becomes an idiotic decision if the new base
    > is not 0 ;-)


    Says you!

    >
    > > However, good coding practise (as you just defined it) would
    > > require that you made the effort. I think that might bring about major
    > > restrictions in what constructions you could safely use. Of course, it

    > would
    > > depend on how many differences there were between the two modes. If

    there
    > > were only minor differences, then it probably wouldn't be worth having

    the
    > > option in the first place. If there were major differences, it might be

    > very
    > > difficult to code around them.

    >
    > No. I did not define it as writing code that works across versions. I said
    > be explicit when there's opportunity for confusion. When I program, I

    would
    > explicitly specify VB6 or VB.NET compatibility. If I could write

    substantial
    > code that ran identically in both (can't mostly due to platform changes),
    > there would be no need for the Option VB6...


    However, if you have the compatibility switch, you are putting two languages
    into a *single* version of the product. If you regard them as two separate
    languages, it would be better to split them out into a seperate packages so
    there is no confusion.


    --
    Regards
    Jonathan West


  13. #13
    Kunle Odutola Guest

    Re: I have seen the light and it starts with B?


    "Jonathan West" <jwest@mvps.org> wrote in message
    news:3b05ab99$1@news.devx.com...
    >
    > "Kunle Odutola okocha.freeserve.co.uk>" <kunle.odutola@<REMOVETHIS> wrote

    in
    > message news:3b055aaf@news.devx.com...


    > > No. I did not define it as writing code that works across versions. I

    said
    > > be explicit when there's opportunity for confusion. When I program, I

    > would
    > > explicitly specify VB6 or VB.NET compatibility. If I could write

    > substantial
    > > code that ran identically in both (can't mostly due to platform

    changes),
    > > there would be no need for the Option VB6...

    >
    > However, if you have the compatibility switch, you are putting two

    languages
    > into a *single* version of the product. If you regard them as two separate
    > languages, it would be better to split them out into a seperate packages

    so
    > there is no confusion.


    I regard them as two dialects of the same language. It would be better if
    they were compatible but even if more rollbacks occured, I can't quite see
    it somehow. Too many hacks to undo IMO.

    Kunle



  14. #14
    David Bayley Guest

    Re: I have seen the light and it starts with B?

    Kunle Odutola wrote in message news:3b052647$1@news.devx.com...

    > How is this different from the Option VB6Compatibility proposals ?


    Very different. As I understand it, Gary is suggesting a C# option rather
    than a VB.NET option.

    I think a C# option to view/edit code without curley brackets and
    semi-colons would be pretty cool. B# would be an extension to the C# editor
    that would allow you to not only adjust the colors of the code, but the
    syntax as well. Both the B# and C# editors could use the same CSC compiler,
    and the source code could be presented according to the developers
    preference.

    Language-independence however goes far deeper than mere syntax if it is to
    mean anything IMO. This is why VB.NET on the one hand is free to evolve
    irrespective of C# semantics, and on the other hand is free to retain
    compatibility with VB.

    If you want a C# editor that presents curley brackets differently, then
    personally I would pay money for that *add-in* as it sounds pretty cool.
    However, gratuitously sacrificing VB to C# semantics seems a pointless
    strategy. Better to use language-independence for adding value to the
    platform, rather than removing it, and VB compatibility adds a LOT of value.

    --
    David.




  15. #15
    Kunle Odutola Guest

    Re: I have seen the light and it starts with B?


    "David Bayley" <dbayley@spamless.aebacus.com> wrote in message
    news:3b05caa4@news.devx.com...
    > Kunle Odutola wrote in message news:3b052647$1@news.devx.com...
    >
    > > How is this different from the Option VB6Compatibility proposals ?

    >
    > Very different. As I understand it, Gary is suggesting a C# option rather
    > than a VB.NET option.


    I meant the idea of supporting two dialects of VB given the differences in
    VB6 and VB.NET. Not the specifics of Gary's idea of a B# language
    particularly.

    > Language-independence however goes far deeper than mere syntax if it is to
    > mean anything IMO. This is why VB.NET on the one hand is free to evolve
    > irrespective of C# semantics, and on the other hand is free to retain
    > compatibility with VB.


    True. Language evolution depends a great deal on cross-fertilization though.

    > However, gratuitously sacrificing VB to C# semantics seems a pointless
    > strategy. Better to use language-independence for adding value to the
    > platform, rather than removing it, and VB compatibility adds a LOT of

    value.

    VB.NET provides compatibility with "classic" VB. The on-going discussions
    are a result of differences between what the level of compatibility that MS
    has provided on the one hand and, individual ideas about what the
    appropriate level of compatibility should be.

    C# hasn't played a major part AFAICT.

    Kunle




Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center