The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
Yes, it does look a bit like Wonderware but ours had more 3D effects. Apparently they became aware of us because one year at SemiCon in San Francisco they saw my badge and wouldn't let me enter their booth. I felt like I had really arrived.
The language was a cross between C and FORTRAN with, as I used to say, the worst of both. It started out fully interpreted with a VM-type of design and then it morphed into a fully compiled-on-the-fly thing with native machine code generation when we heard concerns about its speed. It could be pre-compiled and loaded from a binary image also. It either called functions from DLLs that were mapped in or it executed an intrinsic operation like a computation or comparison. Everything was shared memory based and this was key to the whole system. We had the prototype definitions of all functions from the DLLs that were mapped in loaded into shared memory so it was like a pre-compiled header and it compiled very quickly. The script engine could be embedded and it was into three or four different process, including the operator interface. Every action in it like clicking a button could invoke a script function.
The shared memory part was very key. The whole system was based on it so you could access data anywhere. That forced things to be rather primitive in the sense that we could only have POD types in shared memory. There were what I called psuedo-pointers though which were actually offsets since pointers are useless outside of the owning process. Even the generated code was in shared memory and the script engine context was too. We started all of this in QNX but we became annoyed by the lack of driver support so we jumped into the Win32 world as soon as it was out and Windows NT when it was in beta. We also used Visual C++ version 1.0 with it. At that time, you could map into another process' memory space but you couldn't safely unmap from it. That was an important thing for us and meant everything had to go into shared memory. We wanted to be able to attach to a running process with the debugger, interact with it, and then detach from it so it could continue running.
The debugger was a pretty standard one for its time. It showed all of the script files used in the process and let you single step through the code, set break points, and all the standard stuff. You could also see the variables for current script function along with variables you selected to watch. This brings up one of the weakness of the design. Because everything had to be in shared memory for access by the debugger, the stack was too but it was a static stack like FORTRAN. This limited recursive functions but we never found a need to implement one so it wasn't a big deal. In retrospect, I could have made a big stack in shared memory and made the stack dynamic but I didn't think of it at the time. I was more concerned with mapping the symbols for the current function and it wasn't obvious to me how to do that dynamically then. It is now.
I mentioned QNX. We really liked its message passing, multi-processing architecture so we implemented that for Windows. With shared memory and a few synchronization events we were able to make a very fast message passing library. That made for a very flexible system architecture. We tried Windows 95 and found its context switch time to be too slow at more than ten times slower than NT so we stuck with NT. Both were out about the same time, at least in beta form. MSDN was really useful back then.
I keep writing we and that's because me and one other guy did all of this. It took about three years to get it all refined. We were very fortunate to get that much time.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
I haven't seen 7 or 8 or any that have come in-between "on the big screen" and don't intend to change that. I've seen each exactly once at a neighbor's, and that's about all the money Disney's gonna get out of me for the franchise.
I have seen the 3 Trek reboot movies in theaters (also exactly once) and, unlike every Trek incarnation that came before them, have not purchased them on disc. How bad does it have to be to break a nearly 50-year tradition? I own the very first 40-disc TOS set (which were sold as 2 episodes per disc) all the way to Enterprise.
I still watch what's being produced...but I have no incentive to spend money on them. I may make an exception for Picard, if it's any good. Just don't give me "re-imagined Klingons"...
Still, I am quite happy to have been of the generation who had the pleasure to live with the releses of Starwars movies. The bashing may be justified to some points, but this fantasy universe is still one of the best ever created and imagined.
Any maybe it really happened a long long time ago.
It'd be kinda neat if over the next couple of days the background colour got darker and darker until all the text was just black on black and then it was replaced with a white dot in the middle of a black screen with a high pitched noise in the background ...
(Probably a fair amount of work for a silly joke though)
Sent from my Amstrad PC 1640 Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
Reminds me, took my truck to dealer this week, it had an intermittent shuDDer when pressing the accelerator at speed but is still under warranty, to have the transmission fluid replaced (the manufacturer has found the original type of fluid breaks down too easily)
On the work document the problem was "Truck has a shuTTer at highway speed"