Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to index page

ecm

Düsseldorf, Germany,
15.06.2009, 21:33

New RxDOS memory subsystem source code (Developers)

I finished working on the resident (kernel) memory subsystem of my RxDOS code base today. It isn't that much source code, really, but I thought it might interest some people.

The most important change to RxDOS 7.1.5 here is that it now supports UMBs managed by DOS, although I'm still adding this support to the code processing RXCONFIG.SYS so it's actually only halfway done. The 8086 Assembly source code shows quite good how I want to provide build options to create specialized builds of RxDOS: the complete UMB support will be disabled if the option _UMA is set to zero, and the option _386 (in other source files _186 as well) enables using shorter or faster 386 (or 186) opcodes. The file is intended to be included by other source files - which also include some necessary macro files and contain the sophisticated segment setup of the kernel - NASM won't accept it alone.

Don't forget to read the README.TXT file as some things might seem odd to people not familiar with my source (= everyone except me). The file also features quite extensive commentary which I hope helps to understand the code structure.

Get the 7-Zip archive here: RxDOSMEM-2009-06-15.7z

---
l

Japheth

Germany (South),
16.06.2009, 17:21

@ ecm

New RxDOS memory subsystem source code

Thanks, cm, cool thing! However, what to reply? One cannot run this thing, it cannot be assembled and it doesn't contain bugs to find. So the intellectual challenge is pretty low. The source reportedly implements a "DOS memory subsystem" ... good, perhaps this comes in handy in the not so far future, but I have doubts, it is GPL, which I prefer to ignore for certain reasons.

But it's a good opportunity to tell once again that Nasm's syntax looks desperately ugly. I especially hate the absence of ASSUME, OFFSET, ADDR and PTR keywords.

Sincerely

---
MS-DOS forever!

ecm

Düsseldorf, Germany,
16.06.2009, 21:23

@ Japheth

New RxDOS memory subsystem source code

> One cannot run this thing, it cannot be assembled

True. Why should you assemble it? (Except for debugging separately from a finished kernel, which won't interest you that much either I think.)

> and it doesn't contain bugs to find.

Feel free to search any.

> good, perhaps this comes in handy in the not so far future,

For example in a DOS kernel..? I fixed the memory management stuff first because the process loading (RxDOSEXE.ASM) relies on it and it isn't that much source.

> but I have doubts, it is GPL, which I prefer to ignore for
> certain reasons.

Because you can't use the source to make money? Although I don't fear to release my own work with a 2-clause BSD-type license (or sometimes as Public Domain), I don't think using the GPL is too egoistic either.

However I'm not that sceptic about giving little hints about the binary's operations to people either. Think of it as technical documentation, which of course is usable for software licensed any way. Just don't copy the provided source code because that's restricted to the GPL.

> But it's a good opportunity to tell once again

You always find a good point, don't you? How optimistic.

> that Nasm's syntax looks
> desperately ugly. I especially hate the absence of ASSUME, OFFSET, ADDR
> and PTR keywords.

Strange that I feel the exact opposite about the absence of these keywords ;-)

I recently re-read a good comparison of assemblers and came to the conclusion that type checking, after all, isn't that bad. But I consider myself advanced enough now to write programs without it (and to find the bugs caused by wrong typed access). Plus MASM's type checking is error-prone by relying on correct ASSUME usage. Type checking of course doesn't force the syntax to include OFFSET and PTR to tell the assembler whether memory is accessed or not. NASM's handling of requiring square braces for all memory access I find much easier to understand.

If you have anything else to complain about my ugly NASM source, don't hesitate ;-)

---
l

Rugxulo

Usono,
19.06.2009, 06:54

@ ecm

GPL vs. BSD

>
> > but I have doubts, it is GPL, which I prefer to ignore for
> > certain reasons.
>
> Because you can't use the source to make money? Although I don't fear to
> release my own work with a 2-clause BSD-type license (or sometimes as
> Public Domain), I don't think using the GPL is too egoistic either.
>
> However I'm not that sceptic about giving little hints about the binary's
> operations to people either. Think of it as technical documentation, which
> of course is usable for software licensed any way. Just don't copy the
> provided source code because that's restricted to the GPL.

The *BSD camps seem to strongly dislike GPL, and they flat out refuse to touch GPL3. Hence, they are scrambling to get away from GCC although that isn't too feasible just yet (PCC is weak, Clang sorta works, but only GCC supports Obj. C and C++ well enough so far). Honestly, I think we all waste our time due to silly politics, marketing, etc. I think if we all weren't so petty and argumentative, we'd get more done. But NIH is a strong disease, apparently. (I prefer no license at all, honestly, pure "public domain", but at the same time, having full sources is definitely ideal.)

marcov

20.06.2009, 14:09

@ Rugxulo

GPL vs. BSD

> The *BSD camps seem to strongly dislike GPL, and they flat out refuse to
> touch GPL3. Hence, they are scrambling to get away from GCC although that
> isn't too feasible just yet (PCC is weak, Clang sorta works, but only GCC
> supports Obj. C and C++ well enough so far). Honestly, I think we all
> waste our time due to silly politics, marketing, etc. I think if we all
> weren't so petty and argumentative, we'd get more done. But NIH is a
> strong disease, apparently. (I prefer no license at all, honestly, pure
> "public domain", but at the same time, having full sources is definitely
> ideal.)

I don't think this has anything to do with NIH. It's simply that GPL is a very restrictive license rooted in some ideology.

If you don't believe in that ideology to the fullest it is insane to make the requested sacrifice.

Sooner or later you want to use some code for some minor product, and find yourself effectively excluded.

Rugxulo

Usono,
21.06.2009, 04:37

@ marcov

GPL vs. BSD

> I don't think this has anything to do with NIH. It's simply that GPL is a
> very restrictive license rooted in some ideology.

Well, I haven't counted the universe yet (heh), but GPL seemingly outnumbers BSD a billion times to one. I'm not saying BSD isn't a hundred times easier to understand. And yes, providing full sources on the same site (even when mirrored hundreds of times elsewhere) seems ridiculous. But having sources is always desirable, esp. when you have to fork something due to no maintainer or broken main build.

> If you don't believe in that ideology to the fullest it is insane to make
> the requested sacrifice.

It's not that insane. The only halfway insane part is using copyright law to enforce it. Share and share alike. You like our code? You must share yours too if you use it publicly.

> Sooner or later you want to use some code for some minor product, and find
> yourself effectively excluded.

Not really, you can commercially use it, you just can't do it based upon closed sources. I imagine they are trying to prevent companies from dropping support on a whim or charging for simple bugfixes.

P.S. I have nothing against anyone using either license. (I think licenses are overrated anyways, attempt too much control over people, esp. EULAs.) However, I do wish it wasn't such a hostile "us vs. them" mentality.

marcov

21.06.2009, 14:30

@ Rugxulo

GPL vs. BSD

> > I don't think this has anything to do with NIH. It's simply that GPL is
> a
> > very restrictive license rooted in some ideology.
>
> Well, I haven't counted the universe yet (heh), but GPL seemingly
> outnumbers BSD a billion times to one.

Proving what? Dirt outnumbers diamonds too, but I rather have a few diamonds that a ton of dirt.

> But having sources is always desirable, esp. when you have to fork
> something due to no maintainer or broken main build.

Or join it with some existing project and venture. And that is exactly why GPL is such a pain. Not only in the hard requirements, but also because of the multiple levels in a corporation you have to convince even in the rare case it is perfectly fine to use.

A lot of the GPL pain comes from the exclusiveness and the need for every party to agree (which essentially means BSD/PD or (L)GPL, excluding all hundreds of thousands of other licenses, even some as benign as MPL)

You might go through such trajectory to be able to use a Linux distro on some server, but you don't go through it for a 500 piece of code.

> > If you don't believe in that ideology to the fullest it is insane to
> > make the requested sacrifice.
>
> It's not that insane. The only halfway insane part is using copyright law
> to enforce it. Share and share alike. You like our code? You must share
> yours too if you use it publicly.

I must share it according to guidelines other people enforce on me. I don't set the requirements for my own sharing, but FSF does.

> > Sooner or later you want to use some code for some minor product, and
> find
> > yourself effectively excluded.
>
> Not really, you can commercially use it, you just can't do it based upon
> closed sources.

Which makes is equivalent to pretty much useless for programming in the commercial world. Contrary to e.g. for an OS kernel where it is survivable.

> I imagine they are trying to prevent companies from
> dropping support on a whim or charging for simple bugfixes.

More or less. But they did that in a very draconical and ideologically radical way, possibly to largely avoid any dispute. But that draconical way is the main problem.

The same way with the much laxer LGPL. FSF forces people to adopt *their* views on updating componentized systems as *they* think they should look like. Which is e.g. why FPC is distributed under LGPL-with-linking exception to defang that dangerous clause

> P.S. I have nothing against anyone using either license. (I think licenses
> are overrated anyways, attempt too much control over people, esp. EULAs.)
> However, I do wish it wasn't such a hostile "us vs. them" mentality.

By choosing LGPL/GPL, you are no different from them, and you essentially polarize the situation, and force your views on software restrictions upon others.

Rugxulo

Usono,
22.06.2009, 10:11

@ marcov

GPL vs. BSD

> > > I don't think this has anything to do with NIH. It's simply that GPL
> is
> > a
> > > very restrictive license rooted in some ideology.
> >
> > Well, I haven't counted the universe yet (heh), but GPL seemingly
> > outnumbers BSD a billion times to one.
>
> Proving what? Dirt outnumbers diamonds too, but I rather have a few
> diamonds that a ton of dirt.

Really? Doing a lot of glass cutting? Because building a house needs more dirt than diamond. And one is way more expensive than the other. And expensive is no fun.

> > But having sources is always desirable, esp. when you have to fork
> > something due to no maintainer or broken main build.
>
> Or join it with some existing project and venture. And that is exactly why
> GPL is such a pain. Not only in the hard requirements, but also because of
> the multiple levels in a corporation you have to convince even in the rare
> case it is perfectly fine to use.

Corporations not cooperating is nothing new, and I don't blame FSF / GNU for that. Sure, lots of incompatible licenses hurts everybody, but that's not GPL's fault either. And sorry if I'm not more sympathetic to big business who is every bit as flaky in support as the average consumer is in wants. (Two sides of the same coin.)

> A lot of the GPL pain comes from the exclusiveness and the need for every
> party to agree (which essentially means BSD/PD or (L)GPL, excluding all
> hundreds of thousands of other licenses, even some as benign as MPL)

The real problem is that nobody attributes changes very well (e.g. XEmacs), so if that worries you, you should keep track from the beginning. I know that's not always feasible, but if you care, you have to make sure yourself. In all honestly, it's fairly obvious that at least 50% of the world doesn't even read licenses, EULAs, or care at all. Hence binary blobs, patents, incompatible licenses, trademark and copyright infringement, etc. etc. (And I am very lax about all this in thought too as it's way too pedantic and controlling IMHO. The legislators have gone way too far.)

> > > If you don't believe in that ideology to the fullest it is insane to
> > > make the requested sacrifice.
> >
> > It's not that insane. The only halfway insane part is using copyright
> law
> > to enforce it. Share and share alike. You like our code? You must share
> > yours too if you use it publicly.
>
> I must share it according to guidelines other people enforce on me. I
> don't set the requirements for my own sharing, but FSF does.

I heard today that GPL requires keeping sources available for three years. Now, I'm no lawyer, so I don't understand all that (third-party offers? um, no comprende). I do see where that could be difficult, but hey, it's not an offense against anyone, just a nicety for the end user. The GPL is all about the user. Isn't that what software should be?

> > > Sooner or later you want to use some code for some minor product, and
> > find
> > > yourself effectively excluded.
> >
> > Not really, you can commercially use it, you just can't do it based
> upon
> > closed sources.
>
> Which makes is equivalent to pretty much useless for programming in the
> commercial world. Contrary to e.g. for an OS kernel where it is
> survivable.

I'm not involved in any commercial software aspects, so I have little knowledge, experience, interest (or frankly, sympathy) for them. Rampant commercialism left unchecked is probably a bad thing.

> > I imagine they are trying to prevent companies from
> > dropping support on a whim or charging for simple bugfixes.
>
> More or less. But they did that in a very draconical and ideologically
> radical way, possibly to largely avoid any dispute. But that draconical
> way is the main problem.

You know how it is, build a better mouse trap, but the mouse always finds a way. E-mail? Great idea, but it got exploited by spam. Computers? Fouled up by viruses. Browsers? Phishing. It's always something. You can't win. As if we don't have enough laws and rules anyways. It's too much, I agree, but some people keep fighting. I'm sure you and I agree that when it hurts more than it helps that it's gone too far. So far GPL still has advantages.

> The same way with the much laxer LGPL. FSF forces people to adopt *their*
> views on updating componentized systems as *they* think they should look
> like. Which is e.g. why FPC is distributed under LGPL-with-linking
> exception to defang that dangerous clause

Too confusing for me, I don't understand most of that legal crap. I don't idealize any of it, but I do think "shared source" (with patent protection and free use) is a good thing. In short, there are a lot of crappy licenses out there, and the GPL is far from the worst.

> > P.S. I have nothing against anyone using either license. (I think
> licenses
> > are overrated anyways, attempt too much control over people, esp.
> EULAs.)
> > However, I do wish it wasn't such a hostile "us vs. them" mentality.
>
> By choosing LGPL/GPL, you are no different from them, and you essentially
> polarize the situation, and force your views on software restrictions upon
> others.

Well, as mentioned, I care little about licenses as long as they are "share and share alike" (or even freeware, better than nothing if less than ideal if abandoned). So I don't mind contributing my weak self to GPL or BSD or whatever projects. My aim is to help the software experience improve overall, and I won't refuse just because I don't like the minor legal aspects.

Anyways, as mentioned, the *BSD camps use GCC (<= 4.2.1, i.e. older GPLv2), so it's obviously not that bad. I wish I know a concrete example of where/when/why GPLv3 was bad for *BSD, that part makes no sense to me. (Also the whole optional "v2" instead of "v2 or later" variant seems a bit senseless to my eyes, which is what the Linux kernel uses.)

marcov

22.06.2009, 16:07

@ Rugxulo

GPL vs. BSD

(skipped analogy, msgs getting long enough already without bickering over analogies)

> > Or join it with some existing project and venture. And that is exactly
> why
> > GPL is such a pain. Not only in the hard requirements, but also because
> of
> > the multiple levels in a corporation you have to convince even in the
> rare
> > case it is perfectly fine to use.
>
> Corporations not cooperating is nothing new, and I don't blame FSF / GNU
> for that.

Well, one can obviously question if FSF is to blame at all. But I primarily place the blame by people and groups that randomly select GPL, rather than the ones that only created it.

> Sure, lots of incompatible licenses hurts everybody, but that's
> not GPL's fault either.

Well, since GPL is the one that is typically incompatible, it is not unfair to put a large part of the blame there.

> And sorry if I'm not more sympathetic to big
> business who is every bit as flaky in support as the average consumer is
> in wants. (Two sides of the same coin.)

Well, it is just business, not necessarily big. So there is no need to spout anti-globulist nonsense. The problems applies to anything that has more than a single management layers.

> > A lot of the GPL pain comes from the exclusiveness and the need for
> every
> > party to agree (which essentially means BSD/PD or (L)GPL, excluding all
> > hundreds of thousands of other licenses, even some as benign as MPL)
>
> The real problem is that nobody attributes changes very well (e.g.
> XEmacs), so if that worries you, you should keep track from the beginning.

If you think that people don't follow licenses, there is even less reason to use GPL.

> > > yours too if you use it publicly.
> >
> > I must share it according to guidelines other people enforce on me. I
> > don't set the requirements for my own sharing, but FSF does.
>
> I heard today that GPL requires keeping sources available for three years.

No. There is some relative small jurisprudence in *some* territories that might change at any point. I wouldn't put blind faith in those things you "hear".

> The GPL is all
> about the user. Isn't that what software should be?

Where did you get that delusional idea? It is all about the author, otherwise it wouldn't burden the user with so many duties and pretty heavy restrictions.

> > Which makes is equivalent to pretty much useless for programming in the
> > commercial world. Contrary to e.g. for an OS kernel where it is
> > survivable.

> I'm not involved in any commercial software aspects, so I have little
> knowledge, experience, interest (or frankly, sympathy) for them. Rampant
> commercialism left unchecked is probably a bad thing.

Again, please no anti-globalist oriented vague propaganda. The average situation is about normal programmers (or even non professional programms) recycling a few XML routines, which could be for the inventory system of the butcher next door. Not about a X-Files like plot created by a megalomaniac to create software that exploit patents to sell baby's abroard while clubbing a few baby seals along the way.

> > More or less. But they did that in a very draconical and ideologically
> > radical way, possibly to largely avoid any dispute. But that draconical
> > way is the main problem.
>
> You know how it is, build a better mouse trap, but the mouse always finds
> a way. E-mail? Great idea, but it got exploited by spam. Computers? Fouled
> up by viruses. Browsers? Phishing. It's always something. You can't win. As
> if we don't have enough laws and rules anyways. It's too much, I agree, but
> some people keep fighting. I'm sure you and I agree that when it hurts more
> than it helps that it's gone too far.

I agree there.

> So far GPL still has advantages.

And even here. But only for a few select strategic projects, not for the bulk of open source software, where it is only a burden and barrier.

> Too confusing for me, I don't understand most of that legal crap. I don't
> idealize any of it, but I do think "shared source" (with patent protection
> and free use) is a good thing. In short, there are a lot of crappy licenses
> out there, and the GPL is far from the worst.

This sounds awfully ambigiuous to me. It sounds like somebody is saying that weaponry is a necessarily evil, but he hates it and he doesn't even fully understand how a knife works because it is so complicated, but at the same time he prefers to have a launch ready nuclear rocket in his backyard to play with.

> Anyways, as mentioned, the *BSD camps use GCC (<= 4.2.1, i.e. older
> GPLv2), so it's obviously not that bad. I wish I know a concrete
> example of where/when/why GPLv3 was bad for *BSD, that part makes no sense
> to me. (Also the whole optional "v2" instead of "v2 or later" variant seems
> a bit senseless to my eyes, which is what the Linux kernel uses.)

For the kernel, that is a big thing, due to firmware blobs. But even then that can be remedied easily by only accepting code that is license v2+ (so no V3 only code). I can't see how it matters for gcc, in a normal BSD usage. But I can do see it when you want to integrate it, e.g. in an environment to generate code for microcontrollers.

ecm

Düsseldorf, Germany,
23.06.2009, 00:35

@ marcov

GPL user restrictions ?

> > The GPL is all
> > about the user. Isn't that what software should be?
>
> Where did you get that delusional idea? It is all about the author,
> otherwise it wouldn't burden the user with so many duties and pretty heavy
> restrictions.

Last time I read the GPL, most duties and restrictions were for the author and co-authors (people modifying source code). Pure users (people that want to use a binary only) are able to obtain the source code as per "the authors are required to provide source", but the users don't have to obtain it. Note that a "pure user" in this sense doesn't (re-)distribute the program, he only uses it.

---
l

marcov

23.06.2009, 10:11

@ ecm

GPL user restrictions ?

> > > The GPL is all
> > > about the user. Isn't that what software should be?
> >
> > Where did you get that delusional idea? It is all about the author,
> > otherwise it wouldn't burden the user with so many duties and pretty
> heavy
> > restrictions.
>
> Last time I read the GPL, most duties and restrictions were for the author
> and co-authors (people modifying source code).

Well, that depends on your view. For e.g. a library, users are more typically what you can co-authors.

> Pure users (people that want to use a binary only) are able to obtain the
> source code as per "the authors are required to provide source", but the
> users don't have to obtain it. Note that a "pure user" in this sense doesn't (re-)distribute the program, he only uses it.

Yes. I know the theory. And it works if you are the recipient of a linux distro, never use anything with a different license. Of course that works with any license, including the various licenses that GPL users frown so much on.

There are some sideways related troubles though. E.g. Lazarus is a fine example. The core app is GPL, but some of the plugins are MPL. This combination is formally not compatible, but that only kicks in with distribution. There was some discussion about that (by e.g. excluding the plugin interface from the GPL), but the paranoid were afraid that evil people would overtake the entire IDE etc etc, so it wasn't done in the end.

But recently, with the portable versions popping up everywhere, it has become a problem, since one can't distribute a full app, and thus must link it on target on the enduser's systems. Requiring extra space, and a slow build step on a stick.

ecm

Düsseldorf, Germany,
23.06.2009, 13:05

@ marcov

GPL user restrictions ?

> > > > The GPL is all
> > > > about the user. Isn't that what software should be?
> > >
> > > Where did you get that delusional idea? It is all about the author,
> > > otherwise it wouldn't burden the user with so many duties and pretty
> > heavy
> > > restrictions.
> >
> > Last time I read the GPL, most duties and restrictions were for the
> author
> > and co-authors (people modifying source code).
>
> Well, that depends on your view. For e.g. a library, users are more
> typically what you can co-authors.

If they only use a LGPL library for another program, the other program explicitly doesn't have to be GPL. Isn't that the use of the LGPL? If they want to distribute the library's binary along with the program, they have to provide the source as well.

> > Pure users (people that want to use a binary only) are able to obtain
> the
> > source code as per "the authors are required to provide source", but
> the
> > users don't have to obtain it. Note that a "pure user" in this sense
> doesn't (re-)distribute the program, he only uses it.
>
> Yes. I know the theory. And it works if you are the recipient of a linux
> distro, never use anything with a different license. Of course that works
> with any license, including the various licenses that GPL users frown so
> much on.

Until something requires recompiling a program, users don't really benefit from the source itself. What do you mean by "never use anything with a different license"? If the user runs a linux distro and gets some proprietary software (say, drivers or Windows programs for Wine) he can of course use that with his distro.

> There are some sideways related troubles though. E.g. Lazarus is a fine
> example. The core app is GPL, but some of the plugins are MPL. This
> combination is formally not compatible, but that only kicks in with
> distribution. There was some discussion about that (by e.g. excluding the
> plugin interface from the GPL), but the paranoid were afraid that evil
> people would overtake the entire IDE etc etc, so it wasn't done in the
> end.

And that GPL app is still distributed with MPL plugins? How evil. No, I don't really care. To get back on topic a bit, someone could say DOS drivers are "plugins" for the DOS kernel. (After all, they're specifically designed for the kernel and can only be used by it.) That won't stop anyone from using closed-source DOS drivers on GPL DOS kernels. It's obvious they're different programs (if nothing else, they're stored in different binaries), although there's a specific interface between them. Seeing it that way, isn't a plugin interface used because it doesn't void the GPL to use non-GPL programs with it?

Found something about that in the GPL (version 2, but version 3 has a similar phrase):

5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it.

Edit: I'd better include the phrase from the GPL 3 as well, because it says clearly there that you are allowed to run (but not distribute) the program without accepting the GPL:

9. Acceptance Not Required for Having Copies. You are not required to accept this License in order to receive or run a copy of the Program. Ancillary propagation of a covered work occurring solely as a consequence of using peer-to-peer transmission to receive a copy likewise does not require acceptance. However, nothing other than this License grants you permission to propagate or modify any covered work. These actions infringe copyright if you do not accept this License. Therefore, by modifying or propagating a covered work, you indicate your acceptance of this License to do so.

> But recently, with the portable versions popping up everywhere, it has
> become a problem, since one can't distribute a full app, and thus must
> link it on target on the enduser's systems. Requiring extra space, and a
> slow build step on a stick.

I don't understand the problem. Portable versions require compilation (or only linking) on the user's system, but other versions can work with provided binaries?

---
l

marcov

23.06.2009, 16:39

@ ecm

GPL user restrictions ?

> > Well, that depends on your view. For e.g. a library, users are more
> > typically what you can co-authors.
>
> If they only use a LGPL library for another program, the other program
> explicitly doesn't have to be GPL.

Ah, but then are you are talking about when it is formally a separate library. I was talking about any reusable (general enough) piece of source, whether spun out to a LGPL library or not. The fact that this precise difference must be made is the problem.

> Isn't that the use of the LGPL?

Well, if you mean that about the only use of the LGPL is that it isn't GPL, then you are right :_) The LGPL has its own problems, most notably the shared linking requiring.

> > Yes. I know the theory. And it works if you are the recipient of a
> linux
> > distro, never use anything with a different license. Of course that
> works
> > with any license, including the various licenses that GPL users frown
> so
> > much on.
>
> Until something requires recompiling a program, users don't really benefit
> from the source itself.
> What do you mean by "never use anything with a
> different license"?

If, in your own words, it matters so little to have the source, I wonder why the advocatists are so big on keeping source live.

> If the user runs a linux distro and gets some
> proprietary software (say, drivers or Windows programs for Wine) he can of
> course use that with his distro.

They cannot for drivers afiaik. The commercial driver must use userspace workarounds as a loophole

> To get back on topic a bit, someone could say DOS
> drivers are "plugins" for the DOS kernel. (After all, they're specifically
> designed for the kernel and can only be used by it.) That won't stop anyone
> from using closed-source DOS drivers on GPL DOS kernels.

That's because dos drivers communicate with the kernel over interrupts. In other words they are comparable with Linux "FUSE" drivers in that regard, not with Linux kernel drivers.

> It's obvious they're different programs (if nothing else, they're stored in > different
> binaries), although there's a specific interface between them.

That makes no difference. The GPL/LGPL are licenses that invoke on linking , not on "separate binaries". And dynamic linking is explicitely included in the license text. So "linking" in the GPL sense can span binaries.

The exact extend to what constitute linking in inter-process communcation is not clear to me. It is a gray area.

> Seeing it that way, isn't a plugin interface used because it doesn't void
> the GPL to use non-GPL programs with it?

I'd say the trick that the linking via interrupts is less clear licensing.

(snip totally random pieces of GPL license text, what were they meant to convey? (pun intended))

> > But recently, with the portable versions popping up everywhere, it has
> > become a problem, since one can't distribute a full app, and thus must
> > link it on target on the enduser's systems. Requiring extra space, and
> a
> > slow build step on a stick.
>
> I don't understand the problem. Portable versions require compilation (or
> only linking) on the user's system,

Well that exactly is the problem, on a slow, small filesystem. A lot of files for the link are not needed than for just that.

The whole Lazarus example is btw just meant to illustrate that it is pretty hard to forsee the consequences of choosing an extremely restrictive license as GPL.

> but other versions can work with
> provided binaries?

They also link on the users system, but the need to mimimalistic is there less.

ecm

Düsseldorf, Germany,
23.06.2009, 20:55

@ marcov

GPL user restrictions ?

> > > Well, that depends on your view. For e.g. a library, users are more
> > > typically what you can co-authors.
> >
> > If they only use a LGPL library for another program, the other program
> > explicitly doesn't have to be GPL.
>
> Ah, but then are you are talking about when it is formally a separate
> library.

I think you meant "library" as in, well, library. A separate binary. Its code is called from other programs. GPL source libraries of course can't be used for non-GPL programs.

> > Isn't that the use of the LGPL?
>
> Well, if you mean that about the only use of the LGPL is that it isn't
> GPL, then you are right

Well, no, I meant that it's only use is that "the other program [using the library] explicitly doesn't have to be GPL".

> > Until something requires recompiling a program, users don't really
> benefit
> > from the source itself.
> > What do you mean by "never use anything with a
> > different license"?
>
> If, in your own words, it matters so little to have the source,

First: Not my words. I said for users.

> I wonder why the advocatists are so big on keeping source live.

To keep the program free. That's the concept of Copyleft. (Of course enforced Copyleft is what prohibits use in proprietary programs, so that's what you are criticizing after all.)

And you didn't answer my question.

> > If the user runs a linux distro and gets some
> > proprietary software (say, drivers or Windows programs for Wine) he can
> of
> > course use that with his distro.
>
> They cannot for drivers afiaik. The commercial driver must use userspace
> workarounds as a loophole

I don't know. Only thing I heard is that there are some proprietary Linux drivers. (BTW, as the FSF says: please avoid the word "commercial" if you mean non-free software. Commercial free software is also possible.)

> > To get back on topic a bit, someone could say DOS
> > drivers are "plugins" for the DOS kernel. (After all, they're
> specifically
> > designed for the kernel and can only be used by it.) That won't stop
> anyone
> > from using closed-source DOS drivers on GPL DOS kernels.
>
> That's because dos drivers communicate with the kernel over interrupts.

No they don't. Don't let terms like "device strategy and device interrupt calls" fool you. They communicate over calls from the kernel directly into the device driver's code, which (despite one being called device interrupt) don't use any interrupts at all.

> In
> other words they are comparable with Linux "FUSE" drivers in that regard,
> not with Linux kernel drivers.

I didn't compare them to either and I don't know more about either anyway. I compared DOS drivers to plugins, which I imagine as similar to DLLs. DLLs in turn are often used as plugins on Windows, and even with some DOS extenders. My intention is this: as close as DOS drivers are to their kernel, presumably without being affected by the kernel's GPL, how can the GPL affect plugins which technically are much less tied to their main program?

> > It's obvious they're different programs (if nothing else, they're stored
> in > different
> > binaries), although there's a specific interface between them.
>
> That makes no difference. The GPL/LGPL are licenses that invoke on linking
> , not on "separate binaries". And dynamic linking is explicitely included
> in the license text. So "linking" in the GPL sense can span binaries.

So because the DOS driver interface didn't change for 20-what years, any DOS driver is linked into/for my GPL DOS kernel? I hope you weren't talking about the DOS drivers here anymore, but I won't say writing plugins which reside in different binaries as the main program counts as linking them together either.

> The exact extend to what constitute linking in inter-process communcation
> is not clear to me. It is a gray area.

Which results in that the MPL plugins for the GPL program aren't exactly covered by the GPL's Copyleft.

> (snip totally random pieces of GPL license text, what were they meant to
> convey? (pun intended))

First off, I didn't get the pun, maybe because English isn't my first language. Then, I added these snippets (they're neither total nor random) after the discussion of GPL main program vs. MPL/other license plugins. Essentially here: since the program only interfaces with the plugin's binary while running, you can use the main program disregarding the GPL with your incompatible licensed plugins (if the GPL really covers that plugins have to be GPL too).

> The whole Lazarus example is btw just meant to illustrate that it is
> pretty hard to forsee the consequences of choosing an extremely
> restrictive license as GPL.

Oh. Then, I come to the conclusion that I can only agree with you on that: it is pretty hard to forsee the consequences of choosing an extremely restrictive license. Plus, yes, the GPL is extremely restrictive when you want to use source code for proprietary programs.

---
l

Khusraw

Bucharest, Romania,
24.06.2009, 20:08

@ ecm

GPL user restrictions ?

> > They cannot for drivers afiaik. The commercial driver must use
> userspace
> > workarounds as a loophole
>
> I don't know. Only thing I heard is that there are some proprietary Linux
> drivers. (BTW, as the FSF says: please
> avoid
> the word "commercial" if you mean non-free software. Commercial free
> software is also possible.)

Sorry, but that is an arbitrary and erroneous interpretation of the word "commercial" by the sustainers of the GNU "philosophy". "Commercial" means being aimed for selling or for other type of market exchange, any free software which is the result of business activity is non-commercial and any software produced outside a business activity which is intended for selling/market exchange is commercial. Those are well established terms with a history and an etymology which seem to be far beyond the knowledge of the GNU "philosophy" writers.

---
Glory to God for all things

ecm

Düsseldorf, Germany,
25.06.2009, 02:51

@ Khusraw

Commercial philosophs

> Sorry, but that is an arbitrary and erroneous interpretation of the word
> "commercial" by the sustainers of the GNU "philosophy". "Commercial" means
> being aimed for selling or for other type of market exchange, any free
> software which is the result of business activity is non-commercial
> and any software produced outside a business activity which is intended for
> selling/market exchange is commercial. Those are well established
> terms with a history and an etymology which seem to be far beyond the
> knowledge of the GNU "philosophy" writers.

So, writing a free program and offering paid support for it (whether they call it a business or not) is not "commercial" at all? Also, if people developing a free program are paid for the development, isn't it "commercial" then, in a way?

I think the word "philosophy" doesn't fit the GNU project very well. Also, you probably meant the free software movement, not only GNU.

---
l

Khusraw

Bucharest, Romania,
25.06.2009, 08:47
(edited by Khusraw, 25.06.2009, 08:57)

@ ecm

Commercial philosophs

> So, writing a free program and offering paid support for it (whether they
> call it a business or not) is not "commercial" at all? Also, if people
> developing a free program are paid for the development, isn't it
> "commercial" then, in a way?

In the first case it is commercial support for non-commercial software. In the second, the term "commercial", if properly used in such a context, would concern the activity/work, not its results. Again, commercial software means any software intended to be sold or otherwise exchanged on the market, having a certain profit as aim, non-commercial software is any software which is made available without the intention to receive something in exchange. It is true that anyone can define "commercial" as he wants, but this doesn't imply we should accept that definition generally, outside the scope of the one who defined. Actually the lack of "rigueur" and the extreme mobility in defining and using terms is very wide-spread today, guess why.

> I think the word "philosophy" doesn't fit the GNU project very well. Also,
> you probably meant the free software movement, not only GNU.

Nor do I. I did refer to the link you provided, which is part of the "Philosophy of the GNU Project" and seems to express their particular views.

---
Glory to God for all things

ecm

Düsseldorf, Germany,
25.06.2009, 16:31

@ Khusraw

Commercial philosophs

> It is true that anyone can define "commercial" as he wants,
> but this doesn't imply we should accept that definition generally, outside
> the scope of the one who defined.

I don't want to force anyone from using terms how I define them. I just asked people to do it.

> > I think the word "philosophy" doesn't fit the GNU project very well.
> Also,
> > you probably meant the free software movement, not only GNU.
>
> Nor do I. I did refer to the link you provided, which is part of the
> "Philosophy of the GNU Project" and seems to express their particular
> views.

Well, then probably I should have added that I probably meant the free software movement, not only GNU.

---
l

Khusraw

Bucharest, Romania,
25.06.2009, 16:50

@ ecm

Commercial philosophs

> I don't want to force anyone from using terms how I define them. I just
> asked people to do it.

And I have expressed my point of view on the subject. I understand and respect your opinion and I have never thought it is enslaved to the two masters of today's "civilized" world called "the Ignorance" and its corollary, "the Incompetence".

> Well, then probably I should have added that I probably meant the
> free software movement, not only GNU.

But I don't know a generally accepted by the FSM definition of the word "commercial" etc., there are different opinions inside FSM on many subjects.

---
Glory to God for all things

marcov 25.06.2009, 21:44 @ ecm	Commercial philosophs Post reply
	> Well, then probably I should have added that I probably meant the > free software movement, not only GNU. Is there a difference then?

ecm

Düsseldorf, Germany,
25.06.2009, 23:34

@ marcov

Commercial philosophs

> > Well, then probably I should have added that I probably meant the
> > free software movement, not only GNU.
>
> Is there a difference then?

Yes. For example, I count myself to the free software movement but I don't contribute to any program of the GNU project. Using the GNU GPL doesn't mean your program is part of the GNU project.

---
l

marcov

27.06.2009, 14:09

@ ecm

Commercial philosophs

> > > Well, then probably I should have added that I probably meant
> the
> > > free software movement, not only GNU.
> >
> > Is there a difference then?
>
> Yes. For example, I count myself to the free software movement but I don't
> contribute to any program of the GNU project. Using the GNU GPL doesn't
> mean your program is part of the GNU project.

As soon as you detach "free software" from FSF, the normal english definition of "free" applies again, not the FSF twisted copyleft meaning :-)

Khusraw

Bucharest, Romania,
28.06.2009, 13:16
(edited by Khusraw, 28.06.2009, 13:35)

@ marcov

Commercial philosophs

> > Well, then probably I should have added that I probably meant the
> > free software movement, not only GNU.
>
> Is there a difference then?

FSM in its wide meaning represents today a much larger spectrum than GNU/FSF, which is just the principal offshoot. In its narrow and most used meaning it is the same thing with GNU, but I understood cm was refering to the wide meaning, which was not the case.

---
Glory to God for all things

Rugxulo

Usono,
01.07.2009, 22:52

@ Khusraw

Commercial philosophs

The problem with bad licenses is that when it gets abandoned or deprecated, no one else can maintain the program. However, that's assuming anyone actually wants to fix or improve it. If it's "free" in every sense of the word but nobody knows how or wants to mess with it, it's all moot anyways.

I don't recall anybody here ever commenting on my MOSS findings, but it was basically a fully GPL DOS extender, fully built using GPL tools, long since abandoned, originally cross-compiled, and free for commercial use (e.g. used for shareware Inner Worlds game, which is now freeware). This was only possible due to the existence of GCC and BinUtils and FreeBSD (for the libc). I can only guess this was partly in reaction to the (at the time) non-commercial EMX license and/or DJGPPv1 needing Turbo C for building some things (e.g. the stub). It wasn't updated since 1996 (!), and since it needed cross compilation, it got left by the wayside. Worse is that it doesn't easily compile anymore (used old tools), uses AT&T (this was well before .intel_syntax), and the existing dynamic (!) compiler binaries are too old to run on modern distros (libc5, heh). And it has a few bugs (LF not translated to CRLF on screen output), quirks (hard or even impossible to bundle data + .EXE, used old/broken bsdboot???), omissions (no mkdir(), lacking some other functionality which obviously wasn't needed for the Inner Worlds game).

It's more or less obsoleted by DJGPPv2 I guess. Still, it bugs me to let software disappear or "die" for no reason. (GCC 3.3.6 was the last to support the MOSS target. My own DJGPP-hosted compile was of GCC 2.95.3.) Ironically, all this and yet I can't name any other program ever using MOSS (no examples included!). And DJGPP isn't exactly updated much anymore either. Nor is FreeDOS. It doesn't mean they're dead, just that people don't use 'em as much, despite GPL (for good or bad). Ironically, DJGPP stuff is easier to use (IMHO) since it doesn't need a billion extra libs just to run one app.

marcov

25.06.2009, 21:24

@ ecm

GPL user restrictions ?

> > > If they only use a LGPL library for another program, the other
> program
> > > explicitly doesn't have to be GPL.
> >
> > Ah, but then are you are talking about when it is formally a separate
> > library.
>
> I think you meant "library" as in, well, library. A separate binary. Its
> code is called from other programs. GPL source libraries of course can't
> be used for non-GPL programs.

I meant originally more as in a set of reusable routines. Doesn't matter how exactly they are packages. (since if open that can change if not hampered by license)

> > Well, if you mean that about the only use of the LGPL is that it isn't
> > GPL, then you are right
>
> Well, no, I meant that it's only use is that "the other program [using the
> library] explicitly doesn't have to be GPL".

I think we are saying the same thing here :-)

> > If, in your own words, it matters so little to have the source,
>
> First: Not my words. I said for users.

There are no pure users and pure developers. Even people that don't compile themselves might use binaries that are not generated by the original copyrightholder.

> > I wonder why the advocatists are so big on keeping source live.
>
> To keep the program free.

Then why exclude a large section of people? That is not my kind of freedom.

> That's the concept of Copyleft. (Of course
> enforced Copyleft is what prohibits use in proprietary programs, so that's
> what you are criticizing after all.)

Exactly. And I know exactly how it works. The point is that the cure is IMHO worse than the problem.

> And you didn't answer my question.

If you mean this one:

> What do you mean by "never use anything with a
> different license"?

I meant that if you are a mere Linux distro user that has most of the license choices made for him, precooked, then, from that helicopter view everything looks peachy.

> > They cannot for drivers afiaik. The commercial driver must use
> userspace
> > workarounds as a loophole
>
> I don't know. Only thing I heard is that there are some proprietary Linux
> drivers. (BTW, as the FSF says: please
> avoid
> the word "commercial" if you mean non-free software. Commercial free
> software is also possible.)

I use the Websters dictionary, not GNU's. Excluding 99.9% of normal commercial use, and then pointing to a small loophole that is possible is a great for advocatists, and useless for the rest.

> > That's because dos drivers communicate with the kernel over interrupts.
>
> No they don't. Don't let terms like "device strategy and device interrupt
> calls" fool you. They communicate over calls from the kernel directly into
> the device driver's code, which (despite one being called device interrupt)
> don't use any interrupts at all.

Then, if the kernel is GPL, and there are no special conditions, and the devicedrivers are GPL incompatible, to my best knowledge that is a license violation.

> I didn't compare them to either and I don't know more about either anyway.
> I compared DOS drivers to plugins, which I imagine as similar to DLLs. DLLs
> in turn are often used as plugins on Windows, and even with some DOS
> extenders. My intention is this: as close as DOS drivers are to their
> kernel, presumably without being affected by the kernel's GPL, how can the
> GPL affect plugins which technically are much less tied to their main
> program?

If you combine code in pieces to a large work, the larger work is covered by the GPL. The definition is a linking process. If the dos device drivers hook up to the kernel via some linking process rather than a interrupt or a trap, the GPL applies, and it is no different from DLLs.

> So because the DOS driver interface didn't change for 20-what years, any
> DOS driver is linked into/for my GPL DOS kernel?

It could be yes. It depends on how the loading process works exactly. Maybe if they are loaded straight (no relocation, not even segments) and they call fixed numbers in a calltable, a case could be made that no relocation is performed.

> I hope you weren't
> talking about the DOS drivers here anymore, but I won't say writing
> plugins which reside in different binaries as the main program counts as
> linking them together either.

Well, I _explicitely_ asked the GNU foundation that, and I got an e-mail back from Stallmanns secretary, and he stated it is explicitely so.

> > The exact extend to what constitute linking in inter-process
> communcation
> > is not clear to me. It is a gray area.
>
> Which results in that the MPL plugins for the GPL program aren't exactly
> covered by the GPL's Copyleft.

MPL is not GPL compatible. If there is no special exception for the plugin interface, you don't have a license to use GPL code anymore as soon as you combine it with MPL

> > (snip totally random pieces of GPL license text, what were they meant
> to > convey? (pun intended))
>
> First off, I didn't get the pun, maybe because English isn't my first
> language.

(it was a bad pun, convey is about every other word in the GPLv3 text)

> Then, I added these snippets (they're neither total nor random)
> after the discussion of GPL main program vs. MPL/other license plugins.
> Essentially here: since the program only interfaces with the plugin's
> binary while running, you can use the main program disregarding the
> GPL with your incompatible licensed plugins (if the GPL really covers
> that plugins have to be GPL too).

Ah, correct, good point, and one I overlooked. So it only means you can't distribute the program and its plugins (though that was what I said originally about the lazarus case btw)

> > The whole Lazarus example is btw just meant to illustrate that it is
> > pretty hard to forsee the consequences of choosing an extremely
> > restrictive license as GPL.
>
> Oh. Then, I come to the conclusion that I can only agree with you on that:
> it is pretty hard to forsee the consequences of choosing an extremely
> restrictive license. Plus, yes, the GPL is extremely restrictive
> when you want to use source code for proprietary programs.

Well that is the point. You might know that up front. And the GPL is actually of some use in really critical cases. But too much projects and code just gets a GPL slapped on by young idealistic idiots in their student years, when they don't have a clear picture of the daily reality of staying in Open Source after university.

I know. I was one.

It helps tremendously if you can work on some open source bits at work, but that is hard to make that happen if you can't use the result. A few really big corporations can finance the kernel, GCC, KDE and Gnome, no matter the license, for some big spearpoint in their strategies.

But the smaller packages are helped out by developers working in smaller and medium companies, and also by big business more low-profile.

And then the GPL leads to a lot of double work, also in the open source community, by parties that are not as fanatic. And that extra work and limitations caused by that conflict within the open source community hurts open source, not evil commercial companies. (who wouldn't touch either probably because their legal division is paranoid)

ecm

Düsseldorf, Germany,
26.06.2009, 11:27

@ marcov

GPL user restrictions ?

> > > If, in your own words, it matters so little to have the source,
> >
> > First: Not my words. I said for users.
>
> There are no pure users and pure developers. Even people that don't
> compile themselves might use binaries that are not generated by the
> original copyrightholder.

Someone has to compile the binaries and this probably (depending on the difficulty of the compilation, i.e. with DJGPP more difficult than native Linux) counts as "modification", or at least the one compiling them is a developer, in a sense.

> > And you didn't answer my question.
>
> If you mean this one:

Yes, thanks.

> > > They cannot for drivers afiaik. The commercial driver must use
> > userspace
> > > workarounds as a loophole
> >
> > I don't know. Only thing I heard is that there are some proprietary
> Linux
> > drivers.

> Excluding 99.9% of normal
> commercial use, and then pointing to a small loophole that is possible is
> a great for advocatists, and useless for the rest.

Please explain what kind of workaround that is. I imagine it's some hack to talk to the kernel from userspace (or install kernel space drivers from there?), but how does that work fast enough for accelerated hardware such as graphics cards? I heard some Nvidia cards require proprietary drivers.

> > (BTW, as the FSF says: please
> > avoid
> > the word "commercial" if you mean non-free software. Commercial
> free
> > software is also possible.)
>
> I use the Websters dictionary, not GNU's.

Feel free.

> > > That's because dos drivers communicate with the kernel over
> interrupts.
> >
> > No they don't. Don't let terms like "device strategy and device
> interrupt
> > calls" fool you. They communicate over calls from the kernel directly
> into
> > the device driver's code, which (despite one being called device
> interrupt)
> > don't use any interrupts at all.
>
> Then, if the kernel is GPL, and there are no special conditions, and the
> devicedrivers are GPL incompatible, to my best knowledge that is a license
> violation.

Hm. DOS-C (AKA "The FreeDOS Kernel") did this for years. Probably I should ask someone at the FSF about that. For the worst case, I could try to reach Mike to ask for a 2-clause BSD license or so, for RxDOS. This however won't change a thing for DOS-C.

> > So because the DOS driver interface didn't change for 20-what years,
> any
> > DOS driver is linked into/for my GPL DOS kernel?
>
> It could be yes. It depends on how the loading process works exactly.
> Maybe if they are loaded straight (no relocation, not even segments) and
> they call fixed numbers in a calltable, a case could be made that no
> relocation is performed.

So since you (almost) asked for it, I'll bore you with the details: (If you don't want to, you needn't answer this.)

* DOS device drivers can, since MS-DOS 3.00, be available as .COM (flat, up to 64 KiB loaded) or .EXE (simple relocations) file.

* The DOS configuration code apparently uses the EXEC subfunction Int21.4B03, "Load overlay", to load the file (so the loading process is very similar to actual executable loading for process creation).

* A device driver contains one or more device headers. The first one is located at the start of the program image. Two words in the device header specify near offsets to the two different entry points of this device. After calling the first device header's initialization function, DOS checks whether the pointer field (later used to chain all device headers together) was set by the initialization to a valid value. If so, the segment of this pointer is relocated with the current device header's segment, and the pointer is used to get the next device header. Notably, most device drivers don't use multiple device headers.

* After all device headers of this particular device driver were initialized, DOS points the last one to DOS's current "first device header", and the DOS internal "first device header" field is set to the first header of the device driver.

* The actual request of DOS into a device is made up of setting up a pointer (es:bx registers) to a request packet, which resides in DOS internal data (inside the SDA or on DOS stack) and contains parameters such as the request's function number, a block device's unit number and the first requested sector, the requested number of characters/blocks and the transfer address (for the simple read/write functions). DOS first calls the device's "strategy" call (which usually stores the passed pointer in some inreentrant memory location) and then the "interrupt" call immediately afterwards (which reloads the passed pointer from the completely useless memory location), both which are pointed to by a device header field.

> > > (snip totally random pieces of GPL license text, what were they meant
> > to > convey? (pun intended))
> >
> > First off, I didn't get the pun, maybe because English isn't my first
> > language.
>
> (it was a bad pun, convey is about every other word in the GPLv3 text)

Okay, maybe I would've got it if I'd read the full GPL 3 text ever. Last time I cared about license details, it wasn't out yet ;-)

> > Then, I added these snippets (they're neither total nor random)
> > after the discussion of GPL main program vs. MPL/other license plugins.
> > Essentially here: since the program only interfaces with the plugin's
> > binary while running, you can use the main program disregarding the
> > GPL with your incompatible licensed plugins (if the GPL really
> covers
> > that plugins have to be GPL too).
>
> Ah, correct, good point, and one I overlooked. So it only means you can't
> distribute the program and its plugins (though that was what I said
> originally about the lazarus case btw)

Couldn't you distribute them in different packages, then?

> But too much projects and
> code just gets a GPL slapped on by young idealistic idiots in their
> student years, when they don't have a clear picture of the daily reality
> of staying in Open Source after university.
>
> I know. I was one.

Partly, I fear I'm such a young idiot too.

---
l

marcov

26.06.2009, 23:59

@ ecm

GPL user restrictions ?

> > There are no pure users and pure developers. Even people that don't
> > compile themselves might use binaries that are not generated by the
> > original copyrightholder.
>
> Someone has to compile the binaries and this probably (depending on the
> difficulty of the compilation, i.e. with DJGPP more difficult than native
> Linux) counts as "modification", or at least the one compiling them is a
> developer, in a sense.

I was more thinking of feeling the need for modification.

> > Excluding 99.9% of normal
> > commercial use, and then pointing to a small loophole that is possible
> is
> > a great for advocatists, and useless for the rest.
>
> Please explain what kind of workaround that is. I imagine it's some hack
> to talk to the kernel from userspace (or install kernel space drivers from
> there?), but how does that work fast enough for accelerated hardware such
> as graphics cards? I heard some Nvidia cards require proprietary drivers.

Yes, a small open sourced driver in the kernel that talks to a proprietary driver in userland. Per definition, no linking happened. There are performance penalties though. And for Nvidia this is not an issue at all, since X is entirely in userland. (only now this starts to change slowly )

The nvidia driver is more a driver to X than to the kernel. And X is BSD-like licensed.

> > Then, if the kernel is GPL, and there are no special conditions, and
> the
> > devicedrivers are GPL incompatible, to my best knowledge that is a
> license
> > violation.
>
> Hm. DOS-C (AKA "The FreeDOS Kernel") did this for years.

Al Capone also ruled Chicago for years. A fact doesn't make it legal.

> Probably I should
> ask someone at the FSF about that. For the worst case, I could try to reach
> Mike to ask for a 2-clause BSD license or so, for RxDOS. This however won't
> change a thing for DOS-C.

Just mail J. Hall of FreeDos. If I had question he always replied quickly. (usually about FPC problems)

> So since you (almost) asked for it, I'll bore you with the details: (If
> you don't want to, you needn't answer this.)

No problem, I think it is somewhat interesting from a GPL hobbist legal point.

I can actually ask a internet law specialist about it, but then I need some meat first.
(and actually, it is a good example to have a laugh about over a few beers)

> * DOS device drivers can, since MS-DOS 3.00, be available as .COM (flat,
> up to 64 KiB loaded) or .EXE (simple relocations) file.
>
> * The DOS configuration code apparently uses the EXEC subfunction
> Int21.4B03, "Load overlay", to load the file (so the loading process is
> very similar to actual executable loading for process creation).

That means relocation. But not relocation to access the kernel.

> * The actual request of DOS into a device is made up of setting up a
> pointer (es:bx registers) to a request packet, which resides in DOS
> internal data (inside the SDA or on DOS stack) and contains parameters
> such as the request's function number, a block device's unit number and
> the first requested sector, the requested number of characters/blocks and
> the transfer address (for the simple read/write functions). DOS first
> calls the device's "strategy" call (which usually stores the passed
> pointer in some inreentrant memory location) and then the "interrupt" call
> immediately afterwards (which reloads the passed pointer from the
> completely useless memory location), both which are pointed to by a device
> header field.

It comes back to me now. At least the strategy bit rings some long forgotten bell.

To be honest I'm not sure if it is linking in the GPL sense. This is usually described as resolving entry points into the GPLed code. If the driver is only called, and doesn't call DOS via direct calls (only e.g. ints) , it might not be linking.

> > Ah, correct, good point, and one I overlooked. So it only means you
> can't
> > distribute the program and its plugins (though that was what I said
> > originally about the lazarus case btw)
>
> Couldn't you distribute them in different packages, then?

Well, in this case the linking is partially static, so it has to happen before use. And... that requires a lot more stuff.

I'm not even sure if that counts in the dynamic case. All linking is done before you distribute, so you already formed a larger work.

> > But too much projects and
> > code just gets a GPL slapped on by young idealistic idiots in their
> > student years, when they don't have a clear picture of the daily
> reality
> > of staying in Open Source after university.
> >
> > I know. I was one.
>
> Partly, I fear I'm such a young idiot too.

It has its charms. Don't be too eager to leave, but also don't get stuck in it.

rCX

Maryland, USA,
25.06.2009, 18:01

@ marcov

GPL vs. BSD

> A lot of the GPL pain comes from the exclusiveness and the need for every
> party to agree (which essentially means BSD/PD or (L)GPL, excluding all
> hundreds of thousands of other licenses, even some as benign as MPL)
>
> You might go through such trajectory to be able to use a Linux distro on
> some server, but you don't go through it for a 500 piece of code.

Thats why I'm a fan of the WTFPL. It makes everything so much simpler :-P

ecm

Düsseldorf, Germany,
03.05.2018, 12:55

@ ecm

New RxDOS memory subsystem source code

I brought this back to life for lDOS, with a few changes (mostly formatting, using lmacros2 lframe/lenter/lleave/lret, a few bugs).

https://bitbucket.org/ecm/ldos/src/20453a2eb643240084c469fa2133c3643db7f74d/memory.asm

It actually works as expected now, within the RxDOS 7.24 development state. RxDOSMEM is now implemented entirely by calls to this module.

---
l

rr

Berlin, Germany,
28.10.2018, 19:44

@ ecm

New RxDOS memory subsystem source code

> I brought this back to life for lDOS, with a few changes (mostly
> formatting, using lmacros2 lframe/lenter/lleave/lret, a few bugs).
>
> https://bitbucket.org/ecm/ldos/src/20453a2eb643240084c469fa2133c3643db7f74d/memory.asm
>
> It actually works as expected now, within the RxDOS 7.24 development state.
> RxDOSMEM is now implemented entirely by calls to this module.

So I can delete RxDOSMEM-2009-06-15.7z? (I'm cleaning up a few things on my computers and so in my life.)

---
Forum admin

ecm

Düsseldorf, Germany,
05.11.2018, 14:24

@ rr

New RxDOS memory subsystem source code

> So I can delete
> RxDOSMEM-2009-06-15.7z?
> (I'm cleaning up a few things on my computers and so in my life.)

Yes, of course. I'd forgotten about that. (Sorry, I didn't have access to my desktop machine for over a week, only now back.)

---
l

rr

Berlin, Germany,
05.11.2018, 20:52

@ ecm

New RxDOS memory subsystem source code

> > So I can delete
> >
> RxDOSMEM-2009-06-15.7z?
> > (I'm cleaning up a few things on my computers and so in my life.)
>
> Yes, of course. I'd forgotten about that. (Sorry, I didn't have access to
> my desktop machine for over a week, only now back.)

Thanks for your feedback. Done now.

---
Forum admin

Back to index page

22049 Postings in 2034 Threads, 396 registered users, 257 users online (0 registered, 257 guests)
DOS ain't dead | Admin contact

powered by my little forum