Does this work?

[Paul]

Sorry, it appears that this one still has the same problem.

[MacUser]

Paul: I use the PC daily, I just repress the memory!

Smash: Here is the response from WinZip -

Hi, I am writing in response to your message:

>
> Do you have a Macintosh compatible version of WinZip? I have an iMac running OS 8.6.

Sorry, WinZip works only on Windows.

The Info-ZIP group produces command line Zip/Unzip software for a
variety of other platforms, including the Mac, MVS, and various versions
of Unix. I suggest you take a look at their home page at

http://www.info-zip.org/pub/infozip/

You can also check

http://garbo.uwasa.fi

which has an extensive collection of Macintosh file utilities.

Please let me know if you have any further questions.


-- Chuck Campbell, WinZip Technical Support

I find it very curious that Paul is having such problems with your text file. Perhapes some additional PC users could confirm this behavior. I have always assumed that Simple Text and applications such as Notepad were the most basic of text editors and could produce cross-platform files. Ah, but what do I know. Something is obviously amiss! Again, I had no problems with your file.

------------------
Different is GOOD!

AOL IM--JacSamDad

[Smash]

finding a zip utility was/is not the problem

[Smash]

I give up

[Scouse Gits]

Regret - having the same problem - end of line markers not recognised as such by PC.
Does the Mac use the ASCII character set?


------------------
____________
Scouse Git[1]

"CARTAGO DELENDA EST" - Cato the Censor

[Paul]

It probably does, otherwise the whole text would be unreadable garbage. It is just the end-of-line markers that appear to be the problem.

[MacUser]

I just checked the "Macworld Mac Secrets" book and confirmed that ASCII is the same for all religions whether Windows, Mac or "anything else" (Unix? ) I'll ask this to some real programers and see if they know the answer. This is really curious.

------------------
Different is GOOD!

AOL IM--JacSamDad
[This message has been edited by MacUser (edited June 08, 2000).]

[Tom DeMille]

Hey, I'm a real programmer!

I dug around some c++ docs concerning text editors, and have found the problem.

DOS and Windows use ASCII 13 (carriage return) and ASCII 10 (linefeed character) in combination as their new line marker.

UNIX and Mac use only the linefeed character.

So straight text files are not compatible cross platform. What else is new...

Smash, if you could just toss in an ASCII 13 character everytime you hit enter, it would be appreciated.

[Paul]

Well, it's good to see that we finally know the cause of the problem and a possible solution. Smash, I hope this will help you get your scenario working on both Windows and Mac.

[Steve Clark]

In case you don't know how to do that, just do:

#include <iostream.h>
cout << "string\n";
or
cout << "string" << end1;
where 'string' is the text string.

j/k

[This message has been edited by Steve Clark (edited June 08, 2000).]

[Smash]

huh?

[Tom DeMille]

I think Steve is suggesting you write yourself an app in C. A bit tricky for a non programmer. I remember using Think C for the mac a decade ago, but unfortunately don't have a mac compiler available right now. If I did I'd write a quick and dirty text editor for you.

Do you have a Java interpreter installed on your machine? I could bang off a Java text editor for you.

Or you could try http://www.mac.org/utilities/texeditplus/ . This is a mac text editor that mentions it will reformat text for MS-DOS BBSs. This might save the text in the right format.

It's interesting that the Mac doesn't have trouble with the extra carriage return character in DOS text files. I guess it just ingores it.

edit: Or, you can just tell pc people to fix the damn text file themselves. It's not hard. Just open it in wordpad (or any word processor other than notepad), and resave it as a straight text file.
[This message has been edited by Tom DeMille (edited June 08, 2000).]

[Steve Clark]

Actually, I was just trying to be cleverly funny. Guess it didn't work.

[Tom DeMille]

quote: #include <iostream.h> cout << "string\n"; or cout << "string" << end1; where 'string' is the text string.

Oh, I just got it! Ha, ha! Good old American humour.
[This message has been edited by Tom DeMille (edited June 08, 2000).]

[SCG]

quote: #include <iostream.h> cout << "string\n"; or cout << "string" << end1; where 'string' is the text string.

As someone who has just spend much of the last 6 hrs helping people proofread their beginning Ada and C programs, I guess I'm still in that mindset

So, actually this is a C++ program, not a C program, if anyone really wanted to try that out somewhere C would use printf statements instead, as well as a slightly different file to include. The printf statement in place of cout might have even helped Smash get the gist of the code just from context.

also, can anyone spot the typo in the alternate way to print a new line?

thats right! the 1 should be an l
(lower case 'L')


As one other side note to the actual problem, I'm surprised I didn't think of that - there are a lot of people who load their programs from notepad to UNIX and I always have them do a search and replace on all those pesky little carriage returns (^M) - they don't affect anything compilerwise, but do confuse text editors like emacs.

and my appologies to Tom and Steve - like i said, i've been spending too long today pointing out the obvious and just couldn't help myself

edit: odd - I just tried to edit this page, since the <iostream.h> was missing in my original post - but its already there???

wonder if it will show up this time :|
[This message has been edited by SCG (edited June 08, 2000).]