I think you're right that "nobody cares" about antique code, but it's still against Forum policy. I personally don't care at all about breaking the law, and I don't care if you do, but we don't want to expose the Forum to any liability.
"Scotland Yard was trying hard,
they sent some dude with a calling card,
said do what you like but don't do it here."
'kay?
This is unfortunate, because there are some interesting questions - both about using ndisasm and decompiling code/data in general. Perhaps we could discuss using ndisasm on some arbitrary "myfile.com" that we do have the right to disassemble but don't have the source code for some reason...
One thing to keep in mind is that dos didn't care whether the name was .com or .exe, it distinguished entirely on the presence of an "MZ header" or not. If the first instructions ndisasm finds are "dec bp", "pop dx", you've got an .exe - even if it's named .com. This means that "-o 100h" won't be right, but there might be some useful information in the header. Ndisasm can't read this - or any - header. Doesn't even try... but you can...
I've never found that "automatic" or "intelligent" synchronization worked very well, but you can add manual synch points, as well as specifying areas to skip. This can result in a very long command line to ndisasm before you're done!
At one time there was a proposal to add an option to have ndisasm print (printable) ascii characters on the right. It was rejected, for reasons I don't remember. As I recall, it was just a fairly obvious "printf" statement in a fairly obvious spot, if you care to add it to your copy. This won't detect all data, of course, but it might keep you from struggling with the disassembly of "press any key"...
The overall question of separating code from data, I'm told, maps to the "halting problem" which has theoretically been proven insoluble. That doesn't mean you can't do it for some particular file, just that you can't do it for the "general case".
Agner Fog's "objconv" does a much nicer job disassembling files, but I don't think it works on 16-bit code...
If you've got questions about ndisasm, bring 'em on, and good luck with your "project".
Best,
Frank