With DaaS Windows Coming, Say Goodbye To Your PC As You Know It

In comp.os.linux.misc Dan Purgert wrote:
Wolf K wrote:
Oh, I admit I'm not a Linux expert. After all, I only try the latest
Mint about once a year. I like it a lot, but it won't run WordPerfect,
and that's a deal-breaker. I can't stand Word and its work-alikes, and
avoid them as much as possible.

If there's anyone here who runs WordPerfect under WINE, I'd like to hear
from them.

I've never used it myself (so I don't know what differences it has
between "Word and work-alikes"); but perhaps one of the options here may
be of interest:

https://alternativeto.net/software/c...platform=linux

HTH


I have used WordPerfect on a Linux machine for a number of years. There
are four ways of doing this, none of which use WINE.

1) Use native Linux version. Only works on 32-bit version of the OS. Must
install legacy libraries as detailed on Peter Stone's excellent
http://xwp8users.com/

Macros work. For printing, must save as a postscript file, and use ps2pdf
to create a pdf. Or, open file in LibreOffice to print.

2) Use PC WordPerfect 12 under Crossover. Everything works except macros.

3) Use a recent PC version inside a virtual machine running Windows XP.

4) USE WordPerfect for Mac inside the Sheepshaver Classic Mac emulator.

Hope that this is of some help to somebody out there.
David B.

On 2018-08-07, nospam wrote:
In article , The Natural Philosopher
wrote:

Nope, I used OSX for a couple of years before abandoning it for Linux.

As long as nothing went wrong, it was OK.

As long as you didn't want it to read or write files from windows or
linux, it was fine.

files are files. it doesn't matter where they're from.


Well yes it does.

nope.

Because in OSX files are in fact TWO files.

nope.


The Apple terminology is apparently data fork and device fork,
and last time I looked these were visible as two separate disk files (using
the linux HFS driver). This was like 1998 or so. but when files were
posted uuencoded it seemed that the device fork was 32 bytes on the
start.


--
ت

On 08/08/18 08:12, Jasen Betts wrote:
On 2018-08-07, nospam wrote:
In article , The Natural Philosopher
wrote:

Nope, I used OSX for a couple of years before abandoning it for Linux.

As long as nothing went wrong, it was OK.

As long as you didn't want it to read or write files from windows or
linux, it was fine.

files are files. it doesn't matter where they're from.


Well yes it does.

nope.

Because in OSX files are in fact TWO files.

nope.


The Apple terminology is apparently data fork and device fork,
and last time I looked these were visible as two separate disk files (using
the linux HFS driver). This was like 1998 or so. but when files were
posted uuencoded it seemed that the device fork was 32 bytes on the
start.


When I last used OS/X tiger there were two files. On the Mac, and on any
files exported via SMB.

One of them was a 'hidden' file.

Yes, that was on HFS systems


--
"When one man dies it's a tragedy. When thousands die it's statistics."

Josef Stalin

David B wrote:
In comp.os.linux.misc Dan Purgert wrote:
Wolf K wrote:
Oh, I admit I'm not a Linux expert. After all, I only try the latest
Mint about once a year. I like it a lot, but it won't run WordPerfect,
and that's a deal-breaker. I can't stand Word and its work-alikes, and
avoid them as much as possible.

If there's anyone here who runs WordPerfect under WINE, I'd like to hear
from them.

I've never used it myself (so I don't know what differences it has
between "Word and work-alikes"); but perhaps one of the options here may
be of interest:

https://alternativeto.net/software/c...platform=linux

HTH


I have used WordPerfect on a Linux machine for a number of years. There
are four ways of doing this, none of which use WINE.

1) Use native Linux version. Only works on 32-bit version of the OS.
Must install legacy libraries as detailed on Peter Stone's excellent
http://xwp8users.com/

Seems a bit odd that setting up multi-arch (or your distro's variant
thereto) isn't a possibility. Or has it simply not been tested?


--
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5 4AEE 8E11 DDF3 1279 A281

In article , David B wrote:
....
I have used WordPerfect on a Linux machine for a number of years. There
are four ways of doing this, none of which use WINE.
....
2) Use PC WordPerfect 12 under Crossover. Everything works except macros.

Crossover *is* Wine, pretty much.

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/GodDelusion

In article ,
Jasen Betts wrote:
....
The Apple terminology is apparently data fork and device fork,
and last time I looked these were visible as two separate disk files (using
the linux HFS driver). This was like 1998 or so. but when files were
posted uuencoded it seemed that the device fork was 32 bytes on the
start.

At least in classic Mac, the term was "resource fork", not "device fork".

--
b w r w g y b r y b

On 08/08/18 11:46, Kenny McCormack wrote:
In article ,
Jasen Betts wrote:
...
The Apple terminology is apparently data fork and device fork,
and last time I looked these were visible as two separate disk files (using
the linux HFS driver). This was like 1998 or so. but when files were
posted uuencoded it seemed that the device fork was 32 bytes on the
start.

At least in classic Mac, the term was "resource fork", not "device fork".

Anyway the point is that a macinstosh data 'file' be it a single entity
with two forks internal to HFS or two files as mapped onto any other
file system is INCOMPATIBLE with any other opearting system's
understanding of a 'file'.

I am not concerned with its ultimate representation, just as an example
of Apples unconcerned indiffenece to interoperability with others.

--
Gun Control: The law that ensures that only criminals have guns.

The Natural Philosopher wrote:
On 08/08/18 11:46, Kenny McCormack wrote:
In article ,
Jasen Betts wrote:
...
The Apple terminology is apparently data fork and device fork,
and last time I looked these were visible as two separate disk files (using
the linux HFS driver). This was like 1998 or so. but when files were
posted uuencoded it seemed that the device fork was 32 bytes on the
start.

At least in classic Mac, the term was "resource fork", not "device fork".

Anyway the point is that a macinstosh data 'file' be it a single entity
with two forks internal to HFS or two files as mapped onto any other
file system is INCOMPATIBLE with any other opearting system's
understanding of a 'file'.

I am not concerned with its ultimate representation, just as an example
of Apples unconcerned indiffenece to interoperability with others.

What the hell are you talking about?! Copying files between macOS, windows
and linux is just fine regardless of the source and destination. A pdf or
jpeg file is always a pdf or jpeg.

The one thing you do have watch are plain text files. The different OSs
have different line endings so may confuse some programs (e.g. excel). It's
an easy fix, though. They still aren't "incompatible".

The Natural Philosopher wrote:
On 08/08/18 08:12, Jasen Betts wrote:
On 2018-08-07, nospam wrote:
In article , The Natural Philosopher
wrote:

Nope, I used OSX for a couple of years before abandoning it for Linux.

As long as nothing went wrong, it was OK.

As long as you didn't want it to read or write files from windows or
linux, it was fine.

files are files. it doesn't matter where they're from.


Well yes it does.

nope.

Because in OSX files are in fact TWO files.

nope.


The Apple terminology is apparently data fork and device fork,
and last time I looked these were visible as two separate disk files (using
the linux HFS driver). This was like 1998 or so. but when files were
posted uuencoded it seemed that the device fork was 32 bytes on the
start.


When I last used OS/X tiger there were two files. On the Mac, and on any
files exported via SMB.

One of them was a 'hidden' file.

Yes, that was on HFS systems

I think you're describing metadata files. Finder does this to store
information about a file (e.g. thumbnail versions of images). Other OSes do
the same, but may store it in different places.

They are disposable and are recreated by the Finder if required.

In article , Jasen Betts
wrote:

The Apple terminology is apparently data fork and device fork,

resource fork, not device fork.

and last time I looked these were visible as two separate disk files (using
the linux HFS driver). This was like 1998 or so.

that was 20 years ago, *before* mac os x.

things have changed a *lot* since then, notably that classic mac os is
history and also that the resource fork was deprecated in os x.

also, not all files had a resource fork back then.

but when files were
posted uuencoded it seemed that the device fork was 32 bytes on the
start.

that depends on what was used to post them, and the 32 bytes was not a
fork at all, but rather a file header.

In article , The Natural Philosopher
wrote:

The Apple terminology is apparently data fork and device fork,
and last time I looked these were visible as two separate disk files (using
the linux HFS driver). This was like 1998 or so. but when files were
posted uuencoded it seemed that the device fork was 32 bytes on the
start.

At least in classic Mac, the term was "resource fork", not "device fork".

Anyway the point is that a macinstosh data 'file' be it a single entity
with two forks internal to HFS or two files as mapped onto any other
file system is INCOMPATIBLE with any other opearting system's
understanding of a 'file'.

false.

I am not concerned with its ultimate representation, just as an example
of Apples unconcerned indiffenece to interoperability with others.

you're not concerned with accuracy.

mac resource forks were deprecated long ago, but even before that, not
all files had resource forks and the ones that did usually contained
mac specific metadata that was not critical.

also keep in mind that ntfs supports multiple forks, known as alternate
data streams.

in fact, that was not interoperable with other versions of windows,
never mind other operating systems.
https://blogs.msdn.microsoft.com/oldnewthing/20110527-00/?p=10553/
Why are custom properties created on Windows 2000 lost when I view
the file from newer versions of Windows?
....
Most file types do not have extensibility points for adding metadata.
For example, every byte of a plain text files is devoted to text
data; there is nowhere to put metadata like Author or Summary. In
Windows*2000, the shell chose to store this extra information in NTFS
alternate data streams (or more accurately, the shell chose to use
the STGFMT_FILE storage format, which is implemented in terms of NTFS
alternate data streams.) Storing the information in alternate data
streams attaches the data to the file without affecting the file
contents.

This was a clever idea, taking advantage of NTFS's ability to attach
arbitrary data to a file, but it also had a serious problem:
Alternate streams are not preserved by simple and common operations
like sending the file by email, copying the file to a (FAT-formatted)
USB thumb drive, uploading or downloading the file from a Web site,
or burning the file to a CD. Basically, once the file leaves the
comfortable confines of your local hard drive, there's a good chance
that the metadata will be destroyed.

In article , Chris
wrote:


Anyway the point is that a macinstosh data 'file' be it a single entity
with two forks internal to HFS or two files as mapped onto any other
file system is INCOMPATIBLE with any other opearting system's
understanding of a 'file'.

I am not concerned with its ultimate representation, just as an example
of Apples unconcerned indiffenece to interoperability with others.

What the hell are you talking about?! Copying files between macOS, windows
and linux is just fine regardless of the source and destination. A pdf or
jpeg file is always a pdf or jpeg.

yep. there are no issues.

The one thing you do have watch are plain text files. The different OSs
have different line endings so may confuse some programs (e.g. excel). It's
an easy fix, though. They still aren't "incompatible".

yep. classic macos, windows and unix are all different.

well written software automatically figures it out.

On 08/08/18 13:12, Chris wrote:
The Natural Philosopher wrote:
On 08/08/18 11:46, Kenny McCormack wrote:
In article ,
Jasen Betts wrote:
...
The Apple terminology is apparently data fork and device fork,
and last time I looked these were visible as two separate disk files (using
the linux HFS driver). This was like 1998 or so. but when files were
posted uuencoded it seemed that the device fork was 32 bytes on the
start.

At least in classic Mac, the term was "resource fork", not "device fork".

Anyway the point is that a macinstosh data 'file' be it a single entity
with two forks internal to HFS or two files as mapped onto any other
file system is INCOMPATIBLE with any other opearting system's
understanding of a 'file'.

I am not concerned with its ultimate representation, just as an example
of Apples unconcerned indiffenece to interoperability with others.

What the hell are you talking about?! Copying files between macOS, windows
and linux is just fine regardless of the source and destination. A pdf or
jpeg file is always a pdf or jpeg.

Try an image file or a font file



The one thing you do have watch are plain text files. The different OSs
have different line endings so may confuse some programs (e.g. excel). It's
an easy fix, though. They still aren't "incompatible".



--
"A point of view can be a dangerous luxury when substituted for insight
and understanding".

Marshall McLuhan

On 08/08/18 13:13, Chris wrote:
The Natural Philosopher wrote:
On 08/08/18 08:12, Jasen Betts wrote:
On 2018-08-07, nospam wrote:
In article , The Natural Philosopher
wrote:

Nope, I used OSX for a couple of years before abandoning it for Linux.

As long as nothing went wrong, it was OK.

As long as you didn't want it to read or write files from windows or
linux, it was fine.

files are files. it doesn't matter where they're from.


Well yes it does.

nope.

Because in OSX files are in fact TWO files.

nope.


The Apple terminology is apparently data fork and device fork,
and last time I looked these were visible as two separate disk files (using
the linux HFS driver). This was like 1998 or so. but when files were
posted uuencoded it seemed that the device fork was 32 bytes on the
start.


When I last used OS/X tiger there were two files. On the Mac, and on any
files exported via SMB.

One of them was a 'hidden' file.

Yes, that was on HFS systems

I think you're describing metadata files. Finder does this to store
information about a file (e.g. thumbnail versions of images). Other OSes do
the same, but may store it in different places.

They are disposable and are recreated by the Finder if required.

Nope. Fonts for example use the metadata to store vital info.

So do images in some cases.


--
"A point of view can be a dangerous luxury when substituted for insight
and understanding".

Marshall McLuhan

On 08/08/18 13:18, nospam wrote:
In article , Chris
wrote:


Anyway the point is that a macinstosh data 'file' be it a single entity
with two forks internal to HFS or two files as mapped onto any other
file system is INCOMPATIBLE with any other opearting system's
understanding of a 'file'.

I am not concerned with its ultimate representation, just as an example
of Apples unconcerned indiffenece to interoperability with others.

What the hell are you talking about?! Copying files between macOS, windows
and linux is just fine regardless of the source and destination. A pdf or
jpeg file is always a pdf or jpeg.

yep. there are no issues.

https://blog.jay2k1.com/2010/02/03/w...om-smb-shares/


So, you are lying. There are SERIOUS issuess.


--
"A point of view can be a dangerous luxury when substituted for insight
and understanding".

Marshall McLuhan