So you wish to mash FreeDOS and linux together? If so,I think we can make
that as a DIFFERENT project.It would be interesting to see DOS and Linux
made into one OS.It would be quite amusing to be frank.
On Thu, Oct 1, 2015 at 10:08 AM, Alain Mouette wrote:
> We could work on the LiDOS (Linux + F
We could work on the LiDOS (Linux + FreeDOS) toghether, I have all my
setups annotated and I can share.
Even easier with you as they are in portuguese ;-)
First thing would be to define what will be done...
We could start with a VirtualBox running Ubuntu 14.04 Server, running
FreeDOS at startup.
The bugs are:
1) something in packet driver that interferes with the mouse. I can use
one or the other successfully but not both
2) on 64 bit Linux, the CPU internal timer (a 64 bit register, i don't
remeber the name) is not working.
(1) is annoying but (2) is a showstopper for me and I can only
Oi Alain/All,
Tudo certinho por ai? :)
Well, i think we have different approaches for different needs :P
Alain, while many people dislike the approach you proposed, i can help
updating the distro
That would provide a quick workaround for dosemu users
BTW, what are the bugs that you have found? i
The point is _running DOS programs_
And also having a stable modern platform behind to run on any possible
new hardware (x86)
Alain
On 29-09-2015 22:50, Chelson Aitcheson wrote:
What would be the point of freedos ? Might as well be another Linux distro
On 29/09/2015 1:09 pm, "Geraldo Netto
On Tue, 29 Sep 2015, Mercury Thirteen wrote:
> Agreed. It's better to add more abilities to FreeDOS than to let it fall
> under the Linux umbrella. FreeDOS is a lightweight, nimble OS and it would
> behoove us to not lose its identity under that of another.
Agreed, though I suspect there's not
Haha like
On 30/09/2015 11:58 am, "Mercury Thirteen" wrote:
> In fact, one could make a GNU-style acronym for that: FAL, or *FreeDOS
> ain't Linux*. lol
>
> On 9/29/2015 9:54 PM, JAYDEN CHARBONNEAU wrote:
>
> We aren't linux.We make FreeDOS.Our goal is to make an IBM PC compatible
> OS. :)
>
> On
In fact, one could make a GNU-style acronym for that: FAL, or /FreeDOS
ain't Linux/. lol
On 9/29/2015 9:54 PM, JAYDEN CHARBONNEAU wrote:
We aren't linux.We make FreeDOS.Our goal is to make an IBM PC
compatible OS. :)
On Tue, Sep 29, 2015 at 6:50 PM, Chelson Aitcheson
mailto:chelson.aitche...
Agreed. It's better to add more abilities to FreeDOS than to let it fall
under the Linux umbrella. FreeDOS is a lightweight, nimble OS and it
would behoove us to not lose its identity under that of another.
On 9/29/2015 9:50 PM, Chelson Aitcheson wrote:
What would be the point of freedos ? Mi
We aren't linux.We make FreeDOS.Our goal is to make an IBM PC compatible
OS. :)
On Tue, Sep 29, 2015 at 6:50 PM, Chelson Aitcheson <
chelson.aitche...@gmail.com> wrote:
> What would be the point of freedos ? Might as well be another Linux distro
> On 29/09/2015 1:09 pm, "Geraldo Netto" wrote:
>
What would be the point of freedos ? Might as well be another Linux distro
On 29/09/2015 1:09 pm, "Geraldo Netto" wrote:
> Hi All,
>
> First of all, thank you all very very much for your support :)
> Indeed, i have to follow the whole thread as Eric said
> Also, all tips are very valuable and Edu
Hi Geraldo,
why that instead of making such a big project like exFAT, don't you
consider a FreeDOS distro running on top of Linux?
Dosemu works very well with few bugs (I know of 2 of them) file sharing
is fery nice and fast.
this has already been done before but was abandoned. I use regularly
Hi All,
First of all, thank you all very very much for your support :)
Indeed, i have to follow the whole thread as Eric said
Also, all tips are very valuable and Eduardo even provided a real
project to start :P
Well, i prefer to be low profile/humble to not create much expectations
also because
Hi Jim and Geraldo,
of course I agree that exFAT should be accessed using the
network redirector or CDEX interface: It would be too large
to be in the kernel, should not be carried around with the
kernel all the time and should be kept separately for the
case that there are licensing issues. Howe
Just a couple of comments.
First of all, thanks for volunteering! Stepping up for something like this is
not an easy thing to do, I know. The licensing thing will get managed somehow,
I'm sure.
If you've never written TSR's or device drivers before, this is definitely
"jumping in the deep en
On Sun, Sep 27, 2015 at 5:57 PM, Geraldo Netto wrote:
> Hi All,
>
> I was talking to Eric a few days ago about this exfat thread
> and while we are worried with the license issues
> I would like to volunteer myself to port current exfat from linux
> kernel to freedos
>
> Of course, once it's a no-
On Sun, Sep 27, 2015 at 8:31 PM, Antony Gordon wrote:
>
> With regard to the development environment, Jim has posted somewhere that the
> general development tools are OpenWatcom and NASM. I personally have found
> OpenWatcom a tad bit overwhelming because of all that it can do. If you are
> mo
Hi,
So a cursory read of Wikipedia on this topic (ExFAT) and I stumbled across
this
Two experimental, unofficial solutions are available for DOS. The loadable
USBEXFAT driver requires Panasonic's USB stack for DOS and only works with
USB storage devices; the open-source EXFAT executable is an exF
Hi Geraldo,
> does freedos have any vfs-equivalent interface? which files are involved?
> is Pat's book a valid/current reference to freedos kernel?
> which books would you suggest me to read?
> what is the easiest way to setup the compiler?
>
> i mean, should i setup a freedos vm with with openwa
Open Watcom will generate 16 bit DOS binaries from any host platform that
you run it on. All of my code is developed on Windows 7 using Open Watcom,
generating code for the 16 bit DOS target.
I use DOSbox for quick testing. For this code a virtual machine is
appropriate. Setup networking in the
On Sun, 27 Sep 2015, Antony Gordon wrote:
> Hmmm,
>
> Possibly, BUT the resultant code would still have to be brought back to
> FreeDOS on virtual or real floppy. Might as well develop in a VM under
> FreeDOS.
Well, there's mtools for that. ;)
> OpenWatcom, like I mentioned earlier was too muc
On Sun, 27 Sep 2015, Antony Gordon wrote:
I would advise you to go the route of MSCDEX and use the network
redirector interface. You may want to read Chapter 8 of Undocumented
DOS, 2nd edition to get a feel for the DOS File System and Network
Redirector (assuming you have that book). If you do
Hmmm,
Possibly, BUT the resultant code would still have to be brought back to FreeDOS
on virtual or real floppy. Might as well develop in a VM under FreeDOS.
OpenWatcom, like I mentioned earlier was too much for me, so I went back to my
Borland tools and add defines to cover the bases.
-T
>
On Sunday, September 27, 2015, Antony Gordon wrote:
> Hi,
>
> Unfortunately, Linux doesn’t have a 16-bit C compiler (that I am aware
> of). GCC has some fundamental differences in C dialect from OpenWatcom and
> Borland which would require conditional defines (especially with regard to
> inline a
Hi,
I don’t know too much about the innards of checking in and out code however, if
you have the current version installed, you more than likely have the source
to the current kernel.
I would advise you to go the route of MSCDEX and use the network redirector
interface. You may want to read
Hi All,
Well, i suppose lean fs is not a mainstream filesystem
like the FAT family, ntfs and ext*
Kind Regards,
Geraldo Netto
Sapere Aude => Non dvcor, dvco
São Paulo, Brasil, -3gmt
site: http://exdev.sf.net/
On 27 September 2015 at 22:16, Chelson Aitcheson
wrote:
> Has anyone considered the
Has anyone considered the lean file system at all?
On 25/09/2015 9:13 pm, "Eric Auer" wrote:
>
> Hi Mercury,
>
> (note: 2 GB and one core are no problem even for DOS - but
> for example 8 GB and several cores are supported by almost
> nothing in DOS, as there are no nice DOS extenders for it)
>
>
Hi All,
I was talking to Eric a few days ago about this exfat thread
and while we are worried with the license issues
I would like to volunteer myself to port current exfat from linux
kernel to freedos
Of course, once it's a no-trivial thing i would like to ask your support
i cannot promise anyth
On 9/24/2015 12:33 PM, Mercury Thirteen wrote:
> We could undercut the competition and make our own free FAT
> implementation which does fills the same niche as exFAT.
>
Which will be extremely hard to do without interfering with those patents...
Ralf
---
This email has been checked for viruses b
Hi Mercury,
thanks for having a look at the existing solutions, keep us posted.
Note that HFS+ is by Apple so it will also have license details. As
Linux already supports HFS+ it seems that Apple is friendly on that.
For ext2, note that you may be able to read ext3 and ext4 contents
by compatib
+1
Writing specs is useless if you are not going to put the engineering effort
in.
Let's see FreeDOS 1.2 released sometime soon.
I don't want to sound harsh, but "drawing specs" is easy, anybody can do
that. Do some code that actually works, then we're talking.
Mateusz
On 25/09/2015 03:44, Me
On 9/25/2015 7:12 AM, Eric Auer wrote:
Hi Mercury,
...
As far as I understand, you feel limited by the maximum file
size of 2 or maybe 4 GB and maximum disk size of 2 TB? Then
you may want to start with adding GPT support to the kernel.
Yes. I think it would be a nice addition to FreeDOS to be
Eric,
> as I have noticed that your drivesnapshot website also
> contains tools for exFAT support:
I had almost forgotten it's existence
> What is your opinion
> about possible patent and licensing issues for exFAT?
I can google about as well as you, and read articles like
http://readwrite.com/2
Hi Mercury,
(note: 2 GB and one core are no problem even for DOS - but
for example 8 GB and several cores are supported by almost
nothing in DOS, as there are no nice DOS extenders for it)
> I don't see where we need multitasking for NAS use. A program could be
> made to both handle incoming req
Hi Tom,
as I have noticed that your drivesnapshot website also
contains tools for exFAT support: What is your opinion
about possible patent and licensing issues for exFAT?
Regards, Eric
>> I don't want to sound harsh, but "drawing specs" is easy, anybody can do
>> that. Do some code that actual
> I don't want to sound harsh, but "drawing specs" is easy, anybody can do
> that. Do some code that actually works, then we're talking.
+1
'talk is cheap'
Tom
--
___
Freedo
I don't want to sound harsh, but "drawing specs" is easy, anybody can do
that. Do some code that actually works, then we're talking.
Mateusz
On 25/09/2015 03:44, Mercury Thirteen wrote:
> I don't see where we need multitasking for NAS use. A program could be
> made to both handle incoming requ
I've already had the new kernel successfully probe the entire 2 GB in my
VM. And that's not even with PAE added in yet.
On 9/24/2015 9:23 PM, JAYDEN CHARBONNEAU wrote:
Also,perhaps we should allow our new OS to "see" more RAM and
memory.FreeDOS/DOS only "sees" a specific amount of RAM.I could h
I don't see where we need multitasking for NAS use. A program could be
made to both handle incoming requests while serving data and doing other
tasks, eliminating the need for a proper multitasking kernel. Even if
that was the case, the bloat of the Linux kernel would make it
prohibitive in cer
Also,perhaps we should allow our new OS to "see" more RAM and
memory.FreeDOS/DOS only "sees" a specific amount of RAM.I could have 5GB of
RAM,and it will only read 1MB,and so on with the computer cores.
On Thu, Sep 24, 2015 at 6:21 PM, JAYDEN CHARBONNEAU <
jcharbonnea...@cpsge.org> wrote:
> First
First thing I noticed (This may be just me.),is that we need more memory
for the OS environment.Normally,when I boot FreeDOS on ANY computer (Be it
modern or old),the memory is always 601 MB free.More memory would be needed
for a bigger file system and multi-tasking.
On Thu, Sep 24, 2015 at 5:54 P
Hi Mercury,
so you want to run a NAS or home automation on DOS?
For NAS, you need a multitasking OS, not DOS. For
home automation, which limitation of FAT would be
a problem? Same for other light embedded devices.
Flash does not give good performance for FAT, but
embedded devices would have bee
That's all pretty true, but the way I see it, it doesn't matter - all
the smartphones, cameras, MP3 players, etc. can use whatever stupidly
encumbered format they wish.
Undaunted, we can offer a new FAT to modernize the existing aged FAT
variants, and folks are free to use it (or not) as they s
Hi Steve & Mercury,
>> While I agree that further information would be welcome,
>> I am generally optimistic about possibilities for exFAT.
>
> ...prolly best still to leave it to the network redirector, and keep it
> out of the kernel proper, just in case.
>
> But perhaps it could be provided
On Thu, 24 Sep 2015, Eric Auer wrote:
> And remember my original posts in this thread, or to be more
> exact, the references from the Wikipedia article about the
> licensing issue:
>
> http://sfconservancy.org/news/2013/aug/16/exfat-samsung/
>
> "Conservancy is delighted that the correct outcome h
On Thu, 24 Sep 2015, Jim Hall wrote:
> On Thu, Sep 24, 2015 at 2:33 PM, Mercury Thirteen
> wrote:
>> We could undercut the competition and make our own free FAT
>> implementation which does fills the same niche as exFAT.
>>
>
>
> I think that's a great idea! I encourage any interested developer t
I could write up a spec, but I don't have the time to make a full blown
implementation at this point.
I hope "remain compatible with DOS" does not equal "remain compatible
with FAT 12/16/32" since the implementation I was envisioning would not
offer any backward compatibility. Drives formatted
mail
x-111
===
> -Original Message-
> From: Mercury Thirteen [mailto:mercury0x0...@gmail.com]
> Sent: Thursday, September 24, 2015 3:33 PM
> To: Technical discussion and questions for FreeDOS developers.
> Subject: Re: [Freedos-devel] exfat support from android linux for
&
Hi FreeDOS-ers,
> We could undercut the competition and make our own free FAT
> implementation which does fills the same niche as exFAT.
Extremely unlikely to succeed! For example OGG Vorbis audio
works very well and is free but still companies rather pay
to license MP3. On Sony Smart TV (using
On Thu, Sep 24, 2015 at 2:33 PM, Mercury Thirteen
wrote:
> We could undercut the competition and make our own free FAT
> implementation which does fills the same niche as exFAT.
>
I think that's a great idea! I encourage any interested developer to
write such an implementation.
A key to success
We could undercut the competition and make our own free FAT
implementation which does fills the same niche as exFAT.
On 9/24/2015 3:22 PM, Jim Hall wrote:
> My understanding is similar to Bret's. Also, I understand the exFAT
> implementation on Android and other platforms was derived and licensed
My understanding is similar to Bret's. Also, I understand the exFAT
implementation on Android and other platforms was derived and licensed
from Microsoft. It is patent-encumbered, and therefore cannot be
merged with FreeDOS (or any code distributed under the GNU GPL, for
example.) I would be very c
Delving further into the story it looks like Samsung licensed it legally from
MS and then a Samsung employee (illegally?) uploaded it to github. It all seems
pretty sketchy to me.
Do you really believe MS would give anything it still considers proprietary to
Linux (or Samsung or ...) for PR?
__
I think he meant "file system", not "file".
> -Original Message-
> From: Ralf Quint [mailto:freedos...@gmail.com]
> Sent: Wednesday, September 23, 2015 9:14 PM
> To: freedos-devel@lists.sourceforge.net
> Subject: Re: [Freedos-devel] exfat support fr
ret Johnson [mailto:bretj...@juno.com]
> Sent: Wednesday, September 23, 2015 7:59 PM
> To: freedos-devel@lists.sourceforge.net
> Subject: Re: [Freedos-devel] exfat support from android linux for
> freedos sdxc support and more?
>
> It's very interesting that Linux appears
Hi Ralf,
> ExFAT is indeed covered by Microsoft patents, the Samsung driver is said
> to be in violation of those and should be avoided at all cost if you
> don't want to risk patent litigation with M$ at some point...
>
> http://techrights.org/2013/07/25/joosun-hahn-gpl-violations-and-samsung
On 9/23/2015 6:11 PM, JAYDEN CHARBONNEAU wrote:
> Story of the century:The FreeDOS project sued by M$ for using a simple
> 16 bit file that is outdated.I would have a good laugh at that
> one.Then again,it wouldn't be very funny...
>
What outdated 16 bit file? :?
Bottom line, I would not recomme
Story of the century:The FreeDOS project sued by M$ for using a simple 16
bit file that is outdated.I would have a good laugh at that one.Then
again,it wouldn't be very funny...
On Wed, Sep 23, 2015 at 5:31 PM, Ralf Quint wrote:
> On 9/23/2015 2:45 PM, Eric Auer wrote:
> > Hi again,
> >
> >> May
On 9/23/2015 2:45 PM, Eric Auer wrote:
> Hi again,
>
>> Maybe some DOSers want to have a look at the exFAT driver code,
>> to check complexity: https://github.com/dorimanx/exfat-nofuse
> Some other interesting links are:
>
> https://github.com/relan/exfat
>
> and:
>
> https://en.wikipedia.org/wiki/
It's very interesting that Linux appears to have a legitimately licensed
implementation, which I think means they had to pay some money to MS? Could
that license (via GPL?) perhaps be extended to downstream implementations based
on it, like FreeDOS?
The licensing implications are certainly a c
Hi again,
> Maybe some DOSers want to have a look at the exFAT driver code,
> to check complexity: https://github.com/dorimanx/exfat-nofuse
Some other interesting links are:
https://github.com/relan/exfat
and:
https://en.wikipedia.org/wiki/ExFAT#Adoption
which states that one of the drivers
On Wed, 23 Sep 2015, Eric Auer wrote:
> Hi, I noticed that since 2013, there is free open source exFAT
> support for Linux, originally coming from Android, in spite of
> exFAT being quite proprietary...
IIRC, it's worse than proprietary, it's encumbered, right?
-uso.
---
Hi, I noticed that since 2013, there is free open source exFAT
support for Linux, originally coming from Android, in spite of
exFAT being quite proprietary... However, as memory cards above
32 GB size and probably other (embedded) devices will probably
use exFAT more often in the future, would it
63 matches
Mail list logo
