Re: VSTa lockups and Shared Libraries....

>Yep, a *very* crude one, and a polling keyboard driver (*that* was
>fun...)

Is it enough like an IBM PC for me to drag it over? I don't mind
swelling the kernel a little bit so long as it's behind #ifdef KDB.

>On the 386 I guess PIC will suck 5-20% depending on the code. I once
>messed with gcc's register allocation an crippled it a bit just to see
>how much register usage affected speed. That was the results or
>crippling one register. I think PIC is out, even though it would be
>nice. We have to think of a better idea....

I guess we're left with fixed address assignment (which we all know,
for the general case, is not good enough) or doing relocation &
address assignment on-the-fly. Hmmm... what about doing a shlib
server, and then doing mmap()'s off of files in the shlib server.
During bootup you'd write a library to it, and then when you close()'ed
it the server would relocate the library and start advertising it under
the given name. I don't know, just a wild thought.

>I'm *really* looking forward to getting a decent filesystem. BTW. I
>wonder if we shouldn't remove *all* the CR/LF conversion stuff in the
>libraries, and just go straight Unix style. The more I think about it,
>the more I think a single character EOL is important.

I believe all of VSTa's C library uses single '\n'. gets()/fgets()
will understand \r\n also, although puts()/fputs() also follow the
single \n rule. I don't think the gets() conversion is causing your
problems. It's just that we're living in a DOS cross-compilation
environment, and still running into DOS conventions sometimes. We're
living with it--at least for now--because it was convenient, and we
can't strip the \r's until we have a native port of all our utilities
including RCS, or until somebody finds the DOS RCS port and does a
special version which uses UNIX-style line termination.

                                        Andy
Received on Thu Aug 19 20:48:22 1993