Interesting to note that WINE predates this by several years - 1993 - but apparently there were commercial Win32 UNIX layers available too at the time.
On X-Windows, you can configure your system such that the focus follows the mouse. That is, when you move the mouse to a window, the focus automatically moves to that window.
It seems most early UNIX systems I used were configured this way, and it was extremely irritating since I was accustomed to "parking" the pointer out of the way, somewhere else on the screen, when doing things like filling in text fields.
I, on the other hand, strongly prefer focus follows mouse. At least on Unix systems, one (usually) gets to choose. On Windows and the Mac, no such flexibility exists. It's the same with windows stacking order control. I routinely push a window to the bottom of the pile on Unix and greatly miss that ability on my Mac. The "native" way to do that would be to minimize the window, but that's not really the same thing.
> They will also get auto raised, meaning the window on which the mouse hovers which be brought to the foreground.
If you don't want autoraise you have to hack the registry. And even then it works very badly. A lot of apps, at least back when I was using XMouse on XP, assume that if they have the focus they're at the top of the stack, and some (mostly the Microsoft ones!) will autoraise themselves regardless of the registry setting.
Focus-follows-mouse on Windows isn't, or at least wasn't, much of a success. It was marginally less annoying than click-to-focus, IMO, but only marginally.
On windows it is so so, but some programs are terrible, back in the day I had to use eclipse and it would autoraise when you moved the mouse over certain widget boundries.
I once wrote a small tray icon to dynamically toggle this stuff, including settings for auto-raise and delay. I haven't wanted it in ages, but I just tried on Win10 and it still appears to work!
I won't try to compare this to the Winaero tools. Mine is definitely in the hobbyist-scratches-an-itch class of software, but hey, it's open source too!
Nice. Now if it'd work consistently. We have Microsoft Lync for work. I've enabled the feature, but it will only work on the contact list window, not the chat windows. It also only works for some windows (like IE) when pointing to certain parts of the window. Having the pointer on the text of a page doesn't seem to be good enough, it has to be on the chrome and toolbars.
Agreed that this notion of lost to time proprietary WINE-like layers is indeed an amazingly bizarre curiosity. I would love to see more about that.
Regarding window focus, I use i3wm in which generally focus is switched with keyboard. Though (especially in configuration greater than 2 monitors), a quick mouse motion is even faster. Then I switch back out of my VM for the .1% of the time my work computer needs OSX, and I have to make the effort not to "rage to heart attack" over the most hateful UI paradigm in the universe - click once to focus window - then click AGAIN to focus widget.
On older versions of Windows, it was possible to write a utility that would emulate focus follows pointer, by installing a global message hook. More recent versions prevent messing around with focus across applications for obvious security reasons
That is the cool part about living on Windows and part of me gets sadder every time they try to limit it. I understand the rationale, but I still like to be able to tinker with 3rd party software while it's running. The whole concept of app isolation just rubs me wrong.
Yeah, there's quite a lot of Raymond Chen posts with the theme of "we had to take this cool feature out because people were abusing it". Only way round that is to go full Apple and refuse to run unvetted applications.
Maybe we need a flavour of UAC that allows you to put random junk apps in sandboxes while the others talk happily among each other.
The native way, which still works on Windows 10, is to call SystemParametersInfo() with SPI_SETACTIVEWINDOWTRACKING, SPI_SETACTIVEWNDTRKZORDER, and SPI_SETACTIVEWNDTRKTIMEOUT, followed by a broadcast WM_SETTINGCHANGE message. See my MouseWinX tool I linked elsewhere if you want an example.
Around that time frame, maybe a few years later, I ported some Windows middleware to Linux. The middleware was some COM objects written in C++, configured using the registry. I ported all those functions: CoInitializeEx, CoCreateClass, RegThis, RegThat, you name it. The framework nicely looked for DllMain and DllCanUnloadNow functions in the shared objects, and such. The registry mapped to a hierarchical directory structure.
Today, if you want to write Unix applications using Win32, the obvious choice would be WINE.
There was also a commercial Mac-Toolbox-on-UNIX layer created: Quorum Latitude. Adobe used it to bring Photoshop 3, Illustrator 5.5, and Premiere to SGI IRIX.
They were later purchased by Metrowerks, and saw an opportunity to be a porting layer to bring classic Mac apps to Rhapsody. Of course Apple later relented, and created Carbon to be that transitionary layer.
The MacTech archives have some interesting historical info:
I worked on a large to-UNIX migration using Mainsoft long ago. It was amazing how complete their win32 solution was, but it all felt so wrong. Using cross platform libraries from the get-go and NOT relying on single platform architectural components (like COM) is ultimately a better way to go.
After Avid acquired Softimage 3D from Microsoft, the next version, coined Softimage XSI, had a Linux version available through MainWin. It was diabolical. But it limped on; over the years maintaining an extremely tight version range of external library dependencies. Last version I used required Fedora 7 x64, a minor-version specific driver for FireGL/Quadro that just so happen to be on the CD that came with the HP XW workstation. Bite the head off a chicken, and boil snails with lizard tails, let it cool to room temperature, re-boil and simmer throughout use of softimage.
Softimage is now declared dead by their current owners, Autodesk.
The point about WCHAR size reminded me of how little browser security mattered back then. Kinda interesting to think about how the internet was so fresh that there wasn't such a focus on a secure application. I wonder how many buffer over/underflow exploits were completely ignored.
Danny Hillis gives a great talk called "The Internet could crash. We need a Plan B"[0]. In the talk, outside of security, he was talking about the culture of the early internet. It was really interesting, he said he still has a phonebook sized book of email addresses. He registered the 2nd domain on the entire internet (i think it was symbology but maybe that was the first) and he could have whatever he wanted. He summed up the culture of the time as, "then I realized it would be great to have a couple other domain names, but I thought that wouldn't be very nice"[approximated].
edit: Sorry forgot to make the point. Paul Graham says it in the Pycon 08' talk, it was built for guys at Bell labs to ask one another to get lunch. The people on the early internet were often scientists, engineers and academics and thus had mutual respect for one another. Stallman talks about not even having passwords on stuff, these were academics who were personally or professionally friendly so security wasn't at the forefront of the design.
As for the security, it was actually quite unusual that the ITS operating system machines he, Stallman, etc. used had essentially no security, just obscurity, although a password system did have to be added by the end of the '70s. The threat environment was certainly much much less back then, but computer time was very dear, and the most common paradigm required explicit budgeting, accounts that kept track of each CPU second used, etc. One reason PCs became so popular, their bigger engineering workstation brothers, etc. And plenty of people were thinking about security, e.g. see the Multics project.
> Which he personally did not like at all due to its role in suppressing use of Macsyma outside of its machines.
Symbolics offered Macsyma on other platforms.
Anyway Hillis' problems with Symbolics can't have been very deep, since Thinking Machines used Symbolics Lisp Machines extensively and offered them commercially as frontends for the Connection Machine.
> As for the security, it was actually quite unusual that the ITS operating system machines he, Stallman, etc. used had essentially no security
Stallman was reading other people's mails and he was threatening to sabotage other people, wasn't he?
Eventually, I assume. But when they got the licence they tracked down every copy of VAXSYMA and demanded the org stop using it and return/destroy all of the IP. And while I'm not familiar with the long term history of Macsyma at Symbolics, there's lots of talk about the reluctance of those outside its unit to sell or push it on non-Symbolics Lisp Machine platforms. As far as I know, it wasn't available for LMI's LAMBDA or TI's Explorer, although perhaps that changed as Symbolics' fortunes declined.
My reading on Danny's take on Symbolics comes from when I was working for LMI in the September 1982 to June 1983 period. Due to the ADL/Symbolics single source licencing scam (which also, I'll note, cut out Joel Moses, the "father" of it and others, something he was still unhappy about at the end of the '80s), he didn't want to buy from Symbolics, and asked me if there was any chance LMI could deliver in the time frame he needed for the founding of Thinking Machines, which was incorporated in 1993.
I regretfully had to tell him there was no way that would happen (success was not even in the picture until I recruited a extremely talented classmate right after he graduated in 1983), so they bought ~6 3600s to get the company off the ground (in part limited by the power available in their interim Watham office), and as you note, it was one of the front ends you could buy for the original formula Connection Machines (in black trade dress to fit with their stunning industrial design). Understandably, he wasn't willing to give up on his Comnection Machine dream because of Symbolics's behavior at that time.
Stallman was reading other people's mails and he was threatening to sabotage other people, wasn't he?
"Everybody" read other's emails, Joel Moses' was particularly fascinating. Of course there was an ethos about what you'd do with that information, and one I can see RMS violating.
But the only sabotage rumor I heard was WRT to a conflict he was said to have with Dan Weinreb. As the story went, on the basis of a technical dispute WRT to the Lisp Machine's software, RMS threatened to not only delete all live copies of this bit of Dan's code, but also their copies on backup tapes. Dan's response was to accept a job in Livermore, CA to work on the ambitious S-1 project (this looks good, just skimmed a bit of it: https://forum.stanford.edu/wiki/index.php/S1_project), which had very strong connections with this MIT community (the Chaosnet actually extended all the way over to it, I forget which is which, the other end was the most geographically east node in the MIT EECS machine room, one Trantor, the other Terminus), and for example GCC started with a failed port of its Pastel compiler.
When Dan returned, he flatly denied the rumor, and I found him credible, especially since threatening to mess with ITS backup tapes like that was a cardinal sin.
Lessor methods of sabotage, certainly obstruction, would certainly fit with RMS's style, but I can't remember hearing of any significant examples. And I'll note his response to all this craziness was to do GNU/the FSF, which was ideologically aggressive, but otherwise constructive. We are, after all, people who make things, not destroy them.
Note on my (claimed) credibility: I was on first name business with all of the people I've named in this post, was even a roommate of RMS when he launched the GNU Project.
This was really interesting. Thanks. His talk was fascinating and really opened my eyes to a lot of stuff. I was a bit foggy on some of the details of course, but imagine a culture where you only took what you needed. I thought that bit was really interesting. Rarely am I early, but if I get in on a service well before others I think about this and only register a single acct.
I was a bit foggy on some of the details of course, but imagine a culture where you only took what you needed.
That was indeed the culture of ITS, but it was mediated by very competent and humane admins. The nature of AI research meant that there were times some would need to pretty much take over the machine to do something hard, or quasi-real time (e.g. robotics, or a demo). So this was allowed, but e.g. I remember ... Jeff Schiller, I think it was, telling about how someone upped the priority of a long computation on MIT-MC too high, and rather than kill it and lose what it had accomplished up to that point, they set it to a lower priority (which, I note, anyone with the requisite system knowledge could do) so it wouldn't interfere with other users, and then educated the user about how to politely accomplish his goals (e.g. MIT-MC had a lot of spare cycles at times, it was bloody fast by the time dawn broke, and logged in from the VT-52 in the middle of it I could see lights advance every time I typed in a character).
Global variables in Win32 dynamic-link libraries (DLLs) are visible across processes, so it is important that developers are careful that these globals do not conflict with any variables within the Unix shared libraries.
Does anyone have any more information on this? This is presented/worded as the nature of DLL globals being shared across processes is why they they have to ensure they don't conflict, but this seems somewhat obvious if the globals are not namespaced within the library in some sense.
The more interesting question is how the DLLs' data was visible across processes such that this mattered at all, since this kind of sharing isn't available in the UNIX process or shared object model at all by default.
Global variables in DLL's are definitely not visible across processes. Each process which attaches a DLL has its own instance, in its own protected address space.
If the claim were true at face value, it would mean that if two programs use, say, MSVCRT.DLL (Microsoft's Visual C run-time), if one program reads from stdin or writes to stdout, it interferes with the other.
Correct, normal globals no. There is a way to make some special values have this behavior though. It's been a long time, but I think the reason was to have some analog to the win16 behavior. In that shared-everything universe, there were these IPC through dll patterns.
Win32 has an API for shared memory that is straightforward to use. You use CreateFileMapping with an INVALID_HANDLE for the file to create a mapping which is like MAP_ANONYMOUS in mmap (not backed by a file). It is not literally anonymous because you can give the mapping a name (similar to, say, a POSIX semaphore name in sem_open). Other processes can attach to the mapping using the name. To actually instantiate the mapping in the address space, you use the MapViewOfFile function.
Shared libraries are mmap()ed share private. Imagine that one added library initialization code (load time) that mmap()ed a section as shared public for some values. That's the 'doz model. The win16 model is much more fascinating though.
On X-Windows, you can configure your system such that the focus follows the mouse. That is, when you move the mouse to a window, the focus automatically moves to that window.
It seems most early UNIX systems I used were configured this way, and it was extremely irritating since I was accustomed to "parking" the pointer out of the way, somewhere else on the screen, when doing things like filling in text fields.