VOGONS

Common searches


Reply 21 of 33, by jharrison

User metadata
Rank Newbie
Rank
Newbie
davidrg wrote on 2022-12-27, 22:27:
jharrison wrote on 2022-12-27, 13:03:

It's the ONLY NOS that can network these old systems with modern ones in a seamless fashion. NCP is agnostic of the transport layer and runs over IP or IPX, or anything else.

Though you've got to run NetWare 5 or newer to run NCP natively over IP and AFAIK only the windows clients supported that, though apparently its possible to get the DOS/Win16 version of Client32 to connect over IP using a few bits from the Windows 9x client. Unfortunately, Mars NWE never got IP support - either native or NetWare/IP, though I've often wondered just how hard it would be to add NetWare/IP support to it.

But NetWare is fairly off-topic on a thread about DDLINK - different tool for a different job (copying files over a LAN vs network drives). Perhaps it would be worthwhile creating a thread for discussing the merits of NetWare for vintage PC networking (something I would love to see more widely used too).

I'm sorry this is just wrong. You can run NCP over TCP/IP with Netware 3.1+, and any DOS that can run the VLM stack (MS-DOS 3) can run in this fashion. It was called the Intra-Networking client for DOS before it became integrated into the OS around, oh, 1994?. I don't know why you'd *want* to use an IP stack for this purpose, or why this particularly bugs people, but Novell gave people this option, because apparently people wanted to network low-memory systems with TCP/IP or something???

MARS NWE is bindery-only and doesn't support NDS, and isn't even worth discussing.

But NetWare is fairly off-topic on a thread about DDLINK - different tool for a different job (copying files over a LAN vs network drives). Perhaps it would be worthwhile creating a thread for discussing the merits of NetWare for vintage PC networking (something I would love to see more widely used too).

I appreciate what you're doing, and I think I stated as such a few threads up.

But I think it's only fair that I'm allowed to respond when I don't agree with your response to what I wrote. You're providing incorrect information, and then stating I shouldn't be allowed to continue in this thread because Netware is off-topic. Netware is an alternative to your software on the basis it performs the same core function, namely transferring files between two computers. That's why I believe a discussion of Netware is on-topic. One can argue the Netware approach is more complex or inelegant, but I don't think that puts you or your software above criticism on the internet when you opened yourself to this when you stared the thread.

I have your software and I'm going to give it a spin and fair shot in the same vein as I would expect from anyone else. I don't hold any animus against you or what you're doing.

Reply 22 of 33, by oso2k

User metadata
Rank Newbie
Rank
Newbie

I think Netware is off topic too.

The original post was about adding protocol documentation for a small utility that facilitates file transfer like FTP. I don’t think anyone really has anything to offer for or against your preference for Netware. It’s because you’re comparing something like FTP to something that’s a little more like a (N)OS. It is a way larger package with way more features and requirements for setup than DDLINK. It’s like comparing one’s self built bicycle bell and replying you like electric scooters because they do more.

Reply 23 of 33, by davidrg

User metadata
Rank Member
Rank
Member
jharrison wrote on 2023-01-03, 05:56:
I'm sorry this is just wrong. You can run NCP over TCP/IP with Netware 3.1+, and any DOS that can run the VLM stack (MS-DOS 3) […]
Show full quote
davidrg wrote on 2022-12-27, 22:27:
jharrison wrote on 2022-12-27, 13:03:

It's the ONLY NOS that can network these old systems with modern ones in a seamless fashion. NCP is agnostic of the transport layer and runs over IP or IPX, or anything else.

Though you've got to run NetWare 5 or newer to run NCP natively over IP and AFAIK only the windows clients supported that, though apparently its possible to get the DOS/Win16 version of Client32 to connect over IP using a few bits from the Windows 9x client. Unfortunately, Mars NWE never got IP support - either native or NetWare/IP, though I've often wondered just how hard it would be to add NetWare/IP support to it.

But NetWare is fairly off-topic on a thread about DDLINK - different tool for a different job (copying files over a LAN vs network drives). Perhaps it would be worthwhile creating a thread for discussing the merits of NetWare for vintage PC networking (something I would love to see more widely used too).

I'm sorry this is just wrong. You can run NCP over TCP/IP with Netware 3.1+, and any DOS that can run the VLM stack (MS-DOS 3) can run in this fashion. It was called the Intra-Networking client for DOS before it became integrated into the OS around, oh, 1994?. I don't know why you'd *want* to use an IP stack for this purpose, or why this particularly bugs people, but Novell gave people this option, because apparently people wanted to network low-memory systems with TCP/IP or something???

MARS NWE is bindery-only and doesn't support NDS, and isn't even worth discussing.

But NetWare is fairly off-topic on a thread about DDLINK - different tool for a different job (copying files over a LAN vs network drives). Perhaps it would be worthwhile creating a thread for discussing the merits of NetWare for vintage PC networking (something I would love to see more widely used too).

I appreciate what you're doing, and I think I stated as such a few threads up.

But I think it's only fair that I'm allowed to respond when I don't agree with your response to what I wrote. You're providing incorrect information, and then stating I shouldn't be allowed to continue in this thread because Netware is off-topic. Netware is an alternative to your software on the basis it performs the same core function, namely transferring files between two computers. That's why I believe a discussion of Netware is on-topic. One can argue the Netware approach is more complex or inelegant, but I don't think that puts you or your software above criticism on the internet when you opened yourself to this when you stared the thread.

I have your software and I'm going to give it a spin and fair shot in the same vein as I would expect from anyone else. I don't hold any animus against you or what you're doing.

I think you're probably thinking of NetWare/IP - this is the only Novell-supported way to run NetWare File & Print services over IP prior to the introduction of NetWare 5.0 in October 1998. NetWare/IP isn't a true NCP-over-IP solution, rather it encapsulates IPX packets within UDP packets and provides a pair of IP-only services (DNS and the DSS server) to replace RIP/SAP broadcasts. NetWare/IP still requires IPX plus some additional NWIP bits to be loaded on both the client and the server in order to operate - its NCP over IPX over UDP. NetWare/IP was sold and licensed separately for NetWare 3.x, made available as a free download for 4.0x/4.1, bundled with 4.11 (aka IntranetWare), made available as an unsupported download for 4.2, and does not exist in 5.0 or newer. Novell documents here that the client for DOS and 16bit Windows is an IPX only product, and this TID covers what files you have to steal from the Windows 9x client to change that.

Also, I think you've mistaken me for DaveDDS; I've not used DDLINK myself as network drives suit my purposes better though I'll probably look at DDLINK next time I need to move something over serial. The ability to bootstrap it looks rather handy!

Reply 24 of 33, by DaveDDS

User metadata
Rank Newbie
Rank
Newbie

I've spent some time determining which byte values are/are-not blocked in FreeDos: COPY COMn: file

and have adjusted my bootloader accordingly...

I just posted a new Version (1.7) of DDLINK which can "bootstrap" better with FreeDos!

Dave Dunfield ::: https://dunfield.themindfactory.com
or: "Daves Old Computers" -> Personal (near bottom)

Reply 25 of 33, by oso2k

User metadata
Rank Newbie
Rank
Newbie
DaveDDS wrote on 2023-01-03, 22:49:
I've spent some time determining which byte values are/are-not blocked in FreeDos: COPY COMn: file […]
Show full quote

I've spent some time determining which byte values are/are-not blocked in FreeDos: COPY COMn: file

and have adjusted my bootloader accordingly...

I just posted a new Version (1.7) of DDLINK which can "bootstrap" better with FreeDos!

Dave Dunfield ::: https://dunfield.themindfactory.com
or: "Daves Old Computers" -> Personal (near bottom)

Awesome!

Reply 26 of 33, by DaveDDS

User metadata
Rank Newbie
Rank
Newbie
oso2k wrote on 2023-01-03, 16:40:

The original post was about adding protocol documentation for a small utility that facilitates file transfer like FTP.

Just a note ... DDLINK is NOT FTP 😀 yeah! I said that! (-:

Keep in mind that this is a DOS program, most FTP clients I've used for DOS are simple command line tools (I'm sure there are nicer ones - but probably not in DDLINKs 15k footprint!) - heck even the "network stack" probably exceeds this!

DDLINK :
- Has a decent split screen (local and remote) file display, with file/directories selected for an operation just by moving a highlight bar with the
up/dowm keys, and system select by the right/left keys!
+ this can be local/remote (perform functions below over two systems)
+ can also be two local locations (perform functions below on local system)
- Copy file/directory tree
+ with options to copy timestamp/attributes
- Change attrributes, Rename, Erase (delete), CreateNew
- View files (text or binary)
- Manually select multiple files to perform other operations on them all-at-once
- Easily move between drives and directories
** do the above on either end (local or remote)

DDLINK uses non-routable packets , with the ends identified on the network my MAC address... no network setup at all.
You literally just "plug in" the cables, even on a network!

FTP needs TCP/IP interoperability which means DHCP config on most networks, or at it's simplest - a static IP address (which you have to keep track of for every machine on your network)! In other words some to a fair bit of "network setup" !

As I've stated before, DDLINK was created to be a very simple and straightforward way to move things between systems which have not be set up on a network,
and I do think it does this quite well - recommend you not "discount" it without at least a "look".

Dave Dunfield ::: https://dunfield.themindfactory.com
or: "Daves Old Computers" -> Personal (near bottom)

Reply 28 of 33, by DaveDDS

User metadata
Rank Newbie
Rank
Newbie

It's simple enough to download and try it - I do much of my DOS testing
these days with "real DOS" booted on DosBox - see my "DBBD" (DosBox Boot Dos)
tool!

But sure, here are a few DDLINK ScreenShots:
[1] [2] < Images in
[3] [4] < each .JPG

DDLINK1.JPG:
(1) Main screen, local" system on the left, "remote" on right.
- You can see available commands at bottom.
(2) O)ptions menu
(3) M)ulti commands
(4) Viewing a file as TEXT

DDLINK2.JPG:
(1) Viewing a file as BINARY
(2) The server end just shows a simple "log"
(3) -BootStrap 1st prompt
(4) -BootStrap 2nd prompt

Dave Dunfield - https://dunfield.themindfactory.com

Attachments

  • DDLINK2.JPG
    Filename
    DDLINK2.JPG
    File size
    157.09 KiB
    Views
    350 views
    File license
    Fair use/fair dealing exception
  • DDLINK1.JPG
    Filename
    DDLINK1.JPG
    File size
    163.48 KiB
    Views
    350 views
    File license
    Fair use/fair dealing exception

Reply 29 of 33, by DaveDDS

User metadata
Rank Newbie
Rank
Newbie
DaveDDS wrote on 2023-01-03, 22:49:

I've spent some time determining which byte values are/are-not blocked in FreeDos: COPY COMn: file
and have adjusted my bootloader accordingly...

Just in case anyone in interested:

I've looked at making the initial "boostrap" code (copied by: COPY COMn: file)
purely printable ASCII characters (0x20' '-0x7E'~') which would make it much
more likely to pass through FreeDos...

This would mean I could only use certain instances of the 8086 instructions:

AND CMP DEC INC POP PUSH SUB XOR
cond(short)JMPs {with limited positive-only offsets}

While I do think this would be doable, it would be a fair bit of work, and would
make the bootstrap code considerably larger, and given that this is transferred
with no error detection etc., I doub't it would be significantly more reliable
(and who knows - FreeDos may decide not to transfer some printable characters!)

So... Given that it currently does work with: MSDOS, PCDOS and FreeDOS
I have revised the DDLINK documentation with a section on what byte values it
needs to transfer, and how you can help me "fix" it if it doesn't work with the
particular DOS you are using!

Dave Dunfield - https://dunfield.themindfactory.com

Reply 30 of 33, by oso2k

User metadata
Rank Newbie
Rank
Newbie

Did you try mode + ctty? Have you looked at FreeCOM's copy source?

https://github.com/FDOS/freecom/blob/master/cmd/copy.c

I also posted some notes to the FreeDOS-Devel list which may have some response to what I suspect is a bug.

Reply 31 of 33, by DaveDDS

User metadata
Rank Newbie
Rank
Newbie
oso2k wrote on 2023-01-10, 00:46:

Did you try mode + ctty? Have you looked at FreeCOM's copy source?

https://github.com/FDOS/freecom/blob/master/cmd/copy.c

I also posted some notes to the FreeDOS-Devel list which may have some response to what I suspect is a bug.

I have looked at MODE and CTTY - with MS and PC DOS, the COM port defaults to 2400,n,8,1
which means MODE isn't actually required (but can help) if you want to bootstrap faster.

Once CTTY happens on the remote, DDLINK looks for the prompt., and does:

> COPY COMn: DDLBOOT.COM

It then sends the bootloader code. follower by EOF (0x1A) and at the next prompt,
it issues> DDLBOOT

At which point DDLBOOT does a good/fast/error-retry binary transfer of the
the actual DDLINK .COM image.

The "trick" is the bootloader code..
under MS/PC dos it only has to NOT contain 0x1A (which ends the transfer) all other
byte values (0x00-0x19 and 0x1B-0xFF) are copied to the file as expected.

With FreeDOS several other values are also blocked, and I redesigned the bootloader code to not
use any, however

Another problem I had along the way is that sometimes the first byte of two of the transfer
gets missed. To fix this I start the DDLBOOT.COM code with:

ORG $0100
CLD
CLD
CLD
JMP xmove
... actual bootloader code ...
xmove:
.. code to find first "JMP" then move everything past to 0x100
.. and JMP there

I was able to find a value which I could XOR "actual bootloader code"
with which avoids the byte values blocked by FreeDOS.. Then I just had to change
the code after "xmove" to NOT use any of the blocked bytes and XOR decrypt
the "actual bootloader code" as it moved it!

This works quite well and only adds a few bytes to the total bootloader size (the part
that has to be transferred without error).

Making DDLBOOT.COM "printable only" would require doing the lead-in and "xmove" code using
only very limited code... You can really use only a limited subset of certain instructions:

AAA, AAS, AND, CMP, DAA, DAS, DEC, INC, POP, PUSH, SUB, XOR
conditional(short)JMPs (only limited positive offsets)

And on top of that, not being able to "loop" (jump to a negative offset)
would require enough extra inline lead-in code at the beginning to self-modify one or more
jump targets later after xmove

Doing this would not be easy, for example MOV is not printable, the only way to load a value into
a register is something like:

; Remember all this needs to remain printable
AND AX,#$3F3F
AND AX,#$4040 ; Not AX=0
XOR AX,#$xxxx <= Set bits you want
XOR AX,#$yyyy <= Break up if you need non-printable values etc
; You can use SUB, INC, DEC to modify values (needed to get high bit etc.)
;
PUSH AX
POP register
; And do this in different registers (or memory locations) for every value you will need later...

So the "startup" code would be a LOT bigger than it is, and the "Actual bootloader"
would probably be double in size, using something like: (v1 - -v1) ^ v2
which will let you generate any possible byte value from two printable ones.

All of which has to be transferred with: COPY COMn: file
which allows no error detection/retries etc.

I ultimately decided it probably wouldn't be worth it and decided to instead
document better what the requirements are and count on others to help debug
for platforms I don't have access too.

I did somewhere along the way do a bootstrap which worked by "typing" the bootload
code into DEBUG and launching it. Didn't follow it through because it required "a standard DEBUG"
and also takes a long-time when running at the default COM speed of 2400bps.
-- Could clean it up and make it available if anyone wants --

Dave Dunfield ::: https://dunfield.themindfactory.com
or: "Daves Old Computers" -> Personal (near bottom)

Reply 32 of 33, by Jo22

User metadata
Rank l33t++
Rank
l33t++

The whole thing reminds me of CP/M and KERMIT.. :)

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 33 of 33, by DaveDDS

User metadata
Rank Newbie
Rank
Newbie

Just FYI - posted another update

Added a command line option to allow non-interactive operation (eg: transfers within .BAT)

Makes it easy to auto-move file(s) between systems as part of a "greater" operation.

Dave Dunfield ::: https://dunfield.themindfactory.com
or: "Daves Old Computers" -> Personal (near bottom)