Hi, as there was no reaction to the mail of dos386
ten days ago, I would like to repeat it as new thread:

> Tested and didn't find anything eclatantly evil so far  :-) 
> 
> - It works mostly, see shot:
> http://img211.imageshack.us/img211/4611/ker2038.png

This screenshot shows a 46208 byte kernel, 15550 byte SYS 3.3,
the latter still lacking a "Force LBA" / "Force CHS" command
line option for FAT32 use, alas. It also shows the output of
a tool which tests int 21.7303 and displays the values:

ver 0 size 2c sec/cluster 8 bytes/sector 200 free clusters
c333 total clusters c334 free sectors 61998 total sectors
619a0 free clusters' c333 total clusters' c334 free space
c333000 / 204681216.

Version text says build 2038 May 16 2009 compiled May 16 2009.

> - "my" GetDiskFreeSpaceEx bug seems fixed

Nice :-)

> - "history.txt" neglects any development, oops Eric already pointed it, also,

Yes, still waiting for any reaction on my 18 May mail here...

Can we update the history txt file for www.fdos.org/kernel/latest/
and on SVN soon? It is a pity that we already have post 2038
updates even though 2038 itself is not complete yet. In spite
of all the warnings during the last year that documentation or
lack thereof was the main thing which blocked official release.

>    the filename should be "HISTORY.TXT" and not "history.txt" of course

DOS filenames are not case sensitive. Actually lower case
names are better if you want to keep case sensitive OSes
happy.

> SourceForge page still shows 2006-May-21 (3 years old !!!), so, those having
> the power please fix this now or give the power to someone else.

Pat, Jeremy: Please FIRST update history txt BEFORE we make
a sourceforge file release of kernel 2038. Thank you :-).

Eric



Here is a suggested history.txt section for 2038 based on
http://freedos.svn.sf.net/viewvc/freedos/kernel/trunk/?sortby=date&view=log
http://freedos.svn.sf.net/viewvc/freedos/kernel/trunk/docs/history.txt?revision=1364
In short, SVN revisions 1365 to 1385 are undocumented...!

Also, Bart already made 2039 related revisions - 1411 ;-)
His changes are f_node / SFT and tuning things... It would
be nice to have a web page where the unified diffs can be
looked at for proofreading. Revisions 1386-1388 are about
Linux cross compilation, 1385 bumps version.h to 2039-svn.

A bit unrelated is 1396 sft.h: 0b start cluster is not set
(RBIL 01642) or high part (Bart?) of if FAT32 kernel, file
size and position (incl rel cluster) are unsigned and some
fields at offset 1b-1e (current cluster/sector) change a lot.
Is the sft_status sft_cuclust sft_ifsptr really correct??



- *please change*: Build 2038 is May 2009, not Apr 2008,
  and my email is the one I use now, not eric at coli.

- *please add*:

+ Changes Jeremy 2009

 * r1381-r1384 update bugs.txt, version.h, LSM, tag SVN for 2038 release
 * r1374, r1380 fcbfns FCB open old GEM compat (bigsize/recsiz/recno...)
 * r1379 dosfns.c fatfs.c proto.h from Eric: only check for SHARE on
   open/close, avoid extra 2f.1000 calls.
 * r1378 dsk.c from Lucho: Press any key, not Press the any key ;-)
 * r1377 initdisk.c from RayeR: Use total cyl count, not max cylinder
   (fixes off by one bug on non-LBA PC) & fix overflow by ULONG cast.
   Improve DebugPrintf calls, fix format string (only in debug kernels)
 * r1376 inthndlr.c from Tom: 21.1c return AL=0xff for invalid drives
   (fixes bug for apps which use int 21.1c to find FAT drive letters)
 * r1372, r1375 process.h/entry.asm make CP/M call PSP[5] work
   (1 line jbe versus ja fix plus detailed comments, by Bart)
   This fixes SF tracked bug 2421577.
 * r1373 kernel.asm add : after _HMATextAvailable avoid nasm warning
 * r1371 watcom.mak make sure even Windows Watcom C builds a DOS SYS
   (would otherwise make a SYS meant for use in Windows by default)
 * r1370 default bat make compiling without UPX possible again
 * r1369 let DosGetExtFree 21.7303 accept drive with and w/o slash
   This fixes SF tracked bug 2380828 (GetDiskFreeSpaceEx if no slash)
 * r1368 tag for ke2038test

- *please change*: Please add to the "Changes Bart + Eric" part:

 * r1367 sys.c from Bart: 32bit date/time if WATCOMC 1279+ (OW 1.8)
 * r1366 config.c, config.txt allow BUFFERSHIGH as alias to BUFFERS,
   buffers are in UMB, we use HMA anyway. Drop unused int 16.1 call.
 * r1365 inthndlr.c allow/ignore type hints in int 21.7305 disk read

- *please add to r1334 comments*:

Fixes SF tracked kernel bug 2362450:
http://sf.net/tracker/?func=detail&aid=2362450&group_id=5109&atid=105109



PS: I would like to quote IBID_AG:

> 1. I have checked out the latest build (kernel 2038-32).
> It works fine with GEM/XM. (So did the 2nd RC.)

Nice :-)

> 2. Congratulations on a great kernel/OS
> 3. PLEASE stop the flame wars--the last few digests have looked rather (?!)
> 4. I would rather see more of the features from 2037 in stable than get
> more oddball features in unstable (ExFAT, FAT+).  Once we get COUNTRY.SYS
> & WfW support in stable, these might be handy.  And SHSUCDX with UDF
> support does seem higher priority.

UDF-CDEX would be separate from kernel development, but indeed
it is a very good question which features apart from COUNTRY SYS
support are most interesting for porting from 2037 to stable :-)

> Thanks for developing FreeDOS!

 :-)



PPS: Any help in documenting the source code changes between
2035 and the unstable 2037 development branch is welcome!
http://apps.sourceforge.net/mediawiki/freedos/index.php?title=Unstable_Kernel_Branch

PPPS: There is still the old bugzilla URL in
http://freedos.svn.sf.net/viewvc/freedos/kernel/trunk/docs/readme.txt
and CONTRIB TXT still lists my old, now defunct, email address.



------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT 
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & 
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian 
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
_______________________________________________
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Reply via email to