Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Alain Mouette]

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...

But then I don't know how to make a distribution CD... anyone?

Alain

On 01-10-2015 00:23, Geraldo Netto wrote:
> 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? it is easily reproducible?
> Did you report it to Bart ("Bart Olderman")?
>
> Besides your approach there is the approach proposed by Joe
> And yet the cdex extention
>
> Let's keep track on all :P
>
>
> Kind Regards,
>
> Geraldo Netto
> Sapere Aude => Non dvcor, dvco
> São Paulo, Brasil, -3gmt
> site: http://exdev.sf.net/
>
>
> On 30 September 2015 at 20:36, Alain Mouette  wrote:
>> 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"  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 Eduardo even provided a real
>>> project to start :P
>>>
>>> Well, i prefer to be low profile/humble to not create much expectations
>>> also because i'm mainly used to java/python which is way different from c
>>> and i have no experience with asm so, i'll have a long learning curve
>>>
>>>
>>> Thank You Very Much and Kind Regards,
>>>
>>> Geraldo Netto
>>> Sapere Aude => Non dvcor, dvco
>>> São Paulo, Brasil, -3gmt
>>> site: http://exdev.sf.net/
>>>
>>> On 28 September 2015 at 18:20, Eric Auer  wrote:
 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. However, all of this
 has been mentioned earlier in this thread. Geraldo, I know
 that you did not receive the first few mails here by mail,
 so please go to the freedos-devel web archive to read the
 earlier mails, including useful links to code and info. For
 example VMSMOUNT for VMWare drives is a nice DOS driver :-)

 Cheers, Eric

>> So, what do you think?
>> what is the svn link to checkout the freedos kernel code? [...]
> If you decide to write an exFAT implementation, I ask that you *not*
> put this into the FreeDOS kernel directly. Rather, this should be
> implemented as an external driver. As others have already pointed out,
> there are patent concerns with this. [...]




 --
 ___
 Freedos-devel mailing list
 Freedos-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-devel
>>>
>>> --
>>> ___
>>> Freedos-devel mailing list
>>> Freedos-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>>
>>
>> --
>>
>>
>>
>> ___
>> Freedos-devel mailing list
>> Freedos-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>>
>>
>>
>> --
>>
>> ___
>> Freedos-devel mailing list
>> Freedos-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>>
> --
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Alain Mouette]

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 use on 32 
bit Linux

There are also a few display/keyboard bugs for which I have patches that 
I need to apply and compile my owm dosemu.
One is for screen resolution, one is for the / and ? key that exists 
only on the brazilian notebook keyboard.
IIRC another is to make NDN work but is not really fixed, just a 
work-around that works fine.

I have reported it a lonk time ago but as I am not a regular 
contributor, I got no answer

Alain

On 01-10-2015 00:23, Geraldo Netto wrote:
> 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? it is easily reproducible?
> Did you report it to Bart ("Bart Olderman")?
>
> Besides your approach there is the approach proposed by Joe
> And yet the cdex extention
>
> Let's keep track on all :P
>
>
> Kind Regards,
>
> Geraldo Netto
> Sapere Aude => Non dvcor, dvco
> São Paulo, Brasil, -3gmt
> site: http://exdev.sf.net/
>
>
> On 30 September 2015 at 20:36, Alain Mouette  wrote:
>> 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"  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 Eduardo even provided a real
>>> project to start :P
>>>
>>> Well, i prefer to be low profile/humble to not create much expectations
>>> also because i'm mainly used to java/python which is way different from c
>>> and i have no experience with asm so, i'll have a long learning curve
>>>
>>>
>>> Thank You Very Much and Kind Regards,
>>>
>>> Geraldo Netto
>>> Sapere Aude => Non dvcor, dvco
>>> São Paulo, Brasil, -3gmt
>>> site: http://exdev.sf.net/
>>>
>>> On 28 September 2015 at 18:20, Eric Auer  wrote:
 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. However, all of this
 has been mentioned earlier in this thread. Geraldo, I know
 that you did not receive the first few mails here by mail,
 so please go to the freedos-devel web archive to read the
 earlier mails, including useful links to code and info. For
 example VMSMOUNT for VMWare drives is a nice DOS driver :-)

 Cheers, Eric

>> So, what do you think?
>> what is the svn link to checkout the freedos kernel code? [...]
> If you decide to write an exFAT implementation, I ask that you *not*
> put this into the FreeDOS kernel directly. Rather, this should be
> implemented as an external driver. As others have already pointed out,
> there are patent concerns with this. [...]




 --
 ___
 Freedos-devel mailing list
 Freedos-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-devel
>>>
>>> --
>>> ___
>>> Freedos-devel mailing list
>>> Freedos-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>>
>>
>> --
>>
>>
>>
>> ___
>> Freedos-devel mailing list
>> Freedos-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>>
>>
>>
>> --
>>
>> ___
>> Freedos-devel mailing list
>> Freedos-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>>
> --
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> 

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[JAYDEN CHARBONNEAU]

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 + 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...
>
> But then I don't know how to make a distribution CD... anyone?
>
> Alain
>
> On 01-10-2015 00:23, Geraldo Netto wrote:
> > 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? it is easily reproducible?
> > Did you report it to Bart ("Bart Olderman")?
> >
> > Besides your approach there is the approach proposed by Joe
> > And yet the cdex extention
> >
> > Let's keep track on all :P
> >
> >
> > Kind Regards,
> >
> > Geraldo Netto
> > Sapere Aude => Non dvcor, dvco
> > São Paulo, Brasil, -3gmt
> > site: http://exdev.sf.net/
> >
> >
> > On 30 September 2015 at 20:36, Alain Mouette  wrote:
> >> 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"  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 Eduardo even provided a real
> >>> project to start :P
> >>>
> >>> Well, i prefer to be low profile/humble to not create much expectations
> >>> also because i'm mainly used to java/python which is way different
> from c
> >>> and i have no experience with asm so, i'll have a long learning curve
> >>>
> >>>
> >>> Thank You Very Much and Kind Regards,
> >>>
> >>> Geraldo Netto
> >>> Sapere Aude => Non dvcor, dvco
> >>> São Paulo, Brasil, -3gmt
> >>> site: http://exdev.sf.net/
> >>>
> >>> On 28 September 2015 at 18:20, Eric Auer  wrote:
>  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. However, all of this
>  has been mentioned earlier in this thread. Geraldo, I know
>  that you did not receive the first few mails here by mail,
>  so please go to the freedos-devel web archive to read the
>  earlier mails, including useful links to code and info. For
>  example VMSMOUNT for VMWare drives is a nice DOS driver :-)
> 
>  Cheers, Eric
> 
> >> So, what do you think?
> >> what is the svn link to checkout the freedos kernel code? [...]
> > If you decide to write an exFAT implementation, I ask that you *not*
> > put this into the FreeDOS kernel directly. Rather, this should be
> > implemented as an external driver. As others have already pointed
> out,
> > there are patent concerns with this. [...]
> 
> 
> 
> 
> 
> --
>  ___
>  Freedos-devel mailing list
>  Freedos-devel@lists.sourceforge.net
>  https://lists.sourceforge.net/lists/listinfo/freedos-devel
> >>>
> >>>
> --
> >>> ___
> >>> Freedos-devel mailing list
> >>> Freedos-devel@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/freedos-devel
> >>
> >>
> >>
> --
> >>
> >>
> >>
> >> ___
> >> Freedos-devel mailing list
> >> Freedos-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/freedos-devel
> >>
> >>
> >>
> >>
> --
> >>
> >> ___
> >> Freedos-devel mailing list
> >> Freedos-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/freedos-devel
> >>
> >
> 

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Alain Mouette]

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" > 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 Eduardo even provided a real
project to start :P

Well, i prefer to be low profile/humble to not create much
expectations
also because i'm mainly used to java/python which is way different
from c
and i have no experience with asm so, i'll have a long learning curve


Thank You Very Much and Kind Regards,

Geraldo Netto
Sapere Aude => Non dvcor, dvco
São Paulo, Brasil, -3gmt
site: http://exdev.sf.net/

On 28 September 2015 at 18:20, Eric Auer > wrote:
>
> 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. However, all of this
> has been mentioned earlier in this thread. Geraldo, I know
> that you did not receive the first few mails here by mail,
> so please go to the freedos-devel web archive to read the
> earlier mails, including useful links to code and info. For
> example VMSMOUNT for VMWare drives is a nice DOS driver :-)
>
> Cheers, Eric
>
>>> So, what do you think?
>>> what is the svn link to checkout the freedos kernel code? [...]
>
>> If you decide to write an exFAT implementation, I ask that you
*not*
>> put this into the FreeDOS kernel directly. Rather, this should be
>> implemented as an external driver. As others have already
pointed out,
>> there are patent concerns with this. [...]
>
>
>
>
>

--
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net

> https://lists.sourceforge.net/lists/listinfo/freedos-devel


--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/freedos-devel



--


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel


--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Geraldo Netto]

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? it is easily reproducible?
Did you report it to Bart ("Bart Olderman")?

Besides your approach there is the approach proposed by Joe
And yet the cdex extention

Let's keep track on all :P


Kind Regards,

Geraldo Netto
Sapere Aude => Non dvcor, dvco
São Paulo, Brasil, -3gmt
site: http://exdev.sf.net/


On 30 September 2015 at 20:36, Alain Mouette  wrote:
> 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"  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 Eduardo even provided a real
>> project to start :P
>>
>> Well, i prefer to be low profile/humble to not create much expectations
>> also because i'm mainly used to java/python which is way different from c
>> and i have no experience with asm so, i'll have a long learning curve
>>
>>
>> Thank You Very Much and Kind Regards,
>>
>> Geraldo Netto
>> Sapere Aude => Non dvcor, dvco
>> São Paulo, Brasil, -3gmt
>> site: http://exdev.sf.net/
>>
>> On 28 September 2015 at 18:20, Eric Auer  wrote:
>> >
>> > 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. However, all of this
>> > has been mentioned earlier in this thread. Geraldo, I know
>> > that you did not receive the first few mails here by mail,
>> > so please go to the freedos-devel web archive to read the
>> > earlier mails, including useful links to code and info. For
>> > example VMSMOUNT for VMWare drives is a nice DOS driver :-)
>> >
>> > Cheers, Eric
>> >
>> >>> So, what do you think?
>> >>> what is the svn link to checkout the freedos kernel code? [...]
>> >
>> >> If you decide to write an exFAT implementation, I ask that you *not*
>> >> put this into the FreeDOS kernel directly. Rather, this should be
>> >> implemented as an external driver. As others have already pointed out,
>> >> there are patent concerns with this. [...]
>> >
>> >
>> >
>> >
>> >
>> > --
>> > ___
>> > Freedos-devel mailing list
>> > Freedos-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/freedos-devel
>>
>>
>> --
>> ___
>> Freedos-devel mailing list
>> Freedos-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
>
>
> --
>
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
>
>
> --
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>

--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Chelson Aitcheson]

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 Eduardo even provided a real
> project to start :P
>
> Well, i prefer to be low profile/humble to not create much expectations
> also because i'm mainly used to java/python which is way different from c
> and i have no experience with asm so, i'll have a long learning curve
>
>
> Thank You Very Much and Kind Regards,
>
> Geraldo Netto
> Sapere Aude => Non dvcor, dvco
> São Paulo, Brasil, -3gmt
> site: http://exdev.sf.net/
>
> On 28 September 2015 at 18:20, Eric Auer  wrote:
> >
> > 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. However, all of this
> > has been mentioned earlier in this thread. Geraldo, I know
> > that you did not receive the first few mails here by mail,
> > so please go to the freedos-devel web archive to read the
> > earlier mails, including useful links to code and info. For
> > example VMSMOUNT for VMWare drives is a nice DOS driver :-)
> >
> > Cheers, Eric
> >
> >>> So, what do you think?
> >>> what is the svn link to checkout the freedos kernel code? [...]
> >
> >> If you decide to write an exFAT implementation, I ask that you *not*
> >> put this into the FreeDOS kernel directly. Rather, this should be
> >> implemented as an external driver. As others have already pointed out,
> >> there are patent concerns with this. [...]
> >
> >
> >
> >
> >
> --
> > ___
> > Freedos-devel mailing list
> > Freedos-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
>
> --
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Steve Nickolas]

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 too many people left using it outside 
of dosemu and similar (pity, really - the 8088 side of FreeDOS is the most 
important part imo and oughtn't be left to just rot).

-uso.

--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Alain Mouette]

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 
both Linux and Dosemu with FreeDOS ans I am willing to help...

Alain


On 29-09-2015 00:08, 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 Eduardo even provided a real
> project to start :P
>
> Well, i prefer to be low profile/humble to not create much expectations
> also because i'm mainly used to java/python which is way different from c
> and i have no experience with asm so, i'll have a long learning curve
>
>
> Thank You Very Much and Kind Regards,
>
> Geraldo Netto
> Sapere Aude => Non dvcor, dvco
> São Paulo, Brasil, -3gmt
> site: http://exdev.sf.net/
>
> On 28 September 2015 at 18:20, Eric Auer  wrote:
>> 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. However, all of this
>> has been mentioned earlier in this thread. Geraldo, I know
>> that you did not receive the first few mails here by mail,
>> so please go to the freedos-devel web archive to read the
>> earlier mails, including useful links to code and info. For
>> example VMSMOUNT for VMWare drives is a nice DOS driver :-)
>>
>> Cheers, Eric
>>
 So, what do you think?
 what is the svn link to checkout the freedos kernel code? [...]
>>> If you decide to write an exFAT implementation, I ask that you *not*
>>> put this into the FreeDOS kernel directly. Rather, this should be
>>> implemented as an external driver. As others have already pointed out,
>>> there are patent concerns with this. [...]
>>
>>
>>
>> --
>> ___
>> Freedos-devel mailing list
>> Freedos-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freedos-devel
> --
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Chelson Aitcheson]

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 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:
>>
>>> 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 i'm mainly used to java/python which is way different from c
>>> and i have no experience with asm so, i'll have a long learning curve
>>>
>>>
>>> Thank You Very Much and Kind Regards,
>>>
>>> Geraldo Netto
>>> Sapere Aude => Non dvcor, dvco
>>> São Paulo, Brasil, -3gmt
>>> site: http://exdev.sf.net/
>>>
>>> On 28 September 2015 at 18:20, Eric Auer  wrote:
>>> >
>>> > 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. However, all of this
>>> > has been mentioned earlier in this thread. Geraldo, I know
>>> > that you did not receive the first few mails here by mail,
>>> > so please go to the freedos-devel web archive to read the
>>> > earlier mails, including useful links to code and info. For
>>> > example VMSMOUNT for VMWare drives is a nice DOS driver :-)
>>> >
>>> > Cheers, Eric
>>> >
>>> >>> So, what do you think?
>>> >>> what is the svn link to checkout the freedos kernel code? [...]
>>> >
>>> >> If you decide to write an exFAT implementation, I ask that you *not*
>>> >> put this into the FreeDOS kernel directly. Rather, this should be
>>> >> implemented as an external driver. As others have already pointed out,
>>> >> there are patent concerns with this. [...]
>>> >
>>> >
>>> >
>>> >
>>> >
>>> --
>>> > ___
>>> > Freedos-devel mailing list
>>> > Freedos-devel@lists.sourceforge.net
>>> > https://lists.sourceforge.net/lists/listinfo/freedos-devel
>>>
>>>
>>> --
>>> ___
>>> Freedos-devel mailing list
>>> Freedos-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>>>
>>
>>
>> --
>>
>> ___
>> Freedos-devel mailing list
>> Freedos-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>>
>>
>
>
> --
>
>
>
> ___
> Freedos-devel mailing 
> listFreedos-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/freedos-devel
>
>
>
>
> --
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
>
--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Mercury Thirteen]

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 ? 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 Eduardo even provided a real
project to start :P

Well, i prefer to be low profile/humble to not create much
expectations
also because i'm mainly used to java/python which is way different
from c
and i have no experience with asm so, i'll have a long learning curve


Thank You Very Much and Kind Regards,

Geraldo Netto
Sapere Aude => Non dvcor, dvco
São Paulo, Brasil, -3gmt
site: http://exdev.sf.net/

On 28 September 2015 at 18:20, Eric Auer > wrote:
>
> 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. However, all of this
> has been mentioned earlier in this thread. Geraldo, I know
> that you did not receive the first few mails here by mail,
> so please go to the freedos-devel web archive to read the
> earlier mails, including useful links to code and info. For
> example VMSMOUNT for VMWare drives is a nice DOS driver :-)
>
> Cheers, Eric
>
>>> So, what do you think?
>>> what is the svn link to checkout the freedos kernel code? [...]
>
>> If you decide to write an exFAT implementation, I ask that you
*not*
>> put this into the FreeDOS kernel directly. Rather, this should be
>> implemented as an external driver. As others have already
pointed out,
>> there are patent concerns with this. [...]
>
>
>
>
>

--
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net

> https://lists.sourceforge.net/lists/listinfo/freedos-devel


--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/freedos-devel



--


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel


--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[JAYDEN CHARBONNEAU]

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:
>
>> 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 i'm mainly used to java/python which is way different from c
>> and i have no experience with asm so, i'll have a long learning curve
>>
>>
>> Thank You Very Much and Kind Regards,
>>
>> Geraldo Netto
>> Sapere Aude => Non dvcor, dvco
>> São Paulo, Brasil, -3gmt
>> site: http://exdev.sf.net/
>>
>> On 28 September 2015 at 18:20, Eric Auer  wrote:
>> >
>> > 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. However, all of this
>> > has been mentioned earlier in this thread. Geraldo, I know
>> > that you did not receive the first few mails here by mail,
>> > so please go to the freedos-devel web archive to read the
>> > earlier mails, including useful links to code and info. For
>> > example VMSMOUNT for VMWare drives is a nice DOS driver :-)
>> >
>> > Cheers, Eric
>> >
>> >>> So, what do you think?
>> >>> what is the svn link to checkout the freedos kernel code? [...]
>> >
>> >> If you decide to write an exFAT implementation, I ask that you *not*
>> >> put this into the FreeDOS kernel directly. Rather, this should be
>> >> implemented as an external driver. As others have already pointed out,
>> >> there are patent concerns with this. [...]
>> >
>> >
>> >
>> >
>> >
>> --
>> > ___
>> > Freedos-devel mailing list
>> > Freedos-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/freedos-devel
>>
>>
>> --
>> ___
>> Freedos-devel mailing list
>> Freedos-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>>
>
>
> --
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
>
--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Jim Hall]

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 
> more familiar with the Borland C compilers, you can use those, however, I 
> would STRONGLY suggest gratuitous use of conditional defines and such to make 
> the code more compatible for the final OpenWatcom build.
>



Yes, you are referring to the FreeDOS Spec, from the FreeDOS Wiki:
http://freedos.sourceforge.net/wiki/index.php/FreeDOS_Spec


>>>
*Programming languages*

We prefer that all FreeDOS programs be written in either C or
Assembly. Certainly all FreeDOS "Base" programs (those programs that
reproduce the functionality of MS-DOS) must be written in either C or
Assembly.

Use of any language when writing extensions is implied, although we
strongly recommend that you stick with either C or Assembly.

*Programming tools*

Our reference C compiler is OpenWatcom C. (Borland C 3.1 was
originally chosen as the reference standard because this is the
compiler used to build the FreeDOS kernel. However, it is preferable
to use entirely free tools to create FreeDOS.)

Our reference Assembler is NASM. (Microsoft MASM was the original
reference standard because of the general availability of
MASM-compatible assemblers, but NASM is now the preferred tool.)

This does not mean that everyone must use these tools to contribute to
FreeDOS. That would be counterproductive, as many users may prefer
other programs. Rather, this means that any C code must be compilable
on OpenWatcom C, and all Assembly must be assemble-able on NASM. Good
programming habits such as wise use of #ifdef statements will allow
you to do this.

If you are working with the kernel, FreeCOM, Install, or Mem - these
projects are hosted in the FreeDOS source code repository, and you
should use Subversion to manage this code.
<<<


OpenWatcom is the reference compiler. That doesn't mean that all
FreeDOS projects must be written in OpenWatcom if they are written in
C, just that we prefer that C programs should compile on OpenWatcom.
If you use a different compiler, that is your choice, but it would be
great to be able to compile all FreeDOS programs with the same
compiler. Wise use of #ifdef's will help with this.

--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Eric Auer]

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. However, all of this
has been mentioned earlier in this thread. Geraldo, I know
that you did not receive the first few mails here by mail,
so please go to the freedos-devel web archive to read the
earlier mails, including useful links to code and info. For
example VMSMOUNT for VMWare drives is a nice DOS driver :-)

Cheers, Eric

>> So, what do you think?
>> what is the svn link to checkout the freedos kernel code? [...]

> If you decide to write an exFAT implementation, I ask that you *not*
> put this into the FreeDOS kernel directly. Rather, this should be
> implemented as an external driver. As others have already pointed out,
> there are patent concerns with this. [...]




--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Jim Hall]

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-trivial thing i would like to ask your support
> i cannot promise anything by now, once i know that talk is cheap as
> Mateusz and Tom reported :)
>
> So, what do you think?
> what is the svn link to checkout the freedos kernel code?
[..]


If you decide to write an exFAT implementation, I ask that you *not*
put this into the FreeDOS kernel directly. Rather, this should be
implemented as an external driver. As others have already pointed out,
there are patent concerns with this. We cannot have distribution of
the FreeDOS kernel impeded by patents. The FreeDOS kernel needs to
remain free of this.

--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Antony Gordon]

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 exFAT
filesystem reader, and requires the HX DOS

extender
to work.[48]  There are
no native exFAT real-mode DOS drivers, which would allow usage of, or
booting from exFAT volumes

Also Mac OS X 10.5 and later can read/write and repair exFAT, quite
possibly a solution there as well with minimal rewriting.

-T

On Sun, Sep 27, 2015 at 11:43 PM Eduardo Casino 
wrote:

> 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 openwatcom or freeware
> > version of tc
> > or do we have a way to 'cross-compile' freedos kernel on linux and use
> > the vm just to test the code?
>
> You can have a look at vmsmount sources. A lot of the generic network
> redirector code can be reused and it is written for Openwatcom. You can
> cross compile from Windows or Linux and, if you use vmware and vmsmount,
> you can share a folder with a FreeDOS vm, which will ease a lot your
> testing.
>
> http://sourceforge.net/projects/vmsmount/
>
> Good luck,
> Eduardo.
>
> --
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Bret Johnson]

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 end."  Writing TSR's is very different than writing 
"regular" programs, so I would suggest that you experiment with a "simple" TSR 
first.  There are lots of "gotcha's" in TSR's that don't exist in other 
programs, and the only way you really learn them is with experience (screwing 
things up and then troubleshooting).

The other thing I'll mention is that a lot of people seem to recommend using 
the network interface (Installable File System) as the way to "bridge" between 
DOS and the (currently) foreign file system.  That is certainly one way to do 
it, and may ultimately prove to be the best way, but there are many factors to 
consider.  One thing to consider is whether doing so will make the driver 
incompatible with DOS's Buffers and Caching mechanisms (both for FreeDOS and 
other DOS's as well).  As I mentioned earlier, you also need to consider 
whether this would make it incompatible with removable disks.  USB (removable) 
disks, e.g., is one of the primary places where exFAT is intended to be and 
will be installed.

The other major area where compatibility is a consideration is in the disk 
maintenance utilities, like DEFRAG & CHKDSK (and their clones).  Those types of 
programs don't work with network disks, so if there is any intent on adding 
exFAT support to those utilities, a network interface may not necessarily be a 
good choice.

Again, I need to say that a network interface may indeed be the best option -- 
I'm not really sure.  There are pluses and minuses to a network interface, and 
lots of things to consider besides the fact that a network interface might be 
"easier" to implement.

Buffett’s New Enemy
Buffett just confirmed his worst fear. Click here for his warning.
http://thirdpartyoffers.juno.com/TGL3141/5609ae3149f522e312747st04vuc

--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Geraldo Netto]

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 i'm mainly used to java/python which is way different from c
and i have no experience with asm so, i'll have a long learning curve


Thank You Very Much and Kind Regards,

Geraldo Netto
Sapere Aude => Non dvcor, dvco
São Paulo, Brasil, -3gmt
site: http://exdev.sf.net/

On 28 September 2015 at 18:20, Eric Auer  wrote:
>
> 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. However, all of this
> has been mentioned earlier in this thread. Geraldo, I know
> that you did not receive the first few mails here by mail,
> so please go to the freedos-devel web archive to read the
> earlier mails, including useful links to code and info. For
> example VMSMOUNT for VMWare drives is a nice DOS driver :-)
>
> Cheers, Eric
>
>>> So, what do you think?
>>> what is the svn link to checkout the freedos kernel code? [...]
>
>> If you decide to write an exFAT implementation, I ask that you *not*
>> put this into the FreeDOS kernel directly. Rather, this should be
>> implemented as an external driver. As others have already pointed out,
>> there are patent concerns with this. [...]
>
>
>
>
> --
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel

--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Geraldo Netto]

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 anything by now, once i know that talk is cheap as
Mateusz and Tom reported :)

So, what do you think?
what is the svn link to checkout the freedos kernel code?
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 openwatcom or freeware
version of tc
or do we have a way to 'cross-compile' freedos kernel on linux and use
the vm just to test the code?

Suggestions are always very welcomed :P


Kind Regards,

Geraldo Netto
Sapere Aude => Non dvcor, dvco
São Paulo, Brasil, -3gmt
site: http://exdev.sf.net/

On 25 September 2015 at 19:14, Ralf Quint  wrote:
> 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 by Avast antivirus software.
> https://www.avast.com/antivirus
>
>
> --
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel

--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Antony Gordon]

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 Sep 27, 2015, at 9:45 PM, Louis Santillan  wrote:
> 
> 
> 
> 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 
> assembly) and GCC doesn’t support 16-bit OBJ files as a target, mostly COFF 
> and ELF binaries which will not work on DOS (at least at the 8/16-bit level).
> 
> Can't openwatcom on Linux generate 16-bit dos binaries? 
> --
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel

--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Michael Brutman]

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 virtual machine or some sort of host
/ guest shared drive and the file transfer becomes less painful.

If anybody has questions about Open Watcom I'm happy to share what I know.
Yes, there is a learning curve.  But it is worth it.
--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Chelson Aitcheson]

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)
>
> > 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
>
> You would still have to have several files and networking
> connections open at the same time and preferably transfer
> data from several files in parallel. In Linux, you can do
> that with good performance, but DOS performance is limited
> because your server must not do concurrent kernel calls.
>
> > that was the case, the bloat of the Linux kernel would
> > make it prohibitive in certain applications.
>
> Give an example for that - Linux can even run as embedded
> operating system on SD cards with built-in Wifi / WLAN :-)
> I mean on tiny computers of the size of an actual SD card!
>
> > I will draw up a spec as I said when I get the time. After that,
> > implementation is up to the rest of the community. We could just
> > as easily go with FAT+ or not advance the filesystem at all.
>
> 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.
>
> Another issue is that FAT32 has bad performance and that the
> FAT way of doing LFN is rather ugly internally as well. Which
> other improvements do you have in mind for your new format?
>
>
>
> And of course: Please really have a look at EXISTING formats
> to avoid re-inventing the wheel. Maybe ext2/3/4 already has
> what you need while allowing a relatively small driver, too?
>
> https://en.wikipedia.org/wiki/Comparison_of_file_systems#Limits
>
> https://en.wikipedia.org/wiki/FATX#Derivatives
> (only FAT+ as used on some DR variants might be a bit useful)
>
> https://en.wikipedia.org/wiki/HFS_Plus#Linux
>
> https://en.wikipedia.org/wiki/Ext2 (ext3/ext4 are more complex)
>
> Even a more complete UDF implementation might be cool for flash
> next to DVD: https://en.wikipedia.org/wiki/Universal_Disk_Format
>
> Plus some other filesystems which seemed "too licensed" or too
> complex and too feature rich to me, so start reading as above.
> For example ZFS & Btrfs are probably too comprehensive for DOS.
>
> For general FS inspiration, a Be File System book and overview:
>
> http://www.nobius.org/~dbg/
> http://arstechnica.com/open-source/news/2010/06/the-beos-filesystem.ars
>
> In short, I guess ext2 and HFS+ might be good choices for "being
> the next filesystem to have improved free DOS drivers available"?
> See also some already existing filesystem drivers for those two:
>
> http://www.catacombae.org/hfsexplorer/
>
> http://www.ext2fsd.com/?page_id=2 which is downloadable from:
> http://sourceforge.net/projects/ext2fsd/files/
>
> http://uranus.chrysocome.net/linux/ext2ifs.htm
>
> http://www.ibiblio.org/filesystems/howto/Filesystems-HOWTO-6.html
> ftp://sunsite.unc.edu/pub/Linux/system/filesystems/ext2/
>
> Cheers, Eric
>
>
>
> PS: Level 3 of ISO9660 also sounds nice, do DOS drivers support it?
> https://en.wikipedia.org/wiki/ISO_9660
>
> PPS: Does anybody still have a new copy of the ext2 DOS "LTOOLS"?
> The download is no longer available after 18 years due to EOL. The
> http://www.ibiblio.org/pub/linux/utils/dos/ copy is old, from 2001.
>
>
>
>
> --
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Antony Gordon]

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 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 don’t have that book, then Google the DOS redirector 
interface, which appeared in DOS at version 3.1

That will give you some useful tidbits and examples on understanding system 
file tables (SFT), the current directory structures (CDS), and how things like 
NETX, SHARE, and ASSIGN (for example) work.

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 
more familiar with the Borland C compilers, you can use those, however, I would 
STRONGLY suggest gratuitous use of conditional defines and such to make the 
code more compatible for the final OpenWatcom build.

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 assembly) 
and GCC doesn’t support 16-bit OBJ files as a target, mostly COFF and ELF 
binaries which will not work on DOS (at least at the 8/16-bit level).

I have a VirtualBox VM with FreeDOS installed that I can zip up and throw in my 
Dropbox if you’d like.

-T
> On Sep 27, 2015, at 6: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-trivial thing i would like to ask your support
> i cannot promise anything by now, once i know that talk is cheap as
> Mateusz and Tom reported :)
> 
> So, what do you think?
> what is the svn link to checkout the freedos kernel code?
> 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 openwatcom or freeware
> version of tc
> or do we have a way to 'cross-compile' freedos kernel on linux and use
> the vm just to test the code?
> 
> Suggestions are always very welcomed :P
> 
> 
> Kind Regards,
> 
> Geraldo Netto
> Sapere Aude => Non dvcor, dvco
> São Paulo, Brasil, -3gmt
> site: http://exdev.sf.net/
> 
> On 25 September 2015 at 19:14, Ralf Quint  wrote:
>> 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 by Avast antivirus software.
>> https://www.avast.com/antivirus
>> 
>> 
>> --
>> ___
>> Freedos-devel mailing list
>> Freedos-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freedos-devel
> 
> --
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Geraldo Netto]

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 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)
>>
>> > 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
>>
>> You would still have to have several files and networking
>> connections open at the same time and preferably transfer
>> data from several files in parallel. In Linux, you can do
>> that with good performance, but DOS performance is limited
>> because your server must not do concurrent kernel calls.
>>
>> > that was the case, the bloat of the Linux kernel would
>> > make it prohibitive in certain applications.
>>
>> Give an example for that - Linux can even run as embedded
>> operating system on SD cards with built-in Wifi / WLAN :-)
>> I mean on tiny computers of the size of an actual SD card!
>>
>> > I will draw up a spec as I said when I get the time. After that,
>> > implementation is up to the rest of the community. We could just
>> > as easily go with FAT+ or not advance the filesystem at all.
>>
>> 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.
>>
>> Another issue is that FAT32 has bad performance and that the
>> FAT way of doing LFN is rather ugly internally as well. Which
>> other improvements do you have in mind for your new format?
>>
>>
>>
>> And of course: Please really have a look at EXISTING formats
>> to avoid re-inventing the wheel. Maybe ext2/3/4 already has
>> what you need while allowing a relatively small driver, too?
>>
>> https://en.wikipedia.org/wiki/Comparison_of_file_systems#Limits
>>
>> https://en.wikipedia.org/wiki/FATX#Derivatives
>> (only FAT+ as used on some DR variants might be a bit useful)
>>
>> https://en.wikipedia.org/wiki/HFS_Plus#Linux
>>
>> https://en.wikipedia.org/wiki/Ext2 (ext3/ext4 are more complex)
>>
>> Even a more complete UDF implementation might be cool for flash
>> next to DVD: https://en.wikipedia.org/wiki/Universal_Disk_Format
>>
>> Plus some other filesystems which seemed "too licensed" or too
>> complex and too feature rich to me, so start reading as above.
>> For example ZFS & Btrfs are probably too comprehensive for DOS.
>>
>> For general FS inspiration, a Be File System book and overview:
>>
>> http://www.nobius.org/~dbg/
>> http://arstechnica.com/open-source/news/2010/06/the-beos-filesystem.ars
>>
>> In short, I guess ext2 and HFS+ might be good choices for "being
>> the next filesystem to have improved free DOS drivers available"?
>> See also some already existing filesystem drivers for those two:
>>
>> http://www.catacombae.org/hfsexplorer/
>>
>> http://www.ext2fsd.com/?page_id=2 which is downloadable from:
>> http://sourceforge.net/projects/ext2fsd/files/
>>
>> http://uranus.chrysocome.net/linux/ext2ifs.htm
>>
>> http://www.ibiblio.org/filesystems/howto/Filesystems-HOWTO-6.html
>> ftp://sunsite.unc.edu/pub/Linux/system/filesystems/ext2/
>>
>> Cheers, Eric
>>
>>
>>
>> PS: Level 3 of ISO9660 also sounds nice, do DOS drivers support it?
>> https://en.wikipedia.org/wiki/ISO_9660
>>
>> PPS: Does anybody still have a new copy of the ext2 DOS "LTOOLS"?
>> The download is no longer available after 18 years due to EOL. The
>> http://www.ibiblio.org/pub/linux/utils/dos/ copy is old, from 2001.
>>
>>
>>
>>
>> --
>> ___
>> Freedos-devel mailing list
>> Freedos-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
>
> --
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>

--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Steve Nickolas]

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 much for me, so I went back 
> to my Borland tools and add defines to cover the bases.

I too am more comfortable with Borland if only because I can't do the 
equivalent of the stuff supported in Borland's conio library through 
Watcom's.

(btw, DJGPP supports a Borland-compatible conio library with gcc.)

-uso.

--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Eduardo Casino]

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 openwatcom or freeware
> version of tc
> or do we have a way to 'cross-compile' freedos kernel on linux and use
> the vm just to test the code?

You can have a look at vmsmount sources. A lot of the generic network
redirector code can be reused and it is written for Openwatcom. You can
cross compile from Windows or Linux and, if you use vmware and vmsmount,
you can share a folder with a FreeDOS vm, which will ease a lot your
testing.

http://sourceforge.net/projects/vmsmount/

Good luck,
Eduardo.
--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Louis Santillan]

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 assembly) and GCC doesn’t support 16-bit OBJ files as a target,
> mostly COFF and ELF binaries which will not work on DOS (at least at the
> 8/16-bit level).
>

Can't openwatcom on Linux generate 16-bit dos binaries?
--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Steve Nickolas]

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 don’t have that book, 
then Google the DOS redirector interface, which appeared in DOS at 
version 3.1


I *absolutely* concur.  If it's a plug-in module from a third-party source 
then FreeDOS isn't responsible for any patent violations - and the network 
redirector route (as above, à la MSCDEX) is how to do that.


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 assembly) and GCC doesn’t support 16-bit OBJ files as a 
target, mostly COFF and ELF binaries which will not work on DOS (at 
least at the 8/16-bit level).


You can run OpenWatcom on Linux.  At one point I crosscompiled a few 
pieces of another DOS version with it.


-uso.--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Mercury Thirteen]

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 able to 
finally work with large files. For some of today's files (archives and 
entire system images come to mind) 4 GB just isn't enough.



Another issue is that FAT32 has bad performance and that the
FAT way of doing LFN is rather ugly internally as well. Which
other improvements do you have in mind for your new format?
The internals are /quite/ ugly, which is why I would opt to break 
compatibility with the old FAT variants and restructure any possible new 
format as efficiently as possible.



And of course: Please really have a look at EXISTING formats
to avoid re-inventing the wheel. Maybe ext2/3/4 already has
what you need while allowing a relatively small driver, too?

https://en.wikipedia.org/wiki/Comparison_of_file_systems#Limits

https://en.wikipedia.org/wiki/FATX#Derivatives
(only FAT+ as used on some DR variants might be a bit useful)

https://en.wikipedia.org/wiki/HFS_Plus#Linux

https://en.wikipedia.org/wiki/Ext2 (ext3/ext4 are more complex)

Even a more complete UDF implementation might be cool for flash
next to DVD: https://en.wikipedia.org/wiki/Universal_Disk_Format

Plus some other filesystems which seemed "too licensed" or too
complex and too feature rich to me, so start reading as above.
For example ZFS & Btrfs are probably too comprehensive for DOS.

For general FS inspiration, a Be File System book and overview:

http://www.nobius.org/~dbg/
http://arstechnica.com/open-source/news/2010/06/the-beos-filesystem.ars

In short, I guess ext2 and HFS+ might be good choices for "being
the next filesystem to have improved free DOS drivers available"?
See also some already existing filesystem drivers for those two:

http://www.catacombae.org/hfsexplorer/

http://www.ext2fsd.com/?page_id=2 which is downloadable from:
http://sourceforge.net/projects/ext2fsd/files/

http://uranus.chrysocome.net/linux/ext2ifs.htm

http://www.ibiblio.org/filesystems/howto/Filesystems-HOWTO-6.html
ftp://sunsite.unc.edu/pub/Linux/system/filesystems/ext2/

...


Thanks for the links! Lots of info, although I've checked some of it out 
already. HFS+ may be a good option, I'll have to look into it.
--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Eric Auer]

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 requests while serving data and doing other
> tasks, eliminating the need for a proper multitasking kernel. Even if

You would still have to have several files and networking
connections open at the same time and preferably transfer
data from several files in parallel. In Linux, you can do
that with good performance, but DOS performance is limited
because your server must not do concurrent kernel calls.

> that was the case, the bloat of the Linux kernel would
> make it prohibitive in certain applications.

Give an example for that - Linux can even run as embedded
operating system on SD cards with built-in Wifi / WLAN :-)
I mean on tiny computers of the size of an actual SD card!

> I will draw up a spec as I said when I get the time. After that,
> implementation is up to the rest of the community. We could just
> as easily go with FAT+ or not advance the filesystem at all.

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.

Another issue is that FAT32 has bad performance and that the
FAT way of doing LFN is rather ugly internally as well. Which
other improvements do you have in mind for your new format?



And of course: Please really have a look at EXISTING formats
to avoid re-inventing the wheel. Maybe ext2/3/4 already has
what you need while allowing a relatively small driver, too?

https://en.wikipedia.org/wiki/Comparison_of_file_systems#Limits

https://en.wikipedia.org/wiki/FATX#Derivatives
(only FAT+ as used on some DR variants might be a bit useful)

https://en.wikipedia.org/wiki/HFS_Plus#Linux

https://en.wikipedia.org/wiki/Ext2 (ext3/ext4 are more complex)

Even a more complete UDF implementation might be cool for flash
next to DVD: https://en.wikipedia.org/wiki/Universal_Disk_Format

Plus some other filesystems which seemed "too licensed" or too
complex and too feature rich to me, so start reading as above.
For example ZFS & Btrfs are probably too comprehensive for DOS.

For general FS inspiration, a Be File System book and overview:

http://www.nobius.org/~dbg/
http://arstechnica.com/open-source/news/2010/06/the-beos-filesystem.ars

In short, I guess ext2 and HFS+ might be good choices for "being
the next filesystem to have improved free DOS drivers available"?
See also some already existing filesystem drivers for those two:

http://www.catacombae.org/hfsexplorer/

http://www.ext2fsd.com/?page_id=2 which is downloadable from:
http://sourceforge.net/projects/ext2fsd/files/

http://uranus.chrysocome.net/linux/ext2ifs.htm

http://www.ibiblio.org/filesystems/howto/Filesystems-HOWTO-6.html
ftp://sunsite.unc.edu/pub/Linux/system/filesystems/ext2/

Cheers, Eric



PS: Level 3 of ISO9660 also sounds nice, do DOS drivers support it?
https://en.wikipedia.org/wiki/ISO_9660

PPS: Does anybody still have a new copy of the ext2 DOS "LTOOLS"?
The download is no longer available after 18 years due to EOL. The
http://www.ibiblio.org/pub/linux/utils/dos/ copy is old, from 2001.



--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Michael Brutman]

+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, Mercury Thirteen wrote:
> 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 certain applications. Sure, you could compile your own
> slimmed version specific for the task, but DOS' lightweight requirements
> and comparatively speediness make it the clear out-of-the-box winner.
>
> An improved FAT was something I planned for eventual use with the 32-bit
> kernel we're creating. Perhaps it's best to keep it that way since
> regular DOS (as Eric points out) is not that well suited for the job
> being sans-multitasking as it is.
>
> I will draw up a spec as I said when I get the time. After that,
> implementation is up to the rest of the community. We could just as
> easily go with FAT+ or not advance the filesystem at all.
>
> On 9/24/2015 9:21 PM, JAYDEN CHARBONNEAU wrote:
>> 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 PM, Eric Auer > > wrote:
>>
>>
>> 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 been free to use one
>> of many available Linux filesystems. But did not.
>>
>> Of course the question can be extended: What if an
>> existing nicer-than-FAT filesystem is used more in
>> DOS? Have a look at what already EXISTS for Linux,
>> then have a look at the source code to check which
>> filesystems are 1. simple enough to make a "light"
>> DOS driver possible (some might even be so simple
>> that booting DOS from them is feasible, but only a
>> really popular filesystem may get kernel drivers),
>> 2. better than FAT in some way (e.g. more speed on
>> flash storage, better space allocation or LFN in a
>> less insane way than VFAT) but 3. not putting lots
>> of code into features which mean nothing for DOS,
>> such as ACL based file permissions or extreme file
>> or disk size support beyond existing FAT32 API or
>> "network redirector" API expressible number range.
>>
>> Looking forward to your review of existing FS-es!
>>
>> Of course with an outlook towards which properties
>> a not-yet-existing FS could have to be even nicer
>> for use within a DOS based storage "ecosystem".
>>
>> Cheers, Eric
>>
>> PS: By "light", I mean a driver which is not 100s
>> of kilobytes in size and which can be fast with a
>> bit of DOS RAM and XMS instead of needing 500 MB
>> of DPMI RAM and protected mode implementation :-)
>>
>>
>>
>> > NAS devices, home automation computers and other similar devices
are
>> > becoming increasingly common, and offering a filesystem finally
>> capable
>> > of handling the sizes of modern hard drives could be a welcome
>> > improvement for them, and just may help get FreeDOS used in a
>> wider market.
>> >
>> > How do we know this isn't a chicken-and-egg problem? Maybe all the
>> > devices only use the proprietary exFAT because there was no open
>> > alternative. Maybe, had there been one available, we would all...



--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Eric Auer]

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 compatibility, but must not write to such partitions with ext2-
only drivers and tools...



I agree that FAT LFN are super ugly implementation wise. I do not
agree that file sizes above 2 GB are super important. You say it
is good for archives and disk images. Which archive would pile up
so much data in one file? For disk images, you should also have a
way to MOUNT them. Which would have to support large sizes. Or at
least tools to access (read and maybe even write) files on them.

For example I myself have 10 files of 2 GB or larger 7 of which are
4 GB or larger, usually ISO9660 images or tarballs of large piles of
files, such as entire Ubuntu Linux distros or backups. All less than
8 GB, by the way. To backup an entire drive, I would just copy that
as-is to another drive and NOT try to make a 500 GB tarball. Because
accessing files INSIDE such a 500 GB tarball would be very slow :-p

If I had only DOS and no Linux, I would have DOS DVD burning tools
and WGET style software which can split ISO images in 2 GB chunks.

And I would use more but smaller ZIPs for backing up certain things.
In short, I myself do not feel a big urge to have huge file support
everywhere in my operating system and software, but it does not hurt.



Besides, I think that FAT+ is an okay idea for the special needs of
ISO image handling (store only the low 32 bits of file size in the
directory entry of flagged-as-huge files, check FAT chain length to
figure out actual size) when you only have a few extra large files.

And talking about ISO, I repeat that super complete UDF support for
DOS would be cool :-) But then, almost nobody even burns CD or DVD
in DOS, so complete UDF read support might be sufficient. I really
wonder whether UDF is useful as filesystem for flash storage media?

Cheers, Eric

PS Tom: What are the abilities and license of your 2010 exFAT tool?



> Yes. I think it would be a nice addition to FreeDOS to be able to
> finally work with large files. For some of today's files (archives and
> entire system images come to mind) 4 GB just isn't enough.

> The [LFN] internals are /quite/ ugly, which is why I would opt to break
> compatibility with the old FAT variants and restructure any possible new
> format as efficiently as possible.

>> https://en.wikipedia.org/wiki/HFS_Plus#Linux

>> https://en.wikipedia.org/wiki/Universal_Disk_Format

>> http://www.catacombae.org/hfsexplorer/

> Thanks for the links! Lots of info, although I've checked some of it
> out already. HFS+ may be a good option, I'll have to look into it.




--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Ralf Quint]

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 by Avast antivirus software.
https://www.avast.com/antivirus


--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Mateusz Viste]

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 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 certain applications. Sure, you could compile your own
> slimmed version specific for the task, but DOS' lightweight requirements
> and comparatively speediness make it the clear out-of-the-box winner.
>
> An improved FAT was something I planned for eventual use with the 32-bit
> kernel we're creating. Perhaps it's best to keep it that way since
> regular DOS (as Eric points out) is not that well suited for the job
> being sans-multitasking as it is.
>
> I will draw up a spec as I said when I get the time. After that,
> implementation is up to the rest of the community. We could just as
> easily go with FAT+ or not advance the filesystem at all.
>
> On 9/24/2015 9:21 PM, JAYDEN CHARBONNEAU wrote:
>> 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 PM, Eric Auer > > wrote:
>>
>>
>> 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 been free to use one
>> of many available Linux filesystems. But did not.
>>
>> Of course the question can be extended: What if an
>> existing nicer-than-FAT filesystem is used more in
>> DOS? Have a look at what already EXISTS for Linux,
>> then have a look at the source code to check which
>> filesystems are 1. simple enough to make a "light"
>> DOS driver possible (some might even be so simple
>> that booting DOS from them is feasible, but only a
>> really popular filesystem may get kernel drivers),
>> 2. better than FAT in some way (e.g. more speed on
>> flash storage, better space allocation or LFN in a
>> less insane way than VFAT) but 3. not putting lots
>> of code into features which mean nothing for DOS,
>> such as ACL based file permissions or extreme file
>> or disk size support beyond existing FAT32 API or
>> "network redirector" API expressible number range.
>>
>> Looking forward to your review of existing FS-es!
>>
>> Of course with an outlook towards which properties
>> a not-yet-existing FS could have to be even nicer
>> for use within a DOS based storage "ecosystem".
>>
>> Cheers, Eric
>>
>> PS: By "light", I mean a driver which is not 100s
>> of kilobytes in size and which can be fast with a
>> bit of DOS RAM and XMS instead of needing 500 MB
>> of DPMI RAM and protected mode implementation :-)
>>
>>
>>
>> > NAS devices, home automation computers and other similar devices are
>> > becoming increasingly common, and offering a filesystem finally
>> capable
>> > of handling the sizes of modern hard drives could be a welcome
>> > improvement for them, and just may help get FreeDOS used in a
>> wider market.
>> >
>> > How do we know this isn't a chicken-and-egg problem? Maybe all the
>> > devices only use the proprietary exFAT because there was no open
>> > alternative. Maybe, had there been one available, we would all...



--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Tom Ehlert]

> 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


--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Eric Auer]

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 actually works, then we're talking.

> +1
> 'talk is cheap'
> Tom



--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Tom Ehlert]

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/2013/01/22/open-source-file-system-takes-on-microsofts-exfat-patents
no idea what the outcome will be at the end.

however the discussion is completely pointless as there will NEVER be
an exfat system for freedos;

> I will draw up a spec as I said when I get the time. After that,
> implementation is up to the rest of the community.

there is no large crowd of bored developers, waiting for some
superintelligent guy appearing out of thin air to
hand them a spec so they can finally start to work on something useful

mercury needs some reality check

Tom


--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Eric Auer]

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-samsungs-microsoft-patent-trap-in-linux-exfat/

The slightly newer article here:

http://sfconservancy.org/news/2013/aug/16/exfat-samsung/

... sounds as there has been serious work on the licensing,
to make the Samsung driver less trap and more open source?

Regards, Eric

PS: Maybe something to ask Shane Coughlan / FSF / ... about?



--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Dave Kerber]

Just because there is a legal license doesn't mean any money was involved.
It could have been granted free for PR purposes, there might have been
some kind of cross-licensing agreement, or there might be some restrictive
conditions on its use.


> -Original Message-
> From: Bret 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 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 consideration, though less
> of a concern to me than the technical piece of it.  The main thing I
> would like to see in a DOS implementation would be the flexibility to
> do "plug-and-play" with the disks.  The main need for this would of
> course be USB disks, but could also apply to any other type of
> removable media that may come down the pike (for example, DVD-RAMs
> which can be formatted with hard drive file systems like FAT32 and
> exFAT).
>
> At a minimum, this would mean that the functionality would need to
> exist in the OS (or in a device driver / TSR of some sort) even if no
> exFAT disk was found at boot time (or when the driver was installed).
> In addition, there should be some sort of system call to identify that
> the functionality is installed so other software would know whether
> it's OK to mount the exFAT volume(s) when new media is inserted.
> 
> Want to place your ad here?
> Advertise on United Online
> http://thirdpartyoffers.juno.com/TGL3141/56033d0b9e4c3d0a34d1st04vuc
>
> ---
> ---
> Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
> Get real-time metrics from all of your servers, apps and tools
> in one place.
> SourceForge users - Click here to start your Free Trial of Datadog now!
> http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel

--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Dave Kerber]

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 from android linux for
> freedos sdxc support and more?
>
> 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 recommend to touch the Samsung ExFAT code on
> GitHub, just as I would not recommend to touch any of the leaked MS-DOS
> source code...
>
> Ralf
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
>
> ---
> ---
> Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
> Get real-time metrics from all of your servers, apps and tools
> in one place.
> SourceForge users - Click here to start your Free Trial of Datadog now!
> http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel

--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Eric Auer]

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 Android Linux tech)
you can NOT use OGG in the media player, but it does work
in the image gallery: In other words, in spite of having a
free support in the software, they deliberately removed it
from the media player, only forgot their image viewer :-p



In the case of exFAT, the thing apparently works well, better
than classic FAT32. Plus it ships with millions of cameras,
smartphones and other SDXC enabled software, as well as the
millions of SDXC cards in those devices, which are factory-
formatted to exFAT and (see my original question) might even
get confused when you re-format them to, for example, FAT32.

Of course, nobody stops you from reformatting your storage
to FAT or even ext2/ext3/ext4 or similar filesystems. Well,
apart from your camera or smartphone stopping to support
them in that case, if you are unlucky. Next you could root
those and install Cyanogen or similar OS, but mortals are
not going to take that effort. They will just give you the
SDXC card with their pictures and laugh at you if your VERY
FREE operating system is FREE of the ability to open them.



Regarding Jim's and Bret's comments, I would like to add this:

Remember the old VFAT or "FAT32" discussion. There, in the
end, it turned out that usage was explicitly allowed for a
generic operating system like Linux or DOS!

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 has been
reached: a legitimate, full release from Samsung of all
relevant source code under the terms of Linux's license,
the GPL, version 2."

This does not tell whether you might have to pay licensing
fees when using a Linux with that driver for making some
embedded device, but for using it for interoperability in
a general operating system, I would be optimistic. Also,
nothing in the driver seems to talk about it and even in
Ubuntu, you have the driver in official repositories with
no special warnings about needing a license to use them.

While I agree that further information would be welcome,
I am generally optimistic about possibilities for exFAT.

Regards, Eric



> 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
>> 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 concerned about any effort to put exFAT
>> support directly into the FreeDOS kernel.
>>
>> However, doing a little googling, I found that this developer has
>> created an exFAT reader as a separately-loaded driver:
>> http://www.mdgx.com/secrets.htm#XFAT
>>
>> If you want exFAT support in FreeDOS, I would use that.
>>
>> But include exFAT in FreeDOS? I don't think so; I prefer to avoid the 
>> lawsuit.
>>
>> Jim




--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Bret Johnson]

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?

Buffett’s New Enemy
Buffett just confirmed his worst fear. Click here for his warning.
http://thirdpartyoffers.juno.com/TGL3141/560434241fc153423751cst01duc--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Dave Kerber]

Because it's a Patent (rather than a trade secret or copyright) issue, you
ALSO have to be sure you don't do things the same way the patent does.
That is still infringement even if you do it completely independently.


===
David C. Kerber
WRA in-house e-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
> freedos sdxc support and more?
>
> 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
> > 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 concerned about any effort to put exFAT
> > support directly into the FreeDOS kernel.
> >
> > However, doing a little googling, I found that this developer has
> > created an exFAT reader as a separately-loaded driver:
> > http://www.mdgx.com/secrets.htm#XFAT
> >
> >
> > If you want exFAT support in FreeDOS, I would use that.
> >
> > But include exFAT in FreeDOS? I don't think so; I prefer to avoid the
> lawsuit.
> >
> >
> > Jim
> >
> > -
> -
> > ___
> > Freedos-devel mailing list
> > Freedos-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
>
> ---
> ---
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel

--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Mercury Thirteen]

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
> 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 concerned about any effort to put exFAT
> support directly into the FreeDOS kernel.
>
> However, doing a little googling, I found that this developer has
> created an exFAT reader as a separately-loaded driver:
> http://www.mdgx.com/secrets.htm#XFAT
>
>
> If you want exFAT support in FreeDOS, I would use that.
>
> But include exFAT in FreeDOS? I don't think so; I prefer to avoid the lawsuit.
>
>
> Jim
>
> --
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Mercury Thirteen]

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 in this FAT version 
would not be able to be read by any other DOS version without a software 
module to do so. That sucks for compatibility zealots but, as is said, 
sometimes to go forwards you must first go backwards.

Merc

On 9/24/2015 3:47 PM, 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 to
> write such an implementation.
>
> A key to success is to remain compatible with DOS, and to offer wide
> support so others can merge this implementation to other systems. If
> such a FAT implementation were available only on DOS, but not on Linux
> or Mac or Windows, not many will adopt it.
>
> --
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Eric Auer]

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 as a TSR; and a card reader, or such, 
> treated as a floppy drive.  Fixed letter, but when there's no card in the 
> slot, Not ready reading drive X: Abort, Retry, Fail?

Of course - that is exactly what I suggested exactly 24 hours
ago. Actually normal FAT (12, 16, "32") is the only system
which is simplistic enough for the kernel while all others
are better in separately loaded drivers... :-)



To answer Mercuries mail as well:

> 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 in this FAT version 
> would not be able to be read by any other DOS version without a software 
> module to do so. That sucks for compatibility zealots but, as is said, 
> sometimes to go forwards you must first go backwards.

Well you can try to go forwards, but what use is a cool gadget
when nobody can use it? You would have to offer at least some
rock-stable, easily loadable drivers for DOS, Linux (including
Android), Windows (all currently popular variants of it) and
Mac OS (including iOS) to be available on all places where now
exFAT is already working and pre-installed. Next, you would be
in the position of having to convince people who bought a pre-
formatted exFAT e.g. SD card that they should RE-format that.

Which would require them to install your driver on every item
where they want to actually use the SD card. Which means that
you would have to get smartphone, camera, ... vendors on board.

If you try to make the plan less bold, you have the option to
provide only drivers for DOS and, say, Linux and Windows 7+XP.
Linux because it might be easier and pave the way for Android.

If, on the other hand, you ONLY provide DOS drivers, even all
people who dual-boot anything else with DOS would have to boot
DOS to access files on your new filesystem and be limited to
DOS writeable partitions when making copies of their files to
access them from the Linux, Windows or other on their same PC.

Which means that, because DOS sucks at accessing NTFS or ext2
drives, they would have to copy their files between your new
filesystem and a FAT32 partition, creating a bottleneck where
anything which makes your filesystem better than FAT32 would
never get visible from other operating systems. See also:

https://en.wikipedia.org/wiki/Usage_share_of_operating_systems

Cheers, Eric



--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Steve Nickolas]

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 to
> write such an implementation.
>
> A key to success is to remain compatible with DOS, and to offer wide
> support so others can merge this implementation to other systems. If
> such a FAT implementation were available only on DOS, but not on Linux
> or Mac or Windows, not many will adopt it.

Didn't the guy who enhanced the OpenDOS kernel come up with one?  I think 
it was called FAT+.

-uso.

--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Mercury Thirteen]

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 see fit, but at 
least the option is there for those who wish to employ it. I venture a 
guess it wouldn't end up being the favorite choice of consumers, but 
power users and embedded device manufacturers may see an opportunity. 
NAS devices, home automation computers and other similar devices are 
becoming increasingly common, and offering a filesystem finally capable 
of handling the sizes of modern hard drives could be a welcome 
improvement for them, and just may help get FreeDOS used in a wider market.

How do we know this isn't a chicken-and-egg problem? Maybe all the 
devices only use the proprietary exFAT because there was no open 
alternative. Maybe, had there been one available, we would all be using 
SD cards and such formatted in it by now. Is this unlikely? Yes. 
Impossible? No.

Of course, you all are under no obligation to use my ideas. I know some 
here desperately cling to DOS as it was three decades ago, so far be it 
from me to attempt modernization. :)

Merc

On 9/24/2015 5:50 PM, Eric Auer wrote:
> Hi Steve & Mercury,
> ...
>> 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 in this FAT version
>> would not be able to be read by any other DOS version without a software
>> module to do so. That sucks for compatibility zealots but, as is said,
>> sometimes to go forwards you must first go backwards.
> Well you can try to go forwards, but what use is a cool gadget
> when nobody can use it? You would have to offer at least some
> rock-stable, easily loadable drivers for DOS, Linux (including
> Android), Windows (all currently popular variants of it) and
> Mac OS (including iOS) to be available on all places where now
> exFAT is already working and pre-installed. Next, you would be
> in the position of having to convince people who bought a pre-
> formatted exFAT e.g. SD card that they should RE-format that.
>
> Which would require them to install your driver on every item
> where they want to actually use the SD card. Which means that
> you would have to get smartphone, camera, ... vendors on board.
>
> If you try to make the plan less bold, you have the option to
> provide only drivers for DOS and, say, Linux and Windows 7+XP.
> Linux because it might be easier and pave the way for Android.
>
> If, on the other hand, you ONLY provide DOS drivers, even all
> people who dual-boot anything else with DOS would have to boot
> DOS to access files on your new filesystem and be limited to
> DOS writeable partitions when making copies of their files to
> access them from the Linux, Windows or other on their same PC.
>
> Which means that, because DOS sucks at accessing NTFS or ext2
> drives, they would have to copy their files between your new
> filesystem and a FAT32 partition, creating a bottleneck where
> anything which makes your filesystem better than FAT32 would
> never get visible from other operating systems. See also:
>
> https://en.wikipedia.org/wiki/Usage_share_of_operating_systems
>
> Cheers, Eric
>
>
>
> --
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Mercury Thirteen]

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 certain applications. Sure, you could compile your own 
slimmed version specific for the task, but DOS' lightweight requirements 
and comparatively speediness make it the clear out-of-the-box winner.


An improved FAT was something I planned for eventual use with the 32-bit 
kernel we're creating. Perhaps it's best to keep it that way since 
regular DOS (as Eric points out) is not that well suited for the job 
being sans-multitasking as it is.


I will draw up a spec as I said when I get the time. After that, 
implementation is up to the rest of the community. We could just as 
easily go with FAT+ or not advance the filesystem at all.


On 9/24/2015 9:21 PM, JAYDEN CHARBONNEAU wrote:
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 PM, Eric Auer > wrote:



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 been free to use one
of many available Linux filesystems. But did not.

Of course the question can be extended: What if an
existing nicer-than-FAT filesystem is used more in
DOS? Have a look at what already EXISTS for Linux,
then have a look at the source code to check which
filesystems are 1. simple enough to make a "light"
DOS driver possible (some might even be so simple
that booting DOS from them is feasible, but only a
really popular filesystem may get kernel drivers),
2. better than FAT in some way (e.g. more speed on
flash storage, better space allocation or LFN in a
less insane way than VFAT) but 3. not putting lots
of code into features which mean nothing for DOS,
such as ACL based file permissions or extreme file
or disk size support beyond existing FAT32 API or
"network redirector" API expressible number range.

Looking forward to your review of existing FS-es!

Of course with an outlook towards which properties
a not-yet-existing FS could have to be even nicer
for use within a DOS based storage "ecosystem".

Cheers, Eric

PS: By "light", I mean a driver which is not 100s
of kilobytes in size and which can be fast with a
bit of DOS RAM and XMS instead of needing 500 MB
of DPMI RAM and protected mode implementation :-)



> NAS devices, home automation computers and other similar devices are
> becoming increasingly common, and offering a filesystem finally
capable
> of handling the sizes of modern hard drives could be a welcome
> improvement for them, and just may help get FreeDOS used in a
wider market.
>
> How do we know this isn't a chicken-and-egg problem? Maybe all the
> devices only use the proprietary exFAT because there was no open
> alternative. Maybe, had there been one available, we would all...




--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/freedos-devel




--


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel


--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Mercury Thirteen]

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 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 
> wrote:


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 PM, Eric Auer > wrote:


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 been free to use one
of many available Linux filesystems. But did not.

Of course the question can be extended: What if an
existing nicer-than-FAT filesystem is used more in
DOS? Have a look at what already EXISTS for Linux,
then have a look at the source code to check which
filesystems are 1. simple enough to make a "light"
DOS driver possible (some might even be so simple
that booting DOS from them is feasible, but only a
really popular filesystem may get kernel drivers),
2. better than FAT in some way (e.g. more speed on
flash storage, better space allocation or LFN in a
less insane way than VFAT) but 3. not putting lots
of code into features which mean nothing for DOS,
such as ACL based file permissions or extreme file
or disk size support beyond existing FAT32 API or
"network redirector" API expressible number range.

Looking forward to your review of existing FS-es!

Of course with an outlook towards which properties
a not-yet-existing FS could have to be even nicer
for use within a DOS based storage "ecosystem".

Cheers, Eric

PS: By "light", I mean a driver which is not 100s
of kilobytes in size and which can be fast with a
bit of DOS RAM and XMS instead of needing 500 MB
of DPMI RAM and protected mode implementation :-)



> NAS devices, home automation computers and other similar
devices are
> becoming increasingly common, and offering a filesystem
finally capable
> of handling the sizes of modern hard drives could be a welcome
> improvement for them, and just may help get FreeDOS used in
a wider market.
>
> How do we know this isn't a chicken-and-egg problem? Maybe
all the
> devices only use the proprietary exFAT because there was no open
> alternative. Maybe, had there been one available, we would
all...




--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/freedos-devel





--


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel


--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Eric Auer]

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 been free to use one
of many available Linux filesystems. But did not.

Of course the question can be extended: What if an
existing nicer-than-FAT filesystem is used more in
DOS? Have a look at what already EXISTS for Linux,
then have a look at the source code to check which
filesystems are 1. simple enough to make a "light"
DOS driver possible (some might even be so simple
that booting DOS from them is feasible, but only a
really popular filesystem may get kernel drivers),
2. better than FAT in some way (e.g. more speed on
flash storage, better space allocation or LFN in a
less insane way than VFAT) but 3. not putting lots
of code into features which mean nothing for DOS,
such as ACL based file permissions or extreme file
or disk size support beyond existing FAT32 API or
"network redirector" API expressible number range.

Looking forward to your review of existing FS-es!

Of course with an outlook towards which properties
a not-yet-existing FS could have to be even nicer
for use within a DOS based storage "ecosystem".

Cheers, Eric

PS: By "light", I mean a driver which is not 100s
of kilobytes in size and which can be fast with a
bit of DOS RAM and XMS instead of needing 500 MB
of DPMI RAM and protected mode implementation :-)



> NAS devices, home automation computers and other similar devices are 
> becoming increasingly common, and offering a filesystem finally capable 
> of handling the sizes of modern hard drives could be a welcome 
> improvement for them, and just may help get FreeDOS used in a wider market.
> 
> How do we know this isn't a chicken-and-egg problem? Maybe all the 
> devices only use the proprietary exFAT because there was no open 
> alternative. Maybe, had there been one available, we would all...



--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[JAYDEN CHARBONNEAU]

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 PM, Eric Auer  wrote:

>
> 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 been free to use one
> of many available Linux filesystems. But did not.
>
> Of course the question can be extended: What if an
> existing nicer-than-FAT filesystem is used more in
> DOS? Have a look at what already EXISTS for Linux,
> then have a look at the source code to check which
> filesystems are 1. simple enough to make a "light"
> DOS driver possible (some might even be so simple
> that booting DOS from them is feasible, but only a
> really popular filesystem may get kernel drivers),
> 2. better than FAT in some way (e.g. more speed on
> flash storage, better space allocation or LFN in a
> less insane way than VFAT) but 3. not putting lots
> of code into features which mean nothing for DOS,
> such as ACL based file permissions or extreme file
> or disk size support beyond existing FAT32 API or
> "network redirector" API expressible number range.
>
> Looking forward to your review of existing FS-es!
>
> Of course with an outlook towards which properties
> a not-yet-existing FS could have to be even nicer
> for use within a DOS based storage "ecosystem".
>
> Cheers, Eric
>
> PS: By "light", I mean a driver which is not 100s
> of kilobytes in size and which can be fast with a
> bit of DOS RAM and XMS instead of needing 500 MB
> of DPMI RAM and protected mode implementation :-)
>
>
>
> > NAS devices, home automation computers and other similar devices are
> > becoming increasingly common, and offering a filesystem finally capable
> > of handling the sizes of modern hard drives could be a welcome
> > improvement for them, and just may help get FreeDOS used in a wider
> market.
> >
> > How do we know this isn't a chicken-and-egg problem? Maybe all the
> > devices only use the proprietary exFAT because there was no open
> > alternative. Maybe, had there been one available, we would all...
>
>
>
>
> --
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Jim Hall]

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 concerned about any effort to put exFAT
support directly into the FreeDOS kernel.

However, doing a little googling, I found that this developer has
created an exFAT reader as a separately-loaded driver:
http://www.mdgx.com/secrets.htm#XFAT


If you want exFAT support in FreeDOS, I would use that.

But include exFAT in FreeDOS? I don't think so; I prefer to avoid the lawsuit.


Jim

--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[JAYDEN CHARBONNEAU]

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 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 PM, Eric Auer  wrote:
>
>>
>> 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 been free to use one
>> of many available Linux filesystems. But did not.
>>
>> Of course the question can be extended: What if an
>> existing nicer-than-FAT filesystem is used more in
>> DOS? Have a look at what already EXISTS for Linux,
>> then have a look at the source code to check which
>> filesystems are 1. simple enough to make a "light"
>> DOS driver possible (some might even be so simple
>> that booting DOS from them is feasible, but only a
>> really popular filesystem may get kernel drivers),
>> 2. better than FAT in some way (e.g. more speed on
>> flash storage, better space allocation or LFN in a
>> less insane way than VFAT) but 3. not putting lots
>> of code into features which mean nothing for DOS,
>> such as ACL based file permissions or extreme file
>> or disk size support beyond existing FAT32 API or
>> "network redirector" API expressible number range.
>>
>> Looking forward to your review of existing FS-es!
>>
>> Of course with an outlook towards which properties
>> a not-yet-existing FS could have to be even nicer
>> for use within a DOS based storage "ecosystem".
>>
>> Cheers, Eric
>>
>> PS: By "light", I mean a driver which is not 100s
>> of kilobytes in size and which can be fast with a
>> bit of DOS RAM and XMS instead of needing 500 MB
>> of DPMI RAM and protected mode implementation :-)
>>
>>
>>
>> > NAS devices, home automation computers and other similar devices are
>> > becoming increasingly common, and offering a filesystem finally capable
>> > of handling the sizes of modern hard drives could be a welcome
>> > improvement for them, and just may help get FreeDOS used in a wider
>> market.
>> >
>> > How do we know this isn't a chicken-and-egg problem? Maybe all the
>> > devices only use the proprietary exFAT because there was no open
>> > alternative. Maybe, had there been one available, we would all...
>>
>>
>>
>>
>> --
>> ___
>> Freedos-devel mailing list
>> Freedos-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>>
>
>
--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Steve Nickolas]

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.

--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Eric Auer]

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 be interesting to
port the driver to DOS, similar to how DOS supports ISO9660 on
CD / DVD filesystems? And in a related question, which DOS UDF
(CD/DVD/BluRay) filesystem drivers exist (and work how well)?

Maybe some DOSers want to have a look at the exFAT driver code,
to check complexity: https://github.com/dorimanx/exfat-nofuse

Cheers, Eric

PS: Have any of you encountered e.g. SDXC cards which misbehave
as soon as you re-format them from exFAT to FAT32, ext3, other?


--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Eric Auer]

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 is by Samsung, then GPL-ed,
but claims that all drivers might conflict with Microsoft patents.

I remember that for VFAT and FAT32, it turned out that supporting
the filesystem itself by universal-purpose free operating systems
like Linux or FreeDOS is no problem, as Microsoft explicitly gave
permission for that category of use years ago. How about ExFAT?

The wikipedia piece also lists tricks to use exFAT on DOS already.
And that, interestingly, ExFAT lacks short file names and "."/"..".

Additional links from the wikipedia references:

http://opensource.samsung.com/reception/receptionSub.do?method=sub=F=exfat

further explained in:

www.phoronix.com/scan.php?page=news_item=MTQzODQ (with ads)

Cheers, Eric



--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Ralf Quint]

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/ExFAT#Adoption
>
> which states that one of the drivers is by Samsung, then GPL-ed,
> but claims that all drivers might conflict with Microsoft patents.
>
> I remember that for VFAT and FAT32, it turned out that supporting
> the filesystem itself by universal-purpose free operating systems
> like Linux or FreeDOS is no problem, as Microsoft explicitly gave
> permission for that category of use years ago. How about ExFAT?
>
> The wikipedia piece also lists tricks to use exFAT on DOS already.
> And that, interestingly, ExFAT lacks short file names and "."/"..".
>
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-samsungs-microsoft-patent-trap-in-linux-exfat/

Ralf

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Bret Johnson]

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 consideration, though less of a 
concern to me than the technical piece of it.  The main thing I would like to 
see in a DOS implementation would be the flexibility to do "plug-and-play" with 
the disks.  The main need for this would of course be USB disks, but could also 
apply to any other type of removable media that may come down the pike (for 
example, DVD-RAMs which can be formatted with hard drive file systems like 
FAT32 and exFAT).

At a minimum, this would mean that the functionality would need to exist in the 
OS (or in a device driver / TSR of some sort) even if no exFAT disk was found 
at boot time (or when the driver was installed).  In addition, there should be 
some sort of system call to identify that the functionality is installed so 
other software would know whether it's OK to mount the exFAT volume(s) when new 
media is inserted.

Want to place your ad here?
Advertise on United Online
http://thirdpartyoffers.juno.com/TGL3141/56033d0b9e4c3d0a34d1st04vuc

--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[JAYDEN CHARBONNEAU]

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,
> >
> >> 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 is by Samsung, then GPL-ed,
> > but claims that all drivers might conflict with Microsoft patents.
> >
> > I remember that for VFAT and FAT32, it turned out that supporting
> > the filesystem itself by universal-purpose free operating systems
> > like Linux or FreeDOS is no problem, as Microsoft explicitly gave
> > permission for that category of use years ago. How about ExFAT?
> >
> > The wikipedia piece also lists tricks to use exFAT on DOS already.
> > And that, interestingly, ExFAT lacks short file names and "."/"..".
> >
> 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-samsungs-microsoft-patent-trap-in-linux-exfat/
>
> Ralf
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
>
>
> --
> Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
> Get real-time metrics from all of your servers, apps and tools
> in one place.
> SourceForge users - Click here to start your Free Trial of Datadog now!
> http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

[Ralf Quint]

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 recommend to touch the Samsung ExFAT code on 
GitHub, just as I would not recommend to touch any of the leaked MS-DOS 
source code...

Ralf

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel