RICHARD - Part One Mac OS

The Macintosh (mainly Mac since 1998) is a family of personal computers designed, manufactured, and sold by Apple Inc. Since January 1984. The original Macintosh is the first successful mass-market personal computer to have featured a graphical user interface, built-in screen, and mouse. Apple sold the Macintosh alongside its popular Apple II, Apple III, and Apple Lisa families of computers. All versions of Mac OS X that were made to run on PowerPC systems (with the exception of Leopard) had a Mac OS 9 emulation layer called 'Classic'. It allowed Mac OS X to run Mac OS 9 applications that weren't updated to run natively on OS X (known as carbonization based on the Carbon API). Mac OS X Forensics Imager is a program found on www.macosxforensics.com that makes an identical copy of the hard drive and saves it in a file that we can then analyze using another program. Mac OS X Forensics Imager saves it in a file that is both EnCase and FTK compatible.

Inter-process communication (IPC) can be defined as set of techniques used for exchanging data among multiple threads in one or more processes. Processes may be running on one or more computers connected by a network. IPC methods can divided into methods for message passing, synchronization, shared memory, and remote procedure calls (RPC).

Reasons for allowing two processes to communicate with each other may be different :

  • Information sharing
  • Computational speedup
  • Modularity
  • Convenience
  • Privilege separation

In this article we will discuss various techniques available on Mac to accomplish IPC. In the subsequent articles we will see the implementation part for various techniques.
Let’s look at the techniques available for IPC one by one.

1. Shared File : Most naive solution where multiple processes will share a common file. It could be a simple .txt file or a .sqlite database. The obvious problems in this method are

  • Clients need to continuously poll to see if server has written something in the file.
  • Write problems if multiple processes are trying to write to the shared file at the same time.

2. Shared Memory : This is another implementation for IPC where a memory section is shared between different processes.In other words process A writes to this memory and B can read from this memory, or vice verse. This is fast and data doesn’t have to be copied around. The downside is that it’s really difficult to coordinate changes to the shared memory area.

3. Mach Ports :The fundamental services and primitives of the OS X kernel are based on Mach 3.0. Mach 3.0 was originally conceived as a simple, extensible, communications microkernel. It is capable of running as a stand–alone kernel, with other traditional operating-system services such as I/O, file systems, and networking stacks running as user-mode servers.

However, in OS X, Mach is linked with other kernel components into a single kernel address space. This is primarily for performance. It is much faster to make a direct call between linked components than it is to send messages or do remote procedure calls (RPC) between separate tasks. This modular structure results in a more robust and extensible system than a monolithic kernel would allow, without the performance penalty of a pure microkernel.

The only disadvantage is complexity of implementation and less documentation.

4. Sockets : While most TCP/IP connections are established over a network between two different machines, it is also possible to connect two processes running on the same machine without ever touching a network using TCP/IP.

Using TCP/IP sockets for interprocess communication (IPC) is not very different from using them for network communications. In fact, they can be used in exactly the same way.But if the intent is only for local IPC create a socket in the AF_UNIX family to get a socket that’s only for local communication and uses more flexible addressing than TCP/IP allows.

5. Apple Events : These are the only IPC mechanism which is universally supported by GUI applications on Mac OS X for remote control. Operation like opening a telling a application to open a file or to quit etc. can be done using these.

AppleScript is a scripting language built on top of Apple Events which can be used using scripting bridge in a Mac application.

Richard - part one mac os 11

6. Distributed Notifications : A notification center manages the sending and receiving of notifications. It notifies all observers of notifications meeting specific criteria. The notification information is encapsulated in NSNotification objects. Client objects register themselves with the notification center as observers of specific notifications posted by other objects. When an event occurs, an object posts an appropriate notification to the notification center.

Posting a distributed notification is an expensive operation. The notification gets sent to a system wide server that then distributes it to all the processes that have objects registered for distributed notifications. The latency between posting the notification and the notification’s arrival in another process is unbounded. In fact, if too many notifications are being posted and the server’s queue fills up, notifications can be dropped.

7. Pasteboard : Every time a copy-paste happens between applications, that’s IPC happening using pasteboard. Inter-application drag and drop also uses the pasteboard. It is possible to create custom pasteboards which only desired applications can access for passing data back and forth between applications.
Like distributed notifications, pasteboard work by talking to a central pasteboard server using mach ports.

8. Distributed Objects : This mechanism enables a Cocoa application to call an object in a different Cocoa application (or a different thread in the same application). The applications can even be running on different computers on a network.
Distributed objects operates by having the server make public, an object to which other client processes can connect. Once a connection is made, the client process invokes one of the public object’s methods as if the object existed in the client process.
Distributed Objects normally runs over mach ports but can also be used with sockets, allowing it to work between computers as well.

Written By: HEM DUTT, Sr. Engineer/Tech Lead (Mac OSX development), Mindfire Solutions

Here at the Happy Macs Lab, we have a unique issue. In the lab, you will find vintage Power Macintosh models, running everything from Mac OS 7.5.3 up through Mac OS 9.1, a maxed out Power Mac G4 Cube running all of Mac OS 9.2.2, Mac OS X Tiger and Mac OS X Leopard, Power Mac G5s running Mac OS X Tiger and Mac OS X Leopard, multiple older PCs running various versions of Linux and even a sampling of older Windows machines, running Windows NT 4.0, Windows 95, Windows 98SE, Windows ME, Windows 2000 and finally Windows XP. It is quite the “tower of babel” from a computing perspective, and getting all these machines to talk to each other is a real challenge.

Happily, there are multiple solutions that achieve the desired result, and this blog post is the first of a series where we will look at the best of them, one by one. Some of the solutions are point-to-point, connecting just one OS to one other OS (such as Mac OS to Windows), and some are all encompassing, connecting everything to everything.

In this first post of the series, we will look at the first of two “traditional” point-to-point solutions for connecting Mac OS Classic and Windows, Thursby Software’s Dave. In the second post of this series, we will examine the other classic solution to this problem, Connectix’s DoubleTalk.

Throughout this series of networking posts, “Mac OS Classic” is used to imply Mac OS 9.x and lower, and specifically excludes all versions of Mac OS X. Similarly, throughout this series of posts, “Windows” implies Windows NT 4.0 and higher. For the purposes of this series, I used two principal Macs, a Power Macintosh 7500/100, upgraded with a NewerTech 366 MHz G3, and running Mac OS 8.6, and a fairly stock Power Macintosh 7300/200 running Mac OS 9.1. I used a 200 MHz dual CPU Pentium Pro PC running Windows NT 4.0 as the Windows representative in this networking duet.

Windows, Networking and SMB

OK, lets get going. A little background is in order first. Windows communicates with the networked world using the Server Management Block (SMB) protocol, renamed CIFS (Common Internet File System) in later versions of Windows. Pretty much all versions of Windows since Windows NT 3.x have incorporated both an SMB server and an SMB client, meaning that the OS can both read and write other SMB-based machines and can itself be read and written by those same other machines. I have seen, but not yet been able to confirm, that even the creaky Windows for Workgroups 3.11 included an SMB capability.

Since Windows speaks SMB, if a Mac wants to engage in file sharing with a Windows platform, it needs to speak SMB as well. Functionally speaking, this means that it needs to implement an SMB server and /or an SMB client. The two well-regarded third party applications mentioned above, Thursby Software’s Dave and Connectix’s DoubleTalk, do just this.

Thursby’s Dave seems to be the preferred solution in this space, although both garner a recommendation on Apple’s website.

Dave is preferred because it implements both an SMB server and an SMB client, while DoubleTalk only implements and SMB client. Having both an SMB server and an SMB client, a Dave-equipped Mac can seamlessly read and write files to and from a Windows machine and that Windows machine can seamlessly read and write files to and from the Mac.

Installing and Configuring Dave

I tested Dave and can attest that this is all true. I loaded Dave onto my Power Macintosh 7500, running Mac OS 8.6, and took it for a spin. The above mentioned 200 MHz Pentium Pro PC, running Windows NT 4.0, acted as its Windows counterpart in this testing.

Now before we go any further, there is a pink elephant in the room that we should all acknowledge. Astonishingly, not only is Thursby still a going commercial concern, Dave is still an active product at Thursby, and they want a staggering $119 for a current license for it! This will no doubt stop many folks from experimenting with it further.

Of course, the Dave software, and license numbers for it, are available from multiple “abandonware” sites, but none of the licenses I could find this way worked – all were rejected by Dave as “expired”. Thursby has protected their product well. Already having a valid Dave 4.0 license, I was able to proceed, but those of you not in this happy position will need to either pony up a big $119 to Thursby, or make your peace with trolling the web in search of non-expired licenses. I did this yesterday as a test, and successfully unearthed multiple apparently valid licenses. A little bit of persistence may serve you well in this area.

In an effort to save would be users of Dave from having to pay the hefty $119 fee for what is fundamentally an obsolete product, I queried Thursby’s email support, asking if they would be willing to provide a free license, given the lack of remaining commercial trade in Mac OS 9.x and below. The answer back was a firm “no”, followed by an admonition that Dave should not be considered abandonware. The response concluded with a request to know where I had downloaded Dave from! Realizing that this line of inquiry was not likely to result in a free Dave license, I abandoned it and moved on.

I will leave the licensing issue in your capable hands. Moving on, I can report that Dave is an excellent product. It was simple to install and configure, easy to use, and 100% effective at doing what it said it would do.

Installation and setup was a snap.

Dave’s setup runs you through a few simple questions, the most complex of which may be its query for your workgroup name. If you don’t know the answer, just type in “WORKGROUP”, which is what most PCs default it to. Confirm this by visiting the Network control panel of the PC you are trying to connect to, and change the name on the PC side or the Mac side, if need be. Once the installation is done, you will need to restart your Mac and then you are ready to network with your PC friends.

Networking with Dave: Mac to PC

Networking with Dave from a Mac to a PC is quite intuitive, in a very Mac OS Classic sort of way – you go through Chooser, just like you would for the native form of Mac networking. In Chooser, you will now be greeted by a new connection type in the left hand pane, Dave Client.

When you click this, there will be a disconcerting pause, during which you will wonder whether Dave is working at all, and then the right hand pane will suddenly populate, hopefully showing you the PCs you want to share files with (and anything else on your network that has an SMB server – in my case, this included two Power Mac G5s and my current main Mac, a 2012 27” iMac).

Double click the entry for the PC of interest (in this case it was DualPro200 – so named because it is a dual CPU Pentium Pro 200 MHz) and you will get the expected password prompt. Enter the correct user name and password (this is the user name and password from the PC, or just select Guest instead) and Chooser will pop up a dialog showing the “shares” on the selected PC that are available for you to choose from (a “share” is SMB-speak for an available, shared folder).

You may just run into some trouble here – I did. Initially, the share list was blank! There is not a lot of latitude to share files when the list of possible sharing targets is empty! Happily, Dave provides an “Add Share” button below the list, and I took advantage of this to add the shared folders on the PC to the dialog.

RICHARD - Part One Mac OS

This point requires a brief moment of explanation. When you share a folder in Windows NT 4.0, you give it a “Share Name”. This name should show up in the list of available shares that Dave presents you, but in my case, it did not. The share name did show up in the list of available shares when I connected to the PC from either of my Power Mac G5s, but did not from my older Power Macintosh 7300 or 7500 machines. The reason for this will be explained in a postscript at the end of this post.

For now, I was presented with a blank list of shares, but had the potential of adding shares through the Dave “Add Share” dialog. Back at the Pentium Pro PC, I went to Control Panels -> Server, and clicked the Shares button. This presented me with the following list of the available shares:

As you can see there were a LOT of shares there, but most ended with the “$” sign, indicating that they were administrative shares, automatically created by and internal to Windows NT, and not generally advertised for external connection (although they can be connected to if you wish).

I took note of three shares of interest, C$, D$ and DP200SharedFolder, which corresponded to C:, D: and the folder I was actually trying to share, DP200SharedFolder. One by one, using Dave’s Add Share button, I added these to the list, and they worked. When I double clicked any one of them, Dave promptly mounted the appropriate share on the Windows NT machine and at that point, I could drag and drop, read files, create folders, and in general, do all the things I could do with any local file folder.

I must apologize for the loss of continuity in the screen shot above. The share name mounted on the desktop is different from what is described – I no longer have the original screen shot.

Setting aside the cause of the blank list of shares for a moment, Dave’s Add Share dialog allowed me to work around a potentially show stopping issue and arrive at networking success, at least in the Macintosh to PC direction. What about the other direction, PC to Macintosh?

Networking with Dave: PC to Mac

This was not such a happy story initially. The Power Macintosh 7500 simply did not show up at all in the Network Neighborhood of the PC, nor could I see it in the Network selection of the two G5s I have on the network (both running 10.4.11 Tiger). Guessing that Dave’s SMB server was not enabled, I went hunting for a Dave Control Panel on the Macintosh. Nope, no such thing. There WAS a NetBIOS control panel with Dave labeling in it, so I hunted around in there, but there were no obvious selections to enable or disable visibility of the SMB Server.

My next stop was the Dave installation in the Macintosh’s Applications folder. There was a single file there, a program named, appropriately enough, Dave. Following this obvious lead, I launched the program, selected Dave Sharing and was greeted with what amounts to a Dave control panel.

Of course I immediately noticed that File Sharing was off, which would imply that the Dave SMB Server was not running. I enabled this and then checked to see if Dave was sharing any folders. The list at the top of the window was empty suggesting that it was not. Using Finder, I dropped my AppleTalk shared folder, “PowerMac7300SharedFolder” into the list. It “took” and thereafter, Dave showed that it was sharing this folder. It did warn me that shares with names over 12 characters long might not share properly, but I ignored that for the moment.

Richard - Part One Mac Os Catalina

Again I must offer my apologies for the discontinuity in the image above – the file share name is slightly different from what I have described – I seem to have misplaced the original screenshot.

Back at the Windows NT machine, success. The Power Macintosh 7500 now showed up in the Network Neighborhood. I double clicked the icon, full of confidence that I had solved the problem, and was greeted with … a blank window. The PC could see the Macintosh, but the Macintosh didn’t appear to be sharing anything. I checked this with both of the G5s, and Tiger pretty much agreed – there was nothing being shared. Tiger’s rather obscure way of indicating this to me was to tell me that it could not open the alias because the original item could not be found. Somewhat of a misleading error indication, but I got the message. Something was still definitely wrong at the Macintosh end.

I went back to the Dave application and removed the current folder I was sharing, suspecting that either you could not share a folder over both AppleTalk and SMB, and/or perhaps the file name really DID have to be 12 characters or less. I created a new folder called “PMAC7500-SMB” (EXACTLY 12 characters) and dropped it into the Dave “Shares” list. I specifically did not share this folder through the usual Mac OS way of doing this – it was only shared via Dave’s SMB server.

This did the trick. The Network Neighborhood window that I got when I doubled clicked the icon for the Power Macintosh 7500 now presented one accessible folder, PMAC7500-SMB. This folder could be opened, read, written to… it was fully accessible. Success! PC to Macintosh networking was now up and running as well.

Networking with Dave – Summary

With both Mac to PC and PC to Mac networking up and running, I can now summarize the recipe for success with Dave:

  • On the Macintosh side, make sure you have a unique share folder for Dave, and make sure that the name of that folder is less than 12 characters. Do not share this folder via the normal Mac OS Sharing mechanism. Share it only via Dave.
  • On the PC side, make sure that you have one or more shared folders, and take note of the “Share As” name you assign to each. Like the Macintosh side, keep the filename of each shared folder to 12 characters or less as well.
  • Still on the PC side, if you CANNOT keep the share names to 12 characters or less (perhaps the machine is not under your control), compensate for this on the Macintosh side. On that side, when you use Chooser to select the PC, if you are greeted with a blank list of available shares, use Dave’s Add Share button to manually add the shares whose names you took note of in the last step. You will only have to do this once. Dave remembers the names.
  • That’s it! Apply the above and you should be happily networking in both directions between a Macintosh running Dave and a PC running Windows NT 4.0.

Closing Thoughts

A final note on Dave. Dave will very considerately interrupt the Macintosh shutdown sequence to warn you if it is hosting any connected users, giving you a chance to warn them before their favorite Mac suddenly disappears from cyberspace. As I said above, Thursby has done a very nice job.

That’s it for this post. In our next post on networking, we will look at doing the same sort of thing using the other classic application in this space, Connectix DoubleTalk. Until then, happy networking with Dave!

The Promised Postscript on The Empty Share List Problem

p.s.> A postscript to this story. As outlined above, the “empty list of shares” problem is easily resolved. Reasoning that since Dave warned that Macintosh share names over 12 characters might not share correctly, I concluded that perhaps share names on the Windows NT side should ALSO be 12 characters or less. I went back to the Windows NT 4.0 machine and checked the length of the share name for the folder I was trying to share. Sure enough, it was MUCH longer than 12 characters. When I shortened it to 12 characters (8 characters actually, in this case), it showed up instantly in the Chooser selections of both Mac OS Classic machines. So, one final word to the wise – all share names should be 12 characters or less.

Download New Mac Os

And as if that is not enough, Windows NT 4.0 gently reminds you that if you want the share to be visible to DOS and Windows 3.x class machines, its’ name needs to be 8 characters or less! Just so you know…. 🙂