Slashdot Mirror


User: bratmobile

bratmobile's activity in the archive.

Stories
0
Comments
131
First seen
Last seen
Profile
(view on slashdot.org)

Comments · 131

  1. Re:Well no, it's not all like that on Linux Kernel Code Humor · · Score: 2, Informative

    Oh, you simply wouldn't believe the inside of MS code bases -- both good and bad.

    The Office Assistant (Clippy and all his ilk) started as a project in the Office group. It came up for review in front of BillG, and when someone told Bill exactly what feature the meeting was about, he said, "Oh, is this about that fucking character?"

    Needless to say, this was a pretty demoralizing remark for the team presenting their new feature. So, internally, "TFC" became the codename for the Office Assistant, and was used as the function prefix, header file prefix, etc. for a long time.

    I know this because I worked with some of the guys from that team, and I've heard the story corroborated by a lot of different sources.

  2. Re:Sooner or Later on Windows Security Holes Go Mostly Unexploited · · Score: 1

    What planet are you from? Microsoft fixes security bugs ASAP. It's reputation to server operators is crucial. Plus, XP automatically downloads them and offers them to you, when they are released. How many versions of Linux do this?

  3. Re:Kinda silly on More Drooling Over The Opteron · · Score: 2, Insightful

    Windows has already been ported to several 64-bit architectures: DEC Alpha, IA64, and AMD64. (Although DEC/Compaq abandoned the Alpha, Microsoft still uses them internally to verify the 64-bit port of NT.)

    I worked in the NT division for several years, and I had an Itanium prototype workstation to do my 64-bit work. It worked fine -- the entire OS works fine, and has instruction-level emulation for 32-bit x86 code. (Microsoft had this a long time ago, in their Alpha 32-bit release. This was released as early as NT 3.51.)

    So, you won't see Microsoft lagging behind the 64-bit processors. They are all over 64-bit. As soon as the hardware market is ready, they'll be selling 64-bit OSes.

  4. Re:It is better to take than receive.... on MS .net vs Mono, Open Source · · Score: 1

    Repeat after me:

    One cannot steal DOD/IP because the US government put it in the public domain. One cannot steal DOD/IP because the US government put it in the public domain.

  5. Re:wonder what this means on Microsoft Next Generation Shell · · Score: 1

    You are correct that .Net is Microsoft's main way of dealing with platform portability. The goal is for a majority of OS code to be ported to MSIL-based languages, and for the OS install CDs to contain mostly MSIL-based binaries. (MSIL is .Net's equivalent of Java bytecode.)

    However, Microsoft has pushed very hard for MSIL and C# to be public standards, completely independent of Windows, and (more importantly) free of royalties. You can download the MSIL and C# standards from ECMA (or Microsoft, or a bunch of the companies who also signed on to the submitted standards), and implement your own C# compiler, MSIL JIT compiler, runtime library, etc.

    Microsoft even recently provided a stripped-down version of .Net that runs on FreeBSD and MacOS. Also, the Ximian guys are building Mono, a completely open-source .Net environment. So there is a lot of momentum behind C# and MSIL, completely independent of Windows. Nothing could stop someone from implementing it on Linux -- as the Mono guys are doing right now.

    Which I think is awesome, for all concerned.

  6. Re:wonder what this means on Microsoft Next Generation Shell · · Score: 1


    You're not listening. It doesn't matter if the marketing message is confusing. .Net as a development technology is here to stay.




    I worked at Microsoft for 5 years, mostly in the NT division. Microsoft is extremely, extremely serious about managed execution (.Net / MS-Java).




    About a year ago, Microsoft internally decreed that the next major version of Windows (Longhorn, which comes after .Net Server, which is on RC2 now) will support managed APIs for ALL system functionality.




    Trust me. I've been to the meetings, I've read the internal documents on this. Microsoft is DEAD serious about the .Net languages, development tools, etc. COM/OLE/DCOM/etc. were what Microsoft developed for unmanaged, component-based software development. Microsoft has certainly not abandoned COM/etc. -- look at the .Net SDK, it's all well-supported under .Net -- but the message to developer's is clear: .Net is a huge technological leap (it's basically Java done right), and Microsoft is betting EVERYTHING on it.