[Simh] Simh on Windows - long startup delays and long shutdown delays

[Davis Johnson]

Andreas Davour wrote:

>On Sun, 16 Dec 2007, dave porter wrote:
>
>  
>
>>>Then a couple of days ago I ran across a comment on the microsoft site that
>>>the
>>>fopen instruction had been deprecated - and that one should use the fopen_s
>>>instruction instead - unless one wanted to share the file...
>>>      
>>>
>>Forget it. Microsoft thinks you shouldn't use that function, but that
>>doesn't mean you shouldn't use the function.
>>
>>MS has correctly observed that some C RTL functions (say, strcpy) are
>>unsafe in the hands of idiots. MS has therefore introduced functions
>>with better behaviour and thinks everyone should use those instead.
>>Sure, but you no longer have portable code. And there's no gain if
>>you weren't using the original function idiotically in the first place.
>>
>>Apparently, the 'security' angle of fopen_s is that if you feed
>>it incorrect arguments, it calls an invalid parameter handler rather
>>than immediately letting the MMU execption loose.
>>    
>>
>
>I wouldn't say it is such a bad idea after all. The intention with this 
>is obvious, MS lock in. But, considering the track record we have with 
>buffer overflow errors and the like I think the idea is a great one and 
>long over due. It should have been done with the last C standard, and 
>not as a way by MS to force lock in, though.
>
>If we should start calling people idiots we migth never stop, but I then 
>point the finger towards Richie. Whatever you might think, Dave, C *has* 
>a security problem.
>
>/Andreas
>
While it doesn't matter much what I think on the subject, I think:

    * There are flaws in the C RTL spec. Don't get me started on
      additional signals not being queued while a signal handler is
      executing. fopen() probably doesn't allow for passing enough
      information between the program and the underlying environment. I
      can't really get too worked up about the shared access issue,
      however. If you are in an environment where misbehaving programs
      running in the same user context are a problem you've already lost
      the security battle.
    * Microsoft probably has little motivation to maintain source-level
      compatibility with competing systems. Some would say that they
      have a motivation to actively break source compatibility. I'm not
      so sure. Maintaining compatibility requires effort.
      Incompatibility can result just as easily from lack of trying as
      from trying to be incompatibility.
    * Microsoft made design choices in their implementation of the
      standard C RTL. Some of these seem to have unfortunate performance
      consequences for SIMH in some circumstances. Some of these may
      have security consequences, I really don't know. In any event
      Microsoft has decided to mitigate these consequences with a
      non-standard API, rather than correcting the problems with the
      standard API.

Given all that, which we can't do anything about, we should concentrate 
on what we can do something about. I'll go back to saying that if using 
the non-standard API provides sufficient benefits for Windows users than 
a little conditional compilation or two versions of a small module are  
a reasonable course to take.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20071216/1f8c8382/attachment-0002.html>