Claris Home Page FAQ Cross-Platform Issues Back to Main FAQ This page has had 1146 hits since November 7, 1997. Last updated 1/8/99.

Join the Mac OS 8 Web Campaign!

There are several cross-platform issues to consider when using CHP or any web page creation program, or for that matter doing anything involving more than one platform. Here are some of the major cross-platform issues encountered by Claris Home Page users with solutions and detailed discussions. Occasionally, I will even point a finger at who is to blame (since that is what we all really want to know when there is a problem), though be aware that I am a MacAddict (I doubt you can have gotton this far into my site and not realized that) and I am much more eager to blame a problem on Microsoft (it is basically guilty until proven innocent, and even then).

Windows 95 Filename Case Changing

Filename Changes During Win <--> Mac File Transfer

Windows 95 Filename Case Changing

The Problem, The Solutions, The Discussion

The Problem:

This is a really strange and annoying thing which happens with the Windows 95/NT version of CHP. It can also be an issue with web content creation in general. Several things might happen:

• File names are inconsistently capitalized depending on what program you are using.
• When inserting links or images, CHP will code a filename "Foobar.htm" as "FOOBAR.HTM".
• When opening a previously created HTML file, CHP will change links and image references to uppercase. So "Foobar.htm" will become "FOOBAR.HTM".

Pages where this occurs works when viewed locally, as Win 95 ignores case when identifying a file. However, if and only if the pages are uploaded to a UNIX webserver (UNIX destinguishes between uppercase and lowercase in filenames), the links and images may be "missing". This just means that although the files themselves were uploaded, the links, in the view of the UNIX-based webserver, point to completely different files.

The Solutions:

Solution #1:

Use CHP to upload all your files. It will upload them in the right case.

Solution #2:

Use filenames which do not meet the 8.3 specification. This will apparantly force all applications to see it your way. Use .jpeg instead of .jpg, .html instead of .htm, use longer filenames.

Solution #3:

Explicit renaming in My Computer. People have said it doesn't work, and it really doesn't, I've checked. If you have a file Test.txt (which is really TEST.TXT) and you rename it Test.txt, nothing changes. Apparantly Win95/NT thinks it can save some cycles by not bothering to change the name when it is already that name, ACCORDING to My Computer. So what you need to do is change it to something completely different, such as Think.different, and then change it back again to the name you want it to have. Yet another way to get more use out of Windows.

If you want to create files with this problem, find some old non-Win32 applications and save some files. They too will have dual names.

Solution #4:

Sorry, can't resist, but upgrade to an operating system that can handle filenaming properly, and doesn't overrule your naming decisions.

Hopefully this will clear up the problems for those with them, and no hard feelings about the anti-Windows/pro-Macintosh rants, OK. They are mixed in with actual on-topic stuff.

The Discussion:

Since this has been a big issue over the past several days, amounting to as big a "discussion" as we have had in the past on "Absolute URLs" and "Anchors and Links", I went and found a WinNT machine with CHP, and experimented with it for about an hour and a half, playing all kinds of filenaming games with the OS and with CHP. What I discovered is summarized in the following rant. No one take offense.

This problem is caused by Windows' way of dealing with files, and more specifically, its habit of "adjusting" file names to meet its aesthetic standard. This Microsoft mistake is revealed when non-Win 95 programs name files the way they have always named files, or if users do the same. None of this poses a problem until you upload to a UNIX server.

Here is my ideological rant on this subject (as seen on CHP Talk):

<RANT subject="Windows filename casing" keywords= "Windows, UNIX, case-sensitive, web publishing" author="Marcin Jeske">

I have found that the current incarnation of Windows is seriously flawed as a platform for creation of web-based content. These flaws cause numerous errors when files are moved to case-sensitive platforms, such as UNIX, which constitute the majority of current Internet servers. These flaws attest to the controlling, sloppy, and inconsistent nature of Microsoft and its products, and can cause Microsoft's customers to waste time and money attempting to compensate for the low quality of Microsoft's software. The saddest truth is that when Microsoft corrects, or more likely slightly lessens, these and the many other flaws in their operating systems, these same customers will get to pay them more money

</RANT>

Here's my write up of my experiment with WinNT:

Materials:

Windows NT Workstation 4.0

Claris Home Page 2.0 for Windows

A simple folder called INDEX.HTM

Procedure:

Now that I've ranted and raged against Microsoft, I can take a breath. Here is what I found.

First, I played around with WinNT by itself, not launching CHP. I created a file named index.html. It was just an empty text file. When looking at the file, I used three interfaces: the Finder-like "My Computer", the "Command Prompt" which is a UNIXed-up DOS, and through the eyes of a fairly standard FTP application, WS_FTP32.

So index.html appeared the same in all three. Then in My Computer, I attempted to change the name to INDEX.HTM. WinNT apparantly corrected me and changed the file name to Index.htm instead. Hence my reference to their controling nature. You cannot name a file in My Computer INDEX.HTM, no matter how much you rant and scream. You can type that name in, see it on the screen, but the minute you click away, WinNT decides it doesn't like your casing. Or does it...

The file which I intended to name INDEX.HTM appears as: Index.htm in My Computer INDEX.HTM in Command Prompt index.htm in WS_FTP32

***interesting note: when I make a copy of Index.htm in My Computer, I get Copy of INDEX.HTM***

It seems the issue revolves mainly around filenames which may be Win long file names, but conform to the 8.3 spec. Such files will include almost all web files, since we use .jpg, .gif, .pdf, .ps, .mov, .avi, .cgi, etc. They will only apply to html files if we use .htm as opposed to .html. So even though a filename is NOT a DOS filename, it is treated as such, and there the ambiguity begins.

You see above that three different "programs" got three different answers to the question: What is the name of this file? On a PC, this confusion is only cosmetic, as Windows is case insensitive. But it apparantly also tends to ignore case. On MacOS, a file has a certain ASCII name, and no program can muck around with the case of any of the characters. Even though it is case-insensitive, it recognizes case. You can specify a file search to "Match Case", and there is no ambiguity.

As long as these Win-maligned files stay on a Win or Mac machine, it is all smooth sailing. However, the web market, though many low volume sites do use Macs, depends mainly on the POWERS of UNIX. UNIX *IS* case-sensitive, and if those three programs aforementioned were told to all upload the file INDEX.HTM/Index.htm/index.htm to a UNIX server, we would end up with THREE different files.

Which is where the CHP problems come in. CHP, being a good HTML editor, wants to make sure that even though our links may work on our personal computer, we don't run into any problems when we take it up to a UNIX box. So it dutifully checks whether the casing in our link matches that of the path to the file. So, if the casing has been changed, or the file name was typed in inaccurately (I mess up capitalization all the time) the problem is fixed and averted. THank You CHp. On a Mac, this works fine. A file has one and only one name. But on a PC ...

From what I can figure, CHP uses the same facility as the Command Prompt to find the name of the file, which I think is right, as that is the name I intended for my file. However, when you upload the file with, say, WS_FTP32, the file gets uploaded with a different name, index.htm.

Why doesn't this happen with Netscape Gold and other editors - they don't BOTHER to check!!! You can change case right under the nose of Navigator Gold 3, and it is none the wiser, which also means your web page will be messed up when uploaded.

Thanks to:

Lance Crocker <lance@maine.rr.com> , who early on posted to the CHP Talk mailing list regarding the solution of explicitly changing the filename under "My Computer". He was also insightful (or knowledgeable enough) to state that this was not a CHP bug, but rather a fundamental inconsistency in the way Win95/NT handled filenames. He also mentioned that the problem files were ones which had been created by Pre-Win95/NT applications which could not handle lowercase characters. Here is his web site address: http://usmcug.usm.maine.edu/~crocker

Filename Changes During Win <--> Mac File Transfer

The Problem, The Solutions, The Discussion

The Problem:

When you transfer files via floppy or Zip disk or other medium between a Windows Computer and a Mac and vice versa, the filenames appear to get maimed. My_Cool_File.html becomes MY_COO~1.HTM.

The Solutions:

Solution #1:

Transfer them across the Network/Internet using FTP. The names will stay intact. Most modern FTP clients, such as Fetch and WS_FTP32 can transfer entire folder hierarchies.

Solution #2:

Use the power of zip (no, not the drive, but the compression standard). The .zip compression format stores folder hierarchies, so you pack it up on one platform, then unpack it on the other platform, and all is good. You can find zip compression utilities for both platforms at shareware.com:

WinZip for Windows95/NT is I think pretty common and easy to use.
ZipIt is one program I've used on the Mac.

***StuffIt Expander with Expander Enhancer can decompress .zip too.
***The commercial version of StuffIt can do even more
***Check their site at www.aladdinsys.com

Summary::

I encountered this problem too when moving files cross-platform, and I use the .zip solution. Not only do the names stay unchanged, but I save space.

The Discussion:

This will be added soon...

Cautionary Note:

Be aware there are two other cross-platform issues which can mess things up. First, PC and Mac files (and UNIX, to a lesser extent) have a different selection of characters allowed in the filename. Macs use the : for path delimeters, Windows uses the \, and UNIX uses the /, so if you do plan to move files, don't use those characters. Also, spaces are a touchy issue. If you are dealing with just Macs and PCS, they will pass, but they are not recommended. Just try deleting a file named Bob's File on a command line interface - it can't be done, or rather, it can.

***If you ever do have to delete a file named Bob's File on a command
***line interface, tell it to delete Bob's%20File and it will work.

For this very reason, you might avoid putting %'s in file names, and leading ~ (UNIX home directory shortcut) and *'s (wildcard characters in UNIX and DOS) and ? (also wildcards) and ...

The other problem is with filename length.

Here are the limitations:

A Macintosh filename can be composed of a maximum of 31 characters.

That's 31 + : (path delimeter) = 2^5

A Windows *path* can be composed of no more than 256 characters.

That included C:\ and all subsequent path delimeters.

In other words, each file on a Windows machine must have a unique name of nomore than 256 = 2^8 characters.

It is highly unlikely that you will reach these limits, for hardly anyone named their files longer than 31 characters, and you really have to work at it to create enough nested folders to exceed the 256 character limit. For the record, starting at C:\WINNT\Profiles\mjeske\Desktop, whitch is 32 characters, I had to create *16* nested folder each with a name 13 chars long (plus the path delimeter) just to get the measly message:

"This folder cannot be opened. Path too long."

But these are still issues you should keep in mind.

More cross-platform issues to come ...

It seems that the filesystem is still a version of DOS, so each file has a 8.3 name, which, because of DOS's history, is in all caps. Win 95 also gives it a long name (I'm not certain where this long name is stored) which works very much like Mac filenames. So each file has two names.