Slashdot Mirror
Apple Releases Rendezvous for Linux, Java, Windows
mblase writes "Apple released yesterday a developers preview of their Rendezvous technology for Windows, Linux, FreeBSD, Solaris and Java. Rendezvous is an open protocol which uses industry standard IP protocols to allow devices to automatically find each other without the need to enter IP addresses or configure DNS servers."
Reader xxdarkxxmatterxx adds a link to a story at Macworld about the release."
...was started way back when.
Since there are now native service implementations available, it'd probably be better to just hook into those using Ruby/DL or some such...
The Army reading list
XCode uses distcc for it's distributed compiling, distcc isn't rendezvous aware by default though, so you'll have to configure it yourself.
If you look at it using a sniffer like ethereal, it's actually multicast DNS, so it will work with either IPv4 or IPv6 as it's a layer-4 thing.
Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
iChat can be set to not look for Rendezvous clients, iTunes can be set to not look for playlists (or broadcast them), Safari can be set to not seek other bookmarks, printing can be set to not seek printers, or the whole protocol can be shut down. I personally only use it for iChat at work, and it never gets in the way or is annoying with anything else.
You know what?
Microsoft has UPNP, which is supported by pretty much everyone who isn't Apple.
Here's the Linux UPNP stuff.
As far as I can tell, UPNP is the superior technology.
Darn. Scooped again.. . Note that this technology is NOT Apple's. It's the result of the ZerConf Group. Apple just took the idea and made it 'just work'. And yes, it sounds interesting, and a little scary that all them UDP packets will be whizzing around. OTOH, the reduction of ICANN and other DNS 'gods'is one of the nice benefits of P2P technology like ZeroConf.
For anyone who is interested, Rendezvous is Apple's implementation of of ZeroConf
While Apple's Rendezvous overview gives some decent information, the ZeroConf site provides a lot of good technical resources.
Apple really needed ZeroConf as they transitioned to all-IP networking. Although OS X supports AppleTalk, the AppleTalk protocol has clearly seen it's day and the world is clearly moving to IP-only. Previously, when Macintosh machines were largely communicating via AppleTalk, all of the things that ZeroConf addresses were handled by the AppleTalk protocol suite (service discovery, address allocation, etc), and this ease of use that is signature to the Macintosh is important for Apple to maintain.
That said, Apple releasing this code is pretty significant, as aside from this project, there hasn't been much use of ZeroConf in the wild.
bash-3.00$ uname -a
SunOS panda 5.10 Generic sun4u sparc SUNW,Ultra-2
Actually, iTunes on Mac doesn't use the WebKit either. The music store is all done with QuickTime, which is why iTunes for Windows also installs QuickTime. For more info, see Hyatt's blog-post about this:
0 04 _06.html#005666
http://weblogs.mozillazine.org/hyatt/archives/2
We've launched this only a few weeks ago: Pocketster. It contains an implementation of Rendezvous for the Pocket PC and it also gives you wireless filesharing capabilities (we have a new version coming out on July 6th). It's free, so give it a try if you want (that is if you have a Pocket PC). Also, you might want to check JmDNS (Java version of Rendezvous) and Howl for a Windows implementation. Razvan
A prime example of Rendevous is two Powerbooks in a cafe, both with Airport wireless. You can set up an Ad Hoc wireless network between these computers, and they will auto configure their IP's and other information so that they can talk to each other. Then open up any Rendevous enabled app and you'll be able to see the other users resources, i.e. bookmarks, printers, music, etc.
So Rendevous is not designed to replace DNS/DHCP, but merely to find a way for network configuration when there is no established network structure. Rendevous also works on networks where DNS and DHCP are available, without any change. This is really the beauty of it, because it can determine what configuration is necessary and do whatever needed to get the computers networked, all transparently!
Rendezvous is based on a few underlying services: Dynamic Configuration of IPv4 Link-Local Addresses, Multicast DNS, and DNS-based Service Discovery.
Dynamic Configuration of IPv4 Link-Local Addresses: In the absence of a DHCP server, the machine is able to configure itself with an IP address in a reserved range such that it doesn't clash with other IP addresses configured by other machines on the same network in a similar manner.
Multicast DNS: Multicast DNS Responder services on each machine respond to multicast queries for their DNS information.
DNS-based Service Discovery: Querying for the existence of services (HTTP, FTP, SSH, etc.) via DNS.
So, in a sense, "everything is a DNS/DHCP/Directory server" but only for the information and services provided by that particular machine.
This is not really new. There was an article in the german IT magazine c't recently, which resembled mostly what is in several hints like this one. It's about using Rendezvous on a Linux box combined with a streaming server for iTunes. Works great and is real good fun!
This sig is stolen from someone who had a much better idea than I had.
Rendezvous is actually three technologies: link-local IP addressing (which lets machines assign themselves IPv4
addresses without a DHCP server (IPv6 already has this ability)), multicast DNS to find other services on a network, and DNS Service Records to reterieve information about those services.
Apple's implementation of ZeroConf only works on a single subnet. The current draft of the link-local RFC requires that ZeroConf-aware IP stacks reject any IP packet with a link-local address and a hop-count greater than 1.
But, the other 2 parts, multicast DNS and DNS Service Records, can cross subnet boundaries. So, it's possible that you could create a self-updating directory of machines on a multi-layered network, perhaps by using Dynamic DNS along with the other parts of ZeroConf.
Close, but with one exception:
The SD component of Rendezvous doesn't use DNS servers per se. Any machine that has services (and that can be any node on the net) advertises these services using multicast DNS.
mDNS is used both to advertise available machines, and the services on those machines. So, essentially, the service-discovery component of Rendezvous is a decentralized, local-link DNS service -- it even uses the DNS protocol (albeit multicasted).
And for the people who keep bitching about UDP broadcasts: first of all, multicast != broadcast. But more to the point, I haven't found Rendezvous to be particularly chatty; Apple claims in its docs to have gone to lengths to prevent it from spamming the network. (The developer docs include some thinly veiled references to NetBIOS.)
UDP traffic is pretty lightweight. ZeroConf is basically just some ICMP traffic (when the nodes are assigning themselves addresses) and then DNS. Apple's implementation will aggressively cache query results, and the devices incremementally scale back their announcements.
Another nice feature is that nodes can cache the results of other nodes' queries. Since all of the DNS traffic is mulitcast on the local subnet, every node sees every query and every response. Apple's code expolits this to further reduce the need for duplicate queries. It's a pretty nice setup.
IIRC HP has had rendezvous support in their printers for a while now.
Actually, this doesn't help in creating iTunes-compatible clients.
The Rendezvous protocol specs have been available for some time (it is, after all, a combination of IETF standards). There are compatible implementations for many platforms; on Linux my favorite has been Howl, but JRendezvous is nice too.
iTunes itself uses a proprietary protocol that Apple keeps changing. Parts of it are well-understood (like the music directory portion) but others are not (like the streaming).
Interestingly, Apple is willing to release these docs to developers under NDA. I went through the process but got rejected when they discovered that my product is open-source (even though the iTunes component was to be a binary-only plugin). Apparently they're twitchy about mixed-license developers bending to community pressure and releasing their proprietary info.
Which, with all the GPL bigots I deal with day-to-day, I can kinda understand. Kinda.
It's not the concept that is a security hole...it was (is) all the buffer overflow/run exploits in Microsoft's UPnP implementation.
UPNP is as old as zeroconf and is no more mature than it. Zeroconf is clean and pluggable. It's the published services that may or may not be mature, such as finding web servers, other people to chat with, or another machine with distcc.
People are bashing it here because zeroconf is a small traffic (multicast DNS) linux/OSS technology and UPNP is a high traffic (SOAP aka XML over HTTP) microsoft technology designed to push people to using SOAP everywhere.
zeroconf is rendezvous and vice versa. don't forget
No one is using UPNP that I know of.
"Slashdot, where telling the truth is overrated but lying is insightful."
Jumpstart the tartan drive.
Many would disagree. O'Reilly wrote up a good piece about the two technologies a while back. Its a good overview of what they offer and the pros and cons of each.
A quick rundown? Zeroconf (Rendezvous) provides a way to discover services and addresses automatically, without address duplication by multiple devices. UPnP does the same thing. The difference is that UPnP also dictates HOW to talk to devices and services, while Zeroconf forces devices to know how to talk to each other.
Taft
No reason to buy Apple Hardware? Have you not seen this or this?
Surely, you're talking out of your ass here...
Rendezvous is three things:
- automatic link-local IP addressing for cases where DHCP fails (like APIPA)
- multicast DNS for announcing device names (.local domain)
- service announcements and discovery via DNS-SD
Mac OS X also supported SLP, but Rendezvous / ZeroConf is clearly the more comprehensive technology, as several projects (such as GNOME) are actually moving *over*.
Rendevous is some what like making each computer a DNS/DHCP/Directory server, however that's not completely accurate.
It's not so much that it's not completely accurate as it is that it's completely wrong.
Rendezvous has nothing to do with DNS, DHCP, or directory services. It's a service discovery framework, and that's all. Here's how it works.
Let's say you've got some program, Foo.app, that has a feature for talking to other instances of Foo.app over the network. Doesn't matter what it is. It could be iTunes music sharing or iChat or distributed compilation or whatever you want.
Without Rendezvous, you'd have to tell your instance of Foo.app where to find other instances. That'd require some kind of setup and some kind of maintenance.
With Rendezvous, your instance of Foo.app sends out a single multicast message when it starts up. That message says that there's an instance of Foo.app available at our IP address. Other instances on the network receive that message and make a note of it. They maintain a list in memory of available services, all automatically, without your intervention.
Does this involve a lot of network traffic? Not really. It requires some, but not much. When an instance of Foo.app starts up, it (1) announces its own presence, and (2) sends out a multicast request for other instances, and the other instances reply. When Foo.app shuts down, it sends out an announcement of its own termination. That's it.
Does this involve terrible security risks? Not really. All Rendezvous does is publish the availability of services that are already running on the network. The responder daemon itself doesn't run with any privileges (on a Mac, it runs as the "nobody" user), and all Rendezvous requests are handled by that one daemon. If something magical happened and somebody was able to get mDNSResponder to run arbitrary code, there would have to be another exploitable security hole somewhere else on the system, because mDNSResponder doesn't have privilege to do anything.
A prime example of Rendevous is two Powerbooks in a cafe, both with Airport wireless. You can set up an Ad Hoc wireless network between these computers, and they will auto configure their IP's and other information so that they can talk to each other.
That's not Rendezvous. That's nothing more than self-assigned IP addresses. When your computer can't find a DHCP server, it self-assigns an address in the 169.254/16 network. Which means any two computers on the same network segment that have self-assigned IPs can talk to each other. This has been around since long before Rendezvous.
So Rendevous is not designed to replace DNS/DHCP, but merely to find a way for network configuration when there is no established network structure.
No, that's overstating it. The sole purpose of Rendezvous is service discovery. That's it. It's independent of network configuration. It works with or without DHCP, DNS, or any other network stuff. As long as you've got an IP address, Rendezvous does its thing.
This is really the beauty of it, because it can determine what configuration is necessary and do whatever needed to get the computers networked, all transparently!
No, no, NO! That's not Rendezvous, that's DHCP. Rendezvous is ONLY for service discovery. Rendezvous doesn't set your IP address or your routing table or your hostname resolution parameters. It doesn't do any of those things. All it does is facilitate service announcement and discovery for your applications.
I write in my journal
grr, use preview carefully!
That's 6 MONTHS versus 2 WEEKS.
Bryan
You're not mistaken, but what's new here is the C library for talking to mDNSResponder. That wasn't there in the POSIX example code before, which meant you were SOL if you wanted to actually build Rendezvous support into your application. You could run a Rendezvous proxy on a POSIX system; I set that up at a friend's place. They had a network that was about 75% Mac and 25% SGI. I set up Rendezvous proxies so their IRIX machines would announce their FTP and SSH services via Rendezvous so the Mac users would be able to make use of them more easily. But that was as far as you could go without heavy, heavy lifting.
But now that's no longer a problem.
The only reason for Apple atempting to break DAAP interoperability that I can think of is to enforce the 5-connections maximum present in iTunes.
No, it had to do with stealing. DAAP has to be encrypted to prevent people from being able to easily steal music with iTunes sharing.
I write in my journal
Comparisons have been done. I'd rather have low traffic and better service separation vs the "use-http-for-everything" strategy
You are focusing on the part that doesn't matter. I suspect that in real life, you'd have a hard time finding any performance difference due to the heavier traffic. It's lost in the noise.
The part that is important is specifying the commands and data to/from devices. We learned this lesson back with SCSI-1. When you leave important things up to each vendor (like the way Rendezvous leaves stuff in unstructured text fields for the vendors to define), you end up having to build into your host software a bunch of vendor-specific knowledge. You end up not being able to just go buy and plug in a printer or scanner or whatever and have it work, because the vendor hasn't released documentation to the Linux developers yet.
Notice how much cleaner everything was with SCSI-2 due to having all the important commands specified in the standard, so that you could have generic disk and tape and other drivers that utilized all the device capabilities.
It seems to me that Rendezvous is making the SCSI-1 mistake, which was understandable for SCSI-1 since they didn't have anything to apply hindsight to. The Rendezvous people should be able to look at SCSI-1, though, and see the importance of complete device specifications.
BTW, most of home routers use UPNP. Netgear, linksys, dlink etc.
Have you ever been to a turkish prison?
Microsoft has been in alpha now for a bit with a product called "Windows NCD Technology" (I'm a tester). This is Apple's shot across MS's bow.
From the alpha page, Windows Network Connected Device (NCD) Technology is a comprehensive set of Windows technologies that allow devices on a local network to discover, communicate with, and control each other.
Around the early 90's, Apple developed a prototype operating system called Pink, which they later spun off into a company called Taligent, with the help of IBM and Hewlett Packard. Here is an old article about it and why it was canned. I remember reading something about how former Apple CEO John Scully gave a demonstration to some people of what looked like the Macintosh operating system running on a PC. As I recall it could run on both Mac and PC hardware platforms, and was designed in such a way that programmers could create programs that ran on both platforms through object-oriented programming. I purchased a book on it ages ago in which it was described as an "application system". It was meant to be a true cross-platform operating system.
The current rendezvous stack in OS X doesn't support this, but rendezvous directory lookups are supposed to be able to be advertised by a normal DNS server. That is, a service should be able to be advertised through BIND, so that if a multicast DNS lookup fails, the DNS lookup will work. Although I'm not sure of the precedence -- whether singlecast or multicast DNS takes precendence for a lookup. So rendezvous and traditional DNS are designed to work hand in hand.
I don't know if Rezendevous is any better, but upnp is not all that technologically sexy. It uses http and xml, woop de doo. I'd prefer something a little simpler. Since you can't eliminate the broadcasts, eliminate the http, do everything with UDP, with broadcasts for locating devices. There's nothing wrong with inventing your own simple protocol and it would be cheaper to implement in small devices than xml and http.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
"Insightful" my ass. "Delusional" would be the better adjective. Releasing an OS for Intel would never happen not because Jobs was paid off but because Apple is now, and always has been, a hardware company. A company that makes ~4 billion a year in hardware revenues is not going to abandon that in favor of the few hundred million they make in software.
Apple was "paid off" but the payoff was to drop a lawsuit not to drop development of "rhapsody for Intel" and/or "rhapsody for Windows" which had already been abandoned.
ZeroConf means a visiting professor walks into a lab at a university and can automatically print. There's zero configuration.
It means an iTunes user can broadcast their library on the network and another iTunes user can pick it up with no problem. There's zero configuration.
It means I can open iChat, not go onto AOL's network, and see my coworkers down the hallway with zero configuration.
It means I can share a workgroup document we are editing in SubEthaEdit and easily invite coworkers on the LAN. There's zero configuration
And now it means that non-Mac users can start getting in on a lot of the same stuff.
You are completely wrong.
Draft Standard is a Standards Track Maturity Level. RFC is a document type.
You were probably thinking of Internet-Drafts, which are not the same thing as RFCs. RFCs must first be published as Internet Drafts. Internet-Drafts are removed after 6 months if they are not approved by the IESG for publication. RFCs are archived.
The zeroconf documents are Internet-Drafts. They are not RFCs.
Show me on the doll where his noodly appendage touched you.
- Because Apple would rather live in an open world than in a Microsoft world. (Don't forget, Rendezvous is *not* an Apple invention. It's Apple's name for "zero-conf," and Apple never claimed to have invented it. Apple just made it popular.)
Right... but the guy who started the IETF working group & made zeroconf happen was an Apple employee at the time, and it wasn't exactly a side project.
There are no trails. There are no trees out here.
- Allocate addresses without a DHCP server.
- Translate between names and IP addresses without a DNS server.
- Find services, like printers, without a directory server.
- Allocate IP Multicast addresses without a MADCAP server.
You are quite accurately describing point 3 whereas the parent was describing points 1,2 and 4. But ALL FOUR are rendezvous/zeroconf.Why do you think this will be a noisy, chatty, protocol?
And Rendezvous, if I recall correctly, uses multicast DNS, icmp, and a couple common ones. What it does is piggyback on top of existing protocols.
Which means you would have to block existing protocols...
GPL Deconstructed
Which protocol are you talking about? The open AAC protocol or the unambiguous firewire/usb drive setup it uses?
Rendezvous is *not* an Apple invention. It's Apple's name for "zero-conf," and Apple never claimed to have invented it. Apple just made it popular.
Actually, they sort of did. Zeroconf was initially developed by Stuart Cheshire who is an Apple employee with the job title of "Wizard Without Portfolio".
Possible, but unlikely. The Rendezvous code is probably a small component of the platform-specific code for SEE. They could possibly port the rest to *NIX using GNUStep, but the Windows port of GNUStep is still in its infancy. If a Rendezvous stack had been the barrier to porting then they could have used an existing open source implementation of ZeroConf (Rendezvous) such as gmdns or howl.
I am TheRaven on Soylent News
Apple does NOT support running any laptop with the screen closed, because they can very easily (and do) overheat when the screen is close. Especially if you stick that nice toasty laptop into a sleeve in a bag... that's just asking for the thing to overheat. There are utilities out there that let you turn the sleep when the lid closes off, but as I said, if you change that, then the machine is immediately out of warranty from Apple.
I hate sigs...
When we were all on shared 10b2, such complaints were completely justified.
When we were all on shared 10bT, such complaints were arguably justified.
When we are all on switched 100bT, such complaints are arguably unjustified.
When we are all on switched 1000bT, such complaints are completely unjustified.
Maybe there is a bit of a problem if your entire network is run on 802.11b and you have dozens of Rendezvous enabled nodes out there.
Rendezvous is not especially "chatty". I think nodes broadcast a small packet at most every 30 seconds to advertise their services or at least availability.
Article X: The powers not delegated... by the Constitution...are reserved...to the people
Running a PowerBook with the lid closed is officially supported by Apple, and is mentioned in the instruction manual which is included with the machine. As long as the machine detects an external display and a USB keyboard plugged in, it will run perfectly in lid-closed mode.
I know this is different to closing the lid and then stuffing it into a backpack to use as an overgrown iPod, but the point is that lid-closed operation is not a 'banned' operation because of heat issues. It is very much supported for certain applications.
Oh, and I wasn't talking about multiprocessors in particular. A context switch on a single-CPU PPC machine is roughly equivalent to a function call in terms of overhead. On an x86 system it is about an order of magnitude more. This makes multithreading very expensive on an x86 system (one of the reasons why things like games don't often use it).
I am TheRaven on Soylent News
A post from Stuart Chesire (Apple) on including Rendezvous in Fedora here.
From what I remember this technology either came from Apple or was given a major helping hand. I beleive that the head of the ZeroConf working group is an Apple employee.
Go out and get sailing!
I had already said that before, but there was actually a "Mac OS X" for Intel; it was called OpenStep and it flopped.
Mac OS X is actually more an evolution of NeXTStep/OpenStep with a "Mac OS 9 emulator".
Also, does someone remember BeOS? Their business model didn't seem to make much sense.
Some people might buy another OS, but most will just stay with the one offered on the machine.
Lately, I have been thinking that Apple Mac OS X is more like a free "BSD distro" bundled with a computer. Like TiVO is a special Linux distro with a vanilla x86.
I haven't set up NFS, but it should be just like the AFP stuff. Apple says that AFP, WebDAV, SMB and NFS are all browsable by the Finder.
Anyway, if what Apple is giving out now is the same as what I downloaded a few months ago it's really pretty easy.
I wrote up a quick and dirty Linux Rendezvouz HOWTO-MINI on my website. If you're moderately familiar with UNIX you should be able to use that as a base to set up NFS or anything else you like.
Multicasts you mean?
Effectively the same in this context.. but still.
A tiny UDP multicast is no worse than the typical windows broadcasts or arp broadcast that happens in a network... and this is just for service discovery generally, not normal net-wise DNS lookups. That means things will be looked up once and cached.
(service discovery could be, by the way "WHO HAS A DNS SERVER"or "WHO IS A NET GATEWAY")
That means, provided a large network has proper multicast aware switches, traffic is minimized.
This is not a replacement for DHCP; it is not meant to scale really huge. it is meant to be able to plug in a machine and have things work in the absence of infrastructure.
Now what I'm wondering is.. what awkwardness is it you are referring to in mixing macs and pcs? We have macs and pcs here, and everything works just fine.
- This is not Appletalk. IT is new.
- This is open
- The *key* feature is the mDNS system.
- Yes, it does automatic IP allocation if there is no DHCP server.. so does Windows (though apple is much faster at it for some reason).
- mDNS is not to be confused with "The global DNS system" that you use to lookup Address records, etc, though it can do that. mDNS is DNS adapted to multicast, for service and host discovery. HOw?
- Instead of querying a DNS server, you query a multicast group (the link-local group in this case) and say "Who has a webserver?" or "who has ssh?" or "hey FOO, what is your IP?" or.. more importantly "Who is a real internet DNS server?" or "Who has an internet gateway?". "Who else is running itunes?".
- a machine joining the network will broadcast once, to send out that it has joined, and what services it has, also via mDNS... so anyone listening can update their caches, etc. The opposite happens when it leaves.
This does not create an extra burden of traffic. Previous to this, most protocols that need to find something in the network do so by rather rude broadcasts.. and usually generate quite a bit of unnecessary traffic.
YES, having a set infrastructure, DNS servers, DHCP, etc, and using DHCP to hardcode everything else, avoiding the need for local network discovery is more efficient. The point is, this works very well WITHOUT any infrastructure.. like 10 guys sitting in a conference room with wireless cards and no servers... or 3 guys on the bus. etc.
NO, rendezvous does not grant ACCESS to your computer.. it merely discovers advertised services... much like an X browser can find a bunch of remote X desktops, or windows TS can find all the terminal servers in the network, or the "network neighborhood" list is populated in windows. It's just a more elegant, scaleable approach.
- mDNS is *not* dns... it is mDNS but if you understand DNS you will understand mDNS. They chose to not make a new protocol, and instead adapt an existing one... which makes it much easier to learn and work with.
A zeroconf DHCP server could do fancier things such as preventing a rogue DHCP server from taking over (see previous Apple security article).
You seem to be confusing zeroconf as a replacement for something more "sophisticated" such as a directory service. This is not the case. A network admin benefits from rendezvous in the following way:
* A machine, new from the box, goes online
* Rendezvous detects the DHCP server and Open Directory (Apple) server on the subnet
* The machine connects to the directory server and receives its configuration from the directory after the user provides credentials.
* The machine is now configured and can access all resources in the enterprise. No network administrator intervention was required.
Zeroconf merely helps computers find the higher-powered services you're demanding. This is how Apple is leveraging the technology.
If your WAN is not subnetted over those slow links, I would think that you shouldn't have designed the network that way to begin with. Seems like it's just asking for trouble. If you *have* to have them talk to each other, the Directory Server can do that by making the disparaging services visible to both sides and rendezvous can help your machine find it.
Good point, Apple makes most of it's money on hardware. IIRC, that hardware is called the iPod.
Not even close. Apple sold 807k iPods the first quarter of this year, which is maybe $300 million in revenue, compared to total revenue of $1.9 billion. And that was after the release of new iPods and with most of their CPUs being due for an update. Apple can't survive in anything close to its present form as an iPod seller.
How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
One feature I occasionally use is concurrent editing of a document via Rendezvous.
You appear to be mistaken concerning the role that Rendezvous plays in an app like SEE. According to the SEE FAQ, the network protocol used to implement concurrent editing is BEEP.
What Rendezvous is used for is to automatically find other instances of SEE on the local LAN. That's not required for concurrent editing, and in fact SEE allows you to manually specify host names and/or addresses if you need to connect to a machine that Rendezvous can't find automatically.
With this release, the SubEthaEdit team might produce a port to Windows soon
Don't hold your breath. According to that same FAQ, SEE is Cocoa. Unless Apple decides to resurrect Yellow Box, aka OpenStep for Windows, Cocoa apps aren't easily portable to Windows.
BEEP is an open standard though, so you might be able to find a Windows editor that speaks that protocol and works with SEE.
Lost: Sig, white with black letters. No collar. Reward if found!
One of the things that makes context switching between processes (but not necessarily threads, depending on the implementation model) expensive on x86 is the fact that on x86, an address space switch flushes the entire TLB (including kernel addresses, which are soon to be accessed again).
TLB misses are the most expensive type of cache miss on modern CPUs.