![](/file/12652/www.mactech.com.tar/www.mactech.com/sites/all/themes/custom_front/images/you_are_here_red.gif)
![](/file/12652/www.mactech.com.tar/www.mactech.com/sites/default/files/beta-site.gif)
|
Volume Number: | 10 | |
Issue Number: | 12 | |
Column Tag: | The Editor’s Page |
The Editor’s Page
By Scott T Boyd, Editor
Getting On The Net
I work out of my home here on the Pacific coast. With five phone lines, five computers on an Ethernet, three modems, two cats, an eighteen-month-old daughter, a wife, and views of the ocean and a mountain, we may be looking at something like the home office of the future. No home office could be complete, though, without getting wired, and that takes more than caffeine.
Since January, I’ve experimented with a variety of schemes for connecting. Ihave all sorts of accounts on all the online services, but none of them qualify as “wired”. Getting connected, in this case, means plugging in to the Internet.
I started off by doing what all the Apple escapees seemed to be doing - Igot a Netcom PNC (Personal Network Connection). Icould use MacTCP and run all of my favorite Macintosh apps. It also came with a unix shell account and an e-mail address. It cost $17/month plus an hourly fee for every hour past some allotment.
Flocking to a net provider along with a few bazillion other subscribers isn’t always the best plan. They were growing so fast that they couldn’t add equipment, staff, and phone lines fast enough. Ifound a good excuse to find a new provider - we moved north to Montara (between Half Moon Bay and San Francisco).
Once here, I hooked up with QuakeNet. They’re small, know their stuff, and answer the phone when something goes wrong (hey, it’s networking; something’s bound to go wrong from time to time). Now Ipay $85/month for a 14.4Kbps full-time connection. It’s a local call, so Ican keep my modem connected constantly for the cost of a residential phone line. Ifind myself talking on the phone less, and I expect rates to drop as competition heats up. It’s great to have an unmetered connection - I never have to think about what it’s costing me to stay connected.
I’ve teamed up with a few other home office workers, and we’re finding all sorts of ways to use the net. We’ve tunneled AppleTalk to share printers and servers. We’ve set up FTP and chat servers so we can talk to each other and exchange files. We’ve also experimented with sending voice over the net. With a little work, we’ll be able to talk over 14.4 connections, and that will also reduce our phone bills.
We got our start using MacPPP (similar to SLIP) to make a point-to-point serial connection to our providers. It’s no more complex to configure than MacTCP - straightforward, but not trivial. A couple of us are now using MachTen (Tenon’s unix product for Macs) to make the PPP connection and do ip routing. That’s more fun because now Ican use any of the machines on my net, as well as offer dialup service to friends in the area. It’s also a lot more work because it involves configuring and administering a unix box (e.g. sendmail, FTP, DNS, accounts, firewalls, etc ). You haven’t seen bad documentation until you’ve tried to run a unix system. Flexibility breeds complexity. Turnkey it’s not.
I’d like to hear from those of you who have gotten on the net and found fun ways to use it. I’d especially like to hear from those of you who have written Macintosh-based tcp/ip software to take advantage of the net. The Net offers more opportunity than just running Mosaic.
Software Piracy
Have you ever wondered about those numbers we see from the Software Publishers Association and the Business Software Alliance about software piracy? BSA claims that global piracy costs over $12 billion dollars each year. Where do they get these numbers? They throw them around as if they had a basis for their claims. If so, why don’t they document how they arrive at those numbers? Might it be that the numbers wouldn’t impress us so much if we knew how they were derived?
Piracy certainly exists, but $12 billion? They do our industry a disservice by making unsubstantiated and unbelievable claims. That doesn’t do any of us any good in the long run. Many of you work for member companies; your opinion might help these groups wise up.
Do You Do Windows?
We all hear that Windows is going like gangbusters. It’s hard to tell whether it’s hype or excitement, but there sure seems to be a lot of interest in Windows95 (formerly known as the late Chicago). Have you felt the urge or the need to do Windows?
I know developers who have made the switch so completely that they don’t do Macintosh any more. They couldn’t see missing out on the opportunity to sell their products into the much larger market that Windows seems to offer. They aren’t doing Macintosh mostly because they’re small and can’t afford to split their efforts.
Other developers have decided to add Macintosh to the list of platforms they support. How else can you increase your revenue once you have established how much Windows marketshare you can grab? These vendors see the addition of a platform as a simple money decision. Hire one or two Mac programmers and have them port the Windows code. No big deal (but no love for the platform, either).
Others have successfully built a product and a market on the Macintosh. Having worked hard to own as much market share on the Macintosh as they could, they see expanding into the Windows market as a sensible way to grow the company. Besides, by the time they’ve grown to this point, they have customers clamoring for a Windows version. In one case, it’s become more than twice as hard to maintain a product on two platforms (what do you do when a Mac technology isn’t available on Windows?), with no more revenue than expected staying with Macintosh alone. They owned their market; people bought Macs just to use their product. Putting it on Windows gave those people a choice of platform, but didn’t draw in new customers. Not all products enjoy this position, so mileage no doubt varies from company to company.
We’d like to hear from you. Let’s get some of your stories about comings, goings, reasons, and outcomes.
Sorry About The Confusion
Last month I wrote about EvenBetterBusError - what it is, what it does, and why software that doesn’t work with it is buggy. Unfortunately, we experienced a glitch in the prepress process, and wound up with source code lines that wrapped, making the assembly source listing confusing and hard to read. Worse yet, two good quotes got pushed off the page!
Since the issue of reading from or writing to memory location 0 is so important, here it is again. Greg Marriott wrote EvenBetterBusError (aka EBBE). It puts a 4-byte value into memory location 0 which will generate a bus error or an illegal instruction on any Macintosh if someone dereferences a nil pointer or if they jump to 0. EBBE periodically checks to see whether someone has written to location 0 (probably using a NIL pointer). If so, it drops into the debugger and says, “Write to NIL.” EBBE can help you make your software better.
Here’s reconstituted code which shows you everything that EvenBetterBusError does. It’s pretty simple. It installs a VBL task which periodically checks location 0, drops into the debugger if it needs to, and stuffs $50FF8001 back into location 0.
It’s never ok to write to location 0, nor is it ever ok to dereference a NIL pointer. Code that does these things is buggy.
/* 1 */ BRA.S InstallVBL BeginCodeBlock VBLRecord DC.L 00000000,0001 ; QElemPtr, queue type (1==VBL queue) DC.L 00000000 ; ptr to VBL code DC.W 0001,0000 ; timeout count &phase count MOVE.L $0,D0 ; put location 0’s contents into D0 ANDI.L #$7FFFFFFF,D0 ; strip the high bit CMPI.L #$50FF8001,D0 ; see if someone wrote over it BEQ.S SkipDebugStr ; if not, everything’s ok CMPI.L #$40810000,D0 ; see if it’s ProcMgr’s safe value BEQ.S SkipDebugStr ; if so, everything’s ok PEA BuggyCodeWroteToNIL _DebugStr SkipDebugStr MOVE.L #$50FF8001,$0 ; put a bus error value at $0 MOVE.W #$0001,$000A(A0) ; reset the VBL timer RTS EndOfCodeBlock BuggyCodeWroteToNIL DC.B 'Write to NIL',00 SizeOfCodeBlock equ EndOfCodeBlock-BeginCodeBlock InstallVBL MOVEQ #SizeOfCodeBlock,D0 ; allocate a block for code & data _NewPtr ,sys ; make a block in the system heap MOVE.L A0,-(A7) ; remember this block's address MOVEA.L A0,A1 LEA VBLRecord,A0 ; a static copy of our VBL record MOVEQ #SizeOfCodeBlock,D0 ; the size of the VBL code & data _BlockMove ; copy from INIT into sys heap block MOVEA.L (A7)+,A0 ; the system heap block PEA $000E(A0) ; addr of ptr to VBLin VBL record MOVE.L (A7)+,$0006(A0) ; stuff ptr to VBLcode _VInstall MOVE.L #$50FF8001,$0 ; put a bus error value at $0 RTS
Food For Thought
Post mortem debugging can be fun, especially when you get to see the victim die over and over again in slow motion!
- Greg Marriott
Seen On The Net
Macintosh, for those who can see through Windows.
- reported by baileyc@beetle.com
Dilbert
by Scott Adams
![](/file/12652/www.mactech.com.tar/www.mactech.com/sites/all/themes/custom_front/img/search_text.gif)
- SPREAD THE WORD:
- Slashdot
- Digg
- Del.icio.us
- Newsvine