drag&drop protocol confusing

[lpgb]

Page: https://freemint.github.io/tos.hyp/en/proto_dd.html

This line:
10+n Variable Filename (NULL-terminated)

There's only one null terminated string in the header. Unless this line implies future expansion? Perhaps it should read:

10+n Variable Filename (NULL-terminated) (for future expansion)

I interpreted this as two strings in the header and ended up having to study Atari's leaked desktop sources to figure it out.

[th-otto]

There are two strings the header, "data" and "filename". Both must be terminated with a zero byte.

[lpgb]

Atari's AES 4.1 sends one string (multitos\deskact.c). There's some discrepancy then.

[mikrosk]

Quickly looked into my ancient mxPlay code, it seems that I also handle only the ARGS type. IIRC I tested it in everything -- MagiC, N.AES, XaAES.

[lpgb]

The AES doesn't really matter. The AP_DRAGDROP message typically originates from desktops or programs.
Found a reference to -> Eric Smith: "Drag and Drop protocol, revision 1.1", ATARI Corporation 1993
Anyone have this document knocking around their hard drive?

Also from the leaked multitos sources (multitos\deskact.c) the comment at the top:
"* 921214 esmith Add new drag and drop code."

[pulsar122]

 Eric Smith: "Drag and Drop protocol, revision 1.1", ATARI Corporation 1993
Anyone have this document knocking around their hard drive?

Is not only the text is a release note:
RELEASE.TXT

I don't read the text at the moment.

Regards, Gerhard

[lpgb]

Gerhard, thanks for that doc. Although the doc says there's a 2nd null terminated string in the header, the included sample code doesn't agree, nor does AES 4.1. Now I see why various desktops are not consistent on this.

Just a theory, but maybe esmith realized the filename could be extracted from the data payload that is to follow and scrapped the 2nd null terminated string. Atari went bust the same year and the doc never gets revised. Or AES 4.1 implements version 1.0 of the protocol and there was an AES 4.2 that never saw the light of day. Who knows.

It's however hard to ignore the MultiTOS sources. I'm glad we have them.