Re: Actually I am a little bit disappointed...

From: Joanna Carter \(TeamB\) (joannac_at_btinternetxx.com)
Date: 10/04/04 

Date: Mon, 4 Oct 2004 11:29:21 -0500

"Dennis Landi" <nada@nada.com> a écrit dans le message de news:
41616aed$1@newsgroups.borland.com...

> The diabolical implication of "Win32/64 API will be a .NET emulation
layer"
> is a bald-faced scare tactic indicating that .NET is the only future.

I have never said that .NET is the only future. If that is the point of your
argument, then you are sorely mistaken.

If you want to continue to write Win32/64 code in the managed Longhorn
future, then you are going to come up against security restrictions that are
going to have to be surmounted on client's machines.

If you look at the recent problems caused by XP sp2, you will see the
security implications are already starting to cause problems with some apps.

OS Security has had to become M$ #1 priority; with all the holes in Windows,
they can't afford to continue as they have in the past. .NET is an integral
part of the strategy to ensure a more secure OS; one thing that cannot exist
in a secure OS is unbound arrays that can be exceeded. Win32 uses pszStrings
all over the place.

> That's simply not true. I would much rather see .NET succeed on its own
> merits. Win32/64 API, is already a successful API, and will continue to
be
> so. MS is not stopping its support for these APIs. Whidbey 2005 (VC++
> 2005) will fully support natively compiled and managed code.

They may have been successful APIs in the unsecure past, but if you want to
have a future coding for security conscious clients then AFAICS you do not
have a choice.

It might be an either/or future for folks like you who obviously don't care
about OS security, but for the really big players, cannot afford to ignore
the importance of a secure OS.

Joanna 

--
Joanna Carter (TeamB)
Consultant Software Engineer
TeamBUG support for UK-BUG
TeamMM support for ModelMaker

Relevant Pages

  • Re: StreamSec
    ... Frankly, I have not asked/used Henrick's support a whole lot, ... "secure", and it's not. ... big part of HIPAA deals w/Patient Recordprivacy. ... security requirements on network/in transport/data format etc. ...
    (borland.public.delphi.thirdpartytools.general)
  • Re: Security for SUN-Cluster 3.0/2.2 with OPS (8.1.7)
    ... Security for SUN-Cluster 3.0/2.2 with OPS ... > and like to make them secure. ... what security modifications can I made if I don't care about support? ... hardening tool) on a SunCluster without understanding your support ...
    (Focus-SUN)
  • Re: Why Is the Mac More Secure than Windows?
    ... That being said OSX on UNIX is more secure as it was designed to be ... PLEASE, PLEASE, PLEASE, PLEASE, PLEASE provide something to support this oft ... posted countless times in my short six months here. ... If you are interested in some of the things Apple does to boost its security ...
    (comp.sys.mac.advocacy)
  • nCipher Advisory #6: Access control defects in PKCS#11 keys
    ... As a function of internal QA testing, nCipher has identified that, ... PKCS#11 library, which should be secure, may be exportable from the ... who can issue commands to any module in the same Security World, ... acceleration and do not support key management are NOT affected. ...
    (Bugtraq)
  • Re: Ten least secure programs
    ... it's probably better you leave the topic alone ... I said I do not have security issues with the programs I code. ... I didn't realize you were a Linux user, ... > the most widely used and secure UNIX flavors? ...
    (Security-Basics)