How can I help with FreeDOS 1.1?

[Joe Emenaker]

I apologize in advance. I'm sending this message to both freedos-devel and freedos-users because there seems to be discussion about the delays hampering 1.1's rollout on both lists. I'm sending to them in different messages, however, so that nobody will get a nasty bounce message if they do a "reply all" and they're not subscribed to the other list. That, and also so that people in both lists won't really get duplicate messages (except for this one... ;P ).

I've long been a fan of FreeDOS, and I've been meaning to switch over to it for my Ghost network disks for some time, but there have always been some quirks and bugs to work around... and I've already worked around the ones in DOS 6.22, so I figured I stick with the devil I know. However, now that I've finally found a FreeDOS kernel that sees USB drives natively (without having to load any drivers) and that the latest devload.exe seems to be able to load all of the MS-LANMAN drivers I need after config.sys is processed, I believe I now have, within reach, the ability to make a USB drive which can boot, autodetect the network card, load the appropriate drivers, and run ghost multicast. (Yes, I know about the various "network boot disks" out there.. but they're unsuitable for my purposes, so I have to make my own)

So, anyway, I'm excited about FreeDOS 1.1, and I want to help get it out the door.

As far as what I can offer. I'm pretty fluent in DOS batch programming, linux bash, Perl, Java, C... a few others. It appears that FreeDOS uses a packaging system. Well, I've rolled some of my own packages for Debian, and I don't think FreeDOS's packaging system can be more complicated and Debian's. Oh, and I've got some free time. So... what needs doing?

Oh, and are there web-pages you can direct me to which explain:
 1 - Who's in charge? Who decides when 1.1 is ready to go. Who packages it into a CD image? Who approves/rejects packages?
 2 - The FreeDOS standard file-structure. While MS-DOS would throw everything into C:\DOS, FreeDOS uses C:\FDOS\BIN, C:\FDOS\DOC... and some stuff is further down in C:\FDOS\BIN\CTMOUSE. Where is the manifesto which helps decide what goes where?

- Joe


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Freedos-devel mailing list
Freedos-devel@...
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Pat Villani-3]

Hi Joe,

Welcome.  Some answers:

On Tue, Nov 3, 2009 at 2:22 AM, Joe Emenaker <joe@...> wrote:
>

**** snip ***

>
> So, anyway, I'm excited about FreeDOS 1.1, and I want to help get it out the
> door.

Thank you for volunteering.

> As far as what I can offer. I'm pretty fluent in DOS batch programming,
> linux bash, Perl, Java, C... a few others. It appears that FreeDOS uses a
> packaging system. Well, I've rolled some of my own packages for Debian, and
> I don't think FreeDOS's packaging system can be more complicated and
> Debian's. Oh, and I've got some free time. So... what needs doing?

Time is a major factor.  If you're willing to help. I can definitely
use it.  I'm also glad you have the programming background.  It will
be quite useful.

> Oh, and are there web-pages you can direct me to which explain:
>  1 - Who's in charge? Who decides when 1.1 is ready to go. Who packages it
> into a CD image? Who approves/rejects packages?

I'm the project coordinator, so I get the honor of making a lot of the
decisions.  Of course, there is a lot of input from the community as
well.

>  2 - The FreeDOS standard file-structure. While MS-DOS would throw
> everything into C:\DOS, FreeDOS uses C:\FDOS\BIN, C:\FDOS\DOC... and some
> stuff is further down in C:\FDOS\BIN\CTMOUSE. Where is the manifesto which
> helps decide what goes where?

I don't think there's anything more than what you'll find on the
current web pages.

Let's take this discussion off line and we can talk some more.  I have
other volunteers as well, and we can start working on it.  Personally,
I won't get any time until later this month, but now is a good time to
start.

If anyone else would like to join in the effort, contact me.

Pat

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Freedos-devel mailing list
Freedos-devel@...
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Eduardo Brito]

Hi,
> If anyone else would like to join in the effort, contact me.
>  
I am working (or I should be, I'm slacking off because my thesis is
killing me) with support for some languages and codepages for FreeDOS
but I have a strong background in programming in lots of different
languages but especially C, Java and Haskell (yeah, that shouldn't be
too helpful for this although it is a beautiful language).
I also have experience with testing and debugging besides some more
hardcore stuff such as formal verification and validation. If anyone
needs testers and debuggers, I would gladly help out.

Best regards,
Eduardo

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Freedos-devel mailing list
Freedos-devel@...
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Eric Auer-3]

Hi Pat, Joe, Mateusz, Rugxulo, others,

I would suggest to keep this on-list for a bit longer,
but to switch to either the user or the devel list :-)

[Joe]
>> So, anyway, I'm excited about FreeDOS 1.1, and
>> I want to help get it out the door.

Thanks a lot! I think most needed at the moment is
packaging of missing updates... Mateusz made a list
about missing FDUPDATE items earlier this week:

http://sourceforge.net/mailarchive/message.php?msg_name=200911011751.00324.mateusz%40viste-family.net

BASE missing: Assign, Diskcomp, Display/Graftabl/Printer,
Backup/Restore (non-existing), Fasthelp, GRAPHICS, HIMEMX,
kc/keycode (Ask Aitor!), KEYB and KPDOS, unformat, vol.

Only items in CAPS really need action as the others did not
have any updates since 1.0 so we can re-use 1.0 packages.

BASE outdated: CHKDSK, CPIDOS, DEBUG, DEFRAG, DELTREE, EDLIN,
FIND, SORT and XCOPY (?) - Rugxulo, did we forget anything?

BASE with FDUPDATE / freedos.org version mismatch: UNDELETE
(FAT32 beta?) and COUNTRY SYS (data file) and maybe others.
How about UIDE (IDE-SATA-disk-CD-DVD) and USB drivers...?

BASE which are already okay: Append, Attrib, Choice, Command
(needs debugging of stops-to-run-apps bug!), Comp, Ctmouse,
Diskcopy, EDIT (Aitor plans update?), Emm386, Exe2bin, Fc,
FDAPM (I have updates pending!), FDISK (LBA/detection fixed?),
Fdshield, Fdxms, Fdxms286, FORMAT (some updates pending?),
*GCDROM*, Help/HTMLHELP, Himem, *Jemm386*, *JemmEx*, Label,
Lbacache, Mem, Mirror, Mode, More, Move, Nansi, Nlsfunc, Print,
Recover, Replace, Share, SHSUCDX (how about the other fork?),
Swsubst/Subst/Join and Tree.

Items in CAPS need some checking, *marked* items are new in
comparison to FreeDOS 1.0 :-).

>>  1 - Who's in charge? Who decides when 1.1 is ready to go.
>> Who packages it into a CD image? Who approves/rejects packages?

To package the CD image, one would use 1.0 as basis and
replace packages by newer versions. Updates in installer
software might support new things such as the use of 1.1
combined binary / source ZIP packages here but we can
also use 1.1 packages to autogenerate 1.0 style ones, in
one mode for a binary-only CD and in another with sources.

For experiments, you can master a new ISO yourself:

www.mail-archive.com/freedos-devel@.../msg06886.html
http://209.85.229.132/search?q=cache:dC-XKe1zkXkJ:www.mail-archive.com/freedos-devel%40lists.sourceforge.net/msg06886.html+mkisofs+freedos+2009&hl=nl&gl=nl&strip=1

www.freedos.org/freedos/images/logos/ and for crystalcase/jewelcase:
www.auersoft.eu/soft/by-others/ freedos-cdrom-label-art-FDLFinal.zip

mkisofs -R -D -V "FreeDOS 1.1rc1" -o ~/fdbasecd-remastered.iso \
  -b isolinux/isolinux.bin -c isolinux/boot.cat \
  -no-emul-boot \-boot-load-size 4 \
  -boot-info-table /tmp/fdbasecd-contents/

See also: http://wiki.fdos.org/Installation/BootDiskCreateCDROM

[Pat]
> I'm the project coordinator, so I get the honor of making a lot of the
> decisions.  Of course, there is a lot of input from the community as
> well.

Package decisions are usually inspired by suggestions
and community reactions indeed... However, a realistic
goal for FreeDOS 1.1 would be to contain all that is
in 1.0 but in updated versions :-) In particular the
BASE category is important. Of course there will be
exceptions, such as adding the new free USB drivers,
but it is not the main goal to add many new packages.

>>  2 - The FreeDOS standard file-structure. While MS-DOS would throw
>> everything into C:\DOS, FreeDOS uses C:\FDOS\BIN, C:\FDOS\DOC... and some
>> stuff is further down in C:\FDOS\BIN\CTMOUSE. Where is the manifesto which
>> helps decide what goes where?

Yes, there is a nice Wiki page and some emails about that ;-)
And of course you can look at existing packages in FDUPDATE.

http://sourceforge.net/apps/mediawiki/freedos/index.php?title=Package
http://sourceforge.net/apps/mediawiki/freedos/index.php?title=LSM
http://sourceforge.net/mailarchive/message.php?msg_name=4AED685C.7050207%40jpberlin.de
... plus URLs mentioned there:

www.ibiblio.org/pub/micro/pc-stuff/freedos/files/fdupdate/
www.ibiblio.org/pub/micro/pc-stuff/freedos/files/fdupdate/wip/
www.freedos.org/cgi-bin/lsm.cgi?mode=dir&dir=base
...

Eric



------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Freedos-devel mailing list
Freedos-devel@...
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Joe Emenaker]

Eric Auer wrote:

 2 - The FreeDOS standard file-structure. While MS-DOS would throw
everything into C:\DOS, FreeDOS uses C:\FDOS\BIN, C:\FDOS\DOC... and some
stuff is further down in C:\FDOS\BIN\CTMOUSE. Where is the manifesto which
helps decide what goes where?
      

Yes, there is a nice Wiki page and some emails about that ;-)
And of course you can look at existing packages in FDUPDATE.

http://sourceforge.net/apps/mediawiki/freedos/index.php?title=Package
  

Oh, okay. But what I don't see there is some decision-making policy about extraneous directories. For example, why does CTMOUSE get its own folder under /FDOS/BIN/? What criteria must a package meet in order to warrant special directories?

Also, same goes for the /FDOS main directory. Looks like there's not a lot there. BIN/, DOC/, SOURCE/, APPINFO, FDAUTO.BAT...  are there any rules/guidelines aimed at keeping this very tidy, or can packages just throw random stuff in there?

http://sourceforge.net/apps/mediawiki/freedos/index.php?title=LSM
  

Has there been discussion about adding some fields like "Category:" or "Provides:"? "Category:" would be useful if a user wants to see all of the installed (or installable) packages for "DISKUTIL" or "COMPRESSION". Likewise, "Provides:" could describe what provides a certain function. For example, I only need *one* EMM. I don't need to install JEMM, EMM386, QEMM386, etc. etc. Just one will do. But, I'd also like to be able to choose from all available. So it would be nice, down the road someday, if the FDPKG or FDUPDATE or some future tool could show me, say, what packages "provide" a EMM, or an ANSI, or zipfile capability, or 89-assembler, or whatever.

- Joe


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Freedos-devel mailing list
Freedos-devel@...
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Kenneth J. Davis]

On Tue, Nov 3, 2009 at 6:59 PM, Joe Emenaker <joe@...> wrote:
...
> Oh, okay. But what I don't see there is some decision-making policy about
> extraneous directories. For example, why does CTMOUSE get its own folder
> under /FDOS/BIN/? What criteria must a package meet in order to warrant
> special directories?
>
> Also, same goes for the /FDOS main directory. Looks like there's not a lot
> there. BIN/, DOC/, SOURCE/, APPINFO, FDAUTO.BAT...  are there any
> rules/guidelines aimed at keeping this very tidy, or can packages just throw
> random stuff in there?
...
> - Joe

The idea is to keep the directory structure simple and organized.  Any
executable files and needed support files (assuming only a few) should
go into the BIN subdirectory - ideally this would be the only
directory to add to PATH, however if a particular program includes
several support files or utility programs (such as CuteMouse) then it
may have its own subdirectory [how the maintainer of a particular
package originally packages the files is the basis for which files go
where].  Individual packages should refrain from installing files to
the main directory (FDOS/) unless it makes sense with the overall
distribution such as copies of AUTOEXEC/CONFIG and top level FreeDOS
directories.  The decision to include files in subdirectories named
after the package under the other [non BIN & HELP] directories is
somewhat arbitrary but the basic guideline is if there is more than
one file or that one file is not named after the package then it
should be in a subdirectory named after the package. Jim's original
document is what I used as a guide when updating/creating packages,
with the APPINFO subdirectory being the only addition for any META
information about the packages/programs installed.  Others have taken
over since I last worked on packaging files but I think the above is
still correct.

Jeremy

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Freedos-devel mailing list
Freedos-devel@...
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Joe Emenaker]

Kenneth J. Davis wrote:
> On Tue, Nov 3, 2009 at 6:59 PM, Joe Emenaker <joe@...> wrote:
> ...
>  
>> ...  are there any
>> rules/guidelines aimed at keeping this very tidy, or can packages just throw
>> random stuff in there?
>>    
> The idea is to keep the directory structure simple and organized.
Actually, it seems that I spoke too soon. I had always just installed
fdbasecd.iso and that gives a very clean C:\FDOS install. Yesterday, I
tried the full CD and it throws a *lot* more stuff directly into C:\FDOS
and whatnot. The austere elegance of the C:\FDOS directory kinda goes
out the window. Ah, well....
> Any
> executable files and needed support files (assuming only a few) should
> go into the BIN subdirectory
Okay, next question: Is there any provision for packaging of apps which
aren't part of the FreeDOS distribution, per se (so they wouldn't belong
in C:\FDOS)? Suppose, for example, that I wanted to package something
like Borland's Turbo C so that I can easily deploy it to an entire
computer lab of PC's, say. I doubt that putting it under C:\FDOS is the
best place for this, but I've noticed that the packaging guidelines ask
that the ZIP file only contain relative paths (intended to be relative
to C:\FDOS). So, at first glance, it doesn't seem that the package
maintainer has any way of indicating that it belongs outside of
C:\FDOS.... like maybe a C:\APPS or a C:\BIN or something.
> ... but the basic guideline is if there is more than
> one file or that one file is not named after the package then it
> should be in a subdirectory named after the package.
Well, that's not really what seems to be happening. I look in
C:\FDOS\BIN and there's all kinds of odd stuff. *.CPI files,  CP*.TBL,
META*.BIN, etc.. Is there still hope that all of this will eventually
get organized into per-package folders, or is it kind of a lost cause at
this point? Incidentally, I have noticed that some packages *do* have
all of their files in a dedicated folder and then they just have a .BAT
file in C:\FDOS\BIN which redirects to the actual executable(s) in the
package folder. Lynx does this, for example. The problem, however, is
that the LYNX\ folder is placed directly under C:\FDOS. Is there a
suggestion/plan/guideline that dedicated app directories be placed in a
special place? Maybe a C:\FDOS\LIB, or a C:\FDOS\APPS, or even under
C:\FDOS\BIN? Taking all of Lynx's individual files out of C:\FDOS\BIN
and putting them into a new C:\FDOS\LYNX doesn't seem like all that much
of an improvement.

- Joe


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Freedos-devel mailing list
Freedos-devel@...
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Joe Emenaker]

Eric Auer wrote:
> Thanks a lot! I think most needed at the moment is
> packaging of missing updates... Mateusz made a list
> about missing FDUPDATE items earlier this week:
>  
So... does that mean that I should just start picking stuff from the
list and packaging it and submitting it? Or am I supposed to propose
something I want to package and wait for the "go ahead"?

- Joe


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Freedos-devel mailing list
Freedos-devel@...
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Pat Villani-3]

As I said before, we should plan this off list before charging ahead.
I'm really pretty tied up until the end of the month, but we can start
now and I'll jump in as soon as I free up.

Send me email off list.

Pat


On Mon, Nov 9, 2009 at 3:31 PM, Joe Emenaker <joe@...> wrote:

> Eric Auer wrote:
>>
>> Thanks a lot! I think most needed at the moment is
>> packaging of missing updates... Mateusz made a list
>> about missing FDUPDATE items earlier this week:
>>
>
> So... does that mean that I should just start picking stuff from the list
> and packaging it and submitting it? Or am I supposed to propose something I
> want to package and wait for the "go ahead"?
>
> - Joe
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Freedos-devel mailing list
> Freedos-devel@...
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
>

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Freedos-devel mailing list
Freedos-devel@...
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Joe Emenaker]

Pat Villani wrote:
> As I said before, we should plan this off list before charging ahead.
>  
And I did email you back then. Never heard back. Maybe I'm ending up in
your spam-box. I've emailed you directly a second time (just now) and
this is just to give you a heads-up to check your spam folder (since I
know you're getting these).

- Joe


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Freedos-devel mailing list
Freedos-devel@...
https://lists.sourceforge.net/lists/listinfo/freedos-devel