Python/Wx dot net
Pettersen, Bjorn S
BjornPettersen at fairisaac.com
Mon Oct 6 13:26:20 EDT 2003
More information about the Python-list mailing list
Mon Oct 6 13:26:20 EDT 2003
- Previous message (by thread): Python/Wx dot net
- Next message (by thread): Python/Wx dot net
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> From: HankC [mailto:hankc at nospam.com] > > On Mon, 6 Oct 2003 00:45:17 -0700, "Carl Waldbieser" > <waldbie at attglobal.net> 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
- Previous message (by thread): Python/Wx dot net
- Next message (by thread): Python/Wx dot net
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list