DOS ain't dead

Hi,

Just a quick note - I've posted a new version of mTCP at http://www.brutman.com/mTCP .

The biggest change is a bug fix. Some packet drivers refuse to send packets less than 60 bytes in size while many older packet drivers don't care. Technically speaking, a packet less than 60 bytes in size is invalid. I have fixed the code so that all of the packets meet the minimum.

Notably it was an Intel Gigabit Ethernet packet driver that exposed this bug. I have no idea how many other packet drivers check for 'runt' packets, but this might explain problems people have had with newer PCI cards.

And yes, I am embarrassed. Special thanks to Fred Macall for reporting the bug.

There are also some small performance fixes. The next release will be more substantial.


Regards,
Mike

---
mTCP - TCP/IP apps for vintage DOS machines!
http://www.brutman.com/mTCP

> Just a quick note - I've posted a new version of mTCP at http://www.brutman.com/mTCP

Thanks

> The biggest change is a bug fix. Some packet drivers refuse to send
> packets less than 60 bytes in size while many older packet drivers don't
> care. Technically speaking, a packet less than 60 bytes in size is
> invalid. I have fixed the code so that all of the packets meet the minimum

> but this might explain problems people have had with newer PCI cards

So you fixed the bug I had and you couldn't reproduce in the past ?

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> So you fixed the bug I had and you couldn't reproduce in the past ?

I don't know if you had this bug; I didn't get enough debug information from you to reproduce it or get a clue as to what the problem might be.

Fred was very helpful with what he gave me - I was not able to reproduce it, but based on his information I was able to inspect the code for the Intel Gigabit packet driver and verify that it was throwing away runt frames.

Try the new mTCP - if it works, then you were probably getting hit by this too.


Mike

---
mTCP - TCP/IP apps for vintage DOS machines!
http://www.brutman.com/mTCP

I just posted the latest and greatest code at http://www.brutman.com/mTCP . This version finally supports IP fragments, which might help with some of the stranger network and gateway setups out there.

Another neat feature that I should have done a while ago is command line editing for FTP, including a 10 line command recall buffer. This makes FTP so much nicer to use, especially if your are prone to typing mistakes.

Testing the fragment reassembly code was more difficult than I thought it would be. It's hard to get a modern TCP server to generate fragments; they all work really hard to avoid it.

And yes, this will be open source one day - I'm working on clearing the legal hurdles. (My employer wants to clear it first.)


Enjoy,
Mike

---
mTCP - TCP/IP apps for vintage DOS machines!
http://www.brutman.com/mTCP

> And yes, this will be open source one day - I'm working on clearing the
> legal hurdles. (My employer wants to clear it first.)

Looking forward to that day. It sounds interesting.

> And yes, this will be open source one day - I'm working on clearing the
> legal hurdles. (My employer wants to clear it first.)

Heheheheheh, he's got dollar signs in his eyes. I'm not saying he's wrong (I think???), but damn, it's funny that you still have to do that for such a maligned, "dead" OS.

> > And yes, this will be open source one day - I'm working on clearing the
> > legal hurdles. (My employer wants to clear it first.)
>
> Heheheheheh, he's got dollar signs in his eyes. I'm not saying he's wrong
> (I think???), but damn, it's funny that you still have to do that for such
> a maligned, "dead" OS.

It's funnier than you can imagine. My employer is the big computer company that is known by three letters. ;-0

(It's just a blanket rule they have for any employee contributing to open source.)


Mike

---
mTCP - TCP/IP apps for vintage DOS machines!
http://www.brutman.com/mTCP

> And yes, this will be open source one day [...]

What type of license do you have in mind for this?

---
l

> > And yes, this will be open source one day [...]
>
> What type of license do you have in mind for this?

I am open to suggestions.

I have not picked a specific license for it but I suspect it will be something GPL like. I did this as a hobby to support other hobbyists so I really don't want to see it as the underpinnings of a commercial product, no matter how unlikely that is. That makes a BSD style license less likely.

The problem with any open source license (or any license in general) is enforcement. I don't have the resources to do anything if somebody doesn't want to play fair. I guess that is a problem we all face.

Of a more practical concern is having a real source code repository and being able to keep up with changes that people might want to see. I'm fairly particular about my code so I'm worried about people becoming frustrated and just not sending me patches because I'm too slow or I scrutinize the code too much.

---
mTCP - TCP/IP apps for vintage DOS machines!
http://www.brutman.com/mTCP

> I have not picked a specific license for it but I suspect it will be
> something GPL like.

In this case, please look into using the GPL v2+, v3+ or a license that allows GPL re-licensing. Copyleft (the requirement to keep the same license for derivative works) incompatible to the GPL's is a real obstacle.

LGPL (or whatever the GPLv3 equivalent is called) and maybe an even more explicit linking exception (see FSF website) would certainly aid your goals by allowing anyone to link to (ie. use) your network stack no matter their licensing.

> I did this as a hobby to support other hobbyists so I
> really don't want to see it as the underpinnings of a commercial product,
> no matter how unlikely that is. That makes a BSD style license less
> likely.

I want to give any users freedom; and when I say "any" I do literally mean "any" - including those developing software with more restrictive licenses (such as non-free or GPL software). It is unlikely someone will actually sell your program with little or no modification.

More likely would be someone using your code in building the network stack for their non-free application - but I consider that a good thing. Note that per the BSD licenses, any application build using your code would have to reproduce your copyright notices in its documentation. I think the alternatives in this case are these: either they would have coded their own network stack (probably inferior to yours), or used another one (maybe inferior), or they would not have been able to develop their application at all (even if not free, I consider that a loss), or they would incorporate your GPLed code and release their software under the GPL too. The LGPL and/or a linking exception allows users to use your code in some more cases, but isn't always sufficient.

I think you can tell my suggestion is a "BSD-style" license - specifically, I prefer the 2-clause BSD license (or "Simplified BSD license"). Some of my stuff is available in the public domain too.

I would regret a GPL release of your code, but be assured I would welcome it at the same time. Because GPL code is better than no code.

> The problem with any open source license (or any license in general) is
> enforcement. I don't have the resources to do anything if somebody doesn't
> want to play fair. I guess that is a problem we all face.

First off, I am not a lawyer, and this is not legal advice.
It appears that you can ask the FSF for help in such cases, even if you did not assign the copyright of your programs to the FSF. You're apparently free to do the latter, in which case they can do the enforcement entirely on their own if necessary. I don't know whether they would help you with enforcement of free non-GPL licenses but you're certainly free to e-mail them about that, or try reading it out of their FAQs.

> Of a more practical concern is having a real source code repository and
> being able to keep up with changes that people might want to see. I'm
> fairly particular about my code so I'm worried about people becoming
> frustrated and just not sending me patches because I'm too slow or I
> scrutinize the code too much.

I wouldn't worry about that. If it's about the hosting, make it a project on SourceForge. You have no obligation to keep up with people's request. If anyone were to get that frustrated with your code review practices, they'd probably create a fork. I don't think any of these will prove real difficulties to you.

---
l

Hi,

<rant>

> > > And yes, this will be open source one day [...]
> >
> > What type of license do you have in mind for this?
>
> I am open to suggestions.
>
> I have not picked a specific license for it but I suspect it will be
> something GPL like. I did this as a hobby to support other hobbyists so I
> really don't want to see it as the underpinnings of a commercial product,
> no matter how unlikely that is. That makes a BSD style license less
> likely.

There are at least two (semi-popular, even) programs that I know of that are "GPL" except non-commercial only. The FSF will indeed whine if you do that, though, because that's non-free to them (e.g. Red Hat or whomever can't commercially use it or patch / improve it). Similar to how even our beloved OpenWatcom is OSI approved but Debian hates it (go figure).

And yes, there are still many various commercial DOS software products out there (despite all the deprecation and incompatibilities the world throws at us / them). So it's not really THAT unlikely that somebody will sell something with your code in it. Nevertheless, I'd consider that quite rare.

In short, it sounds like you should just say something like this:

1). Don't be evil, be nice, don't hurt, maim, kill anybody or steal or make viruses, obey the ten commandments, etc.
2). Give back ALL of your changes so we can ALL enjoy a robust, working product without worrying about silly infighting, proprietary bullcrap, etc.
3). Don't use this in a commercial setting (or at least, IMHO, don't sell it outright ... using it AT a commercial site isn't the same as actively making money off of it, Joe Schmoe secretary should be able to use it too, right??)

Having said all that, I do feel like it's worrying over nothing. I like public domain just because I don't have to think about stupid things like licensing. I mean, is it just me or are licensing and legalities really really BORING???

> The problem with any open source license (or any license in general) is
> enforcement. I don't have the resources to do anything if somebody doesn't
> want to play fair. I guess that is a problem we all face.

Nobody can stop anybody else, at least not online. It could be argued that we shouldn't want to anyways. Oh, and plenty of people get really mad if you tell them what they can and can't do with their own hardware, software, etc. The whole "you pay us but we own you" mentality is still predominant everywhere. Kinda crazy. So yeah, I wouldn't worry about it. Don't worry what people do with it, it's not your blame. (Incidentally, has anyone here ever sued or been sued for faulty software??? And yet every single frickin' license whines about NO WARRANTY, etc. Seems overkill for something that no sane person would do anyways, and that's even assuming the courts are dumb enough to agree. I mean, damn, suing someone over software? You should know what you're getting into in the first place. Especially overkill for stuff that isn't mission critical. But people love their silly licenses, *sigh*.)

> Of a more practical concern is having a real source code repository and
> being able to keep up with changes that people might want to see. I'm
> fairly particular about my code so I'm worried about people becoming
> frustrated and just not sending me patches because I'm too slow or I
> scrutinize the code too much.

SourceForge???

Some projects are more closely monitored and controlled than others. Most will admit that an open repo will increase bugfixes, improvements, etc. But some have tried and still fallen by the wayside for lack of updates. (Of course, r/w repo access and licensing and popularity and management affect all this too.) So there is no guarantee.

You only need to worry about yourself (mostly), then your audience (obviously). What do they want? What do they need? What hurts you or them? And so act accordingly.

</rant> (* which I doubt anybody wanted, sorry!! *)

Reading and considering ...

The thing that I am struggling with is that I have at least several hundred hours invested in the code, and while I am willing to share the code with like minded hobbyists I am not willing to let purely commercial users benefit from the work without having to put something back into it. So for me, GPL with copyleft is an option. Or a license that explicitly prohibits linking and reselling with commercial code.

Programming is art - this is a creation. My child if you will. I want to share the joy, but it would utterly irritate me to find out somebody was making money off of the code unfairly. Using the existing apps in a commercial environment would be fine. Building and selling a product based with the code included (linked in) would not be. I've had a few inquiries in the last year, so it is a valid concern.

On the other hand, I (and the rest of us) have benefited greatly from open source of all types. And during the day, I get paid to work on open source software. So I clearly understand the value.

My cost for commercial use would be fairly modest - a postcard and a bottle of wine. ;-0

As far as enforcing the license, I'm not too worried about it. The FSF has enough to do. If somebody wants to expend the effort to hijack the code, obfuscate it and try to hide it in their product then I really can't do much about it except pray that I never have to do business with people like that.

Sourceforge is always an option, but I expect this to be a pretty low volume project. I can probably get away with just using the current web page and devoting a small part of a web forum to it. That makes me the bottleneck, but it can always go to something bigger if the need is there. As fun as this code is, it's not DOSBox, Open Watcom or anything major like that.

---
mTCP - TCP/IP apps for vintage DOS machines!
http://www.brutman.com/mTCP

The rant is fine - your philosophy on this isn't too far away from mine.

I like the general idea of 'Share and enjoy, don't be evil, and the warranty is limited to what you paid for the code'.

There are still embedded DOS applications out there running cash registers, industrial process control, etc. I've had two or three semi-serious inquiries in the past year. While I'm not totally opposed to commercial use, they should be throwing some debug, development, or whatever back into the shared pool to support what they are using. Common sense, but common sense isn't that common.


> Some projects are more closely monitored and controlled than others. Most
> will admit that an open repo will increase bugfixes, improvements, etc. But
> some have tried and still fallen by the wayside for lack of updates.
> (Of course, r/w repo access and licensing and popularity and management
> affect all this too.) So there is no guarantee.
>
> You only need to worry about yourself (mostly), then your audience
> (obviously). What do they want? What do they need? What hurts you or them?
> And so act accordingly.

I don't know my market. This might all be for nothing. ;-0


Mike

---
mTCP - TCP/IP apps for vintage DOS machines!
http://www.brutman.com/mTCP

It sounds like it's just easier for you to personally "vet" potential projects that want to use it (commercially or otherwise). In other words, don't open source it at all, but feel free to "give" free-use licenses to worthy applicants. That's the only way you'll ever have control over who uses it and what they do with it. It won't be GPL, so you'll lose a few "friends", but at least then you won't have to worry yourself at night! If you give any of it away, even only as freeware, as we've seen, people will use it any way they see fit (even commercially). Of course, why that bothers you, I don't know. (If you just want to make sure everybody knows it's "free" so that nobody will accidentally pay money to the wrong person, you could donate it publicly to FreeDOS or EDR-DOS or whomever, probably the first place(s) somebody would look for DOS software these days. FreeDOS does heavily prefer GPL, though, which doesn't forbid commercial use in any circumstances as long as the code is shared. Oh, and feel free to set up a "Donations" button on your site, but don't get your hopes up. But hey, better than nothing, right??)

Also note that I'm a networking noob, esp. in DOS, so I'm completely inept here (more than usual, heh). So I can't use it anyways. So I guess I'm unbiased enough (sorta).

N.B. I honestly don't know what you should do, what you want, etc. I hope you work it out okay. It's a difficult dilemma. (And I don't remember ever sending postcards to any authors [ADOM?], too lazy, heh, but if you really really want one from [your own?] boring ol' U.S.A, then ....)

> As fun as this code is, it's not DOSBox, Open Watcom or anything major

Ways more useful than DOG-BOX

Test:

* problems with bad performance and lost packets are still there (depends heavily from sever)
* [ESC] doesn't work to abort transfer
* commandline history sometimes displays garbage (FreeCOM has similar problems ...)
* problems with saving are still there (it should check & fix the name automatically rather than miserably fail with saving)

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> Ways more useful than DOG-BOX

I like DOSBox a lot. It gives me most of what I need for testing without the overhead of a full blown virtual machine. Have anything better to use?


> Test:
>
> * problems with bad performance and lost packets are still there (depends
> heavily from sever)

Bad performance is a side effect of lost packets. If you are losing packets you need to debug that first. I can help you with some of that, but it's not sufficient to say 'bad performance and lost packets'. A trace would be nice, and running the pktstat.com program (from the Crynwr packet driver collection) to give me statistics on packet driver reported errors would be a start. I also have a file called 'DEBUG.TXT' while gives you the two environment variables you need to collect a trace from mTCP; that would help a lot. And my email address is plastered all over the code and docs if you want to send email directly. I've still never seen a trace from you.


> * [ESC] doesn't work to abort transfer

It's not advertised as aborting a transfer, nor is it supposed to. Try Ctrl-Break. FTP.TXT says this clearly.


> * commandline history sometimes displays garbage (FreeCOM has similar
> problems ...)

I'll have to investigate this, but it's the first time I've seen or heard of this problem after two months of usage. I wrote my own code for this so it's probably not related in any way to what you are reporting with FreeCOM.


> * problems with saving are still there (it should check & fix the name
> automatically rather than miserably fail with saving)

What problems with saving? If you give it an invalid filename it fails - that's really simple. If you are giving it a valid filename and it fails then I'd like to hear about it.

In general it's a bad thing to just fix things automatically. That implies that the program knows more than it's user. It might be true in some cases though.

---
mTCP - TCP/IP apps for vintage DOS machines!
http://www.brutman.com/mTCP

> Also note that I'm a networking noob, esp. in DOS, so I'm completely inept
> here (more than usual, heh). So I can't use it anyways. So I guess I'm
> unbiased enough (sorta).

Ah, see that makes you my target audience. People who want to use networking in their applications without having to master the internals of networking. I wrote the library and I put the fanatical attention to detail in there so that the apps could do what they do best, and not worry about the networking layer.


> N.B. I honestly don't know what you should do, what you want, etc. I hope
> you work it out okay. It's a difficult dilemma. (And I don't remember ever
> sending postcards to any authors [ADOM?], too lazy, heh, but if you really
> really want one from [your own?] boring ol' U.S.A, then ....)


I think the postcard idea is neat, but definitely quirky. I don't expect a lot. Occasionally I get email about the code and those make my day, so you can see how small the user universe is.

---
mTCP - TCP/IP apps for vintage DOS machines!
http://www.brutman.com/mTCP

> Reading and considering ...

Really, considering?

> The thing that I am struggling with is that I have at least several hundred
> hours invested in the code, and while I am willing to share the code with
> like minded hobbyists I am not willing to let purely commercial users
> benefit from the work without having to put something back into it. So for
> me, GPL with copyleft is an option. Or a license that explicitly prohibits
> linking and reselling with commercial code.
>
> Programming is art - this is a creation. My child if you will. I want to
> share the joy, but it would utterly irritate me to find out somebody was
> making money off of the code unfairly. Using the existing apps in a
> commercial environment would be fine.

The GPL allows selling software. You can sell support for GPL software too, but that's not what I mean. You can sell GPL software - though only under the GPL, which means anyone who gets the program is allowed to copy it. Software written for and sold to one client can be licensed under the GPL; that client can release the software publicly or refrain from doing so.

There is no (FSF) "free" or (OSI) "open source" license that disallows all commercial usage of a program. SourceForge requires you to use an OSI-approved license.

> Building and selling a product based
> with the code included (linked in) would not be. I've had a few inquiries
> in the last year, so it is a valid concern.

This pretty much kills it for me. Your utilities are probably useful, but as developer I'm interested in a library, or re-using the network code for my stuff. It's not that I intend to sell my programs, but I don't use code licensed that restrictively. (As an aside, I'll usually not bother asking for source code if it isn't available as download.) But that's just me.

---
l

> This pretty much kills it for me. Your utilities are probably useful, but
> as developer I'm interested in a library, or re-using the network code for
> my stuff. It's not that I intend to sell my programs, but I don't use code
> licensed that restrictively. (As an aside, I'll usually not bother asking
> for source code if it isn't available as download.) But that's just me.

Ok, it kills it for you ... Duly noted.

You are making a stand on principle about not using code that has restrictions. I'm making a stand that says people should support what they use, at a minimum by contributing their changes back or by paying for the right to use it commercially. So somehow two seemingly reasonable principles are now at odds with each other. ;-0

---
mTCP - TCP/IP apps for vintage DOS machines!
http://www.brutman.com/mTCP

I don't like discussions about licenses because it mess the practical point of view. So I would like to ask if you could make some resident or loadable version of mTCP to be usable from other programming languages like Turbo pascal or QuickBasic.

Ideal solution would be:
1) in main program allocate a block in conventional memory
2) in this block load something like NETWORK.DRV
3) call functions by CALL block_adr+func_offset

---
DOS-u-akbar!

> So somehow two seemingly reasonable
> principles are now at odds with each other.

Yes.

> I don't like discussions about licenses because it mess the practical point
> of view. So I would like to ask if you could make some resident or loadable
> version of mTCP to be usable from other programming languages like Turbo
> pascal or QuickBasic.
>
> Ideal solution would be:
> 1) in main program allocate a block in conventional memory
> 2) in this block load something like NETWORK.DRV
> 3) call functions by CALL block_adr+func_offset

The TSR approach avoids the licensing problem and makes it easier to use from a variety of environments. I might do it some day but I have a few concerns about it, which is why I went with a static library:

- Code size is limited. I would have to remove my tracing support, which is a valuable debug aid. The code is pretty stable so I don't use it as much anymore, but I'm not crazy enough to remove it completely.

- Performance: you get better performance and more control when you link the code in. Not a big issue for a lot of apps looking for basic connectivity though ...


Mike

---
mTCP - TCP/IP apps for vintage DOS machines!
http://www.brutman.com/mTCP

> - Code size is limited.

It isn't.

---
l

> > - Code size is limited.
>
> It isn't.

I was presuming a COM file, which is limited to 64KB. An EXE is certainly possible, but that doesn't mean we should stop thinking about storage requirements and what else has to fit in the machine, or the size of the machine.

So yes, it is limited. Even my current apps that include the full library have a requirement to run on a 256K machine.

---
mTCP - TCP/IP apps for vintage DOS machines!
http://www.brutman.com/mTCP

I was referring to the difference between a static library and a TSR implementation. The TSR implementation does not add any size limitations. (Though of course your code might become a little larger to use far calling and such.)

---
l