Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to index page
Thread view  Board view
mbbrutman

Homepage

Washington, USA,
27.05.2011, 23:47
 

mTCP Open Source release (Announce)

Post reply

I've released mTCP under GPL3 - enjoy!

http://code.google.com/p/mtcp/


Regards,
Mike
ecm

Homepage E-mail

Düsseldorf, Germany,
27.05.2011, 23:58

@ mbbrutman
 

mTCP GPL

Post reply

Interesting.

Is the license GPL v3 only or does it allow to upgrade to later versions of the license?
mbbrutman

Homepage

Washington, USA,
28.05.2011, 00:20

@ ecm
 

GPLv3

Post reply

> Interesting.
>
> Is the license GPL v3 only or does it allow to upgrade to later versions of
> the license?
GPL licenses allow for upgrades to future versions of the license; that is a feature of the license.

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

Homepage E-mail

Düsseldorf, Germany,
28.05.2011, 00:55

@ mbbrutman
 

GPL: either version 3 of the license, or any later version

Post reply

> GPL licenses allow for upgrades to future versions of the license; that is
> a feature of the license.
Unless they changed that for v3 and I didn't notice, it isn't part of the license's own text. There were some issues with projects changing their licensing notices which usually read "GPL v2 or any later version" or something like that to specifically say "GPL v2" ruling out GPL v3 compatibility (because they didn't like v3).

Ah, quoting your COPYING.TXT (part of "14. Revised Versions of this License."):

> Each version is given a distinguishing version number. If the
> Program specifies that a certain numbered version of the GNU General
> Public License "or any later version" applies to it, you have the
> option of following the terms and conditions either of that numbered
> version or of any later version published by the Free Software
> Foundation. If the Program does not specify a version number of the
> GNU General Public License, you may choose any version ever published
> by the Free Software Foundation.
So while the license describes the possibility of works which can be re-licensed under later versions, you do either have to specify the "or any later version" phrasing somewhere, or you have to never mention any version at all, to allow upgrading. Therefore I would say the upgrading (still) isn't an inherent feature of the license.

I didn't find that in your documentation. For example, .\README.TXT only mentions the license file in the file list as

> COPYING.TXT The GNU General Public License, Version 3
where of course it correctly specifies that particular version because that's what the file contains. No direct statement is made about which license applies to your software.

USERDOCS\README.TXT does not appear to contain any statement on the GPL.

The other documentation files do not appear to contain any GPL statements either. (Didn't look through them in detail though.)

http://code.google.com/p/mtcp/ says "GNU GPL v3" without "or any later version".

However, I think this is all irrelevant because your source code files do appear to say (didn't check every file):

> mTCP is free software: you can redistribute it and/or modify
> it under the terms of the GNU General Public License as published by
> the Free Software Foundation, either version 3 of the License, or
> (at your option) any later version.
As far as I'm concerned, though of course I'm not a lawyer, this properly indicates that you allow the license upgrade. (Though explicit statements in the documentation pointing this out sure wouldn't hurt.)

---
l
mbbrutman

Homepage

Washington, USA,
28.05.2011, 01:09

@ ecm
 

GPL: either version 3 of the license, or any later version

Post reply

As I interpret it the text embedded within in files containing code contain the answer to the question:

mTCP is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.


Those words were taken from the Free Software Foundation "howto" on how to open source code. So while the code was released under GPL3, somebody who modifies and redistributes it can choose version 3 or a later version.

My understanding is that the documentation does not need to be GPLed explicitly. If it does I can correct that at any time. So you will find the GPL statements in the code and just one version of the license in a file that covers the entire work.

My intent isn't to get into "license" wars .. it is to share the code. I think that GPL3 does a reasonable job of ensuring that the code and modifications to it will remain free and available.


Mike

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

Homepage E-mail

Düsseldorf, Germany,
28.05.2011, 01:18

@ mbbrutman
 

GPL: either version 3 of the license, or any later version

Post reply

> As I interpret it the text embedded within in files containing code contain
> the answer to the question:
Yes, I agree.

> My understanding is that the documentation does not need to be GPLed
> explicitly. If it does I can correct that at any time.
I don't think that would be necessary. What I suggested was only to add a statement indicating the precise license/versions to the documentation so that users looking for that information can find it readily available in the documentation, instead of having to look into source code files.

> My intent isn't to get into "license" wars ..
Don't you remember our last? That was way larger than this ;-)

I don't prefer GPL (2, 3, or any later version) for what I write and that is really all there is to say on the matter of software licensing preferences right now. I only wanted to point out what I have pointed out now.

> it is to share the code.
That is understood.
mbbrutman

Homepage

Washington, USA,
28.05.2011, 01:25

@ ecm
 

GPL: either version 3 of the license, or any later version

Post reply

> Don't you remember our last? That was way larger than this ;-)
My memory is short. ;-0


> > it is to share the code.
>
> That is understood.

Then download, compile, play and enjoy ...



Mike

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

Homepage E-mail

Düsseldorf, Germany,
28.05.2011, 01:30

@ mbbrutman
 

download, compile, ...

Post reply

> My memory is short. ;-0
How fortunate for me ;-)

> Then download, compile, play and enjoy ...
I only downloaded it so far, and might in fact never compile it, but I'll probably look into how the code works and enjoy that still. Thanks for this release!
marcov

30.05.2011, 09:37

@ mbbrutman
 

GPL: either version 3 of the license, or any later version

Post reply

> My intent isn't to get into "license" wars .. it is to share the code. I
> think that GPL3 does a reasonable job of ensuring that the code and
> modifications to it will remain free and available.
Using the GPL3, the tactical nuclear weapon of licenses, is more a political statement.

For libraries, it is more ensuring that it will be unused :-)
mbbrutman

Homepage

Washington, USA,
30.05.2011, 15:32

@ marcov
 

GPL: either version 3 of the license, or any later version

Post reply

> > My intent isn't to get into "license" wars .. it is to share the code.
> I
> > think that GPL3 does a reasonable job of ensuring that the code and
> > modifications to it will remain free and available.
>
> Using the GPL3, the tactical nuclear weapon of licenses, is more a
> political statement.
>
> For libraries, it is more ensuring that it will be unused :-)

Instead of making funny little comments, please provide an example where GPL3 will be an obstacle to this code being used.

You have all of the code, including the TCP/IP code and the applications. The design of the code is such that there is no "library" - you directly compile all of the code and link it with your application. The library is not a standalone component that gets built first, so there is no obstacle to using it.

If you can show me where GPL3 makes this code unusable, do so.

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

Homepage E-mail

Düsseldorf, Germany,
30.05.2011, 16:08

@ mbbrutman
 

What does the GPL allow?

Post reply

> Instead of making funny little comments, please provide an example where
> GPL3 will be an obstacle to this code being used.
Shouldn't that be obvious? Or should the question rather be "Shouldn't you know what your license does and does not allow?"?

> The design of the code is such that there is no "library" - you directly
> compile all of the code and link it with your application.
Linking the code with the application makes the GPL apply to all code linked together therein.

It doesn't matter whether the libraries are dynamically linked (separate files at run-time), whether they are statically linked during linkage (separate static library/object files passed to linker), or whether they are already "linked" by being compiled at the same time (separate source code files but compiled to basically the same group of object files and treated like the application's source code).

The only exceptions for this are:
(a) GPL source code is allowed to be linked to non-GPL "system libraries" or some such, the exact definition can be found in the GPL's text, and
(b) source code that isn't actually licensed under the GPL, but under a modified GPL with additional linking exception. This modified GPL used to be called LGPL but I don't think it's formally called that with GPLv3.

If none of those exceptions apply then all of the application's source code must be provided under the GPL's terms. As you may have heard the GPL is incompatible with a number of other software licenses.

> The library is not a standalone component that gets built first,
> so there is no obstacle to using it.
Wrong.

---
l
mbbrutman

Homepage

Washington, USA,
30.05.2011, 16:30
(edited by mbbrutman, 30.05.2011, 16:45)

@ ecm
 

What does the GPL allow?

Post reply

> Shouldn't that be obvious? Or should the question rather be "Shouldn't you
> know what your license does and does not allow?"?
I spent quite a bit of time comparing GPL2 and GPL3. I think I know the boundaries of the licenses quite well. (Not liking my license choice does not give you the right to infer that I don't understand the license.)


> Linking the code with the application makes the GPL apply to all code
> linked together therein.
Good - that was intentional.


> It doesn't matter whether the libraries are dynamically linked (separate
> files at run-time), whether they are statically linked during linkage
> (separate static library/object files passed to linker), or whether they
> are already "linked" by being compiled at the same time (separate source
> code files but compiled to basically the same group of object files and
> treated like the application's source code).
>
> The only exceptions for this are:
> (a) GPL source code is allowed to be linked to non-GPL "system libraries"
> or some such, the exact definition can be found in the GPL's text, and
> (b) source code that isn't actually licensed under the GPL, but under a
> modified GPL with additional linking exception. This modified GPL used to
> be called LGPL but I don't think it's formally called that with GPLv3.

Understood.

> If none of those exceptions apply then all of the application's source code
> must be provided under the GPL's terms. As you may have heard the GPL is
> incompatible with a number of other software licenses.
>
> > The library is not a standalone component that gets built first,
> > so there is no obstacle to using it.
>
> Wrong.

Ok, so the obstacle is that if you use my code you have to ship it under GPL3. I don't see that as an obstacle.

If you use mTCP I want you to use GPL3. I don't want people modifying the work and distributing it without making the modifications public and under the same license that I chose. I don't see that as a bad thing.

If you or anybody else finds a case where my choice of license is blocking creativity or the release of code good code, contact me at my email address and talk to me about it. As the original developer I have the right to release that code under GPL2 as well. I'm willing to work with people to get the right license in place.

I choose GPL3 because I believe it is a better license. It never occurred to me that after dropping 30,000 lines of code in a place where it was desperately needed that I'd have people complaining about the license instead of discussing the code. We call that "looking the gift horse in the mouth".



Mike

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

Homepage E-mail

Düsseldorf, Germany,
30.05.2011, 17:08

@ mbbrutman
 

GPL something

Post reply

> I think I know the boundaries of the licenses quite well.
It didn't sound like that when I read it. Sorry for misunderstanding what you wrote.

> (Not liking my license choice does
> not give you the right to infer that I don't understand the license.)
Independent of my preferences I have the right to infer whatever I want to infer.

Whether what I infer is true or at least plausible is an entirely different matter.

Whether it appears polite or rude similarly is an entirely different matter.

> > > > For libraries, it is more ensuring that it will be unused :-)
> > >
> > > Instead of making funny little comments, please provide an example where
> > > GPL3 will be an obstacle to this code being used.
Considering this:

> > Linking the code with the application makes the GPL apply to all code
> > linked together therein.
>
> Good - that was intentional.
it should have been obvious to you that the GPL will be an obstacle in two cases:

(a) if some source code's license is incompatible to the GPL, or
(b) if someone doesn't want to tie their source code to the GPL even if possible.

Assuming you thought of both of these when considering the license, I don't understand why you asked for examples where it will be an obstacle.

> Ok, so the obstacle is that if you use my code you have to ship it under
> GPL3. I don't see that as an obstacle.
"So the X is that Y. I don't see that as an X."

Well.

I see it as an X.

More usefully: the obstacle isn't that "if I use your code I have to ship your code under GPL3" (which I personally would often be fine with), it's that "if I use your code I have to ship both your and my code under GPL3". Your statement is ambiguous here but I'll assume you knew what you meant with "it" there.

> If you use mTCP I want you to use GPL3. I don't want people modifying the
> work and distributing it without making the modifications public and under
> the same license that I chose. I don't see that as a bad thing.
Again, "it" is ambiguous. And again if "it" meant just your code I could see myself agreeing with your views a lot more.



However, let's not forget that even a GPL release allows us to read the source code, and use it in some ways. And assuming the binary-only distribution without all the GPL appendage will still be provided on your website, you obviously didn't take away any freedoms with this release. So all in all while I do not agree with your license preference and could probably talk about that forever: It is still accommodating of you to make the source code available and I'm grateful for that. (Presumably. Haven't actually used the source code for anything yet.)

---
l
mbbrutman

Homepage

Washington, USA,
30.05.2011, 18:05

@ ecm
 

GPL something

Post reply

> > I think I know the boundaries of the licenses quite well.
>
> It didn't sound like that when I read it. Sorry for misunderstanding what
> you wrote.
>
> > (Not liking my license choice does
> > not give you the right to infer that I don't understand the license.)
>
> Independent of my preferences I have the right to infer whatever I want to
> infer.
>
> Whether what I infer is true or at least plausible is an entirely different
> matter.
>
> Whether it appears polite or rude similarly is an entirely different
> matter.
In civilized society we try not to insult people unnecessarily. I believe in giving people the benefit of the doubt, and not inferring negative things unnecessarily.

> > > > > For libraries, it is more ensuring that it will be unused :-)
> > > >
> > > > Instead of making funny little comments, please provide an example
> where
> > > > GPL3 will be an obstacle to this code being used.
>
> Considering this:
>
> > > Linking the code with the application makes the GPL apply to all code
> > > linked together therein.
> >
> > Good - that was intentional.
>
> it should have been obvious to you that the GPL will be an obstacle in two
> cases:
>
> (a) if some source code's license is incompatible to the GPL, or
> (b) if someone doesn't want to tie their source code to the GPL even if
> possible.
>
> Assuming you thought of both of these when considering the license, I don't
> understand why you asked for examples where it will be an obstacle.
>
> > Ok, so the obstacle is that if you use my code you have to ship it under
> > GPL3. I don't see that as an obstacle.
>
> "So the X is that Y. I don't see that as an X."
>
> Well.
>
> I see it as an X.
>
> More usefully: the obstacle isn't that "if I use your code I have to ship
> your code under GPL3" (which I personally would often be fine with), it's
> that "if I use your code I have to ship both your and my code under GPL3".
> Your statement is ambiguous here but I'll assume you knew what you meant
> with "it" there.
Once again, I don't consider those conditions to be an obstacle. I gave away this code with this license. I am not inhibiting anybody from writing their own code. But as a condition of using this code you have to use my same license. I think that is more than fair. GPL2 is viral in many of the same ways. I've also left a provision that people who have a project in conflict with current license can contact me to discuss other licenses, so there is a safety valve that can be used.

If somebody really can't abide by this license then they are free to distribute their code (source or binaries) with a description or script that compiles mTCP and links it to their code. As long as they don't distribute the resulting binary they are in compliance with any version of the GPL. Remember, it is in the distribution of code where the GPL gets cumbersome to some people. This loophole is fairly large and should satisfy anybody - large corporations like IBM routinely use it.


> > If you use mTCP I want you to use GPL3. I don't want people modifying
> the
> > work and distributing it without making the modifications public and
> under
> > the same license that I chose. I don't see that as a bad thing.
>
> Again, "it" is ambiguous. And again if "it" meant just your code I could
> see myself agreeing with your views a lot more.
See above - you have remedies if you write some code and need a remedy.

>
>
>
> However, let's not forget that even a GPL release allows us to read the
> source code, and use it in some ways. And assuming the binary-only
> distribution without all the GPL appendage will still be provided on your
> website, you obviously didn't take away any freedoms with this release. So
> all in all while I do not agree with your license preference and could
> probably talk about that forever: It is still accommodating of you to make
> the source code available and I'm grateful for that. (Presumably. Haven't
> actually used the source code for anything yet.)
I think that being able to see the code, modify it for personal use, and use it in the context of other GPL3 code as a very good thing.

You are reacting to the choice of license as though I have restricted you from doing something reasonable. In the absence of any code that you actually want to use mTCP with, I'd refrain from worrying about it. Let us cross that bridge when we come upon it.

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

Homepage E-mail

Düsseldorf, Germany,
30.05.2011, 18:28

@ mbbrutman
 

theoretical licensing problems and such

Post reply

> In civilized society we try not to insult people unnecessarily.
I wasn't addressing that; as I said, entirely different matter. What I addressed was my right to say something like that. Consequences and all, of course.

(Off-topic: And do you imply I am, or might be, uncivilized? Ha! That could almost be taken as an insult. (I don't actually care.))

> I believe
> in giving people the benefit of the doubt, and not inferring negative
> things unnecessarily.
I got that. I think I explained my wrong impression of what you wrote.

> GPL2 is viral in many of the same ways.
(Off-topic right now. I don't actually care about the GPLv2 vs. GPLv3 incompatibilities that much, I was just pointing that out earlier.)

> Once again, I don't consider those conditions to be an obstacle.
I understood that.

> I gave away this code with this license.
Yes. Did I thank you for that already?

> I am not inhibiting anybody from writing their own code.
No one stated you were.

> But as a condition of using this code you have to use my
> same license. I think that is more than fair.
You made your position clear.

> I've also left a provision that people who have a project
> in conflict with current license can contact me to discuss other licenses,
> so there is a safety valve that can be used.
(Yes, but it's inherently tied to contacting you. While that's good-willed, this won't always be possible. That's an entirely different can of worms though. (Read: off-topic.))

> If somebody really can't abide by this license then they are free to
> distribute their code (source or binaries) with a description or script
> that compiles mTCP and links it to their code. As long as they don't
> distribute the resulting binary they are in compliance with any
> version of the GPL. Remember, it is in the distribution of code where the
> GPL gets cumbersome to some people. This loophole is fairly large and
> should satisfy anybody - large corporations like IBM routinely use it.
You are right.

> > Again, "it" is ambiguous. And again if "it" meant just your code I could
> > see myself agreeing with your views a lot more.
>
> See above - you have remedies if you write some code and need a remedy.
Sorry, I like theorizing about remedies for theoretical problems. Be it software programming or software licensing problems.

> I think that being able to see the code, modify it for personal use, and
> use it in the context of other GPL3 code as a very good thing.
That is what I said. Source code under GPL is better than no source code. See, I agree with you.

> You are reacting to the choice of license as though I have restricted you
> from doing something reasonable.
Not at all, you're perceiving this wrongly. I am reacting to the choice of license as though I would have preferred another choice but am still grateful for what you offer now.

> In the absence of any code that you
> actually want to use mTCP with, I'd refrain from worrying about it. Let us
> cross that bridge when we come upon it.
Right, I should do that! I won't bother you about your software's licenses any more unless there's immediate need.
ecm

Homepage E-mail

Düsseldorf, Germany,
30.05.2011, 22:34

@ mbbrutman
 

licensing again... executables

Post reply

> > And assuming the binary-only distribution without all the GPL
> > appendage will still be provided on your website, you obviously
> > didn't take away any freedoms with this release.
> ... as though I have restricted ...
http://www.brutman.com/mTCP/ now directs one to http://code.google.com/p/mtcp/downloads/detail?name=mTCP_2011-05-30.zip&can=2&q= to download the executables. This says the programs are now licensed under the GPL in its readme and includes the GPL file. That's alright.

I do not want to cause any offence with this simple question. However you did not specifically address this point so I want to ask you: This appears to mean you do not provide non-GPL executables any longer. Is that intentional?

(Note that this isn't related to source code licensing directly; the question in itself just refers to what I'm allowed to do with the executables as "user".)
mbbrutman

Homepage

Washington, USA,
31.05.2011, 03:33

@ ecm
 

licensing again... executables

Post reply

> > > And assuming the binary-only distribution without all the GPL
> > > appendage will still be provided on your website, you obviously
> > > didn't take away any freedoms with this release.
>
> > ... as though I have restricted ...
>
> http://www.brutman.com/mTCP/ now directs one to
> http://code.google.com/p/mtcp/downloads/detail?name=mTCP_2011-05-30.zip&can=2&q=
> to download the executables. This says the programs are now licensed under
> the GPL in its readme and includes the GPL file. That's alright.
>
> I do not want to cause any offence with this simple question. However you
> did not specifically address this point so I want to ask you: This appears
> to mean you do not provide non-GPL executables any longer. Is that
> intentional?
>
> (Note that this isn't related to source code licensing directly; the
> question in itself just refers to what I'm allowed to do with the
> executables as "user".)

I'm not sure I understand the question. The GPL does not prohibit you from doing anything you were doing last week.

You can't link against the current executables. None of them have a plug-in architecture that might allow you to run your own code within them. And you can't modify the binaries in a meaningful way, so there is no worry about contributing your changes back under GPLv3.

As far as I know and am concerned, noting that the binaries come from an open source code base just tells you where to find the source code and how the source code is distributed. If you choose to redistribute the binaries you may do so, but the license and the other files should go along with the distribution.

Were you thinking that GPL somehow alters the way you can use the binaries?

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

Homepage E-mail

Düsseldorf, Germany,
31.05.2011, 13:59

@ mbbrutman
 

licensing again... executables

Post reply

> The GPL does not prohibit you from doing anything you were doing last week.
Please refer to the GPL(v3)'s section 6, "Conveying Non-Source Forms". I believe that your previous executable-only releases granted users more freedoms (as long as they were not interested in the source code).

> As far as I know and am concerned, noting that the binaries come from an
> open source code base just tells you where to find the source code and how
> the source code is distributed. If you choose to redistribute the binaries
> you may do so, but the license and the other files should go along with the
> distribution.
See above. The GPL does affect the redistribution of binaries. If I choose to redistribute your GPL binaries I have to comply with the GPL, specifically section 6.

> Were you thinking that GPL somehow alters the way you can use the binaries?
To be exact, no, that's just fine. The GPL allows unrestricted usage of binaries, and source code at that. (As usual, only redistribution is restricted.)

---
l
mbbrutman

Homepage

Washington, USA,
01.06.2011, 01:16

@ ecm
 

licensing again... executables

Post reply

> > Were you thinking that GPL somehow alters the way you can use the
> binaries?
>
> To be exact, no, that's just fine. The GPL allows unrestricted usage
> of binaries, and source code at that. (As usual, only redistribution is
> restricted.)
Were you planning on redistributing the binaries in a way that is not allowed by the GPL? Have you been redistributing the older binaries and has the change to GPL caused some harm?

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

Homepage E-mail

Düsseldorf, Germany,
01.06.2011, 01:53

@ mbbrutman
 

licensing again... executables

Post reply

> Were you planning on redistributing the binaries in a way that is not
> allowed by the GPL?
Not specifically planning, but it's definitively more convenient if you can just pass binaries along like that.

> has the change to GPL caused some harm?
The redistribution terms for your binaries are now more restricted than previously.
mbbrutman

Homepage

Washington, USA,
01.06.2011, 02:17

@ ecm
 

licensing again... executables

Post reply

> > has the change to GPL caused some harm?
>
> The redistribution terms for your binaries are now more restricted than
> previously.
Understood. But how exactly is this additional restriction affecting you?

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

Homepage E-mail

Düsseldorf, Germany,
01.06.2011, 15:49

@ mbbrutman
 

licensing again... executables

Post reply

> > > has the change to GPL caused some harm?
> >
> > The redistribution terms for your binaries are now more restricted than
> > previously.
>
> Understood. But how exactly is this additional restriction affecting you?
So you appear to say it is intentional. No, my question wasn't about whether you'd make the binaries available like before, it was about whether this change was indeed intentional.
Rugxulo

Homepage

Usono,
30.05.2011, 18:14

@ mbbrutman
 

What does the GPL allow?

Post reply

> I choose GPL3 because I believe it is a better license. It never occurred
> to me that after dropping 30,000 lines of code in a place where it was
> desperately needed that I'd have people complaining about the license
> instead of discussing the code. We call that "looking the gift horse in
> the mouth".
It's fine, I'm sure. I've seen plenty of projects use GPLv3 (e.g. Desktop Cyber emulator, not that I've tried it or anything, heh). In fact, GNU/FSF pretty much upgraded everything of theirs to use it (GCC, sed, etc). There are still way more GPLv2 users, though, which is by far the #1 choice (don't ask me why), approx. 50% of the "open source" market. I know BSD and Apple dislike v3 (and thus stick to GCC 4.2.1 or older), but otherwise there's no clear consensus.

Actually, the weird part is the difference between "v2 or later" and "v2 only" (Linux kernel), and similar incompatibilities. And my vague memory (since I don't "enjoy" pretending to read boring licenses, nor am I legally inclined or skilled) says that v3 only fixed some loopholes (and incorporated LGPL), e.g. MS patent licenses w/ Novell and TiVo-ization.

Anyways, enough of this, who cares, thanks for your work! :ok: (Now if only I can figure out how to get it working under DOSEMU, heh, am I crazy for wanting that?)
ecm

Homepage E-mail

Düsseldorf, Germany,
30.05.2011, 22:38

@ Rugxulo
 

mTCP in DOSEMU; Linux kernel developers' GPLv2-only reasons

Post reply

> Actually, the weird part is the difference between "v2 or later" and "v2
> only" (Linux kernel), and similar incompatibilities. And my vague memory
> (since I don't "enjoy" pretending to read boring licenses, nor am I legally
> inclined or skilled) says that v3 only fixed some loopholes (and
> incorporated LGPL), e.g. MS patent licenses w/ Novell and TiVo-ization.
This appears relevant, although it refers to one of the v3 drafts: http://lwn.net/Articles/200422/

> Now if only I can figure out how to get it working under DOSEMU, heh
If mTCP even works in DOSBox then you should be able to get it to work in DOSEMU.

---
l
marcov

30.05.2011, 22:49

@ Rugxulo
 

What does the GPL allow?

Post reply

> I know BSD and Apple dislike v3 (and thus stick to GCC 4.2.1 or older), >
> but otherwise there's no clear consensus.
The next release, FreeBSD 9.0 is going to be LLVM based, with the core distribution being GPLv3 free. The older versions are indeed stuck on pre GPLv3.

The other BSDs are studying and sympathetic about FreeBSD's move, and are looking at it (but afaik haven't made a decision. Which is funny, I always had OpenBSD pegged as the first to make the move)

> inclined or skilled) says that v3 only fixed some loopholes (and
> incorporated LGPL), e.g. MS patent licenses w/ Novell and TiVo-ization.
Both seriously impact employment of open source oriented professionals, that are mostly employed by hardware manufacturers or the Googles of this world.

So many believe it will hurt open source adoptation (and its financing, since contrary to popular belief, most is done by people on big business' payrol), more than it ever will solve. But it is a matter of principle for the FSF.
mbbrutman

Homepage

Washington, USA,
31.05.2011, 03:41

@ marcov
 

What does the GPL allow?

Post reply

> Both seriously impact employment of open source oriented professionals,
> that are mostly employed by hardware manufacturers or the Googles of this
> world.
>
> So many believe it will hurt open source adoptation (and its financing,
> since contrary to popular belief, most is done by people on big business'
> payrol), more than it ever will solve. But it is a matter of principle for
> the FSF.
My previous employer did not seem too upset by GPL3, and they paid me to do open source software development. (And they are one of the biggest contributors to open source.) You can get around almost any licensing requirement by using patch sets and providing instructions with build scripts.

I started with GPL3 because of the "Tivoization" argument. I also evaluated my code in the context of the license - I don't think that I'm doing anybody any serious harm by having mTCP released under GPL v3, as the code is probably not commercially interesting. If there is a sudden resurgence in interest in DOS TCP/IP for non-hobbyist purposes I will be incredibly surprised. In that context I don't think that the GPL2 vs. GPL3 decision should be making anybody upset and I'm really surprised at how much attention this has drawn.

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

Homepage

Washington, USA,
31.05.2011, 04:18

@ Rugxulo
 

What does the GPL allow?

Post reply

> Anyways, enough of this, who cares, thanks for your work! :ok: (Now if only
> I can figure out how to get it working under DOSEMU, heh, am I crazy for
> wanting that?)
The state of the DOSEMU documentation leaves a little bit to be desired, but I see two paths:

[1] Dedicate a network card to DOSEMU. This works today in the stable release. (Documented in chapter 2 of the docs.)

[2] Use the developers release; it looks like DOSEMU can be set to emulate a packet driver. Instead of loading a packet driver in your DOS session to talk to an emulated network card this technique cuts out the emulation of the hardware and just provides the packet driver interface already built in. (Documented in chapter 15 of the docs.)


I'm not sure how stable option 2 is, but that is a promising approach. My Linux machine is woefully out of date otherwise I'd try it out.

I routinely run under DOSBox under Windows. DOSBox doesn't support networking directly, but there is a custom build of it that has NE2000 emulation. Look for the HAL-9000 "Megabuild".


Mike

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

Homepage

Germany (South),
30.05.2011, 18:47

@ mbbrutman
 

What does the GPL allow?

Post reply

> If you use mTCP I want you to use GPL3. I don't want people modifying the
> work and distributing it without making the modifications public and under
> the same license that I chose. I don't see that as a bad thing.
I fully agree.

> I choose GPL3 because I believe it is a better license. It never occurred
> to me that after dropping 30,000 lines of code in a place where it was
> desperately needed that I'd have people complaining about the license
> instead of discussing the code. We call that "looking the gift horse in
> the mouth".
Mike, don't let yourself discourage by the board's trolls. :-P

Thanks for sharing!

---
MS-DOS forever!
ecm

Homepage E-mail

Düsseldorf, Germany,
30.05.2011, 19:20

@ Japheth
 

Gift trolls and other curiosities

Post reply

> > I choose GPL3 because I believe it is a better license. It never
> occurred
> > to me that after dropping 30,000 lines of code in a place where it was
> > desperately needed that I'd have people complaining about the license
> > instead of discussing the code. We call that "looking the gift horse in
> > the mouth".
>
> Mike, don't let yourself discourage by the board's trolls. :-P

Yep, it's us Bunch of Trolls That Ruin ;-)

Mike edited in the part about the gift horses. However, the troll would like to complain that (a) the troll doesn't complain, and (b) the troll appreciates the gift horse very much either way.
mbbrutman

Homepage

Washington, USA,
30.05.2011, 19:54

@ ecm
 

Gift trolls and other curiosities

Post reply

> > > I choose GPL3 because I believe it is a better license. It never
> > occurred
> > > to me that after dropping 30,000 lines of code in a place where it was
> > > desperately needed that I'd have people complaining about the license
> > > instead of discussing the code. We call that "looking the gift horse
> in
> > > the mouth".
> >
> > Mike, don't let yourself discourage by the board's trolls. :-P
>
> Yep, it's us Bunch of Trolls That Ruin ;-)
>
> Mike edited in the part about the gift horses. However, the troll would
> like to complain that (a) the troll doesn't complain, and (b) the troll
> appreciates the gift horse very much either way.
And just for the record, the last two paragraphs (I think) of that post were added by the edit within 2 or 3 minutes of the post and before anybody else appended to the thread. (I don't want the illusion of bad behavior via editing.)

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

Homepage E-mail

Düsseldorf, Germany,
30.05.2011, 20:03

@ mbbrutman
 

editing

Post reply

Ah! Either I already read and quoted your post before you made that edit then, or I must have skipped that part. I'm sorry if the latter is true.
marcov

30.05.2011, 22:38
(edited by marcov, 30.05.2011, 22:50)

@ mbbrutman
 

What does the GPL allow?

Post reply

> Ok, so the obstacle is that if you use my code you have to ship it under
> GPL3. I don't see that as an obstacle.
An intentional obstacle is still an obstacle.

If you want to use the GPL (and worse, v3), fine. But don't pretend it is a minor thing, since it isn't.
marcov

30.05.2011, 22:37

@ ecm
 

What does the GPL allow?

Post reply

> (b) source code that isn't actually licensed under the GPL, but under a
> modified GPL with additional linking exception. This modified GPL used to
> be called LGPL but I don't think it's formally called that with GPLv3.
There are various GPL exceptions. Since LGPL has its own name now, GPL modified is usually used for something like LGPL, but without the mandatory dynamic linking requirement.

Typically used for libgcc and similar base libraries.
marcov

30.05.2011, 22:35

@ mbbrutman
 

GPL: either version 3 of the license, or any later version

Post reply

>
>
> Instead of making funny little comments, please provide an example where
> GPL3 will be an obstacle to this code being used.
1) If you don't want or can put your own code under the GPL3, or one of the few compatible licenses.

2) If you get that close even, for instance when your employer won't even entertain the idea of GPL.
mbbrutman

Homepage

Washington, USA,
30.05.2011, 22:56

@ marcov
 

GPL: either version 3 of the license, or any later version

Post reply

> >
> >
> > Instead of making funny little comments, please provide an example where
> > GPL3 will be an obstacle to this code being used.
>
> 1) If you don't want or can put your own code under the GPL3, or one of the
> few compatible licenses.
>
> 2) If you get that close even, for instance when your employer won't even
> entertain the idea of GPL.

The solution to both problems was presented earlier - if you or your employer are opposed to the GPL then don't distribute the code that you produce. You can do whatever you want to in private. The GPL is just setting the rules for distribution.

In the case where you have to distribute to somebody else (a customer?) then deliver the source code of your code and instructions on how to build it and link it with the mTCP code. If those steps are performed by your end customer then you have not distributed any code and are in compliance with any license. Large corporations routinely work with open source in this way.

I released the code for use by other hobbyists. If your employer has a problem with the licensing, then they are free to convince me to use another license by supporting my hobby in some tangible way. ;-)

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

02.06.2011, 16:10
(edited by marcov, 02.06.2011, 20:41)

@ mbbrutman
 

GPL: either version 3 of the license, or any later version

Post reply

(snip GPL explanation for dummies)

> I released the code for use by other hobbyists. If your employer has a
> problem with the licensing, then they are free to convince me to use
> another license by supporting my hobby in some tangible way. ;-)
I merely reacted to the "avoidance of license wars" and choice for GPLv3, something that I saw as a contradiction.

My employer, nor I have the intention to use your stack. All my comments must be seen in a general fashion, and not specific to this package.

The only minor remark left to make is that one mustn't confuse the flirtation of a few big IT giants with employers in general. Most haven't heard of the GPL, and when shown the text run for the hills.

Regardless if you agree with the GPL principles (and explanation) or not, as a programmer having to get borrowing code is such an hassle, it is usually worthwhile to simply rewrite GPLed code rather than trying to get permission. I have been in such situation with past employers (the current one couldn't care less).

Apparantly you think that some excessive protection using the GPLv3 is more important than some programmer here and there working with it and submitting fixes. That is the only thing I wanted to point out in the first place.

If that is intentional, so be it. For the rest I can say that I wish you all the best, and I hope that this form of licensing will forfill your expectation, whatever those are

Oh, and I'm not an anti GPL bigot. I couldn't be, since I spend the last 14 years working on one :-)
mbbrutman

Homepage

Washington, USA,
03.06.2011, 04:12

@ marcov
 

GPL: either version 3 of the license, or any later version

Post reply

Marcov,

I look at GPL3 as the latest version of one of the best open source licenses. I generally agree with the philosophy that if you pick something up for free and make it better, then you should contribute back. I think we are in a bad state when we need a license to mandate good behavior - in the end it really doesn't matter because I can't detect somebody violating the license nor do I have the means to enforce the license even if I can detect a violation.

I am inclined to think that if the only thing that might make somebody submit a fix is the license terms then that person was not going to submit a fix in the first place. And by the same reasoning, there will be people who submit fixes no matter what the license is.

In short, you can't legislate good behavior. So I chose the license that I thought matched my coding ethic and the needs of the project. GPLv3 has been heavily reviewed. Despite what people think of RMS, I think legally it is sound and the spirit of share and enjoy is preserved in it.

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

03.06.2011, 13:36
(edited by marcov, 03.06.2011, 14:08)

@ mbbrutman
 

GPL: either version 3 of the license, or any later version

Post reply

> I look at GPL3 as the latest version of one of the best open source
> licenses. I generally agree with the philosophy that if you pick
> something
We roughly agree, specially on the bit that forcing people to do the morally good thing is hard.

And that brings us to the force bit, and the place where we differ. IMHO the GPL should only be applied in special, strategic cases, and in most common cases the force bit hurts more than it helps, while your position could be summoned up as "force, just in case"

And I already described one prime example of that pain: getting usage of the GPL approved in corporate hierarchies outside the handful of IT multinationals. Even if the planned usage would be completely in line with the license.

The GPLv3 worsens this, it tries to screw an handful vendors out of some minor customization and scripts. (and usually these are not the smartest ones, since otherwise they wouldn't get caught.

On the flip side however, people using the GPLv3 only internally might have to rework their infrastructure if something tied to a GPLed part suddenly faces outwards. And decide to avoid the GPLv3 all together, IMHO rightfully so.

It does finely continue the GPL tradition of preparing for the worse though, damn the consequences :-)

It caused the BSDs to defect (they halted upgrading of GNU software in base, and stick to the GPLv2 while they work frantically on deGNUifying base), and the Linux kernel to change its base license to GPLv2 only.

And I really wonder if whatever v3 brings is worth carving up the united OSS front.

P.s.

I found an old document I wrote that discusses the "force" argument a bit, as part of a very old BSD vs GPL discussion:

http://www.stack.nl/~marcov/bsdvslgpl.txt

note that these were quickly written down bulletpoints for what was going to be the finishing sheet(s) of a lecture, and it is deliberately put very crude and argumentative to provoke discussion after the lecture. Don't worry, my own opinions are slightly more nuanced (the biggest flaw is heaping LGPL and GPL together) :-)
Rugxulo

Homepage

Usono,
03.06.2011, 16:45

@ marcov
 

GPL: either version 3 of the license, or any later version

Post reply

> > I look at GPL3 as the latest version of one of the best open source
> > licenses. I generally agree with the philosophy that if you pick
> > something
>
> We roughly agree, specially on the bit that forcing people to do the
> morally good thing is hard.
Here's what I don't understand: how can you force anybody to do anything? Especially legally, how can you force somebody to share changes? Or force somebody not to reverse engineer? Etc. etc. It seems legalistic people are obsessed with forcing other people to do things. It's an annoyingly confusing idea. I'm all for sharing code, very much so, but "forcing" somebody just seems odd. I just can't imagine that ever working (though it does, rarely, which is weird).

But we all agree that open source is better than buggy, abandoned, proprietary, expensive software.

> And that brings us to the force bit, and the place where we differ. IMHO
> the GPL should only be applied in special, strategic cases, and in most
> common cases the force bit hurts more than it helps, while your position
> could be summoned up as "force, just in case"
GPL is heavily tied to Linux and FSF and *nix-centric philosophy. As such, their code barely works (if even) on non-POSIX systems. And for things like GCC, making modifications is difficult because it's so complex (and mirroring sources is huge). So that's all a pain.

> And I already described one prime example of that pain: getting usage of
> the GPL approved in corporate hierarchies outside the handful of IT
> multinationals. Even if the planned usage would be completely in line with
> the license.
"Want" isn't as important as "need". The only reasons to complain about GPL is if it literally cannot be used, i.e. when it's out of your control. If you want to use DUGL with paq8o8 (I don't, it's just an imaginary example), you can't because it's disallowed. Just preferring something else isn't a real reason.

But yeah, *BSD (or MIT, Apache, ZLIB) is simpler. I mean, GPL is very very verbose and legalistic. And nobody reads the damn thing anyways (else all billion forced-included copies of COPYING would say "51 Franklin St." instead of old obsolete snail mail addresses that nobody writes to anymore anyways).

> The GPLv3 worsens this, it tries to screw an handful vendors out of some
> minor customization and scripts. (and usually these are not the smartest
> ones, since otherwise they wouldn't get caught.
It doesn't actively screw anyone, AFAICT, but it does whine against TiVoization (which I think is pretty rare) as well as patents (losing battle, they're not going anywhere). I think most corporations are honestly afraid that they will have to give up some or even all of their patents (software or otherwise) if they ever redistribute GPLv3 software. I don't see how that could happen, but fear makes people do crazy things.

And of course the biggest open source juggernauts come from FSF / GNU, e.g. Emacs and especially GCC, so they have a lot of political sway just out of practicality because everybody and their brother uses some of their software (except Microsoft).

> On the flip side however, people using the GPLv3 only internally might have
> to rework their infrastructure if something tied to a GPLed part suddenly
> faces outwards. And decide to avoid the GPLv3 all together, IMHO rightfully
> so.
I really don't see much difference between v2 and v3. I mean, there's nothing shocking in there. Patents are the only thing, and it makes perfect sense not to disingenuously let someone use software just to later sue them for patents. I mean, it's really annoying how everybody sues everybody else. Sharing code and fixing bugs, getting things done, etc. is good, but legalities suck.

> It does finely continue the GPL tradition of preparing for the worse
> though, damn the consequences :-)
They have a lot of sway. GPLv2 is by far the most popular open source license, and Linux is by far the most (over)hyped open source OS. It's almost impossible not to deal with it somehow.

> It caused the BSDs to defect (they halted upgrading of GNU software in
> base, and stick to the GPLv2 while they work frantically on deGNUifying
> base), and the Linux kernel to change its base license to GPLv2 only.
The *BSDs are weird. Well, honestly, everybody thinking from a purely political licensing standpoint comes across as weird. It's people like Linus himself who take a more pragmatic approach, which is more reasonable. I mean, it's not like I love proprietary software either, but hey, some free software zealots can really cut off their own nose to spite their face. I mean, when you start rejecting perfectly working software because "our free is more free than your free", you've missed the point, IMHO. That seems to be all too common these days, sadly. (And when your wifi doesn't work because the firmware ain't included and you can't download it, you'll wish somebody included it anyways, free or not.)

> And I really wonder if whatever v3 brings is worth carving up the united
> OSS front.
Note that they didn't intentionally do this. In fact, I would say they need to be more careful next time because of it. *BSD is smaller than Linux but still important. A working consensus is almost always better than a purely idealogical standpoint anyday.

If it were up to me, I'd add a few more ideas to the (already confused pot):

1). You don't have to mirror (big!) sources if they're already mirrored in 10 other places.
2). You don't have to include "COPYING" anymore, everybody already has it (not that they care).
3). It's needs to be a lot shorter in length, nobody's going to read 30 kb of text in one sitting.
4). It needs to deal with the whole "or later" issue. The fact that some projects are "v2 only" while others are "v2 or later" is insane, IMHO.
5). It needs to take a stand on whether GPL software built with non-free tools is "free" or not (e.g. FreeDOS kernel). I would say yes, but clearly Debian and Fedora disagree.
6). Patents suck, but they aren't going away. It needs to be more careful to say, "Only relevant patents to this particular software apply here. Just don't sue us over any accidental overlaps here, okay? All others are irrelevant in this instance." In other words, make sure to clarify that it doesn't automatically import all your patent portfolio to /dev/null by just redistributing this.

> P.s.
>
> I found an old document I wrote that discusses the "force" argument a bit,
> as part of a very old BSD vs GPL discussion:
>
> http://www.stack.nl/~marcov/bsdvslgpl.txt
Shared libs? (sigh) I don't know why nobody can agree on whether it counts or not. But my understanding of that is fuzzy.

Yes, BSD is easier, but it's really true that without GPL, a lot of hoarding and subsequent "fork / close / sell" attempts would be made. I've seen it happen.

Honestly, I just hate licensing, it just always gets in the way and impedes real progress. It's just such a pain. People would rather argue for years over licensing rather than actually write or patch real software. I hate licensing! It's so useless and destructive. (And BTW, software patents aren't so great either. How can you sue somebody for "accidentally" violating something? Ridiculous.)

> note that these were quickly written down bulletpoints for what was going
> to be the finishing sheet(s) of a lecture, and it is deliberately put very
> crude and argumentative to provoke discussion after the lecture. Don't
> worry, my own opinions are slightly more nuanced (the biggest flaw is
> heaping LGPL and GPL together) :-)
Open sourcing or abandonware never happens. So much software is literally lost to the ages because it literally dies on the rack because nobody mirrored it, nobody cleared the copyright, or else nobody wanted to share it, even though it's no longer sold. I hate that. That's another advantage of GPL, at least (in theory) the software will live on.

Submitting fixes is fine in theory, but upstream is often VERY picky about what they will accept anyways, and they don't like certain platforms (ahem).

The real enemy of GPL (besides selfishness) seems to be that people are just too lazy to bother. BSD is a bit worse in that regard, they don't feel like it's their responsibility. Hence GPL carries more responsibility due to its demands.

In theory, you would think BSD would be more fruitful or more widely accepted, but it doesn't appear to be, surprisingly. GPL is far more popular. It seems that people genuinely don't want their code to be pilfered to closed source (though I don't think most people would bother trying that anyways), plus GPL is (incorrectly) often assumed to be a good way to keep people from making money off it (heavily reduces the incentive to almost nothing). GPL is often equated with "non-commercial only", which is wrong but still implied.

In reality, like I said, all this licensing talk sometimes puts people off. I'm mostly agnostic (out of pragmatism, you can't defeat the world, you have to sometimes go with the flow), but I'd honestly prefer the simplest possible, or even nothing ("public domain").

I mean, at the end of the day, who cares? If you just want to get the job done, why would licensing matter at all?
Japheth

Homepage

Germany (South),
31.05.2011, 09:03

@ mbbrutman
 

mTCP and SwsVPkt

Post reply

FYI: I just tried mTCP with SwsVPkt in a Windows XP NTVDM "DOS box". It works - at least I was able to use DHCP.EXE, PING.EXE and FTP.EXE ( connect, directory listing and to download a file from ftp.openwatcom.com worked; with ftp.microsoft.com, the directory listing failed for some reason ).

Since mTCP runs natively in NTVDM, it might be a preferable option ( compared to run it in DOSBox/Qemu/VMware ) - but I didn't do any benchmarks so far.

---
MS-DOS forever!
mbbrutman

Homepage

Washington, USA,
01.06.2011, 03:11

@ Japheth
 

mTCP and SwsVPkt

Post reply

> FYI: I just tried mTCP with SwsVPkt in a Windows XP NTVDM "DOS box". It
> works - at least I was able to use DHCP.EXE, PING.EXE and FTP.EXE (
> connect, directory listing and to download a file from ftp.openwatcom.com
> worked; with ftp.microsoft.com, the directory listing failed for some
> reason ).
>
> Since mTCP runs natively in NTVDM, it might be a preferable option (
> compared to run it in DOSBox/Qemu/VMware ) - but I didn't do any benchmarks
> so far.
I just tried SwsVPkt for the first time - I was unaware that it existed. It seems to work as advertised, at least from a functional standpoint. I'm still in shock that my DOS programs are running natively in a Windows XP DOS Box.

DHCP has a slight problem. I believe that SwsVPkt is passing packets out directly on the specified interface. My router gave my DOS Box the same IP addr that is assigned to the host operating system, which is correct - that MAC address already has an IP address. A unique IP address would avoid conflicts like the one I just experienced - the IRC network that I connected to was not happy that I had two connections from the same machine. ;-0

I'm going to play around with this some more to try to break it .. if it doesn't break easily then I have four ways to run DOS networking code: [1] on native hardware, [2] in DOSBox with the NE2000 emulation, [3] using VirtualBox or VMWare and now [4] natively in an XP NTVDM using SwsVPkt. That's pretty neat!

(There is one small catch. My anti-social polling of the network adapter is making the DOS box run continuously, pegging one of my CPU cores.)


-Mike
Japheth

Homepage

Germany (South),
01.06.2011, 13:14

@ mbbrutman
 

mTCP and SwsVPkt

Post reply

> I just tried SwsVPkt for the first time - I was unaware that it existed.
That's a bit surprising for me - because SoftWare Systems (SWS) also offers SWSSock, which is kind of a "competitor" of mTCP.

---
MS-DOS forever!
mbbrutman

Homepage

Washington, USA,
01.06.2011, 15:04

@ Japheth
 

mTCP and SwsVPkt

Post reply

> > I just tried SwsVPkt for the first time - I was unaware that it existed.
>
> That's a bit surprising for me - because SoftWare Systems (SWS) also offers
> SWSSock, which is kind of a "competitor" of mTCP.
When I started coding a few years ago I had been exposed to NTCPDRV (Trumpet). Trumpet worked on my favorite machine (the IBM PCjr) but the applications were horribly dated and usually crashed. It was just plain frustrating. So I started writing my own code.

I wasn't aware of WATTCP at the time. If I had known about it at the time I might be writing WATTCP applications instead. I knew about NCSA Telnet but I resisted the urge to look at their code until I couldn't figure out why their FTP was faster than mine. (It turned out to be nothing to do with TCP protocol - it was larger buffer sizes for the DOS reads and writes.)

I keep becoming more and more aware of the DOS networking world as I go. In many respects, I am a newbie ...

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

Homepage E-mail

Düsseldorf, Germany,
01.06.2011, 16:07

@ mbbrutman
 

polling

Post reply

> My anti-social polling of the network adapter
> is making the DOS box run continuously, pegging one of my CPU cores.
If it's supported (as in NTVDM) you can call Int2F.1680 every time the packet polling loop found no packet. You could default to HLT if the service isn't supported, or you could execute HLT only as an option.

---
l
Japheth

Homepage

Germany (South),
01.06.2011, 17:12

@ ecm
 

polling

Post reply

> > My anti-social polling of the network adapter
> > is making the DOS box run continuously, pegging one of my CPU cores.
>
> If it's supported (as in NTVDM) you can call Int2F.1680 every time the
> packet polling loop found no packet.
From my experience I'd say that this variant of "idle call" isn't supported in NTVDM ( I am not 100% sure). Although it sounds a bit strange, probably the best option in NTVDM is to call the "keyboard status interrupt" (int 16h, ah=01) if you want to "give up" your time slice.

---
MS-DOS forever!
ecm

Homepage E-mail

Düsseldorf, Germany,
01.06.2011, 17:27

@ Japheth
 

polling

Post reply

> From my experience I'd say that this variant of "idle call" isn't supported
> in NTVDM ( I am not 100% sure).
You are wrong; it is indeed supported.

D:\>debug
-a
136C:0100 mov ax, 1680
136C:0103 int 2f
136C:0105 jmp 100
136C:0107
-r
AX=0000 BX=0000 CX=0000 DX=0000 SP=FFFE BP=0000 SI=0000 DI=0000
DS=136C ES=136C SS=136C CS=136C IP=0100 NV UP EI PL ZR NA PE NC
136C:0100 B88016            mov     ax, 1680
-t
AX=1680 BX=0000 CX=0000 DX=0000 SP=FFFE BP=0000 SI=0000 DI=0000
DS=136C ES=136C SS=136C CS=136C IP=0103 NV UP EI PL ZR NA PE NC
136C:0103 CD2F              int     2F
-
AX=1600 BX=0000 CX=0000 DX=0000 SP=FFFE BP=0000 SI=0000 DI=0000
DS=136C ES=136C SS=136C CS=136C IP=0105 NV UP EI PL ZR NA PE NC
136C:0105 EBF9              jmp     0100
-g

After the call AL was properly set to zero, indicating the call is supported. The G command at the end hangs the VM but does so without fully loading one core. This in a MSW XP NTVDM. (I don't remember ever getting other results in MSW 2000, Vista, or 7 though.)

> Although it sounds a bit strange, probably
> the best option in NTVDM is to call the "keyboard status interrupt" (int
> 16h, ah=01) if you want to "give up" your time slice.
Are you sure? That sounds indeed strange. Isn't 16.01 supposed to return immediately? In any case mTCP's DHCP (other programs probably too) does appear to call 16.01 in each loop iteration so if that gave up enough time it wouldn't fully load a core.

---
l
Japheth

Homepage

Germany (South),
01.06.2011, 17:50

@ ecm
 

polling

Post reply

> > From my experience I'd say that this variant of "idle call" isn't
> supported
> > in NTVDM ( I am not 100% sure).
>
> You are wrong; it is indeed supported.
Yes, partially. I recall the issue now: it isn't supported by NTVDM if the DOS app is in protected-mode. It's somewhat funny that the call is supported in real-mode, but not in protected-mode, because, IIRC, this API was introduced with DPMI.

> > Although it sounds a bit strange, probably
> > the best option in NTVDM is to call the "keyboard status interrupt" (int
> > 16h, ah=01) if you want to "give up" your time slice.
>
> Are you sure? That sounds indeed strange. Isn't 16.01 supposed to return
> immediately? In any case mTCP's DHCP (other programs probably too) does
> appear to call 16.01 in each loop iteration so if that gave up enough time
> it wouldn't fully load a core.
Yes, it is supposed to return immediately. I guess the NTVDM hooks this interrupt and will go idle if it is called "too often".

---
MS-DOS forever!
ecm

Homepage E-mail

Düsseldorf, Germany,
01.06.2011, 17:55

@ Japheth
 

polling

Post reply

> I recall the issue now: it isn't supported by NTVDM if the
> DOS app is in protected-mode. It's somewhat funny that the call is
> supported in real-mode, but not in protected-mode, because, IIRC, this API
> was introduced with DPMI.
Ah, yes. So is 16.01 the best method to idle while in protected mode? Switching to V86 mode and calling the working 2F.1680 would probably take too long.

---
l
Japheth

Homepage

Germany (South),
01.06.2011, 18:39

@ ecm
 

polling

Post reply

> Ah, yes. So is 16.01 the best method to idle while in protected mode?
> Switching to V86 mode and calling the working 2F.1680 would probably take
> too long.
I don't think this is a question of speed - both variants will have to switch to v86-mode and back. Int 16h,ah=01 is more simple to call than int 31h, ax=0300h, that's the main advantage I see.

To be sure, I just verified that calling int 2F, ax=1680h thru DPMI Int 31h, ax=0300h indeed works as expected with NTVDM.

---
MS-DOS forever!
ecm

Homepage E-mail

Düsseldorf, Germany,
01.06.2011, 18:49

@ Japheth
 

polling

Post reply

> Int 16h,ah=01 is more simple to call than int
> 31h, ax=0300h, that's the main advantage I see.
>
> To be sure, I just verified that calling int 2F, ax=1680h thru DPMI Int
> 31h, ax=0300h indeed works as expected with NTVDM.
Ah, so shouldn't 2F.1680 via 31.0300 be preferred then? At least 2F.1680 is properly defined to idle, while NTVDM's implementation extends 16.01 somehow to make it idle.

Aside from preference, that means it should always be fine to call 2F.1680 via 31.0300 if direct 2F.1680 isn't supported in protected mode?

(I verified that NTVDM indeed doesn't pretend to support 2F.1680 in protected mode. Calling that service leaves AL unchanged.)

---
l
Rugxulo

Homepage

Usono,
02.06.2011, 00:37

@ ecm
 

polling

Post reply

> > Int 16h,ah=01 is more simple to call than int
> > 31h, ax=0300h, that's the main advantage I see.
> >
> > To be sure, I just verified that calling int 2F, ax=1680h thru DPMI Int
> > 31h, ax=0300h indeed works as expected with NTVDM.
>
> Ah, so shouldn't 2F.1680 via 31.0300 be preferred then? At least 2F.1680 is
> properly defined to idle, while NTVDM's implementation extends 16.01
> somehow to make it idle.
>
> Aside from preference, that means it should always be fine to call 2F.1680
> via 31.0300 if direct 2F.1680 isn't supported in protected mode?
>
> (I verified that NTVDM indeed doesn't pretend to support 2F.1680 in
> protected mode. Calling that service leaves AL unchanged.)
That's pretty dopey. I know Mined/DJGPP (thanks to my wimpy suggestion) uses that DPMI call, and it works under XP. Anyways, a quick (hopefully correct) test doesn't show it supported at all under DOSEMU, which I find odd. I know DR-DOS 7.03 supports it too, as do others probably, though probably not CWSDPMI. (RBIL only mentions Win 3+, DOS 5+ [eh?], DPMI 1.0+ [who??], OS/2 2.0+.)

Yeah, I know, silly to call a DPMI 1.0 call for mTCP (real mode), but if it works, it works! But I definitely wouldn't call it ten bazillion times a second.

Oh well, it probably doesn't majorly matter anyways.
ecm

Homepage E-mail

Düsseldorf, Germany,
02.06.2011, 00:52

@ Rugxulo
 

polling

Post reply

> Anyways, a quick (hopefully correct) test doesn't show it supported
> at all under DOSEMU, which I find odd.
Maybe one can properly idle there using HLT then? And how did you test for it?

> Yeah, I know, silly to call a DPMI 1.0 call for mTCP (real mode)
Is there a better alternative?

> But I definitely wouldn't call it ten bazillion times a second.
That's how it's intended to be used though (if supported). If you spent all that time polling for packets or keystrokes instead, you'd just waste CPU time.

---
l
Japheth

Homepage

Germany (South),
02.06.2011, 05:42

@ ecm
 

polling

Post reply

> Ah, so shouldn't 2F.1680 via 31.0300 be preferred then?
Yes, definitely!

> Aside from preference, that means it should always be fine to call 2F.1680
> via 31.0300 if direct 2F.1680 isn't supported in protected mode?
I just tested the variants in both XP and 9x: Int 2Fh, 1680h via int 31h, 0300h works well on both platforms. So this is indeed the most generic approach.

---
MS-DOS forever!
mbbrutman

Homepage

Washington, USA,
04.06.2011, 04:13

@ Japheth
 

polling

Post reply

Polling was fine for my PCjr, but I probably should fix this for later machines.

I am thinking of doing a check for the DOS version, and then if it is one of the versions that supports int 2f.1680 using it each time I check for a new packet and one is not there. I'm using int 2f.1680 now in an XP DOS Box with SWSVPKT and the busy polling behavior that consumed a core is gone, but the application is more than usable.

I understand that the call yields the processor for a time slice, where the OS supports that. But what is the definition of a time slice? I imagine it varies from environment to environment.

The interrupt list says that it was supported in DOS 5. What does DOS 5 do with it?

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

Homepage E-mail

Düsseldorf, Germany,
04.06.2011, 06:50

@ mbbrutman
 

polling

Post reply

> I am thinking of doing a check for the DOS version, and then if it is one
> of the versions that supports int 2f.1680 using it each time I check for a
> new packet and one is not there.
Just check for 2F.1680 support directly: If the call sets AL to zero, it is supported. Otherwise it isn't supported.

You can do that check before your application actually starts its operation; or you could do it the first time you're waiting for a packet; or each time. I usually do it each time since then (in TSRs) I won't have to keep track of whether 2F.1680 becomes supported (or goes away) while my program is running. With non-TSR programs, that's obviously not that useful.

> I'm using int 2f.1680 now in an XP DOS Box with SWSVPKT and the busy
> polling behavior that consumed a core is gone,
Good.

> but the application is more than usable.
What do you mean with this?

> I understand that the call yields the processor for a time slice, where the
> OS supports that. But what is the definition of a time slice? I imagine
> it varies from environment to environment.
Yes. However, if it's supported in a single-tasking DOS environment (FDAPM or MS-DOS POWER possibly provide it, I'm not sure) then I'd assume its operation is similar to that of executing HLT (with interrupts enabled): wait until the next external interrupt reaches the CPU. That can for example be caused by a keystroke, a packet from the network, or the timer.

> The interrupt list says that it was supported in DOS 5. What does DOS 5 do
> with it?
I don't think any kernel provides this interface directly. That entry probably just means that interface became popular with MS-DOS 5, or that MS-DOS 5+ programs use it or something.

---
l
Arjay

04.06.2011, 10:46

@ ecm
 

polling

Post reply

> I don't think any kernel provides this interface directly. That entry
> probably just means that interface became popular with MS-DOS 5, or that
> MS-DOS 5+ programs use it or something.
Prior to AX=1680h, Interrupt 28 (DOS 2+ - DOS IDLE INTERRUPT) was the main method used. A good source of info on time slice returning are programs BBS Door designed to run under Desqview/Windows and OS/2. However be aware there are several different OS specific calls that exist.

A Windows aware DOS game that I wrote in 1997 used the 1680h calls and I think Int 28h as well however I didn't implement some DESQview/OS2 calls for example as they were already dead at that time. I'll see if I can dig out the src for that particular routine. On a related note it also worth noting the existance of WINOLDAP / Int 2F/AX=1607h, Int 2F/AX=1607h/BX=0006h which when collectively used together allowed a DOS program to not only interface with the clipboard (fairly well documented) but also change the current task focus to itself and maximise the screen etc. My DOS also made use of these calls, e.g. GET current VM then Set VM (after checking they were supported etc...)
mbbrutman

Homepage

Washington, USA,
16.07.2011, 22:09

@ Arjay
 

polling

Post reply

I meant to revisit this earlier. It's time to clean it up ...

DOS 2 and higher have INT 0x28 known as the idle handler. According to what I have read DOS may not have a idle handler installed. If it does not, then making INT 0x28 calls is harmless, but burns a few cycles. If there is an idle handler installed then it can make use of the fact that the foreground application has basically said 'I'm idle'. This function should always be safe to use.

Then there is INT 0x2F,1680 (the idle call). This is supported in DOS 5 and later versions of Windows, but there is a warning in the "Microsoft DOS 5 Programmers Reference" to check to ensure that INT 0x2F is not zero first before using it. It also has a return code to check to ensure that does something. It has the desired effect in a Windows XP command window.

I'd like one version of my executables to work in all of the environments. The simplistic way to do this is to get the DOS version and if DOS 5 or better is reported to verify INT 0x2F,1680 is installed and use it. (And if it returns 0, then continue using it.) If 0x2F,1680 does not work then fall back to using INT 0x28.

Does this seem reasonable?

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

E-mail

17.07.2011, 12:59

@ mbbrutman
 

polling

Post reply

Hello Mike
> DOS 2 and higher have INT 0x28 known as the idle handler. According to
> what I have read DOS may not have a idle handler installed. If it does
> not, then making INT 0x28 calls is harmless, but burns a few cycles. If
> there is an idle handler installed then it can make use of the fact that
> the foreground application has basically said 'I'm idle'. This function
> should always be safe to use.
I don't think you got it right. Int 28 isn't something you CALL, (the handler is just an IRET anyway), it's something your TSR may HOOK and DOS itself calls it to signal it is basically idle - as in waiting for keyboard entry, and the like. It doesn't look like what your polling app wants to do.


> Then there is INT 0x2F,1680 (the idle call). This is supported in DOS 5
> and later versions of Windows,
The bit about "DOS 5" is a misunderstanding of R. Brown's list, forget it. What int 2F/1680 is, is a DPMI/Windows/Task Switcher thing (hence supported by DOS 5's "DOSSHELL", NOT supported by DOS 5 or any DOS's kernel).

How it works is your app calls int 2F/1680 in order to tell the multitasker "I think I have nothing useful to do for a while", thus allowing the multitasker to pass control to other tasks; In other words yielding.



> I'd like one version of my executables to work in all of the environments.
> The simplistic way to do this is to get the DOS version and if DOS 5 or
> better is reported to verify INT 0x2F,1680 is installed and use it. (And
> if it returns 0, then continue using it.) If 0x2F,1680 does not work then
> fall back to using INT 0x28.
>
> Does this seem reasonable?
Pretty much, except the bit about int 28 ;=) You may call 2F/80 in all DOS versions, too, not just 5+.

---
Ninho
mbbrutman

Homepage

Washington, USA,
17.07.2011, 23:05

@ Ninho
 

polling

Post reply

> Hello Mike
> I don't think you got it right. Int 28 isn't something you CALL, (the
> handler is just an IRET anyway), it's something your TSR may HOOK and DOS
> itself calls it to signal it is basically idle - as in waiting for keyboard
> entry, and the like. It doesn't look like what your polling app wants to
> do.
If DOS calls INT 0x28 to indicate that it is idle (between keystrokes presumable) then it is perfectly reasonable for an application to do the same and for the same reason - especially if it is not using DOS services.

An example: my IRC program under FreeDOS loops polling for keyboard and Ethernet traffic hard enough to cause VMWare to burn an entire CPU core. (In effect it is busy that time.) That is with FPADM running. If I make INT 0x28 calls the CPU utilization of the VM that FreeDOS and IRCjr are running in drops to almost nothing, but everything is still responsive.


>
> > Then there is INT 0x2F,1680 (the idle call). This is supported in DOS 5
> > and later versions of Windows,
>
> The bit about "DOS 5" is a misunderstanding of R. Brown's list, forget it.
> What int 2F/1680 is, is a DPMI/Windows/Task Switcher thing (hence supported
> by DOS 5's "DOSSHELL", NOT supported by DOS 5 or any DOS's kernel).
>
> How it works is your app calls int 2F/1680 in order to tell the multitasker
> "I think I have nothing useful to do for a while", thus allowing the
> multitasker to pass control to other tasks; In other words yielding.
Ok, that explains why I need to test to see if it is enabled. On XP in a command window it is enabled, but it might not be available in on a pure DOS machine.

So for machines with INT 0x2f installed I can test function 1680 once to see if it is working, and then make a decision on if to keep using it or not. If it is not available I think that INT 0x28 still makes sense, unless I am wrong with my reasoning above.

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

E-mail

18.07.2011, 11:22

@ mbbrutman
 

polling

Post reply

Mike, I wonder whether there isn't a little confusion over two notions :

- your DOS app might be running in concurrence with others under a multitasker such as Windows, OS2,or simply the DOS's DOSSHELL or similar multitaskers.
This is what I had in mind mostly when writing the previous note. Basically the solution is for an app to signal it's OK to idle by calling int 2F80.

- alternatively or in addition, your DOS itself might be running under a virtualisation system like VMWare, Virtual BOX etc. I think this is what /you/ had in mind, apology for miscontruing your question.
Then, the fact that an "inactive" VM seems to consume processor time is NOT a consequence of your app polling the virtual hardware, it is a general property of virtual machines running DOS. in order to "tame" the VM you could hook int 28, and inside your intercept you could issue HLT instructions. Idem for int 2F1680 as well as several others.

BUT this "taming" really shouldn't be installed by your (or any other) /application/ program, rather it should be /DOS system wide/ and is best done by specially tuned residents : load DOSIDLE and SLEEPVM into your DOS configuration - very recommended, look them up on the Internet (both are needed for best results as they complement each other. The latter specifically hooks int 28, the former a number of others). Net result, CPU utilisation instantly drops to zero, problem solved.

> If DOS calls INT 0x28 to indicate that it is idle (between keystrokes
> presumable) then it is perfectly reasonable for an application to do the
> same and for the same reason
Not really, it is not meant to be used in this way and will cause problems (with printers e.g.)

>> What int 2F/1680 is, is a DPMI/Windows/Task Switcher thing

> Ok, that explains why I need to test to see if it is enabled. On XP in a
> command window it is enabled, but it might not be available in on a pure
> DOS machine.
You don't have to test, at least as of DOS version 2, int 2F is a fundamental mechanism; you don't test for int 2F/1680 either, may call it blindly, can't harm in any way.

> So for machines with INT 0x2f installed I can test function 1680 once to
> see if it is working, and then make a decision on if to keep using it or
> not. If it is not available I think that INT 0x28 still makes sense,
> unless I am wrong with my reasoning above.
Calling int 28 would be wrong. See above.

Regards,

---
Ninho
mbbrutman

Homepage

Washington, USA,
18.07.2011, 16:05

@ Ninho
 

polling

Post reply

Ninho - I appreciate the back and forth of the discussion - this is an area I am not very familiar with.

Lets consider the case of 2F/1680 first. I think that the only concern with 2F is ensuring that it is installed first. On a bare system with no TSRs the interrupt vector might not be in use; at best if you invoke it there is an IRET there and nothing happens. At worse the interrupt vector is zero, and the machine blows up. If 2F is installed then the convention is to not alter registers unless a particular TSR chained from 2F detects it's signature was used. This all makes sense.

The only concern I have is that 2F has been around since DOS 2.x; I wonder if the behavior is the same going all of the way back to those early releases. (I can test this.) While PRINT.COM used 2F back then I doubt the concept of the multiplex interrupt was fully architected/understood so I am expecting that it does not work well with older TSRs.



INT 28h is much more interesting ...

I think you misread me earlier. I don't want to install an INT28 handler. I just want to invoke INT28 from my idle loop and if there is an INT28 handler installed it can do whatever it needs to do.

Everything that I can find says that DOS issues it while waiting for keyboard input, and as you pointed out this is something that TSRs might want to monitor. Applications normally have no use for this.

My applications are ill-behaved in that they are constantly polling for I/O outside of DOS so this interrupt will never be called. That gives the illusion of never having any idle time because I never called DOS functions to read the keyboard. This clearly is not the case - I'm just not using DOS when my application is in its idle loop.

Some of what I have read says that only DOS should use this, but explains that DOS just uses it to give TSRs time to run if DOS is idle. One reference I saw was talking about older application switchers, and that using this interrupt in your application IDLE loop would improve system performance. I presume that is because the older application switchers were monitoring it. In my testing with FDAPM calling INT28 reduced overall VM utilization; I suspect that FDAPM is monitoring INT28 and using halt instructions to reduce power consumption.

Clearly if 2F/1680 is working that is the better way to indicate that the application is idle. But in the absence of 2F/1680 I know that 28 is still available, and it has been in place since DOS 2.x. (It still might not do anything useful - that depends on if there is something monitoring it.)


-Mike

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

E-mail

18.07.2011, 17:28

@ mbbrutman
 

polling

Post reply

> Ninho - I appreciate the back and forth of the discussion - this is an area
> I am not very familiar with.
It's alright; In order to be brief and not too boring I not repeat the same things over and over, just try to make'm clearer if I can.

> Lets consider the case of 2F/1680 first. I think that the only concern
> with 2F is ensuring that it is installed first. On a bare system with no
> TSRs the interrupt vector might not be in use; at best if you invoke it
> there is an IRET there and nothing happens. At worse the interrupt vector
> is zero, and the machine blows up.

The vector won't be null on a bare DOS system, no more than say, int 21. It won't be null, and should be a valid callable software int on any system (DOS internally calls int 2F all the time). This is not meant to say you don't want to check, just in case... nuff said 'bout 2F.

> INT 28h is much more interesting ...
> I think you misread me earlier. I don't want to install an INT28 handler.
> I just want to invoke INT28 from my idle loop and if there is an INT28
> handler installed it can do whatever it needs to do.
No I think I understood what you meant to do, and I think it was the bad (TM) idea.

> Everything that I can find says that DOS issues it while waiting for
> keyboard input, and as you pointed out this is something that TSRs might
> want to monitor. Applications normally have no use for this.

> My applications are ill-behaved in that they are constantly polling for I/O
> outside of DOS so this interrupt will never be called. That gives the
> illusion of never having any idle time because I never called DOS functions
> to read the keyboard. This clearly is not the case - I'm just not using
> DOS when my application is in its idle loop.
I think you want to call int 2F/1680 in your polling loop. Windows and other multi taskers will notice the fact that your VM is calling the int repeatedly and adjust their scheduling strategies accordingly. It won't do anything under bare, monotasking, DOS, but there you have no use for those CPU cyles anyway, they aren't wasted; also see next point.

And, load/advise your users load DOSIDLE and SLEEPVM from your/their config or autoexec files. You might be suprised how efficient they are: in VMware and similar boxes, CPU usage will suddenly stay near zero; in real machines running Windows etc, multitasking will be eased; last but not least in stand alone DOS configurations this reduces processor power and heat by halting it (DOSIDLE can optionally make use of Advance Power Management functions of BIOS, not recommended for in virtual machines though).

...
> Clearly if 2F/1680 is working that is the better way to indicate that the
> application is idle. But in the absence of 2F/1680 I know that 28 is still
> available, and it has been in place since DOS 2.x. (It still might not do
> anything useful - that depends on if there is something monitoring it.)
Not that it is not useful, it's use is not that which you imagine. It is one of several "callouts" made by DOS to give TSRs a chance to do their thing.

---
Ninho
Ninho

E-mail

18.07.2011, 17:30

@ Ninho
 

IGNORE! no text, posting error

Post reply

.
mbbrutman

Homepage

Washington, USA,
18.07.2011, 17:41

@ Ninho
 

polling

Post reply

Ok, you have me convinced .. I'll ignore INT 28 unless it comes up at a party during conversation.

As for INT 2F/1680, I will test it in a few environments and with DOSIDLE/SLEEPVM. Both of those are new to me - the old hardware that I run doesn't have an APM BIOS and is not task switching in any way, so I've been ignoring the fact that my code looks like a CPU hog.


Thanks again!
Mike

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

Homepage E-mail

Düsseldorf, Germany,
21.08.2011, 16:28

@ mbbrutman
 

polling

Post reply

Just for the record, in my applications I idle with the following sequence:

* issue 2F.1680, done if it zerod al

* if in DPMI protected mode, issue 2F.1680 via 31.0300 (ie from real/V86 mode), done if it zerod al

* otherwise insure interrupts are enabled (via sti) then execute a hlt instruction, assume this did it

The second way is necessary because at least some DPMI environments (including the NTVDM's) do not support 2F.1680 even though it's supported in their real/V86 mode.

The third way, executing hlt, is a default handler to idle directly. It doesn't work in some environments. I provide an option to change whether hlt will be used at all; if that option is set, my handler gives up instead of attempting to idle via hlt.

I additionally currently never issue hlt in DPMI protected mode because DPMI hosts seem to dislike that instruction (or possibly sti, not sure).

I'm not using Int28 primarily because there is no intrinsically supported way to determine whether it did something useful at all. (One could check for, say, whether the handler wasn't a single iret, but that wouldn't always indicate that the handler would do something useful if called right now.) If it did something, additionally attempting to idle by hlt or 2F.1680 afterwards would decrease performance and responsiveness. If it didn't, not additionally attempting to idle in other ways afterwards would mean not to idle at all. (I might add an option to my application to call Int28 instead or additionally though.)

I assume that Int2F can be called without crashing the machine. But then again, I make that assumption everywhere, so if I'd crash because Int2F is invalid, then I'd crash much earlier before ever reaching the idling code.

One could say I'm running the idling method detection every time I am idling. I recognize that this may not be the best way to do it. However, some of my applications stay resident in one or another way, so they want to catch changes in interrupt handlers and such - necessitating running the detection again. I might change that so I won't try detecting changes every time I idle though.

---
l
Back to index page
Thread view  Board view
22632 Postings in 2109 Threads, 402 registered users, 383 users online (0 registered, 383 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum