>>> Hope you don't mind me to ask, why didn't you rather contribute to
>>> FreeDOS?
First, I do sometimes contribute to FreeDOS (i.e. DEVLOAD) and sometimes
even to the thing called "FreeDOS kernel" (or DOS-C), which is to be
distinguished from FreeDOS as a project. However I choosed not to
Christian Masloch schrieb:
> Besides, I'm too egoistic to write or re-write major parts
> of something when this new version isn't accepted because it isn't tested
> enough. That was the case with the "unstable" DOS-C version 2037 (which
> had many features version 2036 and the upcoming 2038
Hi!
It has been a while I am searching a good DOS gopher client, but can't find
anything really worth noticing...
Does anybody know some good gopher clients working on FreeDOS? By "good", I
mean runing with WatTCP, not crashing randomly the whole system and having a
nice interface (may be text
>> Hope you don't mind me to ask, why didn't you rather contribute to FreeDOS?
> But he DOES contribute to FreeDOS: once the few remaining bugs are fixed in
> the RxDOS kernel, it will replace the inferior current FD kernel.
why do you think that the RxDOS kernel is superior - besides having
man
> First, I do sometimes contribute to FreeDOS (i.e. DEVLOAD) and sometimes
> even to the thing called "FreeDOS kernel" (or DOS-C), which is to be
> distinguished from FreeDOS as a project. However I choosed not to become a
> developer of DOS-C (FreeDOS kernel) because it's design is to be written
> That was the case with the "unstable" DOS-C version 2037 (which
> had many features version 2036 and the upcoming 2038 don't have).
I forgot to mention:
2038 is 'upcoming' since about 2 years. it's probable stable (the last
changes were done by Bart, no Arkady in sight ), most likely better t
Hi Tom,
>> That was the case with the "unstable" DOS-C version 2037 (which
>> had many features version 2036 and the upcoming 2038 don't have).
>
> I forgot to mention:
> 2038 is 'upcoming' since about 2 years. it's probable stable
> (the last changes were done by Bart, no Arkady in sight ),
> mo
Hi guys,
uhm, i can't say that much once i'm just a newbie, but
on kernel side would be possible to track all those 'bad' changes?
btw, Arkady, are you there?
maybe you can comment out it, please note, i'm not saying it to create
a flamewar
but instead say:
'hey guys, some people disagree with som
> also many things are running in background :)
> just ask Eric, Mateusz, Rugxulo, Blair, ...
That's probably one of FreeDOS's problems: there's ony guy - I don't want to
be more specific - who forces all communication into private mails. This makes
the current FD status absolutely intransparen
> why do you think that the RxDOS kernel is superior - besides having
> many more bugs ?
What about built-in support for LFN?
--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With
Hi Geraldo,
> uhm, i can't say that much once i'm just a newbie, but
> on kernel side would be possible to track all those 'bad'
> changes?
Please use the new kernel 2037 thread for this :-)
> btw, Arkady, are you there?
I hope so :-)
> maybe you can comment out it, please note, i'm not sayin
Hi,
>> Besides, I'm too egoistic to write or re-write major parts
>> of something when this new version isn't accepted because it
>> isn't tested enough. That was the case with the "unstable"
>> DOS-C version 2037
> this entire bullshit.
> 2037 has been tested, and the results say 'unstable'
Ok
Hi Japheth,
>> also many things are running in background :)
>> just ask Eric, Mateusz, Rugxulo, Blair, ...
>
> That's probably one of FreeDOS's problems: there's
> only one guy - I don't want to be more specific - who
> forces all communication into private mails. This
> makes the current FD sta
Eric Auer schrieb:
> Hi Japheth,
>
>>> also many things are running in background :)
>>> just ask Eric, Mateusz, Rugxulo, Blair, ...
>> That's probably one of FreeDOS's problems: there's
>> only one guy - I don't want to be more specific - who
>> forces all communication into private mails. This
>
> Does anybody know why we assumed that all compilers except
> MS C (which almost nobody uses for the kernel) would init
> BSS to 0, while at least the often-used OpenWatcom does not?
a) ALL compilers initialize BSS to 0
b) ALL compilers do this in the RTL startup code
c) there is no RTL startup
I use lynx for most dos web browsing, it works with all kinds of urls,
including gopher.
The version I use is from fdisk.com, he no longer updates/fixes it,
but it's still a fairly stable release.
--
Create and Deploy
>> Is it possible to inject eltorito.sys and shsucdx into the kernel?
>
> You would need eltorito.sys source code first, and have
> to be aware that shsucdx is about 8 kB (6 kB UPXed, 6 kB
> or more in RAM depending on how you load it). All this
> would have to fit (preferably) into the resident-in
Hi,
>>> Is it possible to inject eltorito.sys and shsucdx into the kernel?
>>
>> You would need eltorito.sys source code first, and have
>> to be aware that shsucdx is about 8 kB...
> You could just add both binaries to the kernel binary, then
> let the CONFIG.SYS parser/init code load them if d
18 matches
Mail list logo
