RE: Managed OS?

From: Tiago Halm (thalm_at_netcabo.pt)
Date: 11/24/03

  • Next message: Nick Duda: "RE: About SUS." 
    To: <security-basics@securityfocus.com>
Date: Mon, 24 Nov 2003 17:04:34 -0000

    As far as I can understand, Longhorn will be built using Win32 API.
    Windows OS functionality is vast and some of it could be accessed using
    .NET, or COM. What could not be accessed directly using COM or .NET could be
    somewhat overcome using declares (VB) and dllimport (.NET).
    C/C++ is, of course, unlimited to that respect.

    The main difference is that **all** OS functionality in Longhorn, will be
    now be accessible using **directly** managed code (.NET), meaning that there
    will be a whole range of classes to deal with every functionality of the
    operating system.

    Regards,
    Tiago Halm

    -----Original Message-----
    From: Some one [mailto:someonenearyou@yahoo.com]
    Sent: sábado, 22 de Novembro de 2003 1:52
    To: security-basics@securityfocus.com
    Subject: Managed OS?

    I have some questions about forth comming Operating
    System by Microsoft code named "LongHorn". I have read
    on microsoft.com that this OS will be first ever OS
    that will be built with managed code.
    Now if I am right that would mean that it would and
    should eliminated all Buffer Over flows theoratically
    right?.

    and also I wanted to know that can an entire OS be
    built with managed code?

    If so if Microsoft is developing the OS with managed
    Code that would mean no WIN32?? and that would be a
    complete rewrite ?? or just the same code will be
    compiled with buffer over flow protection on some
    intelligent compiler.??
    As far as I know all technologies like .NET or MFC
    were all built on top of WIN32 API, and it is the
    official langauage of Microsoft (though we had some
    limited support for POSIX and OS/2 libraries).

    If I am right what would happen to legacy applications
    built on Win32 ??

    __________________________________
    Do you Yahoo!?
    Free Pop-Up Blocker - Get it now
    http://companion.yahoo.com/

    ---------------------------------------------------------------------------
    ----------------------------------------------------------------------------

    ---------------------------------------------------------------------------
    ----------------------------------------------------------------------------

  • Next message: Nick Duda: "RE: About SUS."

    Relevant Pages

    • Large directories... DirectoryInfo or Win32 API?
      ... It appears that when GetFiles is called it loads the entire ... directory into memory before proceding to the next line. ... To solve this problem I put the Win32 API functions FindFirstFile, ... managed code if possible. ...
      (microsoft.public.dotnet.framework.performance)
    • Re: Large directories... DirectoryInfo or Win32 API?
      ... Blog: http://weblogs.asp.net/justin_rogers "Justin Rogers" wrote in message ... >> To solve this problem I put the Win32 API functions FindFirstFile,>> FindNextFile, and FindClose in a wrapper class and created a struct to hold>> the FileData. ... I would really like to stay in the world of>> managed code if possible. ... >> Mike G.> ...
      (microsoft.public.dotnet.framework.performance)
    • Re: textbox and size.
      ... the Win32 API is always available, and I use it occasionally for tasks that ... aren't available through Managed code. ... I had to add cludges to multiply heights by 1.05, etc, and still often ...
      (microsoft.public.dotnet.general)
    • Re: Now Microsoft decouples Longhorn from .NET
      ... > Obviously, according to that quote, some - if not a lot - of Longhorn ... > will be built with managed code. ...
      (borland.public.delphi.non-technical)
    • Re: Large directories... DirectoryInfo or Win32 API?
      ... Internally they are doing the Win32 API calls for you. ... also allocating a LOT of array space to do it. ... I would really like to stay in the world of> managed code if possible. ... > Mike G. ...
      (microsoft.public.dotnet.framework.performance)