Discussion:
.obj => .txt and .txt => .obj program(s)???
(too old to reply)
m***@gmail.com
2017-01-09 15:19:26 UTC
Permalink
Raw Message
I'm looking for a program which converts an object file to a text
file and visa-versa. I'd like a way to be able to mail object modules
to people and it seems I need such a program to do this. So not only
would I need the program, I'd have to send it out to other people to
compile and use.
If you have such a program you're willing to part with, please
contact me.
Tony Purmal
Sorry for necroing this thread.
Jan-Erik Soderholm
2017-01-09 15:41:43 UTC
Permalink
Raw Message
Post by m***@gmail.com
I'm looking for a program which converts an object file to a text
file and visa-versa. I'd like a way to be able to mail object modules
to people and it seems I need such a program to do this. So not only
would I need the program, I'd have to send it out to other people to
compile and use.
If you have such a program you're willing to part with, please
contact me.
Tony Purmal
Sorry for necroing this thread.
What is "necroing" ?

For the questions as such, use ZIP/UNZIP and UUENCODE/UUDECODE.

Or only UUENCODE/UUDECODE, if ZIP/UNZIP is not installed...
Arne Vajhøj
2017-01-10 01:07:06 UTC
Permalink
Raw Message
Post by Jan-Erik Soderholm
Post by m***@gmail.com
I'm looking for a program which converts an object file to a text
file and visa-versa. I'd like a way to be able to mail object modules
to people and it seems I need such a program to do this. So not only
would I need the program, I'd have to send it out to other people to
compile and use.
If you have such a program you're willing to part with, please
contact me.
Sorry for necroing this thread.
What is "necroing" ?
http://www.urbandictionary.com/define.php?term=Necroing

Arne
David Froble
2017-01-09 16:00:31 UTC
Permalink
Raw Message
Post by m***@gmail.com
I'm looking for a program which converts an object file to a text
file and visa-versa. I'd like a way to be able to mail object modules
to people and it seems I need such a program to do this. So not only
would I need the program, I'd have to send it out to other people to
compile and use.
If you have such a program you're willing to part with, please
contact me.
Tony Purmal
Sorry for necroing this thread.
Got to ask, what's wrong with ZIP, or VMS BACKUP. Either one will work. Or
both will work, create a backup save set, then ZIP it with the /VMS qualifier to
preserve file characteristics.
Simon Clubley
2017-01-09 18:14:10 UTC
Permalink
Raw Message
Post by David Froble
Post by m***@gmail.com
I'm looking for a program which converts an object file to a text
file and visa-versa. I'd like a way to be able to mail object modules
to people and it seems I need such a program to do this. So not only
would I need the program, I'd have to send it out to other people to
compile and use.
If you have such a program you're willing to part with, please
contact me.
Tony Purmal
Sorry for necroing this thread.
Got to ask, what's wrong with ZIP, or VMS BACKUP. Either one will work. Or
both will work, create a backup save set, then ZIP it with the /VMS qualifier to
preserve file characteristics.
Because the file needs to be in printable format to survive transmission
through the mail system. That's why uuencode was originally recommended
and why base 64 encoding would be used these days.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
David Froble
2017-01-09 22:58:02 UTC
Permalink
Raw Message
Post by Simon Clubley
Post by David Froble
Post by m***@gmail.com
I'm looking for a program which converts an object file to a text
file and visa-versa. I'd like a way to be able to mail object modules
to people and it seems I need such a program to do this. So not only
would I need the program, I'd have to send it out to other people to
compile and use.
If you have such a program you're willing to part with, please
contact me.
Tony Purmal
Sorry for necroing this thread.
Got to ask, what's wrong with ZIP, or VMS BACKUP. Either one will work. Or
both will work, create a backup save set, then ZIP it with the /VMS qualifier to
preserve file characteristics.
Because the file needs to be in printable format to survive transmission
through the mail system. That's why uuencode was originally recommended
and why base 64 encoding would be used these days.
Simon.
No, it doesn't. At least the e-mail I'm using. I routinely send VMS files,
objs, exes, and such as email attachments.

Unless there is something here I'm not seeing, or understanding ....
Johnny Billquist
2017-01-09 23:09:26 UTC
Permalink
Raw Message
Post by David Froble
Post by Simon Clubley
Post by David Froble
Op donderdag 3 november 1994 16:43:25 UTC+1 schreef
I'm looking for a program which converts an object file to a text
file and visa-versa. I'd like a way to be able to mail object modules
to people and it seems I need such a program to do this. So not only
would I need the program, I'd have to send it out to other people to
compile and use.
If you have such a program you're willing to part with, please
contact me.
Tony Purmal
Sorry for necroing this thread.
Got to ask, what's wrong with ZIP, or VMS BACKUP. Either one will
work. Or both will work, create a backup save set, then ZIP it with
the /VMS qualifier to preserve file characteristics.
Because the file needs to be in printable format to survive transmission
through the mail system. That's why uuencode was originally recommended
and why base 64 encoding would be used these days.
Simon.
No, it doesn't. At least the e-mail I'm using. I routinely send VMS
files, objs, exes, and such as email attachments.
Unless there is something here I'm not seeing, or understanding ....
What you are not seeing is that in this situation, mail is using MIME
and BASE64 encoding for you. That is what "attachments" are. You never
thought about how a mail, which is at the bottom line just a text
message, manage to pass attachments? Or how binary data gets through a
text based protocol?

Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: ***@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
David Froble
2017-01-10 00:59:31 UTC
Permalink
Raw Message
Post by Johnny Billquist
Post by David Froble
Post by Simon Clubley
Post by David Froble
Op donderdag 3 november 1994 16:43:25 UTC+1 schreef
I'm looking for a program which converts an object file to a text
file and visa-versa. I'd like a way to be able to mail object modules
to people and it seems I need such a program to do this. So not only
would I need the program, I'd have to send it out to other people to
compile and use.
If you have such a program you're willing to part with, please
contact me.
Tony Purmal
Sorry for necroing this thread.
Got to ask, what's wrong with ZIP, or VMS BACKUP. Either one will
work. Or both will work, create a backup save set, then ZIP it with
the /VMS qualifier to preserve file characteristics.
Because the file needs to be in printable format to survive transmission
through the mail system. That's why uuencode was originally recommended
and why base 64 encoding would be used these days.
Simon.
No, it doesn't. At least the e-mail I'm using. I routinely send VMS
files, objs, exes, and such as email attachments.
Unless there is something here I'm not seeing, or understanding ....
What you are not seeing is that in this situation, mail is using MIME
and BASE64 encoding for you. That is what "attachments" are. You never
thought about how a mail, which is at the bottom line just a text
message, manage to pass attachments? Or how binary data gets through a
text based protocol?
Johnny
Ok, but even so, I don't see the problem. Maybe something rather basic (sic)
I'm not seeing. If sent as attachments, then a ZIP file seems to fit the
request. No?
Simon Clubley
2017-01-10 18:20:51 UTC
Permalink
Raw Message
Post by David Froble
Post by Johnny Billquist
What you are not seeing is that in this situation, mail is using MIME
and BASE64 encoding for you. That is what "attachments" are. You never
thought about how a mail, which is at the bottom line just a text
message, manage to pass attachments? Or how binary data gets through a
text based protocol?
Ok, but even so, I don't see the problem. Maybe something rather basic (sic)
I'm not seeing. If sent as attachments, then a ZIP file seems to fit the
request. No?
Yes, provided you go to the extra effort of manually performing
a base64 or uuencode pass on the resulting zip file if you are
planning to send the file via VMS.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Johnny Billquist
2017-01-10 19:30:39 UTC
Permalink
Raw Message
Post by David Froble
Post by Johnny Billquist
Post by David Froble
Post by Simon Clubley
Post by David Froble
Op donderdag 3 november 1994 16:43:25 UTC+1 schreef
I'm looking for a program which converts an object file to a text
file and visa-versa. I'd like a way to be able to mail object modules
to people and it seems I need such a program to do this. So not only
would I need the program, I'd have to send it out to other people to
compile and use.
If you have such a program you're willing to part with, please
contact me.
Tony Purmal
Sorry for necroing this thread.
Got to ask, what's wrong with ZIP, or VMS BACKUP. Either one will
work. Or both will work, create a backup save set, then ZIP it with
the /VMS qualifier to preserve file characteristics.
Because the file needs to be in printable format to survive
transmission
through the mail system. That's why uuencode was originally recommended
and why base 64 encoding would be used these days.
Simon.
No, it doesn't. At least the e-mail I'm using. I routinely send VMS
files, objs, exes, and such as email attachments.
Unless there is something here I'm not seeing, or understanding ....
What you are not seeing is that in this situation, mail is using MIME
and BASE64 encoding for you. That is what "attachments" are. You never
thought about how a mail, which is at the bottom line just a text
message, manage to pass attachments? Or how binary data gets through a
text based protocol?
Johnny
Ok, but even so, I don't see the problem. Maybe something rather basic
(sic) I'm not seeing. If sent as attachments, then a ZIP file seems to
fit the request. No?
No, since a ZIP file is also not text. You can certainly send a zip file
as an attachment, if you want to.
Mail will then have to create a MIME formatted message in order to
attach the ZIP file, and the system will have to encode the ZIP file in
a text-oriented coding scheme, so that it can pass through mail.
And thus we're back to MIME and BASE64, which is the most common
encoding scheme used in MIME attachments for binary data encoded as text.

Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: ***@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Jan-Erik Soderholm
2017-01-09 23:12:55 UTC
Permalink
Raw Message
Post by David Froble
Post by Simon Clubley
Post by David Froble
Post by m***@gmail.com
I'm looking for a program which converts an object file to a text
file and visa-versa. I'd like a way to be able to mail object modules
to people and it seems I need such a program to do this. So not only
would I need the program, I'd have to send it out to other people to
compile and use.
If you have such a program you're willing to part with, please
contact me.
Tony Purmal
Sorry for necroing this thread.
Got to ask, what's wrong with ZIP, or VMS BACKUP. Either one will
work. Or both will work, create a backup save set, then ZIP it with the
/VMS qualifier to preserve file characteristics.
Because the file needs to be in printable format to survive transmission
through the mail system. That's why uuencode was originally recommended
and why base 64 encoding would be used these days.
Simon.
No, it doesn't.
Yes, it does. Any mails with attachements are always in text format.
Maybe you do not see it (you simply attach a binary file), but it
is still sent as text by your mail client. That is what MIME is
all about.
Post by David Froble
At least the e-mail I'm using.
Quite useless information without telling what "e-mail" that is.
Post by David Froble
I routinely send VMS files, objs, exes, and such as email attachments.
Works sometimes, sometimes not. Depends to a great deal on who
the sender and the recevied are. And what mail servers the
mailes passes on the way. And what spam-filters they use.
Post by David Froble
Unless there is something here I'm not seeing, or understanding ....
Both, it seems... :-)
Stephen Hoffman
2017-01-10 00:20:38 UTC
Permalink
Raw Message
Post by David Froble
Post by Simon Clubley
Because the file needs to be in printable format to survive
transmission through the mail system. That's why uuencode was
originally recommended and why base 64 encoding would be used these
days.
No, it doesn't. At least the e-mail I'm using. I routinely send VMS
files, objs, exes, and such as email attachments.
Unless there is something here I'm not seeing, or understanding ....
Look at the raw source for the messages in your GUI mail client, and
underneath you'll find the file attachements are usually base 64
encoded attachments in a mail message using a MIME-format structure.

If you're using the OpenVMS command line mail client, then you're
usually either using uuencode and uudecode or using MIME for the
message and adding the data into the MIME message using the MIME
utility.
--
Pure Personal Opinion | HoffmanLabs LLC
David Froble
2017-01-10 01:01:57 UTC
Permalink
Raw Message
Post by Stephen Hoffman
Post by David Froble
Post by Simon Clubley
Because the file needs to be in printable format to survive
transmission through the mail system. That's why uuencode was
originally recommended and why base 64 encoding would be used these
days.
No, it doesn't. At least the e-mail I'm using. I routinely send VMS
files, objs, exes, and such as email attachments.
Unless there is something here I'm not seeing, or understanding ....
Look at the raw source for the messages in your GUI mail client, and
underneath you'll find the file attachements are usually base 64 encoded
attachments in a mail message using a MIME-format structure.
If you're using the OpenVMS command line mail client, then you're
usually either using uuencode and uudecode or using MIME for the message
and adding the data into the MIME message using the MIME utility.
Ok, maybe what I'm not seeing is the use of VMS mail to send the messages. See,
right in front of me, best place to hide things from me.

Getting old isn't for sissies ....
Steven Schweda
2017-01-09 19:05:11 UTC
Permalink
Raw Message
Post by m***@gmail.com
Sorry for necroing this thread.
So, start your own, instead, and avoid the sorrow?

There are two potential problems with VMS object files: 1)
e-mail-incompatible content, and 2) file attributes different
from those of normal text files.
Post by m***@gmail.com
Got to ask, what's wrong with ZIP, or VMS BACKUP. Either
one will work. [...]
Either one will deal with (only) the file attributes
problem. Because of the usual problems involving BACKUP
save-set attributes, I'd lean toward Zip (-V, /VMS), and not
bother with BACKUP. (UnZip cares very little about the
attributes of a Zip archive.)
Post by m***@gmail.com
[...] uuencode was originally recommended and why base 64
encoding would be used these days.
And those methods will deal with the non-text content.

There should be an abundance of old discussions on MIME
encoding and sending (and MIME extraction and decoding) of
e-mail attachments on VMS by now.
hb
2017-01-09 20:19:37 UTC
Permalink
Raw Message
Post by Steven Schweda
There are two potential problems with VMS object files: 1)
e-mail-incompatible content, and 2) file attributes different
from those of normal text files.
For VAX/Alpha/I64 you probably mean the rat=none and for I64 the
different rfm=udf. The original post was from 1994 so I64 may not be of
interest, here.
Post by Steven Schweda
Post by m***@gmail.com
[...] uuencode was originally recommended and why base 64
encoding would be used these days.
And those methods will deal with the non-text content.
There should be an abundance of old discussions on MIME
encoding and sending (and MIME extraction and decoding) of
e-mail attachments on VMS by now.
... including the
MIME> ADD whatever.zip /CONTENT_TYPE="application/zip" /ENCODING=base64

But there are also the
MIME> show file
Known File Types:
...
Extension: OLB, Content-Type: application/vms-olb, Encoding: Base64
Extension: OBJ, Content-Type: application/vms-obj, Encoding: Base64
...
Extension: EXE, Content-Type: application/vms-exe, Encoding: Base64
Extension: COM, Content-Type: text/plain; charset=ISO-8859-1,
Encoding: 7bit/8bit
Extension: BCK, Content-Type: application/vms-backup, Encoding: Base64
MIME>

So an

MIME>NEW message.txt
edit your message text
MIME>ADD whatever.obj
MIME>CLOSE

should create the (correct?) multipart mail message body.

IF it were implemented as expected:
MIME>EXTRACT/ATTACHMENT=2 x.obj

$ fats x.obj
File DISK$USER:[USER]X.OBJ;1
credate=" 9-JAN-2017 15:06:54.33"
revdate=" 9-JAN-2017 15:06:54.34"
expdate="17-NOV-1858 00:00:00.00"
bakdate="17-NOV-1858 00:00:00.00"
org=seq
rfm=stmlf
rat=cr
lrl=32767
hbk=6
ebk=5
ffb=494
bks=0
fsz=0
deq=0
mrs=0
gbc=0
vrs=0
$

This is output from Alpha/V8.3. Did this change/work as expected in 8.4
and later?

Anyway, the content type should be vms-xxx-obj with xxx=vax, alpha, i64
or x86 and mime should know hot to correctly set the file attributes.
hb
2017-01-09 20:25:48 UTC
Permalink
Raw Message
Post by hb
Anyway, the content type should be vms-xxx-obj with xxx=vax, alpha, i64
or x86 and mime should know hot to correctly set the file attributes.
Sorry for the typo: sed 's/hot/how/'

and then I think MIME should delete the temporary copies, here the
MIME$334B_WHATEVER.OBJ;1
Steven Schweda
2017-01-10 01:26:34 UTC
Permalink
Raw Message
Post by hb
Anyway, the content type should be vms-xxx-obj with xxx=vax, alpha, i64
or x86 and mime should know hot to correctly set the file attributes.
I have no reason to expect any MIME program to do this
correctly. I can copy a .OBJ file from anywhere to anywhere
else, and a MIME program which looks at only file _names_
won't know whence it came. (Least of all the MIME program
supplied with VMS, which, so far as I know, can't deal
properly with mixed-case attachment file names, and leaves
junk like MIME$<PID>_<NAME>.<TYPE> lying around after it
dies. Expecting it to deal with fine-print file attributes
seems to me to be misguided, at best.)

I expect programs like Zip and UnZip (or BACKUP) to deal
properly with actual file attributes, without regard to the
file names (or other irrelevancies).

alp $ pipe write sys$output "show version" | mime
MIME Version: V1.93

(That was convenient, too.)
Johnny Billquist
2017-01-10 19:35:58 UTC
Permalink
Raw Message
Post by Steven Schweda
Post by hb
Anyway, the content type should be vms-xxx-obj with xxx=vax, alpha, i64
or x86 and mime should know hot to correctly set the file attributes.
I have no reason to expect any MIME program to do this
correctly. I can copy a .OBJ file from anywhere to anywhere
else, and a MIME program which looks at only file _names_
won't know whence it came. (Least of all the MIME program
supplied with VMS, which, so far as I know, can't deal
properly with mixed-case attachment file names, and leaves
junk like MIME$<PID>_<NAME>.<TYPE> lying around after it
dies. Expecting it to deal with fine-print file attributes
seems to me to be misguided, at best.)
Well, I can't properly comment on the MIME implementation in VMS
programs, but MIME attachments as such are not identified by their name
as to how the content should be handled. MIME have a content-type tag,
that should be telling you this.

MIME as a technical solution, can handled any kind of strange formats
correctly, as the meta-data exists to inform the other end of both the
name, and how to interpret the content. But as usual, you also need to
have implementations that actually correctly make use of it all.

That said, I'm not particularly fond of MIME, but I guess I have
accepted by now that it's what we'll have to live with.
Post by Steven Schweda
I expect programs like Zip and UnZip (or BACKUP) to deal
properly with actual file attributes, without regard to the
file names (or other irrelevancies).
As should MIME. I think it would be a very broken MIME that tries to
interpret the contents of the message from the filename given, and not
the content-type tag.

Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: ***@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Steven Schweda
2017-01-10 22:37:39 UTC
Permalink
Raw Message
Post by Johnny Billquist
Well, I can't properly comment on the MIME implementation
in VMS programs,
You should try the VMS MIME utility. I find it slightly
better than none. Usually.
Post by Johnny Billquist
but MIME attachments as such are not identified by their
name as to how the content should be handled. MIME have a
content-type tag, that should be telling you this.
On the receiving end, yes. I was worried about the
sending end, where someone has to determine what that
Content-Type tag should be. Relying on the user to specify
/CONTENT_TYPE=whatever is one potential problem. Expecting
the receiving program to reproduce the original file
attributes based on that tag is another.

My understanding of MIME may be weak, but my impression
was that Content-Type was used primarily to determine which
program should be used to display/interpret/process the data
in an attachment, not to determine the attributes of an
extracted file containing those data.

Given the weaknesses of the existing VMS MIME utility, I
would not expect it ever to do anything about attributes of
extracted files, even if it made some sense for it to try.
Which I doubt. (Knowing nothing, I assume that it uses the C
default attributes always.)
Post by Johnny Billquist
[...] I think it would be a very broken MIME that tries to
interpret the contents of the message from the filename
given, and not the content-type tag.
The VMS MIME utility, in my opinion, might qualify, but,
as I said, I was worried about the sending end.
Post by Johnny Billquist
MIME as a technical solution, can handled any kind of
strange formats correctly, as the meta-data exists to inform
the other end of both the name, and how to interpret the
content. [...]
I claim that any reasonable collection of Content-Type
values will not be adequate to recover VMS file attributes
for arbitrary files. BACKUP and Zip+UnZip can record and
restore actual VMS file attributes, making them more suitable
than raw MIME for dealing with VMS object files and the like.
Johnny Billquist
2017-01-11 08:56:33 UTC
Permalink
Raw Message
Post by Steven Schweda
Post by Johnny Billquist
Well, I can't properly comment on the MIME implementation
in VMS programs,
You should try the VMS MIME utility. I find it slightly
better than none. Usually.
Post by Johnny Billquist
but MIME attachments as such are not identified by their
name as to how the content should be handled. MIME have a
content-type tag, that should be telling you this.
On the receiving end, yes. I was worried about the
sending end, where someone has to determine what that
Content-Type tag should be. Relying on the user to specify
/CONTENT_TYPE=whatever is one potential problem. Expecting
the receiving program to reproduce the original file
attributes based on that tag is another.
If the sending end is a VMS system, it should examine the file to figure
out an appropriate content-type tag to use.
If the sending system is not VMS, then some meta-data have already been
lost, and you are guaranteed to fail.
Post by Steven Schweda
My understanding of MIME may be weak, but my impression
was that Content-Type was used primarily to determine which
program should be used to display/interpret/process the data
in an attachment, not to determine the attributes of an
extracted file containing those data.
Since most systems are Unix or Windows, there is little more to do than
just determine what program to use, if any. For something like VMS, it
would obviously be usable for more. If you have a content-type like
binary/vms-objectfile, then you create a destination file that looks the
right for this, and (hopefully) the actual data in the attachment would
also hold some extra information to actually restore the file content in
a correct way.

If a Unix system received this, it would essentially say that it
wouldn't know what to do with it, and just offer to save the file as is.

But obviously, MIME as a format, can deal with the parts required on
this side. The actual implementations however is, in the end, what makes
the difference.
Post by Steven Schweda
Given the weaknesses of the existing VMS MIME utility, I
would not expect it ever to do anything about attributes of
extracted files, even if it made some sense for it to try.
Which I doubt. (Knowing nothing, I assume that it uses the C
default attributes always.)
You might be right. Like I said, I don't know how the actual
implementation is done.
Post by Steven Schweda
Post by Johnny Billquist
[...] I think it would be a very broken MIME that tries to
interpret the contents of the message from the filename
given, and not the content-type tag.
The VMS MIME utility, in my opinion, might qualify, but,
as I said, I was worried about the sending end.
That would be the same MIME utility then, no?
Post by Steven Schweda
Post by Johnny Billquist
MIME as a technical solution, can handled any kind of
strange formats correctly, as the meta-data exists to inform
the other end of both the name, and how to interpret the
content. [...]
I claim that any reasonable collection of Content-Type
values will not be adequate to recover VMS file attributes
for arbitrary files. BACKUP and Zip+UnZip can record and
restore actual VMS file attributes, making them more suitable
than raw MIME for dealing with VMS object files and the like.
I think I'd disagree. You could easily just create a few values for
content-type that would cover all VMS attributes.
You could, in fact, cover them all in just one attribute.
Think something like this:

binary/vmsformat; rat=...; rfm=...; rsz=...;

and so on... And then just let the actual data in the section be a raw
dump of all the disk blocks.

Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: ***@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
hb
2017-01-11 10:29:02 UTC
Permalink
Raw Message
Post by Johnny Billquist
Post by Steven Schweda
Post by Johnny Billquist
Well, I can't properly comment on the MIME implementation
in VMS programs,
You should try the VMS MIME utility. I find it slightly
better than none. Usually.
Post by Johnny Billquist
but MIME attachments as such are not identified by their
name as to how the content should be handled. MIME have a
content-type tag, that should be telling you this.
On the receiving end, yes. I was worried about the
sending end, where someone has to determine what that
Content-Type tag should be. Relying on the user to specify
/CONTENT_TYPE=whatever is one potential problem. Expecting
the receiving program to reproduce the original file
attributes based on that tag is another.
If the sending end is a VMS system, it should examine the file to figure
out an appropriate content-type tag to use.
If the sending system is not VMS, then some meta-data have already been
lost, and you are guaranteed to fail.
Post by Steven Schweda
My understanding of MIME may be weak, but my impression
was that Content-Type was used primarily to determine which
program should be used to display/interpret/process the data
in an attachment, not to determine the attributes of an
extracted file containing those data.
Since most systems are Unix or Windows, there is little more to do than
just determine what program to use, if any. For something like VMS, it
would obviously be usable for more. If you have a content-type like
binary/vms-objectfile, then you create a destination file that looks the
right for this, and (hopefully) the actual data in the attachment would
also hold some extra information to actually restore the file content in
a correct way.
If a Unix system received this, it would essentially say that it
wouldn't know what to do with it, and just offer to save the file as is.
But obviously, MIME as a format, can deal with the parts required on
this side. The actual implementations however is, in the end, what makes
the difference.
Post by Steven Schweda
Given the weaknesses of the existing VMS MIME utility, I
would not expect it ever to do anything about attributes of
extracted files, even if it made some sense for it to try.
Which I doubt. (Knowing nothing, I assume that it uses the C
default attributes always.)
You might be right. Like I said, I don't know how the actual
implementation is done.
Post by Steven Schweda
Post by Johnny Billquist
[...] I think it would be a very broken MIME that tries to
interpret the contents of the message from the filename
given, and not the content-type tag.
The VMS MIME utility, in my opinion, might qualify, but,
as I said, I was worried about the sending end.
That would be the same MIME utility then, no?
Post by Steven Schweda
Post by Johnny Billquist
MIME as a technical solution, can handled any kind of
strange formats correctly, as the meta-data exists to inform
the other end of both the name, and how to interpret the
content. [...]
I claim that any reasonable collection of Content-Type
values will not be adequate to recover VMS file attributes
for arbitrary files. BACKUP and Zip+UnZip can record and
restore actual VMS file attributes, making them more suitable
than raw MIME for dealing with VMS object files and the like.
I think I'd disagree. You could easily just create a few values for
content-type that would cover all VMS attributes.
You could, in fact, cover them all in just one attribute.
binary/vmsformat; rat=...; rfm=...; rsz=...;
and so on... And then just let the actual data in the section be a raw
dump of all the disk blocks.
Johnny
As already shown, the VMS MIME utility knows/defines a (vendor specific)
content type: "application/vms-obj" (whether it should be prefixed with
"vnd." is a different question). Adding parameters to specify the file
attributes makes more sense than my suggestion to have platform specific
subtypes, as such parameters can be used for other VMS content/files as
well. Sending the encoded file without such file attributes but with a
VMS specific subtype doesn't seem to make sense: on the receiving side
there is no difference to the (generic) subtype "octet-stream", which is
the fallback for unknown application subtypes anyway.
David Froble
2017-01-11 16:41:57 UTC
Permalink
Raw Message
Post by Johnny Billquist
Post by Steven Schweda
Post by Johnny Billquist
Well, I can't properly comment on the MIME implementation
in VMS programs,
You should try the VMS MIME utility. I find it slightly
better than none. Usually.
Post by Johnny Billquist
but MIME attachments as such are not identified by their
name as to how the content should be handled. MIME have a
content-type tag, that should be telling you this.
On the receiving end, yes. I was worried about the
sending end, where someone has to determine what that
Content-Type tag should be. Relying on the user to specify
/CONTENT_TYPE=whatever is one potential problem. Expecting
the receiving program to reproduce the original file
attributes based on that tag is another.
If the sending end is a VMS system, it should examine the file to figure
out an appropriate content-type tag to use.
If the sending system is not VMS, then some meta-data have already been
lost, and you are guaranteed to fail.
Post by Steven Schweda
My understanding of MIME may be weak, but my impression
was that Content-Type was used primarily to determine which
program should be used to display/interpret/process the data
in an attachment, not to determine the attributes of an
extracted file containing those data.
Since most systems are Unix or Windows, there is little more to do than
just determine what program to use, if any. For something like VMS, it
would obviously be usable for more. If you have a content-type like
binary/vms-objectfile, then you create a destination file that looks the
right for this, and (hopefully) the actual data in the attachment would
also hold some extra information to actually restore the file content in
a correct way.
If a Unix system received this, it would essentially say that it
wouldn't know what to do with it, and just offer to save the file as is.
But obviously, MIME as a format, can deal with the parts required on
this side. The actual implementations however is, in the end, what makes
the difference.
Post by Steven Schweda
Given the weaknesses of the existing VMS MIME utility, I
would not expect it ever to do anything about attributes of
extracted files, even if it made some sense for it to try.
Which I doubt. (Knowing nothing, I assume that it uses the C
default attributes always.)
You might be right. Like I said, I don't know how the actual
implementation is done.
Post by Steven Schweda
Post by Johnny Billquist
[...] I think it would be a very broken MIME that tries to
interpret the contents of the message from the filename
given, and not the content-type tag.
The VMS MIME utility, in my opinion, might qualify, but,
as I said, I was worried about the sending end.
That would be the same MIME utility then, no?
Post by Steven Schweda
Post by Johnny Billquist
MIME as a technical solution, can handled any kind of
strange formats correctly, as the meta-data exists to inform
the other end of both the name, and how to interpret the
content. [...]
I claim that any reasonable collection of Content-Type
values will not be adequate to recover VMS file attributes
for arbitrary files. BACKUP and Zip+UnZip can record and
restore actual VMS file attributes, making them more suitable
than raw MIME for dealing with VMS object files and the like.
I think I'd disagree. You could
You "could", but BACKUP and ZIP have it now ....
Post by Johnny Billquist
easily just create a few values for
content-type that would cover all VMS attributes.
You could, in fact, cover them all in just one attribute.
binary/vmsformat; rat=...; rfm=...; rsz=...;
and so on... And then just let the actual data in the section be a raw
dump of all the disk blocks.
Johnny
Stephen Hoffman
2017-01-09 17:58:10 UTC
Permalink
Raw Message
Post by m***@gmail.com
I'm looking for a program which converts an object file to a text file
and visa-versa. I'd like a way to be able to mail object modules to
people and it seems I need such a program to do this. So not only
would I need the program, I'd have to send it out to other people to
compile and use.
If you have such a program you're willing to part with, please contact me....
Sorry for necroing this thread.
MIME-encode the file into a blob of base-64 data and mail it.

or use the xxd tool from within the vim distribution.

Or are you looking to go from an object back to source code; for an
object disassembler?
--
Pure Personal Opinion | HoffmanLabs LLC
Loading...