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

[Davis Johnson]

The basic difficulty is that fopen() is standard. I had never heard of 
fopen_s() so I did a little googling and, so far as I can tell, fopen_s 
is a Microsoft invention, not part of any standard.

An implementation that simply substituted fopen_s() for fopen() would 
not be portable.

What you could do is replace fopen() with a new function (file_open() or 
something). There could be two implementations of file_open(), one using 
standard interfaces and another for windows.

Villy Madsen wrote:

>I haven't seen too much about this lately - I assume that no one has found the
>magic bullet yet...
>
>I think that I might have.
>
>It's kind of early in the testing process, but things are looking good...
>
>I have been tinkering with the idea of re-writing the IO stuff to go directly
>against the windows api's.  The newer documentation describes the CREATEFILE api
>- which is supposed to replace the OPENFILE etc -  with more functionality.  I
>have always thought that the issues with the delay startup (and the massive
>number of write IOs that accompany the delay) were related with how windoze
>handles file sharing.  The CreateFile api allow us to control how (or if) file
>sharing occurs.
>
>For whatever reason, I never bothered to look at the higher level C instructions
>- after all fopen doesn't have enough parameters to support any control over
>file sharing.
>
>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...
>
>fopen_s doesn't appear to be supported in GCC - so unfortunately it means
>compiling it with Visual Studio..
>
>I replaced the fopen statement in sim_fio.c with
>
>FILE *fp;
>fopen_s (&fp,file, mode);
>return fp;
>
>I have seen one instance of the long write on termination and an instance of the
>long write on statup on another system that I was testing this out on.  In each
>case, it only happened on a single drive.  Prior to this change, it would
>usually happen on both of my drives - at both startup and shutdown.
>
>Side benefit, when it did happen it ran faster - the read/write buffering seems
>to be better.
>
>Other side benefit - tweaking the optimizations seems to have bought faster
>execution than I had with the mingw compiles version.
>
>On my 1.5ghz 1gb P4 I now get 6+ vups.  I was getting less than 5 before.  On
>the 3+ghz celeron I am getting ~ 16 vups.  I haven't tried recompiling it on
>that system - it would be interesting to see if VS can get any more out of the
>code if it's compiling on the target system.
>
>Still a little early to jump and down - but it sure looks like this change beats
>the problem I was having.
>
>Ove Christmas, I am going to see if I can modify my autoshutdown code (that lets
>windows shutdown the VAX) so that the processor is halted, the memory image is
>written to disk and the process shutdown..
>
>Merry almost Christmas
>
>Villy
>
>
>
>Villy Madsen
>www.members.shaw.ca/villy.madsen
>
>
>_______________________________________________
>Simh mailing list
>Simh at trailing-edge.com
>http://mailman.trailing-edge.com/mailman/listinfo/simh
>
>
>  
>