RE: Python/Wx dot net

Discussion in 'Python' started by Pettersen, Bjorn S, Oct 6, 2003.

  1. > From: HankC [mailto:]
    >
    > On Mon, 6 Oct 2003 00:45:17 -0700, "Carl Waldbieser"
    > <> wrote:
    >
    > >To me, it seems like it would be a very extreme position for
    > >Microsoft to disallow native code on their future operating
    > >systems. find myself asking, "what would be the point?"
    > >If someone wanted to write a program that they couldn't write
    > >using managed code, they couldn't use Windows.

    [...]
    > Carl, thanks for your comments - they're actually a little reassuring.
    > Not really to argue, but just to comment on the points above:
    >
    > extreme position - yes indeed, but I can see it happening if it would
    > increase the control/power of MS.


    Sounds almost like the next Stephen King novel... Purely logically, can
    you explain why they wouldn't just re-allocate resources to the newer
    (and arguably better) technology? (Why would they risk bad pr from any
    public statement when they can ignore it into oblivion? -- anyone
    remember J#, rememer when it compiled to Java byte codes? [it still
    does? (I have no idea... people are still using Java? <wink>)].

    Windows has never really been the poster-child for
    "rewrite-from-scratch-using-new-superior-idea" in the development
    department (all of ODBC, DAO, ADO, and now ADO.NET are still alive and
    well). The needed idealism is rather one of the foundations of
    open-source (and LISP programmers <grin>). Besides, Microsoft has too
    many LARGE customers to do something like that -- i.e. try telling
    someone like ms.com [no that isn't microsoft ;-] that their internal
    apps will not run on the newest Windows? (ROFL, ah, that made my day :)

    > the point? - Well, two quick ones: 1) controlling a framework that is
    > written to by a huge number of developers gives them a huge amount of
    > power;


    they didn't need .NET for that, did they?

    > 2) if Windows runs managed code only the security of the
    > platform would increase substantially.


    I'm anxious to hear how Microsoft has managed to convince you they can
    substantially increase security... (regardless of technology)?

    > they couldn't use Windows - I think as .net matures there will be
    > very few apps that won't be capable of running as managed code.
    > Drivers and other low level stuff may be excepted with an MS
    > certification or something.


    ok.., so I've got about 950K LOC of c++ that supports the applications I
    care about. I also have customers who want bugs fixed and features
    added, management who wants new product lines that will make us the next
    million, sales, tech support, and let's say a dozen developers to handle
    it... What's your business case for giving developers 2-5 weeks to learn
    the "over 50,000 methods" in .NET, then rewriting, testing, finding
    workarounds for new compiler and .NET bugs, (most likely) rewrite a
    proprietary testing framework, write new internal documentation,
    schedule releases, create transition plans, emergency roll-back plans,
    etc., etc. (and we're a very small part of a not 'terribly' big
    company).

    (..hmm, my 1394 card is MS certified... wonder how it has managed to
    "blue"-screen XP Pro four times... ;-/)

    > integration - Yeah, but it's still early, you would have to expect
    > integration at this point. I also understand that there will be no
    > thunking layer to run 32 bit native code from 64 bit managed code so
    > writing to Win64 will require either a 64bit compiler or managed code
    > exclusively.


    Seems like they learned from the Win16 transition. You should be very
    HAPPY! <grin>.

    > I know some of those points are a little far fetched - I'm just
    > feeling a little bleak about the future lately :)


    Any better?

    -- bjorn
    Pettersen, Bjorn S, Oct 6, 2003
    #1
    1. Advertising

  2. Pettersen, Bjorn S

    HankC Guest

    On Mon, 6 Oct 2003 12:26:20 -0500, "Pettersen, Bjorn S"
    <> wrote:

    >
    >> 2) if Windows runs managed code only the security of the
    >> platform would increase substantially.

    >
    >I'm anxious to hear how Microsoft has managed to convince you they can
    >substantially increase security... (regardless of technology)?
    >


    I thought managed code would prevent, among other things, things like
    buffer over runs. In any case, they can't do to much worse.


    >
    >> integration - Yeah, but it's still early, you would have to expect
    >> integration at this point. I also understand that there will be no
    >> thunking layer to run 32 bit native code from 64 bit managed code so
    >> writing to Win64 will require either a 64bit compiler or managed code
    >> exclusively.

    >
    >Seems like they learned from the Win16 transition. You should be very
    >HAPPY! <grin>.=20
    >


    My understanding is that 32bit native code will be run by the 64bit
    OS, but 32bit dll's cannot be called from 64bit managed code. IOW,
    there will still be native 32 bit apps running under 64bit windows.

    >
    >Any better?=20
    >


    Actually, yes. It's been a rough week, especially in Bor-Land :)
    HankC, Oct 7, 2003
    #2
    1. Advertising

  3. ----- Original Message -----
    From: "HankC" < <mailto:>>
    Newsgroups: comp.lang.python
    Sent: Monday, October 06, 2003 4:13 PM
    Subject: Re: Python/Wx dot net
    > I thought managed code would prevent, among other things, things like
    > buffer over runs. In any case, they can't do to much worse.
    >

    Well, that's the theory. Since managed code does not let you use pointers,
    you are not supposed to be able to accidently write past the end of your
    data structures. However, you can make the same arguments for Python, or
    Java, or a lot of other languages that don't let you "get down to the
    metal". Of course, Python is written in C, so if there was a bug in the
    interpreter code, it could overwite a buffer on your behalf (of course this
    is purely hypothetical ;-) ). It is really somewhat misleading to say
    "buffer overruns are now impossible." It would probably be more accurate to
    say, "if you trust Microsoft, or if you trust Sun, or if you trust the
    Python Dev team and the Open Source community, you are trusting that they
    are going to make sure that there are not going to be buffer overruns in
    *their* code."

    To some extent, I would suppose it is less likely for code that is generated
    by a widely used compiler or interpreter to make the same kind of mistakes
    that would otherwise be made by hand. But even machine generated code could
    have some hidden, exploitable bug. I have never in the course of programming
    with Python come across what I would have recognized as a bug in the
    interpreter. However, the fact that there are bug-fix releases suggests that
    there has in fact been code that was incorrectly interpreted by a particular
    implementation. The same is also probably very true of .NET managed code. It
    all comes down to who you are going to trust.

    I'm not sure if Microsoft relases bug-fix information for .NETor not, so I
    really am not sure the extent I can trust that their code is going to be any
    more secure than say using some third party C++ libraries and tools like
    lint. I probably can assume that if a problem exploitable by malfefactor
    emerges, Microsoft will try to correct it as quickly as possible-- but there
    are also rumour floating around that suggest that maybe they would just try
    to conceal it instead. I don't have the answers here, and Microsoft has
    picked up a bad reputation in this regard. It doesn't necessarily mean it's
    true, but it doesn't particulary increase my confidence.

    Since Python's source code is freely available, it's a lot easier for me to
    trust it. If I have particular concerns, I can look at the source myself,
    or I can ask people with more expertise to look at it for me. And if there
    is a bug discovered, I don't have to take a passive role and sit around
    waiting for someone to correct the problem for me-- I can take an active
    role. I could patch it myself (if it's within my technical capabilites), or
    I could hire a team of experts to patch it (if it's in my budget). I can
    still just submit a bug report, too, but the fact that the bug is going to
    be in the open at least lets others be aware of what's going on. For these
    reasons, I feel I can have a good deal of trust using Python.

    Saying that code written in (unmanaged) C or C++ is inherently not secure is
    also misleading. C and C++ catch a lot of flak because it is possible to
    accidently have buffer overrun errors and enter the dreaded realm of
    "undefined behavior". These mistakes tend to be especially common when you
    are just starting out in either of these languages. However, both these
    languages have been around for quite some time, and a good deal of effort
    has gone into producing sophisticated tools for detecting these kind of
    errors. Again it boils down to trust. Am I going to trust code that I
    wrote? Code that someone wrote for the Standard Library? Code that my
    compiler generated? Can I trust my tools to catch errors that I won't? In
    some cases maybe I can trust the code-- in others, maybe I shouldn't.

    Carl Waldbieser
    Carl Waldbieser, Oct 7, 2003
    #3
  4. "Carl Waldbieser" <> wrote in message news:<Bxrgb.2924$>...
    > ----- Original Message -----
    > From: "HankC" < <mailto:>>
    > > I thought managed code would prevent, among other things, things like
    > > buffer over runs. In any case, they can't do to much worse.
    > >

    > Well, that's the theory. Since managed code does not let you use pointers,
    > you are not supposed to be able to accidently write past the end of your
    > data structures.


    This is not correct. The Microsoft ".NET" Virtual Machine does support
    pointers. C/C++ code doesn't magically become "safe" when compiled for
    the VM, and may well be harder to debug.

    Sam
    Samuel Barber, Oct 7, 2003
    #4
  5. Pettersen, Bjorn S

    Neil Hodgson Guest

    Samuel Barber:

    > This is not correct. The Microsoft ".NET" Virtual Machine does support
    > pointers. C/C++ code doesn't magically become "safe" when compiled for
    > the VM, and may well be harder to debug.


    There are various levels of compliance in .NET. Since VS .NET 2003, C++
    can compile to "verifiable" MSIL, which can then be checked by the verifier.
    There are some quite onerous restrictions on verifiable code such as not
    being able to perform pointer arithmetic.

    Some information in
    http://msdn.microsoft.com/library/d...producingverifiablecomponentswithmanagedc.asp

    Many will say that without pointer arithmetic, it is not C++. Microsoft
    people have indicated that some of the restrictions may be lifted in later
    versions.

    Neil
    Neil Hodgson, Oct 7, 2003
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Samuël van Laere

    To dot or not to dot?

    Samuël van Laere, Oct 16, 2003, in forum: HTML
    Replies:
    8
    Views:
    415
    Samuël van Laere
    Oct 16, 2003
  2. Christopher M. Lusardi

    volatile struct in dot h vs dot c

    Christopher M. Lusardi, May 11, 2004, in forum: C Programming
    Replies:
    3
    Views:
    464
    Peter Shaggy Haywood
    May 15, 2004
  3. Nathan Sokalski
    Replies:
    11
    Views:
    690
    AAaron123
    Aug 14, 2009
  4. krishnan

    Dot Net Project Execution without Dot Net and Framework....

    krishnan, Jan 7, 2006, in forum: ASP .Net Building Controls
    Replies:
    0
    Views:
    175
    krishnan
    Jan 7, 2006
  5. Replies:
    6
    Views:
    230
    Thomas 'PointedEars' Lahn
    Dec 12, 2005
Loading...

Share This Page