-- Original message --
From: "Blair Campbell" <[EMAIL PROTECTED]>
> > Isn't glibc licensed under the Lesser GPL (LGPL) for this very reason?
>
> But a commercial app still cannot _statically_ link to it in that
> case; only dynamically.
> >
> > Mark
No, that's th
Alain M. wrote:
> Mark Bailey escreveu:
>
>> Isn't glibc licensed under the Lesser GPL (LGPL) for this very reason?
>>
>
> There is nowhere to be seen any licence for glibc, not even in it's
> site. But even in LGPL it is a problem: you have to use the systems's
> version and it brings ma
Eric Auer wrote:
>> I would *very much* appreciateit. I did some tests with it and could not
>> make it work, nor did I find a suggested configuration anywhere.
>>
>> BUT: is it working? There was a lot of talk about LFN lately, but I did
>> not find a final diagnostic, just that 1.0 will have it d
At 01:02 AM 8/2/2006 +0400, Arkady V.Belousov wrote:
> Though, I don't understand, why to AVB> duplicate all pops on each exit
> branch, whereas you may just move push "move _pushf_" AVB> after
> other pushes?
Because it was not prone to any introduced error that way. Many pushes in
man
Blair Campbell wrote:
>> Isn't glibc licensed under the Lesser GPL (LGPL) for this very reason?
>>
>
> But a commercial app still cannot _statically_ link to it in that
> case; only dynamically.
>
Specifically, the GNU LGPL says this in its preamble:
> For example, [..] If you link othe
Mark Bailey escreveu:
>
> Isn't glibc licensed under the Lesser GPL (LGPL) for this very reason?
There is nowhere to be seen any licence for glibc, not even in it's
site. But even in LGPL it is a problem: you have to use the systems's
version and it brings many compatibility problems
Alain
> Isn't glibc licensed under the Lesser GPL (LGPL) for this very reason?
But a commercial app still cannot _statically_ link to it in that
case; only dynamically.
>
> Mark
>
> -
> Take Surveys. Earn Cash. Influence the Future
Alain M. wrote:
>
> Arkady V.Belousov escreveu:
>> GPL also free for _any_ use (binaries). And, for example, you may
>> compile commercial apps by GCC.
>
> That is what the comercial says. the hard reality is that you have
> problems with the lib which cannot be used, with GCC you have wo
Arkady V.Belousov escreveu:
>
> GPL also free for _any_ use (binaries). And, for example, you may
> compile commercial apps by GCC.
That is what the comercial says. the hard reality is that you have
problems with the lib which cannot be used, with GCC you have worse
problems with glibc
Hi!
2-Авг-2006 00:53 Arkady V.Belousov wrote to
[email protected]:
MD>> out of memory prematurely when free areas were available. Okay, that was
MD>> worth the entire thread.
AVB> :) And this is FIXED in 2.21. Though, I don't understand, why to
AVB> duplicate all pops on
Hi!
30-Июл-2006 22:32 [EMAIL PROTECTED] (Michael Devore) wrote to
[email protected]:
>>0. In emm386.c you forget remove one space (in "/ *").
MD> And? It's a comment. Is there another one of those #ifdef 0 type
MD> things? Because I'm not ready to debate the style of embedded
> GPL also free for _any_ use (binaries). And, for example, you may
> compile commercial apps by GCC.
BUT IIRC if you compile commercial apps with GCC and don't want to
make source available, you have to dynamically link (not possible
under DOS except with DJGPP)
>
>
Hi!
31-Июл-2006 15:45 [EMAIL PROTECTED] (Alain M.) wrote to
[email protected]:
>> The problem may then be that openwatcom is not GPL licensed. And it is still
>> controlled by a big company that would most likely not want to listen to
>> issues from the FreeDOS project.
AM> I
Hi!
31-Июл-2006 17:32 [EMAIL PROTECTED] (Imre Leber) wrote to
[email protected]:
IL> But still it would have been nice to have this kind of compiler when I was
IL> searching for one before I started writing on FreeDOS. I think this compiler
IL> might even be better than the one
At 12:08 AM 8/1/2006 -0700, Blair Campbell wrote:
>Due to the serious nature of the recent bug reports for the latest
>testing release, I would like to release one more testing release (at
>least) that would hopefully fix the users' problems. (Probably coming
>out tomorrow).
Tangentially related
> One will be the version 1, stable. Same speed, no FAT support. A rather flat
> in your face screen problem with large disks will be fixed in this release
> though, (the one where the screen would be completely filled when you did an
> "unfragment files only" defragmentation).
>
Sounds great!
By now, you are all just wandering what happened to defrag version 1.
Well, I am working on defrag.
There will be two versions out shortly.
One will be the version 1, stable. Same speed, no FAT support. A rather flat in
your face screen problem with large disks will be fixed in this release tho
Alain M. schreef:
> I believe that you are doing the right thing. A stable 1.0 is *very*
> important, just in my opinion, of course ;-)
>
A stable 1.0 is appreciated, for how the public judges on FreeDOS. For
other people it however counts as "hey now we got a stable base platform
we can exte
I believe that you are doing the right thing. A stable 1.0 is *very*
important, just in my opinion, of course ;-)
Alain
Blair Campbell escreveu:
> Due to the serious nature of the recent bug reports for the latest
> testing release, I would like to release one more testing release (at
> least) t
:
: Thanks for the feedback, John, I'll see into this the soonest.
This one:
: > - Something horrible happens to the first codepage loaded the second time
: > it is selected.
looks like it's caused by MoveBufferToSelect copying twice as many bytes
as it should. The real-memory move copies
Due to the serious nature of the recent bug reports for the latest
testing release, I would like to release one more testing release (at
least) that would hopefully fix the users' problems. (Probably coming
out tomorrow). I've implemented free disk space checking in the
installer and I may decide
21 matches
Mail list logo
