Microsoft developers develope the patches using managed code in one of many
languages including
C# based on the CLR (Common Language Runtime) model in the .NET Platform
in Visual Studio.NET. The languages all share a common unified set of class
libraries that can be encoded
into IL (Intermediate Language). A runtime-aware compiler compiles the IL into
native executable code within a managed execution environment that ensures type
safety, array bound and index checking, exception handling, and garbage
collection.
Using managed code tends to be secure becuase managed code can't be reversed
engineered so easily unlike that
of p-code becuase the managed code is obuscated (encrypted). Programmers can
avoid the many mistakes that they make in using unmanged code like incorrect
type casting, out of bound errors and not deleting unused objects correctly
from memory by not using Object.delete() method template (garbage cleanup).
This managed code use in Microsoft .Net Framework allows developers using
Managed code to spend much less
time in worrying about non-logical issues and focus on the managed code
security methods and best practices using fewer lines of code with .NET
Framework than they ever could using the method that mainframe and assembly
programmers used over 30 years ago.
Marc Sims
Data Technician I
Prince George's Community College
>>> [EMAIL PROTECTED] Friday, January 06, 2006 >>>
Sorry to have to disagree somewhat
Microsoft need to code and assemble their executable modules in a properly
secure manner
Most of the current software is written as sub-modules which are then
assembled into an executable set for distribution,
but that distributable file then contains intermixed blocks of code data and
workingspace buffers
Then when loaded into memory, a similar process happens
What is needed is for the technique used 30 years ago in mainframes to be
adopted.
modules created in at least 4 distinct sections, and those sections handled
differently by the OS program loader, and the CPU
Part 1 - code, and constants loaded into memory, and cannot be changed
Part 2 - working control data loaded into memory and can only be changed by
the code
Part 3 - inter-program communication areas for passing on data and API
requests - code will not be executed from this area
Part 4 - buffer and storage areas - allocated by the OS - code will not be
executed from this area
Each sub-module's parts will be assembled into 4 separate parts in any
distributable dll, com, exe etc
The 4 (or more) sections are managed separately by the hardware
and only the stuff in the Part 1 can be processed as instructions
And only the OS loader can put stuff into a memory area designated as a Part
1 zone
NO BUFFER Exploits possible
JimB
--
----------------------------------------
To unsubscribe, mailto: [EMAIL PROTECTED]
Is your picture included in the Official Win-Home List Members Profiles Page?
http://www.besteffort.com/winhome/Profiles.html
If not, write to: [EMAIL PROTECTED]
