Re: [Freedos-kernel] Kernel 2040 released
On 20 July 2011 13:36, Bernd Blaauw bbla...@home.nl wrote: And now the fun part: compiling on Windows x64. No support for running 16bit programs at all. Sure, for that you *need* a true cross-compilation. Just like on Linux. The FreeDOS-kernel build's utility programs (patchobj.exe) are also 16-bit DOS if you compile on Windows, so I don't think anybody has used Windows x64 to compile the kernel yet. Bart -- 10 Tips for Better Web Security Learn 10 ways to better secure your business today. Topics covered include: Web security, SSL, hacker attacks Denial of Service (DoS), private keys, security Microsoft Exchange, secure Instant Messaging, and much more. http://www.accelacomm.com/jaw/sfnl/114/51426210/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Kernel 2040 released
On 19 July 2011 13:27, Kenneth J. Davis jere...@fdos.org wrote: On Sat, Jun 25, 2011 at 4:40 PM, Bernd Blaauw bbla...@home.nl wrote: Op 25-6-2011 16:06, Kenneth J. Davis schreef: Hello all. ... Are there any verified/stable working compiled versions available of the following? * COMMAND (there's an openwatcom CVS/SVN version somewhere?) I finally managed to built the OW version (had issues with the utility programs being built as win16 executables, so modified the makefiles to build them as win32 [native], and have yet to build the installable command loading program - didn't even know it existed) so you can now find OW builds of command.com on fdos.org Thanks for testing! I haven't had the time to properly finish the port myself so I've been careful not to promote it too much... Anyway, yes: the sequence such as d:\watcom\BINW\wcc -zq mktools.c @watcomc.cfg d:\watcom\BINW\wlink f mktools.obj lib ..\SUPPL\SUPPL_s.LIB op q gives a win16 executable instead of the intended dos16 if %WATCOM% is set to d:\watcom\binnt instead of d:\watcom\binw. It's probably best to make things explicit (unless the goal is a true Win32-DOS cross-compile), using DOS16 utilities, by changing the last part of mkfiles\watcom.mak to: CFLAGS1 = -os-s-wx-bt=dos # *Implicit Rules* .obj.exe: $(BINPATH)\wlink sys dos f $ lib $(SUPPL_LIB_PATH)\SUPPL_$(SHELL_MMODEL).LIB op q .c.obj: $(CC) $ @$(CFG) But I haven't tested this! Bart -- 10 Tips for Better Web Security Learn 10 ways to better secure your business today. Topics covered include: Web security, SSL, hacker attacks Denial of Service (DoS), private keys, security Microsoft Exchange, secure Instant Messaging, and much more. http://www.accelacomm.com/jaw/sfnl/114/51426210/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] USB-HDD booting and LBA-to-CHS conversion
Hi, it's risky to guess CHS geometry from the MBR, because partitions don't necessarily end at cylinder boundaries. Using CHS internally means to use int13 calls to read/write sectors using CHS values (which Linux does not do). For those the only values that make sense and are safe are the ones compatible with the BIOS, irrespective of what is in the boot sector or MBR! The only reason why CHS is used at all internally for BIOSes that also support LBA is for compatibility with older device drivers (think of cache) that only know about CHS. If all is well, your pendrive's boot sector(s) use the 1021/124/62 geometry. You can always use SYS CONFIG (see docs\sys.txt) with forcelba or set the partition type(s) to an LBA type (0c/0e/0f) (which makes the drive invisible to MSDOS 7) to avoid all the CHS complications. Bart -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] CRITICAL BUG - crosslinked files - 2039 unusable
On 3 May 2011 03:03, dos386 dos...@gmail.com wrote: Good catch and thanks for the fix! I committed your patch to svn Heh ... excellent ... so my excessive HD trashing http://www.mail-archive.com/freedos-kernel%40lists.sourceforge.net/msg02431.html 1+1/2 years ago was NOT only waste of time ? Indeed! I tried hard to reproduce it at the time but I missed that to trigger the bug a FAT12/16 drive also needs to be involved. I was doing extensive testing but only copied files from network/cdrom-style drives and then kept them on FAT32 (there was lots of FAT32-FAT32 copying though). That avoids the effects of the bug, since only FAT32 DPBs were ever seen. Thanks to Damien, I'll test 2040 Did you try out this kernel? An 8086/FAT32 OW1.9 compiled kernel.sys binary for testing at: http://dosemu.org/bart/kernel.sys Bart -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] freedos 2039 finddisk regression
On 24 August 2009 10:25, Rugxulo rugx...@gmail.com wrote: On Mon, Aug 24, 2009 at 2:18 PM, Bart Oldemanbartolde...@users.sourceforge.net wrote: I can't reproduce a regression, although there is a bug with respect to MSDOS: FreeDOS kernel build 2038 [version May 16, 2009 compiled May 16 2009] Kernel compatibility 7.10 - WATCOMC - FAT32 support D:\FREEDOSfinddisk fdos no match D:\FREEDOSfinddisk FDOS echo Match on E: (i.e. it only works case sensitive!, unlike MSDOS) But this behaviour is the same for the FD1.0 kernel and also kernel 2039 No, that's not the problem. When using Jack Ellis' RDISK (RAM drive) it won't find the volume Hallelu-Jah in 2039 whereas 2038 works fine. (If you really really want, I can upload my test floppy image where I discovered the problem.) In particular, I originally used 2038pre when making the floppy disk for testing, and when 2038 came out I upgraded. And then when 2039 came out, I figured I should upgrade again but didn't test again until recently. And at startup it immediately tries to jump to RAM disk for my purposes, but definitely a regression since it doesn't find it anymore. I finally had a closer look. What happens is that the int21/11 input pattern of finddisk gets uppercased to HALLELU-JAH, and then case-sensitively compared to the directory entries on the RAM drive. So it doesn't find it. This is compatible with MSDOS, where finddisk doesn't find the RAM disk either. (It's very strange to have a mixed case label as that doesn't match with short-file-name FAT). Older versions of the FreeDOS kernel (=2038) did not compare (ignored) the name for the volume label: it was returned no matter which pattern was given to int21/11 (and 4e). That's why there is %define BUGGY_FCB 1 in finddisk.asm. The correct DOS-independent fix would be to change finddisk to search for the volume label with .???, and then compare the result with the search term. Bart -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] CRITICAL BUG - crosslinked files - 2039 unusable
Hi, I'm having a look. But I can't reproduce it so far. So: * how large is your FAT partition exactly? There is always the GB/GiB confusion... * what is the cluster size (I'm looking for potential overflows) * does it happen with plain FreeCOM COPY, XCOPY, or any copy? Bart -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] freedos 2039 finddisk regression
Hi Eric, I can't reproduce a regression, although there is a bug with respect to MSDOS: FreeDOS kernel build 2038 [version May 16, 2009 compiled May 16 2009] Kernel compatibility 7.10 - WATCOMC - FAT32 support D:\FREEDOSfinddisk fdos no match D:\FREEDOSfinddisk FDOS echo Match on E: (i.e. it only works case sensitive!, unlike MSDOS) But this behaviour is the same for the FD1.0 kernel and also kernel 2039 how to reproduce your exact problem? cc-ing freedos-kernel as this shouldn't be private. FYI, There have been quite a few internal changes between 2038 and 2039 (the far fnode removal operation). Bart 2009/8/24 Eric Auer e.a...@jpberlin.de: Hi Bart, Ruxgulo reports a regression problem in kernel 2039 with a small piece of software: www.auersoft.eu/~auersoft/soft/specials/find-drive-by-label-finddisk.zip This software uses int 21.11 - 21.69 - 21.0e as notable DOS calls, plus of course the usual command line, print stuff, exit to dos stuff. Could you have a look at this? Thanks :-) Eric Hey, small regression in latest 2039 kernel, Your finddisk (useful with RDISK, for instance) doesn't work anymore. I then reverted to kernel 2038, and it worked again. Weird. I honestly didn't expect that (or anything, really) to break with 2039 as I expected overall changes to be small. Oh well. Also on SourceForge I saw a report that Breadbox Ensemble also doesn't work with 2039 but 2038 is okay. Strange. Not a huge problem, but still weird. Just thought you should know. :-) -- 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-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Int21.7304.sf03 should actually copy/move FATs
2009/8/6 Christian Masloch c...@bttr-software.de: the kernel is supposed to support all Int21.7304 (Set DPB/BPB fields for formatting) subfunctions but doesn't provide subfunction 03h completely. The current code simply gets (and sets as requested) the flags from the BPB, but doesn't move the FAT accordingly. MS-DOS apparently contains code to do so. This isn't documented in RBIL, but can be tested by setting the active FAT (of a FAT32 drive) to a single one, then resetting the flags to include all FATs later. The second call overwrites the previously inactive FAT(s) with a copy of the active one. (Depending on the size of the file system, this results in a short delay. If this isn't the case, files/directories can be created (changing FAT entries) while only the active FAT is used and dosfsck can be used to insure both FATs have the same content later when the flags were reset.) About a month ago I looked at the int21/ah=73 functions and there are a lot of corrections to make, mostly because RBIL is very brief in this area. I found this documentation which says more or less what you tell us too: http://www.thehackademy.net/madchat/vxdevl/vxmags/moonbug05/FAT32_32.HTM The links don't work without manually correcting URLs (case sensitivity!) but this looks like MSDN-style Microsoft documentation. Bart -- 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-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Building kernel 2038, compiles fine but hangs during boot.
2009/8/2 Thomas Jansen, WTY Soft tho...@wtysoft.com: I'm trying to build a version of kernel version 2038 and really need some help. All compiles well but the boot hangs after the FreeDOS print. There was a problem with non-UPXed kernels, fixed after the 2038 release. So you can try to use UPX. Or you can try the new 2039 release -- see sf.net/projects/freedos but not yet officially announced. Bart -- 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-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] new kernel release pending
2009/7/29 Kenneth J. Davis jere...@fdos.org: Assuming no objections, I will tag and make available kernel 2039 sometime at the end of this week. So if there are objections, please speak up! but include exactly what you feel needs to be done before the new release [that can not wait for a future release]. thanks! history.txt needs updating. I'll do that tomorrow. There's nothing else I can think of that is urgent. Brief list of user-visible/compilation changes: * OW 1.8 compatibility * ability to cross-compile from Linux * fnodes are eliminated, except for internal use inside DOS calls (2 fnodes in the SDA remain); SFTs are now compatible with MSDOS which helps some programs that look at these structures. * Fix rename in full root directories (Bugzilla bug 1908) * Fixed Int21/AX=4409 for drives from device drivers. * Add COUNTRY.SYS support (from unstable, Eduardo Casino). * Findfirst/findnext are more MSDOS compatible. * Fix SF bug 2380531 (DOS should not update directory entries for a created but not changed temp file that a buggy program forgot to close) * New SYS, merged from unstable branch. * build.bat has a few new options to simplify changing some settings on the fly without needing to edit config.bat. * Fix exit for self-owning PSPs: they should not close files or release memory (Christian Masloch). * Avoid calling media_check() too often (to get fewer Abort/Retry/Ignore prompts if you press I) * Check BPB instead of DPB to check for FAT32 after a BUILDBPB device call, to fix a problem with USBDRIVE. Pat: Jeremy wrote earlier that current SVN binaries are always at: http://fdos.org/kernel/ke386f32.zip - 386+, FAT32 enabled kernel http://fdos.org/kernel/ke86f16.zip - 8086+, FAT16/12 only kernel now would be a good time to test for everyone else too! Bart -- 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-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] new kernel release pending
2009/7/29 Christian Masloch c...@bttr-software.de:
Which aspects of SFT changed and how? Are there potential
performance issues because we no longer can cache certain
data in extra fields of fnodes?
It seems to me that the fnode (as defined in fnode.h) doesn't save any
information that isn't contained in the SFT, except the new file dates and
times (in the directory entry) which are accessed with a filename instead
of a SFT; so they're not required in the SFT. Note that the directory
entry's cluster and index into cluster (as found in the fnode) can be
computed with some shifting from the entry's sector and index into sector
(as found in the SFT) when the sector size, cluster size and the sector of
the first cluster is available (all found in a valid DPB or EDPB).
Before I eliminated the far fnodes I made them compatible with SFTs.
There are no performance issues; the directory entry now needs to be
read, updated and written for a file close, instead of just copied
from the fnode, but since the sector needs to be read anyway it
doesn't change performance.
An fnode now is defined like this:
struct f_node {
UWORD f_flags;/* file flags */
dmatch *f_dmp;/* this file's dir match*/
struct dirent f_dir; /* this file's dir entry image */
ULONG f_dirsector;/* the sector containing dir entry*/
UBYTE f_diridx; /* offset/32 of dir entry in sec*/
/* when dir is not root */
struct dpb FAR *f_dpb;/* the block device for file*/
ULONG f_offset; /* byte offset for next op */
CLUSTER f_cluster_offset; /* relative cluster number within file */
CLUSTER f_cluster;/* the cluster we are at*/
UBYTE f_sft_idx; /* corresponding SFT index */
};
Some fields moved to f_dmp -- there two directory match structures in
the SDA (even documented in RBIL), one for every fnode. I have some
patches to move the f_dir directory entries to the RBIL SDA locations
too but I'll wait with those until after release. Once dos_close() and
rwblock() (for read and write) use SFT entries directly, it's actually
more appropriate to call an fnode a dirnode, since it only pertains to
directory operations.
Right now however, directory and file operations share map_cluster()
which takes an fnode pointer, so it's not a trivial change.
Originally, files and directories seem to have used the same
read/write code but directories are too special in DOS so they were
split.
* Fixed Int21/AX=4409 for drives from device drivers.
What was wrong?
I'm interested too.
ioctl.c had:
CharReqHdr.r_unit = dpbp-dpb_subunit;
(changed from dpbp-dpb_unit in
r1115 | perditionc | 2005-02-24 15:35:48 -0500 (Thu, 24 Feb 2005) | 2 lines
from Eric (similar already in dev), set driver request field with
subunit number)
but after that it was used in:
case 0x09:
{
struct cds FAR *cdsp = get_cds(CharReqHdr.r_unit);
so you also now got the CDS from the subunit. That's ok for built-in
devices but not for loaded devices.
I changed the get_cds call to use BL.
Bart
--
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-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Potential issues with FAR printf
2009/7/20 ibid...@lavabit.com: Jeremy: The FAR printf is probably good for 16-bit builds with DEBUG defined. However, there are at least two potential issues (NOT YET VERIFIED). 1. 386 (or higher) builds might fail on a FAR value, as a 32-bit FAR is past 4GB. I don't know how the compilers treat FAR in these builds. 2.Low memory systems? It might be good (though perhaps difficult) to 1 Check for 16-bit 2 Check for DEBUG If both are true, 3 Use FAR printf with my commit printf only now uses FAR pointers for DEBUG statements in resident code, but just to clarify: the 386 builds don't use 32-bit code segments with 32/48-bit pointers, DPMI, etc, they only tell the compiler that it is allowed to use CPU instructions that are only available on 386+ processors, such as movsx, movzx, and those involving fs and gs segments. Some compilers use 32-bit registers for (unsigned) longs. But It all remains real mode code with 16-bit segments. The *only real* advantage of the 386 builds is that the code size decreases so kernel.sys and its resident memory footprint decrease; theoretically it could be a bit faster too but I'd be surprised if anyone could measure that. Bart -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Fwd: FreeDOS kernel Build Fixed: Build 2009.07.18.001
2009/7/18 Kenneth J. Davis jere...@fdos.org: I was just checking my email and about to work on an issue with the usb stack from Bret Johnson. Does this change effect/fix the issues with this (from the description it looks like it does - as the problem was described as FAT32 specific issue with the kernel and related to the buildbpb call) or is it just something you ran across? Yes, see my post at http://bretjohnson.us/forum/ for details. My patch just changing the ISFAT32(dpbp) check to checking the corresponding field in the BPB (that bpb_to_dpb copies there). Bart -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] prinf changes
2009/7/18 Kenneth J. Davis jere...@fdos.org: It has to deal with debugging the kernel, especially during initialization. I choose this method as the kernel does not usually have many strings it prints except when built with DEBUG and the alternative is to determine exactly which portions of the C code and corresponding strings may possibly reside in different segments at different times (any time DS may not equal seg of string) and change just those prints - otherwise some strings print and some print garbage. I realize it changes printf prototype to only match compilers in large data mode, but the kernel does not use printf from the standard library of DOS compilers anyway. However, I will revert the changes if you prefer. ok, I've reverted some of the changes: I found a couple of situations: DS == SS == DGROUP: this is normal, no problems here. DS == DGROUP, but SS!=DS. This happens for instance in nls.c, in that case we need to be careful by making pointers to items on the stack FAR, and similarly for va_list/va_arg. I've kept that part of your change, but only for resident debug printf()s. Compiling such code with -zu helps for OW (especially also to catch warnings) but unfortunately such a switch isn't there for TC, so we need to handle this situation manually. DS != DGROUP, and (perhaps) SS!=DS. This is very confusing and doesn't even work after your change: printf(foo) with a far format string is just compiled into a PUSH DS/PUSH foo/CALL printf. So we need to *always* keep DS equal to DGROUP in C code, which is why I fixed the entry to the kernel's int2f/ah=14 handler for NLSFUNC in nls.c. By the way, I didn't find init code where SS!=DS, but did you find any? Bart -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Past bugs and CONFIG dot SYS
2009/7/5 Christian Masloch c...@bttr-software.de: Regarding the updating of SFTs opened for the same file (previous mail), is that already in the kernel? If not, I want to add that point to your list for SHARE. Yes, that has been in the kernel since the initial implementation by Ron Cemer. It used to work on fnodes but now updates the SFTs. These routines (mainly merge_file_changes() in fatfs.c) could be moved to share.c if the hooks from RBIL table 01636 were implemented. share.exe as part of the kernel is of course a trade-off: it's natural for an OS, but for DOS you'd like the base kernel small and only include things that most people use (and most people don't need SHARE). Bart -- ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] 2039-svn bugs
2009/6/30 ibid...@lavabit.com: I've been trying to patch 2039-svn with Christian's fix, while working under a TC 186/FAT32/Win kernel (built myself), and I have found the following: what does Win here mean? 1. Code changed. In other words, the if (!tsr) line referred to seems to not exist (per TC find, and visual inspection) That line is at task.c, line 529. 2. BUG! Runnning command.com, no drivers loaded/programs run, I go cd tc or cd trunk Then dir Then try any/all of the following cd .. cd \ cd ..\ cd .\.. cd ..\. cdd c:\ Result: CHDIR failed for [argument] I'm not sure what is up, though it probably has something to do with fnode/sft changes. Yes, the mistake was mine, it had to do with filename parsing simplifications, thanks for catching it! What happens is that all does cd's are converted to cd C:\ internally and that is passed on and wasn't working anymore. SVN r1468 fixes that. Also, the kernel says that the partition doesn't seem to be LBA, then goes ahead and uses LBA anyway (ACER Aspire One, 160gb SATA hd, 1.25 gb FAT16 partition from gparted at end after massive NTFS/xp partition, boot kernel directly via Grub4DOS) Possibly the partition type is set to one of the non-LBA values. You should set it to 0xe (14) for FAT16 instead of 6. Bart -- ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] patch for the rename function, please check
Hi Eric,
2007/9/19 Eric Auer e...@coli.uni-sb.de:
I tried to fix bug 1908: Our kernel used to need a fresh
dir entry for renaming, as it renamed by create new dir
entry for file, then mark old entry as deleted. My patch
tries to limit this to cases where you rename files or
directories across directories. If both old and new name
are in the same directory, the new version should only
change the old dir entry in place. So that should even
work if you rename files on a disk with full root dir...
I got a zero-sized file when I tried to save the attachment of
archived bug 1908,
www.freedos.org/bugzilla/cgi-bin/show_bug.cgi?id=1908
www.freedos.org/bugzilla/cgi-bin/attachment.cgi?id=43
but I've changed dos_rename in SVN r1417 to change the directory entry
in-place instead of creating a new one and then deleting the old one
-- if the directory is the same for both paths.
Caveats:
- it is possible that renaming directories on a disk with
full root directory still does consume an extra dir entry,
as I am not sure whether my does the rename take place in
the same directory test captures that case as well.
I don't think that's a problem: then we have
fnp1-f_dirstart == fnp2-f_dirstart == 0
- if you rename a directory across directories, then the
.. entry for the directory itself is not updated. Note
that neither FreeCOM command.com nor MOVE use the int21
rename interface for such activities at the moment (?).
I think MSDOS specifically disallows this:
http://groups.google.com/group/comp.os.msdos.programmer/msg/259ca094fe4d0c9a
so we need to add another check.
- if ((ret = remove_lfn_entries(fnp1)) 0)
- return ret;
+ if ((ret = remove_lfn_entries(fnp1)) 0) {
+ dir_close(fnp2);
+ return ret; /* remove_... already closes fnp1 on error */
+ }
With my recent fnode changes (I'll send another email) we no longer
need to close fnodes: there are only two at fixed locations and
usually only the first is used. The only exception being
dos_rename() which uses the two fnodes. So it saves some trouble
with leaks.
Bart
--
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Cross compilation from Linux
Hi Eric, Interesting :-) How does it work (in other words, what was the trick to make it possible) and how do the config bat settings work in this context? :-) Can you be more specific? Did you look at the svn diff at all? Bart -- 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 asthey present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://www.creativitycat.com ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Cross compilation from Linux
2009/5/21 Eric Auer e.a...@jpberlin.de: That is the point... svn diff -r1386:1388 gives a diff of 14 kilobytes, 12 files modified, 46 lines changed, 170 lines added. Quite a lot. Okay okay I can analyze the patch myself... :-( Some explanations from the author would have saved some time here, of course ;-). That makes it easier to answer, although you could have researched many of your question marks yourself too... Do you think the change is too big? Should it have been cut into more smaller changes than two? Or do you require a GNU style changelog like this? http://gcc.gnu.org/viewcvs/trunk/gcc/ChangeLog?revision=147771view=markup k. makefile: various target names: use slashes instead of backslash? Yes: / in targets works in DOS too. - build.txt: add section about Linux (config.mak is Linux config bat?) Yes. Is that not clear enough? Do you have suggestions to improve the documentation? - generic.mak: use slashes instead of backslash for includes? yes, because generic.mak needs to work on both DOS and Linux. - generic.mak: if CLDEF not 0 then do something with CLT CLC? CLT/CLC are used for build utilities, using tiny and compact memory model. On Linux they are set to use plain gcc, but on DOS special settings are needed. - owlinux.mak: defines ECHOTO as echo which looks odd... The reason for the existence of ECHOTO is (as briefly stated in kernel/makefile) that Turbo C 2.01 make cannot handle redirections. So I wrote a batch file that appends: ..\utils\echoto.bat file file1.obj file2.obj instead of writing echo file1.obj file2.obj file in the makefile. The batch file does not work in Linux obviously but wmake is smart enough to handle echo . - utils makefile: use DIRSEP, drop use of INCLUDEPATH? - utils makefile: use CLT CLC instead of CL - utils makefile: drop TINY, CFLAGSC,CFLAGST? they're not dropped, but moved to generic.mak. - config.m: is preconfigured for 8086 FAT16, interestingly It's not strange: I just copied the default from config.b. - makefile: change all target into build target which does build? yes - makefile: add some Linux section and some defaults (and DOS?) Nothing changed for DOS, except that make will give you a message. - makefile: rewrite all/clean/clobber targets, big changes? just additions: this is like build/clobber/clean.bat for Linux, for DOS this is not used. Are you sure this still works on DOS, even with Turbo C etc? :-) Of course, I tested what I could. Bart -- 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 asthey present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://www.creativitycat.com ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Cross compilation from Linux
2009/5/21 Eric Auer e.a...@jpberlin.de: Not really - I think it would be tricky to put the config variables in something that all used MAKE versions can deal with directly, as opposed to having both a BAT and a MAK? There used to be (a long time ago) both a config.bat and a config.mak (for DOS!), where config.bat defined the make to use and config.mak the rest. However it is easier to use just one file. Problems: a) On Linux you can assume that make works, on DOS you can't, only batch files are sure to work. b) The logic as done in default.bat and config.bat is impossible to do in portable make; esp. Turbo C 2.01 Make is very basic, and can only do !if tests on numbers. c) A recursive make or GNU make calling OW wmake as now done in the cross-build can make DOS run out of memory (depending on compiler/command.com/make). That's why build.bat is used for DOS. Okay but echo file file1.obj file2.obj here? that works too. Bart -- 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 asthey present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://www.creativitycat.com ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Cross compilation from Linux
Hi, Jim reinstated SVN write access so I committed a patch that I have used internally in a not so clean fashion for a long time: cross-compiling from Linux using Open Watcom. The reason why: well it is more convenient and quicker (less than 2 vs. 20+ seconds here) to cross-compile than fire up DOSEMU or another VM and do the compilation there. I hope it is useful to some others and also clean enough: mostly DOS understands / fine but some commands in makefiles need to use $(DIRSEP) to get either \ or /. The batch files obviously can't be used but the top level makefile can do the trick using make all, make clean, and make clobber. Bart -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Hello again
2009/5/18 Christian Masloch c...@bttr-software.de: Good work! I verified RBIL's statement that the word at 0Bh was not used by checking it for files located on a FAT12 and FAT32 drives. It contained a seemingly random value which lead me to the wrong assumption MS-DOS just didn't properly initialize it. However I don't think I'll copy this strange behaviour (at least not by default). As reported by Eric, it breaks programs like JAM (the point is, even on FAT12 and FAT16 disks) which look into the SFT to get the first cluster of a (FAT12 or FAT16) file. Whether you call it strange depends... I just call it a change in layout, just like one was made from DOS 3.3x to DOS 4. It's hard to be compatible to everyone... In any case JAM can be made compatible to MSDOS 7.10 on FAT16 by DEBUG (in addition to the changes discussed before): debug jmount.com edf3 35 w That'll make jmount incompatible with MSDOS4, DRDOS 56, but compatible with newer versions, because the word at 35h is the last accessed cluster, and after reading one sector (as Eric showed) that will still be the starting cluster. It won't help FreeDOS of course because it still uses fnodes for these things instead of SFTs. Bart -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Hello again
2009/5/18 Tom Ehlert t...@drivesnapshot.de: It won't help FreeDOS of course because it still uses fnodes for these things instead of SFTs. Those are ancient relics that should be done away with. There is no need for them anymore. I'd like to put that high on the priority list for kernel development. in theory you are right. in praxis fnodes are everywhere throughout the file system (as you probably know), and there's a reason we left them in the kernel the last few years. it's probably fairly easy to convert a stable kernel into unstable by trying to convert this. not that I wouldn't like to get rid of the fnodes (it would be a very good thing), but it's probably a non-trivial amount of work (and risk) involved with that. dont start it if you are not prepared to finish it. Well, now we have two kinds of f_nodes, the near ones and the far ones. The far ones are copied to and from near ones using 4 fmemcpy's in fatfs.c Replacing the fmemcpy's by a convert fnode to/from SFT function should be able to eliminate the far fnodes. I'll give that a go. Once that's done at least some of the fatfs.c functions can be converted to use SFTs directly. Though this is not as easy as it looks because fnodes are also used as internal structures for directories. Bart -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Hello again
2009/5/18 Christian Masloch c...@bttr-software.de: However I don't think I'll copy this strange behaviour (at least not by default). As reported by Eric, it breaks programs like JAM (the point is, even on FAT12 and FAT16 disks) which look into the SFT to get the first cluster of a (FAT12 or FAT16) file. Whether you call it strange depends... I just call it a change in layout, just like one was made from DOS 3.3x to DOS 4. It was however not documented (well, like most things about MS-DOS 7+) and unexpected, especially because the usage of these fields (or their lower word parts) is now incompatible to previous versions even on FAT12/16 filesystems. (Ignoring the fact that it apparently broke SHARE.EXE, too.) It's all undocumented, of course :) You're distinguishing undocumented undocumented from documented undocumented... It just happens that nobody has updated RBIL. I'm not sure about unexpected because the 3.3x-4.0 change is similar, i.e. they could have left the 16bit sector counter for disks 32MB. About SHARE: http://support.microsoft.com/kb/161619 nevertheless FreeDOS has its own share which doesn't use these SFT fields. Does JAM read anything from the archive file (I presume it wants the first cluster of that file) before looking into the SFT? Also, what if it read exactly one sector (or more) but the cluster size was only one sector, either? Then it would read the second cluster instead of the first one from the SFT. I wouldn't patch the program like that if I didn't know for sure such things wouldn't happen. Of course it needs further testing, but I tested that reading a whole cluster only sets the last accessed cluster to that cluster, not the one following it. You must actually read one byte more to get that field updated. It won't help FreeDOS of course because it still uses fnodes for these things instead of SFTs. Doesn't it update the SFT relative and absolute current cluster values, too? As far as I've understood it, fnodes should be invalidated when leaving DOS, so if these cluster references were saved in the fnode only, it wouldn't help a lot. It should update those but doesn't at the moment. Bart -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Hello again
2009/5/17 Bart Oldeman bartolde...@users.sourceforge.net: 0Bh WORD contains the high word of the relative cluster number at offset 19h 2Bh DWORD contains the current cluster number 35h DWORD contains the starting cluster number sorry, the last two are the other way around: 2BhDWORD contains the starting cluster number 35hDWORD contains the current cluster number Bart -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Hello again
2009/5/17 Christian Masloch c...@bttr-software.de: Just in case you're talking about the extended SFT: I'll use a FAT32-extended SFT (probably compatible to EDR-DOS's extensions for FAT32) even without FAT+. Somewhere *at least the beginning cluster* of the file has to be stored, and the MS-DOS SFT provides no space for the high word of a 32-bit cluster value. If programs assume the SFT size of MS-DOS these can be used with FAT16 kernels which don't extend the SFT. As mentioned previously, redirectors are not affected by larger SFTs since they get passed only pointers to the SFT by DOS. Actually MSDOS 7.10 already uses the SFT in a different way, but undocumented by RBIL, for both FAT16 and FAT32: 0BhWORDcontains the high word of the relative cluster number at offset 19h 2BhDWORD contains the current cluster number 35hDWORD contains the starting cluster number How this interacts with SHARE.EXE: I have no idea This was just obtained by writing a program that dumps the SFT after opening a large file and reading 7*4k into it on a FAT32 partition with 4k clusters. Note also that the FAT+ specification provides a method to avoid access by low-level programs or operating systems which don't know FAT+ on FAT32 filesystems by setting the version number to 0.1. DOS-C's FAT+ support could be set by default (if the build option for that support was enabled at all) to support/create large files only on drives with the version number set that way. Since DOS-C doesn't (yet) support FAT16 file systems larger than 4 GiB, FAT16+ is no option anyway. I think FAT+ as is (and implemented by EDR-DOS) then is still much too dangerous, because other OSes can still see it, so: * a new partition type number for the MBR should be defined (much in the same way as 32 MB FAT16, LBA etc) to avoid other (D)OSes from seeing it automatically. * normal DOS programs should not be able to open too large files. This can be accomplished by extending int21/ah=6c, another bit in BH (FreeDOS doesn't properly implement its bit 4 for files = 2Gb, 4Gb even: it opens without complaint). The difference with VFAT, and the NT lcase bit is that those were much more backwards compatible, i.e. no harmful data corruption when using such partititions with earlier DOS versions. Bart -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] [PATCH] fix to FCB fix
2009/5/15 Kenneth J. Davis jere...@fdos.org: Thanks, saved me some time further examining it. Explains why 0 was being passed in. Reviewing it further, I should have caught that. I still haven't found any programs other than old GEM that use FCBs for more than volume label, but its a bit hard to query for since its not something that is usually advertised and FCBs usage was already deprecated by the time I started programming. Yes, you pretty much have to look for programs from 1981/1982; MSDOS 2.0 was released in February 1983. And most hobby programmers used other computers anyway. One example however: visicalc for sure uses FCBs: download here: http://www.danbricklin.com/history/vcexecutable.htm Bart -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] state of kernel 2038
2009/2/17 Eric Auer e.a...@jpberlin.de: /* clear the Init BSS area (what normally the RTL does */ memset(_ib_start, 0, _ib_end - _ib_start); Maybe this broke when Bart tuned the memory model recently? Remember for example JEMM386 int 19 fastboot compatible storage of original pointers of hooked BIOS intr here... As quite a few BIOSes also clear the RAM, it would be plausible that a bug in this area could stay undetected for quite a while? in both cases the variable ends up as 0 Not for RayeR, apparently: Some variables were nonzero in initdisk. if this makes any difference, either the memset() memset above doesn't work or the error relates to the actual placement of the variable in the DATA segment. usually an overwriting problem or similar. good luck hunting if it's the latter As RayeR was able to fix the symptom by using BSS_INIT(x) = x style for the macro, I hope that if it is the latter his fix would have broken something else, so I believe that the memset has a problem. I don't see it: even when tracing with DOSEMU's debugger dosdebug: t Trap 1, system state: emulated,stopped AX= BX=0206 CX=0e7c DX=0a04 SI= DI=0fdc SP=2240 BP=224c DS=9dd9 ES=9dd9 FS= GS= FL=3312 CS:IP=9062:9c5f SS:SP=9dd9:2240 9062:9c5f 88C4 mov ah,al t Trap 1, system state: emulated,stopped AX= BX=0206 CX=0e7c DX=0a04 SI= DI=0fdc SP=2240 BP=224c DS=9dd9 ES=9dd9 FS= GS= FL=3312 CS:IP=9062:9c61 SS:SP=9dd9:2240 9062:9c61 D1E9 shr cx,1 t Trap 1, system state: emulated,stopped AX= BX=0206 CX=073e DX=0a04 SI= DI=0fdc SP=2240 BP=224c DS=9dd9 ES=9dd9 FS= GS= FL=3312 CS:IP=9062:9c63 SS:SP=9dd9:2240 9062:9c63 F3AB repe stosw rep stosw is called for the correct values compared to kernel.map and the kernel boots fine. (OW 1.8, current SVN stable kernel source) So which initdisk variables do you refer too? Where are they in kernel.map? Bart -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] PATCH: sys fix
2009/5/1 Eric Auer e.a...@jpberlin.de: Why did our old code do that complex put bp at [bp+2] thing? I don't know; it is old code from Pat Villani. Perhaps it wanted to do an extra pop bp from that place but bp was already set to sp so that would be wrong too. -pushbp ; trash old return address -mov bp,sp -xchgbp,[2+bp] -pop bp Bart -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] PATCH: sys fix
Hi Eric, 2009/4/25 Eric Auer e.a...@jpberlin.de: Would you like to have access again? Should be no problem :-) Sure! Question about the change in OpenWatcom headers which now apparently want 32 bit arguments for 16 bit values, which breaks not only SYS but also other DOS apps: - why did they do it? http://www.openwatcom.org/index.php/C_Compilers_Release_Changes * The date and time arguments to _dos_getftime() and _dos_setftime() are now using 'unsigned int' type instead of 'unsigned short'. This change has been made to improve compatibility with other compilers. * The segment argument used with _dos_allocmem(), _dos_freemem() and _dos_setblock() is now unsigned int instead of unsigned short. This change was made for compatibility with other compilers. So it's a good change because it makes OW compatible with MSVC, DJGPP etc. - when did they do it, what is version 1280? OW 1.8 - what are the hopes that they fix that regression? I don't think they will; it's deliberate. And sys only gets a warning, but the compilation breaks because it sets the compiler option err on warning. PS: Is the kernel compilation itself affected, too? No. Bart -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] PATCH: sys fix
Hi,
here's a patch to be able to compile SYS with OW 1.8. I've lost SVN
commit access (sorry Jim for not responding to your email, I was very
busy at the time), so I'm sending a patch in the hope somebody will
apply it.
Bart
Index: sys/sys.c
===
--- sys/sys.c (revision 1366)
+++ sys/sys.c (working copy)
@@ -162,7 +162,11 @@
#else
typedef struct
{
+#if defined(__WATCOMC__) __WATCOMC__ 1280
unsigned short date, time;
+#else
+ unsigned date, time;
+#endif
} ftime;
#endif
@@ -1001,7 +1005,11 @@
struct stat fstatbuf;
BYTE far *bufptr;
BYTE far *buffer;
+#if defined(__WATCOMC__) __WATCOMC__ 1280
UWORD theseg;
+#else
+ unsigned theseg;
+#endif
strcpy(source, srcPath);
if (rootPath != NULL) /* trick for comspec */
--
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] fresh freedos svn kernel updates
On 7/22/07, Eric Auer [EMAIL PROTECTED] wrote: again, I think that only IRQTEXT is what broke Bochs compatibility. So I applied a patch (revision 1341) which leaves the other 1325 changes intact. Jemm FASTBOOT should work with version 1341. With the 1325 IRQTEXT, all versions (1325 to 1340) failed in Bochs at some point around the PostConfig kernel relocate moment, even if no HMA was available. No idea why - 1341 is based on intuition and experiments, not on theoretical knowledge why IRQTEXT was bad. The problem was that the irqstacks.asm init (for config.sys STACKS=n where n0) was setting up the wrong segments for IRQ vectors. It should be correct now in SVN (tested with Bochs). IRQTEXT needs to be present to force the saved IVT vectors to be at 70:100, which is the RBIL documented location; otherwise they are stored somewhere else. Bart - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] fresh freedos svn kernel updates
On 7/21/07, Eric Auer [EMAIL PROTECTED] wrote: Are there any volunteers to maintain the UNSTABLE branch of the kernel? I was looking into merging parts of UNSTABLE a few months ago but it's a lot of work since I don't like about half of the changes. And after that I ran out of time, and still am, just now spending a spare hour or two on FreeDOS. There are funny space savings in text strings just so that Lucho could get the compressed kernel under 40K. I found one bug in the inittext.c optimizations by Arkady. And so on. Although the ioctl.c restructuring is good, most of the chario.c savings also help. A lot more could be saved in initdisk.c by using the fact that the sector size equals 512 (the DOS code cannot assume that with ram disks etc, but the BIOS code needs to assume 512 because the BIOS int13 does not support any other size AFAIK -- though I've heard Aitor claiming some things about an old AT I do not understand how that can work -- what BIOS interface to use to figure out that sectors have 1024 bytes?). External country.sys and more windows 3.x support never hurt. Removing the internal country table makes things a little bit more dependent (Tom's point of having the internal table is that you don't need a country.sys file if all you want is the correct date-month-year display). Of course the internal table is not good for the 40K aim. Bart - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Use of DJGPP under FreeDOS
On 6/3/07, Andris Pavenis [EMAIL PROTECTED] wrote:
kernel/int2f.asm generates reference to _nlsInfo which remains
unresolved. I had to rename it to NLSINFO there for linker to succeed.
2007/05/01 CVS version did not compiled out of box. So this problem
has appeared after that.
This problem was fixed in SVN last weekend, not in CVS anymore.
It only happens with Borland compilers though, not with Open Watcom,
which is why it was there unnoticed.
Without LFN there is not such problem. I am however I myself am
interested only on system which support LFN.
'touch FOO' fails in exactly the same way. As far as debugging
showed it is DJGPP's utime() (or more exactly DOS Fn 0x5705, which
fails).
Yes exactly, it is DOSEMU not implementing 0x5705 (and al=4,6,7). So
last time you reported the GNU sed bug at the wrong place, and now
this bug again :)
Anyway, I attached a quick dirty DOSEMU patch (probably applies to
all fairly recent sources incl 1.4.0) that works around it. It does
not actually modify the access time (that is more work, as DOSEMU will
need to get code to associate the DOS handle with an SFT, and then
look up an index into a file descriptor array in that SFT if DOSEMU
owns it; I'll do that later) -- it just pretends the call succeeds.
Bart
Index: src/dosext/mfs/lfn.c
===
--- src/dosext/mfs/lfn.c (revision 1815)
+++ src/dosext/mfs/lfn.c (working copy)
@@ -803,6 +803,18 @@
d_printf(LFN: doing LFN!, AX=%x DL=%x\n, _AX, _DL);
NOCARRY;
+
+ if (_AH == 0x57) {
+ switch (_AL) {
+ case 0x04:
+ case 0x05:
+ case 0x06:
+ case 0x07:
+ return 1;
+ }
+ return 0;
+ }
+ /* else _AH == 0x71 */
switch (_AL) {
case 0x0D: /* reset drive, nothing to do */
break;
Index: src/base/async/int.c
===
--- src/base/async/int.c (revision 1819)
+++ src/base/async/int.c (working copy)
@@ -1143,7 +1143,7 @@
static int int21lfnhook(void)
{
- if (HI(ax) != 0x71 || !mfs_lfn())
+ if (!(HI(ax) == 0x71 || HI(ax) == 0x57) || !mfs_lfn())
fake_int_to(int21seg, int21off);
return 1;
}
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Tom's kernel changes vs. CVS
Hi,
I've put on some effort in merging Tom's changes into the current CVS
('stable').
Thanks to Eric for forwarding the patch. Committing them back into CVS
is mostly done now.
Many of the changes in Tom's kernel, when compared to 2035 plain, were
already there (or in a slightly different form), some are not.
I'm left with the small diff below of changes I do not understand.
Tom, can you explain?
1. config.c. Why use instead of =? Is there a corner case with equality?
2. initoem.c:
+ if (ramsize == peek(0, RAMSIZE))
if (ramsize * 64 == ebdaseg ramsize 640 peek(0, RAMSIZE) == ramsize)
the extra double check looks strange to me, why check twice?
Something strange with short-circuit boolean evaluation?
3. int21/ax=3301. The comment and the code are out of sync. By falling
through it reports the new state of break_ena in DL (not AL).
Moreover, RBIL tells us that Novell DOS 7 report the *old* state
(instead of the new state) in DL. What is the intended logic here?
Thanks,
Bart
--- ke2035/kernel/config.c 2004-05-25 01:02:46.0 -0400
+++ ke2035ctom/kernel/config.c 2007-05-14 12:43:46.0 -0400
@@ -753,8 +753,8 @@
if (timeout = 0) do
{
r.a.x = 0x0100; /* are there keys available ? */
init_call_intr(0x16, r);
-if ((unsigned)(GetBiosTime() - startTime) = timeout * 18u)
+if ((unsigned)(GetBiosTime() - startTime) timeout * 18u)
return 0x;
}
while (r.flags FLG_ZERO);
diff -urb ke2035/kernel/dsk.c ke2035ctom/kernel/dsk.c
+++ ke2035ctom/kernel/initoem.c 2007-05-14 12:43:46.0 -0400
@@ -58,7 +59,8 @@
unsigned ebdaseg = peek(0, EBDASEG);
unsigned ramsize = ram_top;
+ if (ramsize == peek(0, RAMSIZE))
if (ramsize * 64 == ebdaseg ramsize 640 peek(0, RAMSIZE) == ramsize)
{
unsigned ebdasz = peekb(ebdaseg, 0);
diff -urb ke2035/kernel/inthndlr.c ke2035ctom/kernel/inthndlr.c
--- ke2035/kernel/inthndlr.c2004-05-30 20:31:06.0 -0400
+++ ke2035ctom/kernel/inthndlr.c2007-05-14 12:43:46.0 -0400
@@ -78,17 +78,17 @@
case 0x33:
switch (irp-AL)
{
+ /* Set Ctrl-C flag; returns al = break_ena */
+case 0x01:
+ break_ena = irp-DL 1;
+ /* fall through */
+
/* Get Ctrl-C flag */
case 0x00:
irp-DL = break_ena;
break;
- /* Set Ctrl-C flag */
-case 0x01:
- break_ena = irp-DL 1;
- break;
-
case 0x02: /* andrew schulman: get/set extended
control break */
{
UBYTE tmp = break_ena;
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Comparison of FreeDOS 2036 to the Tom kernel
Part 2...
On 1/1/07, Eric Auer [EMAIL PROTECTED] wrote:
inthndlr.c: Toms version modifies DL on return from int 21.3301
(set ctrl c flag), while the CVS does not - CVS is better.
TA -- discussed earlier
The CVS version uses the new dpb16to32 function for shorter code.
CN
TOMS version has some interesting extra error handling, maybe
this can be added to the CVS version: Around line 430, Tom does
if ErrorMode AH=0c AH neither 30 nor 59 then { ErrorMode=0;
fnode[0].f_count = 0; fnode[1].f_count = 0; } - in other words,
for the non-reentrant DOS functions, make sure to mark all near
fnodes as unused on entrance to int 21.
Later, around line 1550, if not both fnode counts are 0, force
them to be 0, but display a warning if ErrorMode was 0. Explanation:
An int24, for example in FindFirst, is handled by an app by NOT
returning to the kernel (possible). That way, resources are never
freed and ErrorMode is never reset...
Note that Tom only forces fnode freeing, not ErrorMode reset.
TA. This is also in the UNSTABLE kernel, to be exact I ported it from there.
FatGetDrvData modifies AX in Toms version and AL in CVS, which of
the two is better? See fcbfns.c
The FcbParseFname call of int 21.29 modifies AL directly in CVS,
while Toms version also updates rc. WHICH OF THE TWO IS BETTER?
CN (both)
Tom re-orders some register writes, which looks as if he tried
to set lr.ES / lr.DI as late as possible. Why? Optimizes better?
TA. Probably to allow the compiler to do common tail optimization. It
saves a few bytes.
The CVS version returns CX = 0 on int 21.30, while Tom returns
the REVISION numbers. A comment in CVS tells that CX must be 0
for 32RTM compatibility - found by Michael.
The int 21.36 implementation follows the different DosGetFree
parameter / return value structure in both versions.
The function int 21.??0a, set extended error, looks more optimized
in the CVS version. Both seem to have the same effect. COMMENTS?
In the CVS version, int 21.5f checks if cdsp-cdsDpb has a zero
offset, according to comments this checks if a drive is physical.
Sounds good...? This affects the handling of the AL==7 case.
The CVS version provides a more extended stub for the DBCS API
int 21.63xx ;-).
CN
The int2F_12_handler of the CVS version supports several new
functions: 26 (open), 27 (close), 29 (read). HOWEVER, the new
code for function 28 (seek) is disabled. WHY?
There is also a SET DOS VERSION DX interface at function 2f.
CN
- intr.asm: Toms version has the following additional code:
global INTR / INTR: INTR (between the no_read_error: ret and
the segment INIT_TEXT around line 125). What is that used for?
Where is INTR defined?
TNA
right at the beginning: %macro INTR 0
called by Tom in two places.
- ioctl.c looks BETTER IN TOMS version: r_command of the request
header is set based on al, using a table with the entries
0,0,C_IOCTLIN,C_IOCTLOUT,C_IOCTLIN,C_IOCTLOUT,C_ISTAT,C_OSTAT,
C_REMMEDIA,0,0,0,C_GENIOCTL,C_GENIOCTL,C_GETLDEV,C_SETLDEV,
C_IOCTLQRY,C_IOCTLQRY at slots 0..11 (hex). The CVS code, on
the other hand, spreads this information over two switch / case
areas which first set a nMode variable and later set r_command.
TA: This is a little optimization that is also present in the UNSTABLE
ioctl.c (which takes things a bit further). The table saves doing
everything seperately in switch cases. Actually ioctl can be made a
lot simpler with that table. Done in UNSTABLE, but I could do better
myself (saving ~200 bytes in the process), not applied yet.
- main.c has an updated copyright string year in the CVS version.
Other differences seem to be whitespace-only around line 570 and
correcting a typo: TOM has the corrected boot from string around
line 735, while the CVS version writes booot from. One more diff
is around line 690: Is EmulatedDriveStatus nothing/void (Toms
version) or is it STATIC int (CVS version)...?
TA (for booot), the rest is CN.
- memmgr.c: The CVS version allows double free of memory blocks,
which is necessary to be compatible with a flaw in QBasic 4...
CN
- nls.c: TOMS version quotes quite some ASM code and sets many
registers before calling intr(0x2f,r): BH=0x14 BL=subfct CX=bufsize
SI=(short)nlsinfo BP=bp BX=cp DX=cntry ES:DI = pointer bp.
The CVS version, on the other hand, uses call_nls(subfct,
nlsInfo, bp, cp, cntry, bufsize, buf, id). WHICH OF THEM IS BETTER?
TO (none :) I applied something else that puts id in the high part
of a long, and no intr. It's a tricky variable because SS!=DS in that
code.
- proto.h: The parameters / return types differ for DosGetFree,
FcbParseFname and FatGetDrvData. The CVS also has dpb16to32...
CN
- serial.asm: The CVS version has ComInStat, which allows polling
the serial port status. Implemented based on a feature request
[Freedos-kernel] Comparison of FreeDOS 2036 to the Tom kernel
Hi, here is the point by point reply to Eric's list... CN means: a new change in CVS independent of Tom (not present in the 2035-Tom diff) TA means: Tom's change, applied TNA means: Tom's change, not applied TO means: Tom's change, other, see explanation. On 12/31/06, Eric Auer [EMAIL PROTECTED] wrote: - Tom has a build2 bat file, which does a SYS CONFIG on the kernel, copies the kernel to A:, and sorts the map file. We could add that to the cvs. TNA He's had that for a long time, I always saw that as something Tom specific. You certainly don't want to put it as is... as strange things will happen, I'd get Error reading from drive A: DOS area: sector not found (A)bort, (I)gnore, (R)etry, (F)ail? without a floppy drive... - buildall, build, default: more comments in cvs, plus cvs has set dos4g=quiet CN - bugs / build / lfnapi / mkboot / nls / sys / readme.txt: at most differs in linebreak style? WHAT is 2. in mkboot?? There hasn't been a 2. in mkboot since at least May 2000. Is the zip naming scheme still up to date in readme? Does sys.txt describe all current stable SYS options? CN (I don't know) - config.txt: cvs has a newer extended version NOTE: I think there should be a FCBS note telling that FreeDOS can provide FCBS without FCBS=... line? The IF %config%==... example should use . CN (Perhaps) - contrib.txt: cvs is newer, updates Bernd / Aitor CN - fdkernel.lsm / version.h / globals.h differ, of course NOTE that we no longer have REVISION_MAJOR nor REVISION_MINOR as those were incompatible to 32RTM! CN. Well you can still (sort of) derive them from the string via int21/ax=33ff - intfns.txt CVS version better describes the current state QUESTION: Which int 2f functions are still missing? Any volunteers for int 21.5d01 ... 21.5d05? Typo in CVS: drive instead of driver for LFN CN - readme.cvs CVS version is better, more up to date CN - floppy.asm CVS version is slightly better, improved comments. The FL_DISKCHANGED implementation is a bit different but in the end seems to do the same thing. Could anybody CHECK THAT? TNA Tom and Arkady (in CVS) both fixed the same bug with ret 8 but in different ways: Arkady jumps backwards to ret_AH whereas Tom jumps forwards. - filelist, makefile: CVS version provides more FreeDOS style directory / zip file structure and no longer includes autoexec / config / install bat files. IF we had somewhat more useful SAMPLE CONFIG / autoexec, it would make sense to include them, but for now, I prefer the CVS style :-). CN - device.h CVS version provides r_si and r_di but those do not seem to be used yet? CN should be in ioctl.c (see UNSTABLE branch). I'll do that later. - hdr.h CVS version makes intr() void, Tom uses unsigned WHICH is better? CVS probably? TO... Tom changed intr() in pcb.h (which was unused) to match up with the one prototyped for init code, when he started using it for NLS and floppy change notification. I have instead, removed the intr() prototype. I thought, and still think, that intr() is a bit too expensive (too many bytes) to use in the resident code. Tom disagrees, but we've been through that :) - portab.h CVS version has some extra Watcom pragmas with the comment min.unpacked size (default parm / modify) I assume CVS is better? The CVS version also has MK_SEG_PTR and MK_UWORD and MK_ULONG, probably by Arkady, but I think those are not yet actually used for much? CN. I don't like those macros much, so I like it that they are hardly used but we've been through that too :) - asmsupt.asm CVS version uses some FSTRCMP / _fstrcmp / pascal_setup in Watcom, while Tom has that commented out as still untested. WHICH IS BETTER? CN. Now used in fatfs.c to prevent removal of current directory so tested. - config.c timeout is time timeout in Tom version and time = timeout in CVS version, the latter is maybe better for 0 timeouts / hanging timers?? TNA as explained by Tom just now. - dosfns.c CVS DosGetFree returns UWORD (-1 for false) instead of BOOL, so it no longer has a UWORD * spc argument NOTE: What is the purpose of spc = rg[0] in cvs? it was just moved up a bit, getting redirector data. IsDevice has different handling of padding can be with spaces or 00 bytes, probably having the same effect in the end. Could somebody COMPARE both versions? The CVS version also skips something for block devices. CN. All those changes were on purpose, no changes in Tom's kernel. - dsk.c the TOM VERSION provides an call to int 2f.4a00 to ask a potential GUI whether it is okay to display the insert disk a:/b:... DJ message as text. A GUI can trap this and show a dialog box instead. VERY NICE. TO. I have applied this but using a special purpose asm function to avoid intr to sav e about 120 bytes. NOTE that both versions have a typo: ... the any key ... It's not a
Re: [Freedos-kernel] FreeDOS kernel 2036 released
On Sun, 21 May 2006, Eric Auer wrote: As a next step, I would like to update the UNSTABLE kernel branch. If anybody can tell me how this is accessible via cvs, that is. you have to give cvs the command line option -r UNSTABLE. PS: If you want Turbo C compiled kernels published, please help compiling them. Somehow my Turbo C does not like the current source snapshot...? Turbo C insists that the source files have CRLF line endings. You ran into the old problem that UNIX CVS clients check out source files using LF line endings and Windows (not sure if anyone uses a DOS CVS client...) clients use CRLF line endings. So you've been playing the batch file cat and mouse game once again. Next time somebody uses CVS on Windows, sees CRCRLF endings and corrects them again! Subversion allows to force CRLF for all files independent of the OS it runs on so that may be a solution (converting the FreeDOS CVS repo to Subversion), but I don't think there exists a Subversion client for DOS. But then again that may not be an issue if nobody uses CVS on DOS either. Bart --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] please change the default freecom and increasethe kernel version
On Thu, 26 Jan 2006, Bernd Blaauw wrote: David O'Shea schreef: It says The UNSTABLE (aka development) branch is what I refer to as the development kernel (kernels with w suffix). It looks like those kernels actually have .dev or .dbgdev in them, right? There doesn't seem to be a discussion of the naming convention for FreeCOM. well, we have: kernel 2034, 2035 released by Bart kernel 2035A released by Jeremy kernel 2035B by Jeremy (2035A + stable features backported from 2035W) kernel 2035W by Jeremy, experimental/development line isn't there also still a kernel 2035-Tom somewhere (drivesnapshot.de)? Or did 2035A supersede that as far as Tom is concerned? Maybe I should search the emails from 1.5 years ago to find out. Bart --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] notes about my recent commits (dev kernel only)
On Sun, 20 Nov 2005, Kenneth J. Davis wrote: The reason for these -zu compatible fixes is that in cases where SS is not the same as DS (DGROUP) certain calls behave oddly, such as printf, since the compiler is passing an offset on the stack where it assumes DS==SS so the function receiving the parameters can use either segment interchangeably. The problem is in certain circumstances (such as this new interrupt handler) we are using the user's stack so the printfs only work if that happens to be the kernel else you get random values. There may be other cases where this occurs (I have experienced the printf issue before when doing some win3 work in the int 2f handler, but did not investigate at that time). I think Borland's compilers default to DS!=SS (given I only saw an option to set DS==SS) so should not be an issue for them. From a now somewhat lazy bystander... you can avoid using -zu by explictly coding the offending pointer dereferences in this way: MK_FP(_SS, ch) like it's done in nls.c. Bart --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628alloc_id=16845op=click ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Trying to figure out 386 kernel EMM386 crashes
On Sun, 24 Apr 2005, Eric Auer wrote: Things that I found: - there is an I86 define which is triggered for most (all?) known compilers and which activates some Turbo C / ... style syntax in some places. See portab.h and grep for I86 in kernel/*. and tell me WHY we have I86 at all. it's an old define to distinguish between the Intel chip and the Motorola mc68k chip. I don't think anyone has managed to build an mc68k FreeDOS kernel during the last 10 years but at some point it was possible. At least for Pat. ; we have never seen MSVC to use anything but eax, ecx, edx, ; nor have we seen Borland C to use anything but eax, ebx, edx, ; so we only protect eax, ebx or ecx, edx to conserve stack space ; WATCOM only uses FS: and GS: (using -zff and -zgf) and never ; any high part of the 386 registers If any of those assumptions is wrong, you are toast. For example if compilers do start to use more registers. Even worse, there are a few places where the Protect/Restore macros are NOT used: www.agner.org/assem has a piece (PDF) about calling conventions. This document may provide some more info. http://www.agner.org/assem/calling_conventions.pdf (Arkady-friendly URL) MSVC and Borland 16bit generating compilers have been dead for 10 years+. Noone expects their register allocators to change. Still it's a somewhat bold statement of Lucho to make about MSVC and Borland but I trust he did his research thoroughly. - int2f.asm saves/restores FS and GS to SI and DI if the compiler is Watcom. This saves 4 bytes of stack but is a BAD IDEA because it hardcodes the idea that Protect/Restore macros save ONLY FS and GS if the compiler is Watcom. I checked the OpenWatcom source code for 386 optimizations in the i86 code generator a couple years ago. There's no use of e* registers at all. I'll promise to let you know if an enterprising developer changes this, but frankly, I think that the chance of a meteorite hitting your house tomorrow at 3:00am is higher. Bart --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Re: [Freedos-cvs] kernel/kernel inthndlr.c,1.87.2.12,1.87.2.13
Hi Tom, the whole point is that in a shared programming effort (as the freedos kernel still should be) it's a waste of resources to change ANYTHING without a certain payback. Lucho's payback is clear. He compiles with Borland C and compresses the result, so that the *compressed* kernel fits in 40K. Not the uncompressed usage matters but the compressed; as far as I understood, he has exactly 40K left on his ROM for kernel.sys. Anyway, for those not watching freedos-cvs, he removed the breaks and put in some other optimizations now. in this case, removing 'break;' may have saved 5 bytes in the early 90ties, but is irrelevant (or even contraproductive) with optimizing compilers, and leads only to such irrelevant 'why was this changed' threads. For Turbo: 6 bytes (2x jmp near). With Watcom and the #pragma aux return_user aborts (so the compiler knows it can use jmp and not call) no difference at all. Bart --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Optiize and OpenWatcom
On Thu, 6 Jan 2005, Alain wrote: Peter Fedorow escreveu: OmmitIfOptimizeSize break (); Has anyone managed to make this construct qork with OpenWatcom? We (me and Andreas) have run across this issue for debug macros and the /##/ construct aparently does not work. We would appreciate any hint to an alternate construct ;-) I cannot read your mind to see what you want exactly, but of the following the first construct works with any C89 compiler; the second, which saves a pair of brackets is C99-style (works with OW and GCC, not with old Borland compilers). #ifdef DEBUG #define DebugPrintf(x) printf x #else #define DebugPrintf(x) #endif DebugPrintf((hello)); #ifdef DEBUG #define DebugPrintf2(...) printf(__VA_ARGS__) #else #define DebugPrintf2(...) #endif DebugPrintf2(hello); Bart --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] [patch] int21/ah=6/dl=ff must call int28
--- inthndlr.c
+++ inthndlr.c
@@ -467,8 +467,10 @@
lr.AL = 0x00;
r-FLAGS |= FLG_ZERO;
- if (StdinBusy())
+ if (StdinBusy()) {
+DosIdle_int();
break;
+ }
r-FLAGS = ~FLG_ZERO;
/* fall through */
---
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/utils exeflat.c,1.9.2.3,1.9.2.4
On Thu, 18 Nov 2004, Arkady V.Belousov wrote: Of course, qsort() if very fast algo (except some specific cases, when it is O(N^2)), but why to do _any_ extra action, when unnecessary? :) Especially, I suggest, (most) linkers do own sorting anyway? I think even bubble sort would be fast enough here. It's just that qsort is convenient because it is provided by the RTL. Hm. I think for simplicity and safety, exeflat should itself move relocation table from executable's header inside executable itself, so that it may be reused by MoveKernel(). This allows to eliminate manual table at kernel.asm:__HMARelocationTableStart. (Yes, I know __HMARelocationTableStart is not plain relocation table, but jump/code table, with jmps and calls to EnableA20. But table from header may be copied (after fixing) into secondary table. This allows to make code, which is more relocatable and may make cross-segments calls and accesses. This also solves issues with standard library routines, which may be used both from non-relocatable low code and from relocatable code.) This is not so easy. Firstly a secondary table would need extra space in low memory. There used to be entries to strcpy et al in the table but I removed them later because that part of the table that was useless after init was still resident. Secondly it would be quite a bit of effort for very little gain. Also think about it: we don't know in advance how big the table will be, it's hard to insert something of arbitrary size in kernel.sys. And then, where's the simplicity? PS: Bart, some time ago you decrease kernel by reordering object files. May you explain what was changed and how you find this? Just reordered by placing more or less similar files close together (asm close to asm, c close to c); that decreased entropy so compression improved. Bart --- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/utils exeflat.c,1.9.2.3,1.9.2.4
On Sat, 20 Nov 2004, Arkady V.Belousov wrote: Yes, and then now may be reduced code duplication in asmsupt.asm (which generated both for transient and resident portion). only for Borland C. For Watcom they are not duplicated (only one CS: there). And anyway it's only a small amount of code. Of course, initial efforts to implement are not very easy, but gain is noticeable. For example, with such relocation you will never encounter troubles, like was issued with RTL-multiplcation functions from OW. That was a different problem. Watcom generated NEAR calls to these functions. Relocation wouldn't help. This point is moot now with one CS, and anyway I like our own versions better :) The more so, now they may be moved from low/nonrelocatable part (in kernel.asm) into resident part! (Do you remember, how I was try to move Borland's RTL functions into resident part and forget about relocations?) Yes you could move these into the resident part if you do runtime patching. But is it worth the effort for a secondary compiler? I will not stop you trying to do this, but I see it as a waste of time myself (other than an exercise in patching). PS: Bart, some time ago you decrease kernel by reordering object files. May you explain what was changed and how you find this? BO Just reordered by placing more or less similar files close together (asm BO close to asm, c close to c); that decreased entropy so compression BO improved. Only compression? I remeber something about reduced executable size, but without words about compression. No it was only compression, how else can reordering save space? The trick to reduce uncompressed executable size was only obtained using a different default calling convention via #pragma. Bart --- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/utils exeflat.c,1.9.2.3,1.9.2.4
On Thu, 18 Nov 2004, Arkady V.Belousov wrote:
Small optimization: because BC doesn't knows, that exit() doesn't
returns, better to insert explicit return 0; after exit() or return error
code through return (remaining error handling for main()). For BC, this
allows to join common tails.
I don't think optimizing exeflat.exe's size is very important though ;)
LG + qsort(reloc, header.exRelocItems, sizeof(reloc[0]), compReloc);
Why to spend extra time for sorting relocations?
I think it's easier to read the output that way. Tom's idea.
Does qsort() really take a long time for you in exeflat? I find that hard
to believe, for just ~70 relocations.
LG +for (j = 0; j silentcount; j++)
LG + if (segment == silentSegments[j])
LG + {
LG +silentdone++;
LG +goto dontPrint;
LG + }
Never understand this option. (Though, don't try to study its meaning
deeper). The more so, me always annoying tons of some information about some
relocations, which garbaes output after exeflat.
use a larger backscroll buffer. Anyway, seriously:
The -S0x10 -S0x8B is outdated. 0x10 corresponds to segment 0x70 (device
drivers etc) and 0x8B to the DOS data segment at 0xEB. However over the
years some things were made smaller and the DOS data segment seems to be
at 0xCF or 0xD0 depending on compilation options now.
-S0x10 -S0x6F -S0x70
will catch relocations from these segments. The idea to silence these is
that these relocations are harmless because these segments don't move.
Relocations to other segments may be bugs. With the above options you
should get something like
relocation at 0x:0x0021 -01d6 (far jmp to init code in kernel.asm)
relocation at 0x01d6:0x9f2d -0f2f (seg init_tos in kernel.asm)
relocation at 0x01d6:0xa19c - (LowKernelConfig, main.c)
relocation at 0x01d6:0xc21c -01d6 (MoveKernel, FP_SEG(_HMATextEnd, inithma.c)
I checked them and these relocations are all fine. But if a fifth shows up
unexpectedly we may have a bug.
---
UPXOPT seems indeed unnecessary now.
Bart
---
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Fwd: FreeDOS kernel disk routines
On Sat, 6 Nov 2004, tom ehlert wrote: However,FreeDOS hooks INT 13 No, if anything hooks INT 13 it could be LBACACHE but the kernel does not (it should but for different reasons -- see int2f/ah=13 in RBIL). how are these disks/BIOS variants detected ? I have a faint memory of these translating BIOS's, but can't find it in RBIL. RBIL D-1302 INT 13 - DISK - READ SECTOR(S) INTO MEMORY [...] AWARD AT BIOS and AMI 386sx BIOS have been extended to handle more than 1024 cylinders by placing bits 10 and 11 of the cylinder number into bits 6 and 7 of DH Probably a rare breed of machines. For most bit 6 7 of DH mean bit 6 and 7 of the (translated) head number. I have no idea how to distinguish this meaning. My 386 SX only had 80 MB hard disk space, which was far below the first problematic barrier of 1024*16*63*512=512MB IMO the kernel shouldn't touch partitions that are to big to handle (1024 cylinders), unless LBA is detected. Agreed. That's what it does today. Bart --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
RE: Re: [Freedos-kernel] unused SFT fields - f_nodes not needed???
On Tue, 2 Nov 2004 [EMAIL PROTECTED] wrote: So there is the problem to estimate the size of the code: - changing references to f_nodes from near to far (thus with a segment prefix) about 1300 bytes. It's not just segment prefixes; lots of pointers get passed around. They're really quite expensive, those far pointers. against: - the code used to sync both structures Most probably less than 1300. - the amount of memory occupied by the f_nodes themselves 120 bytes (2x60). There's also something else, the SFT is quite a clunky structure to work with: with fnodes we have total flexibility, but SFTs suffer backward compatibility hacks to store FAT32 cluster numbers (see RBIL table 1642, which doesn't even mention where Win 98 DOS stores them for the most part, but they need to be spread out over multiple WORDs). Some simple functions such as lseek don't need fnodes. But for something like open() they're quite convenient. Eric: the missing direntry items aren't a big deal: dir_write would need to be changed to do a read/modify/write instead of a simple write. The rest more or less corresponds, indeed. Bart --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] unused SFT fields - f_nodes not needed???
Hi Eric, Is that correct? I think SFT-messing programs like Windoze will not be happy in particular about all those uninitialized cluster values, the missing DCB pointer, and missing dir entry info. The share / ifs stuff is probably less interesting or set by SHARE / IFSdrivers directly, without kernel interaction. True, perhaps. I don't think Windows XP will fiddle much with SFTs though, except in NTVDM... ;) Next point are the fnodes themselves: f_count, f_mode, f_flags, f_diroff, f_dirstart, f_offset, f_cluster and f_cluster_offset all seem to have exact equivalents in the SFT slot structure. Am I misunderstanding something here or could we just throw away half of the f_node fields by using the SFT slot fields instead??? We could, but I don't think it's a good idea. Working directly with SFTs means bloating the code since these are far and not near. The *far* fnodes can be eliminated and their purpose can be replaced by SFTs. Basically the fmemcpy() that is called in save_far_f_node() and xlt_fd() could be replaced by a function that copies things from or to the SFT for the fnode. Then all the basic functions (dos_mkdir etc) in fat*.c can remain unchanged. That way the two near fnodes become a purely internal FreeDOS kernel implementation detail within fatfs/fatdir.c; the permanent fnodes are gone. I mentioned this before; then Tom replied http://www.mail-archive.com/[EMAIL PROTECTED]/msg00493.html so we have the far fnodes in the HMA now and the rest is planned to do for an unspecified date. In retrospect the near/far fnode change was a big step into this direction (seperating internal/external representation), it doesn't conflict with it! Bart --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] BUFFERS problem: wasting low memory if HMA too small
On Mon, 11 Oct 2004, Eric Auer wrote: http://fd-doc.sourceforge.net/faq/cgi-bin/viewfaq.cgi?faq=incoming/321 tells: If not ALL buffers fit into HMA, then ALL buffers will be in low DOS memory. How hard would it be to put MOST buffers in HMA and only the REST in low DOS memory, if many BUFFERS are requested? downgrade to kernel 2027 or earlier ;) It's an undocumented DOS limitation; other DOSes also have the BUFFERS in one segment, although I think some may be able able to place them in a UMB rather than the HMA. I don't see this as a big problem: 38 buffers seems plenty to me and if you want more buffering there's cache anyway as you know very well (or in other words I don't know why the poster needed 40 of them). Bart --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Creation times
On Mon, 13 Sep 2004, Luchezar Georgiev wrote:
Bart wrote:
I wonder about those creation time set removals. It looks like your
removing a useful feature here. Sure a reason given is MSDOS 7.10
doesn't do this. Well, I say, who cares about this specific DOS,
Isn't *this* specific OS what we try to emulate as closely as possible
(including even its bugs)?
no. We want to be compatible with it. That's a subtle but important
difference. It means that we should feel free to implement features in
FreeDOS not present in any other DOS, as long as it doesn't break existing
DOS programs (which of course proved harder than it seems :( ).
The reason why the FAT32 version reports 7.10 is simply because 5.00
would mislead some programs into believing that FAT32 support is not present.
It didn't actually do that. FreeDOS did *always* set the creation time
*equal* to the write time.
No way. init_direntry set the creation time equal to the write time but
only for created or replaced files (status != S_OPENED), and in mkdir.
The place where write time starts to be different from creation time is
in
fnp-f_dir.dir_time = dos_gettime();
fnp-f_dir.dir_date = dos_getdate();
in dos_close().
Since you sound so confident I wrote a small program that creates a file
where the creation time is not equal to the write time.
So the creation time didn't hold even a single
of bit of information and was therefore misleading. Making it set the
creation time *only* once, when a file is created, is surprisingly
difficult (I tried and failed), and is not required for a DOS anyway.
Let's not try to be bigger catholics than the pope.
There's nothing religious about this. It's simply a feature.
Bart
#include fcntl.h
#include io.h
#include dos.h
int main(void)
{
int fd = open(fool.dat, O_WRONLY|O_CREAT|O_TRUNC);
write(fd, hello, 5);
close(fd);
sleep(2);
fd = open(fool.dat, O_WRONLY);
write(fd, hello bye, 9);
close(fd);
return 0;
}
---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Creation times
On Tue, 14 Sep 2004, Luchezar Georgiev wrote:
#include fcntl.h
#include io.h
#include dos.h
int main(void)
{
int fd = open(fool.dat, O_WRONLY|O_CREAT|O_TRUNC);
write(fd, hello, 5);
close(fd);
sleep(2);
fd = open(fool.dat, O_WRONLY);
write(fd, hello bye, 9);
close(fd);
return 0;
}
Thanks, Bart. Seems that as I already have written so, I AM THE FOOL HERE!
Tested, and it's really as you say. Then why my files I worked over in
FreeDOS were all with creation times = write times?
No, I will resign from kernel development. Let me leave it to the more
competent and young. No, seriously!!!
what is going on? I simply provided a counter-example. Everyone makes
mistakes.
People provide counter-examples to me as well, then you simply
have to accept that, you learned something new, and life goes on. Don't
see this as a personal failure. fool.dat was more a tongue-in-cheek
filename, basically I already had a file named foo.dat so played with
that ;)
Bart
---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: [Freedos-cvs] kernel/kernel asmsupt.asm,1.23,1.24 entry.asm,1.27,1.28 fatfs.c,1.70,1.71
On Sun, 12 Sep 2004, Kenneth Davis wrote: merge in some changes from UNSTABLE I wonder about those creation time set removals. It looks like your removing a useful feature here. Sure a reason given is MSDOS 7.10 doesn't do this. Well, I say, who cares about this specific DOS, many other OS'es *do* set the creation time. Did it hurt that FreeDOS did this? Maybe it should be a config.sys option if it did hurt in certain (documented) circumstances. batch files no change just line ending issue which is pretty annoying if you check out on Linux -- I'll really have to push a patch to Steffen to allow FreeCOM not to choke on LF-ended batch files... Bart --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Compilers (the eternal topic :)
On Mon, 23 Aug 2004, Luchezar Georgiev wrote: What do you mean by the 386 options? I do use the -3 option as well as -zff -zgf options. Yes that's what I meant. What are the errors dsk.c gives you? That's the only weak point indeed. They didn't seem to fix the bug I reported (bug 407) either. I suspect there are other bugs introduced in 11.0 but not present in 10.6 that remain in 13.0 (1.3). OW is just like FreeDOS here, bugs only gets fixed when somebody is interested enough to fix it, pays someone else to fix it, or hopes that somebody else fixes it, but no guarantees. In your case not enough people have cared about it so far, I'm afraid. A bug tracker just records the bug so it won't be forgotten as easily as writing an email. Bart --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Compilers (the eternal topic :)
On Sat, 21 Aug 2004, Luchezar Georgiev wrote: Even after reducing kernel size with my latest patches I still get 65830 bytes. That's more than a kilobyte bigger! How can we explain that? Well I can only try to narrow down by telling exactly what I did: here we go: download UNSTABLE cvs cvs -z3 -d:ext:[EMAIL PROTECTED]:/cvsroot/freedos co -rUNSTABLE kernel cd kernel get your patch wget http://linux.tu-varna.acad.bg/~lig/freedos/kernel/CVSPATCH.TXT apply patch -p2 CVSPATCH.TXT resolve rejects in exeflat.c :( Make batch files CRLF as Jeremy converted them find . -name \*.bat | xargs unix2dos copy config.bat from elsewhere, disable UPX Use DOSEMU with OW 1.2 just to make sure. cd to directory build wc 386 fat32 kernel/kernel.sys and kernel/kernel.map have disappeared... Hard to get my fingers used to that. Oh well we still have bin/kernel.sys: 64266 bytes. bin/kernel.map. Also gone... Ok bin/kwc38632.map still exists. I've uploaded it to http://freedos.sf.net/kernel/kwc38632.txt so you can compare the map file. Bart --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Compilers (the eternal topic :)
On Sun, 22 Aug 2004, Luchezar Georgiev wrote: They had moved the 1.3 from the devel/beta subdirectory onto a new one: http://downloads.openwatcom.org/ftp/zips-1.3/ I think it's a good sign that they're ready to announce it soon. But Bart probably knows more ;-) Michal Necasek just said he was going on holiday for two weeks. He just apparently (didn't know myself) just renamed 1.3rc3 to 1.3 before taking his bags ;) but there hasn't been any formal announcement Anyway the code generator hasn't improved from our point of view. The compiler is significantly faster for certain code (not sure if that affects FD-kernel). In case you're interested I've put the changes below. Bart * The C++ compiler now restricts the scope of variables declared in a for loop to the scope of that loop in accordance with ISO C++, not extending the scope beyond the loop (ARM compliant behaviour). Code relying on the pre-standard behaviour must either be changed or compiled with new -zf switch which reverts to old scoping rules. * Support for default template arguments has been added to the C++ compiler. * Support for alternative tokens (and, xor etc.) has been added to the C++ compiler. It is enabled by default, can be turned off with the new -zat switch. * The C runtime library has been made significantly more C99 compliant. A number of new headers have been added (inttypes.h, stdbool.h, stdint.h, wctype.h) and corresponding new functions implemented. Wide character classification functions were moved out of ctype.h into wctype.h. C99 va_copy macro was added to stdarg.h. * Added 'cname' style C++ headers. * Support for SSE, SSE2, SSE3 and 3DNow! instruction sets has been added. Affected tools are the assembler (wasm), as well as all x86 compilers, disassembler and debugger. The debugger now also supports MMX registers formatted as floats (for 3DNow!) as well as a new XMM register window for SSE. * Inline assembler directives .MMX, .K3D, .XMM, .XMM2 and .XMM3 are now supported in the _asm as well as #pragma aux style inline assembler interface. Note: .MMX directive is now required (in addition to .586) to use MMX instructions. * C compiler performance has been significantly improved (up to 5-10 times speedup) when compiling large and complex source files. * All x86 compilers now have the ability to perform no truncation when converting floating point values to integers. Additionally, 32-bit x86 compilers have the option to inline the rounding code instead of calling __CHP. * The C lexical scanner no longer evaluates constants with (U)LL suffix that fit into 32 bits as zero (1ULL was wrong, LONGLONG_MAX was correct). * C and C++ x86 inline assembler has been fixed to properly process hexadecimal constants postfixed with 'h'. * The C compiler now supports the C99 'inline' keyword, in addition to previously supported '_inline' and '__inline' keywords. * The C compiler now treats a sequence of adjacent character strings as wide if any of the components are wide (required by C99), instead of depending on the type of the last component. For example, Lfoo bar is now interpreted as Lfoo bar, instead of foo bar. * The internal C compiler limit on complex expressions has been increased and if it is still insufficient, the compiler now reports an error instead of crashing. * The C compiler now issues a warning on the default warning level if a function with no prototype is referenced. This was previously warning W301 (level 3), now it is warning W131 (level 1). * Warning W132: No storage class or type specified has been added to the C compiler. This warning is issued if a variable is declared without specifying either storage class or type. This is not allowed in C89. * Warning W304: Return type 'int' assumed for function 'foo' has been added. This warning is issued if a function is declared without specifying return type. This is allowed in C89 but not in C99. * Warning W305: Type 'int' assumed in declaration of 'foo' has been added to the C compiler. This warning is issued if a variable is declared without specifying its type. This is allowed in C89 but not in C99. Note that if warning W132 is issued, W305 applies as well. * The C compiler now properly warns if a function with implied 'int' return type fails to return a value. This potential error was previously undetected. * C++ compiler diagnostic messages have been made more consistent and slightly more detailed. * Linker for Win32 targets can now create file checksums. These are primarily used for DLLs and device drivers, but can be applied to all Win32 PE images if required. * Linker for Win32 targets can now set operating system version requirements into the PECOFF optional header (Microsoft extended header). * Linker for Win32 targets can now set the linker version number into the PE optional header (Microsoft extended header). * The linker will now eliminate zero-sized segments from NE format (16-bit OS/2 and Windows) executables. This fixes a problem where Windows 3.x
Re: [Freedos-kernel] Announce: COUNTRY.SYS
On Sun, 22 Aug 2004, Aitor Santamaría Merino wrote: Yes, but as I mentioned, the problem is that, how do we get collating tables, etc for other countries than US and Germany? We could rely on user's efforts to create those tables, but this can be quite laborious Probably best to have a look at the locale tables in Linux. If one can make an automatic conversion from there it would go a long way (probably not 100% MS compatible but is that desirable for collation algorithms? -- they've probably changed themselves too). On Linux we have in /usr/share/i18n/locales a file called iso14651_1 which has the Unicode collating table (you can search the internet for iso 14651). That on its own would go a long way (good enough for English, German, Dutch, Italian -- Spanish has some exceptions with ch and ll, Lithuanian has y between i and k). Then some individual country/language combinations do a few modifications on that. e.g. a fragment of bg_BG: LC_COLLATE % We have made the following changes to the basic collation scheme in % the file iso14651_t1: % 1. The Cyrillic script is first in the order. % 2. The non-Bulgarian Cyrillic letters are sorted according to % their transliteration with Bulgarian Cyrillic letters. copy iso14651_t1 reorder-after 9 CYR-A CYR-BE CYR-VE CYR-GHE [...] It's still a lot of work but it's not that the information itself isn't there. Bart --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Compilers (the eternal topic :)
On Thu, 19 Aug 2004, Luchezar Georgiev wrote: Hallo Bart, Question is how much of a difference can you tolerate? From you I get the impression that a 100K uncompressed kernel that compresses to 3 bytes would be preferable to a 64K one that compresses to 4 bytes. ;-) I could never use an uncompressed kernel that is below 64 KB. OpenWatcom makes the FAT32/80386 unstable kernel 66330 bytes long. The maximum size that UPX accepts is 65350 bytes. The difference is almost a kilobyte. How could we reduce the kernel further without crippling it? It's difficult! Well if I claim I can get it under 64K I'm not lying. OW compiles *plain 2035* as 66318 bytes uncompressed for me for FAT32/386. Why your kernel is bigger after all these optimizations is a puzzle. I've read that on low memory machines its optimizer may be limited but I can't think of anything else. For the unstable branch it's 64700 or so. Changing the calling convention to #pragma aux default parm [ax dx cx] modify [ax dx es fs] in portab.h (careful, don't do that for SYS EXEFLAT) and making LoL (init-mod.h, main.c) extern struct lol FAR * const LoL; (see the const) chops of another couple 100s of bytes. I've seen compressed differences between Turbo C++ 1.01 and OW going down over the years. As for Borland, is it worth spending $59+postage for an unsupported product on an obscure Ebay site when so many free compilers are available? It's not worth a penny because it can be freely downloaded from Vietnam (I posted the URL here ;-) The smiley implies that it can't be freely downloaded from Vietnam. Maybe you can but I can't. Everything can be physically downloaded. But that's a silly argument and by publically encouraging it you're not doing this project a favour. How about Digital Mars for instance? A very good compiler in my opinion, backed by Walter Bright's C++ great compiler know-how, but Tom once wrote that he gave up porting the kernel to it as he didn't see advantages. Sure, Tom's primary interest wasn't compressed kernel sizes at the time, just the uncompressed time (IIRC this was before compressing was even on the radar screen). Does that 64K kernel support FAT32? Of course. Besides, aPack doesn't compress .SYS files at all. An incorrect comparison again. Right, checking again I see it compresses a SYS file like a COM file. Well with some hand holding (load at 50:100) you could treat kernel.sys like a COM file too. Haven't tried that though. Bart --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Compilers (the eternal topic :)
On Sun, 15 Aug 2004, Luchezar Georgiev wrote: Besides, you know that Borland C++ 4.0 produces the smallest possible packed kernel binary file. Sometimes kernel file size is what matters (for floppy and ROM disks) and sometimes - the resident size in RAM (where Watcom is the king), if the DOS is in low RAM or if there is no cache. Depends. Question is how much of a difference can you tolerate? From you I get the impression that a 100K uncompressed kernel that compresses to 3 bytes would be preferable to a 64K one that compresses to 4 bytes. I've seen compressed differences between Turbo C++ 1.01 and OW going down over the years. As for Borland, is it worth spending $59+postage for an unsupported product on an obscure Ebay site when so many free compilers are available? How about Digitals Mars for instance? I experimented a bit -- as it turns out once the uncompressed size goes to 64K you can stick on a SYS header to kernel.sys, UPX the already exeflatted SYS file and use that. For some reason in this case UPX is better than APACK by the way. Well I got it down to ~41300 bytes vs. your 40957. Now you're just lucky that 40957 is just below the 80 sector boundary but the difference is gone at 40961 bytes. But on the other hand, Datalight still use Borland as their one and only compiler for ROM-DOS. If it was so bad, would they use it? Did I say it was bad? I just claim it's not the best tool for our job and has several other disadvantages. Do Datalight really use it because the entropy is lower so the compressed size goes down? Bart, some programmers claim that the only true Watcom is 10.6-, and 11.0+ is NO LONGER WATCOM as it was RUINED by Sybase. I have compared the code generated by both, and the difference is not so big, plus the code by 11.0+ is more optimal. What you can say on these Watcom version differences? I don't know. Only ever used 10.x for 32bit a long time ago, and haven't used it at all for several years before openwatcom was there. Of course they lost the race (MSVC, Intel, GCC) when Sybase took over and eventually stopped development. And from what I gather 11.x however introduced various obscure linker bugs, and loop optimization bugs (most are fixed in OW now). And OW still has years to catch up in terms of C++ standards (slowly getting there). Bart --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] 32RTM Bug Found, no good fix
On Fri, 13 Aug 2004, Luchezar Georgiev wrote:
Sure. But since it's easier to make the kernel return a serial mumber of 0
as MS-DOS does than to patch each and every copy of 32RTM.EXE, I changed
our function 30h to return 0 in CX. I tested this change and now 32RTM
works without -X as Michael wrote indeed! So I uploaded a new unstable
kernel binary at http://linux.tu-varna.acad.bg/~lig/freedos/kernel/ along
with a comulative patch (CVSPATCH.TXT) for the unstable branch consisting
of the Eduardo's NLS patch and the following patch. Thus, regrettably
we're back to version 0.0.35 now (as reported by the FreeCOM's VER /R ;-)
whatever, now we have 2035, 2.0.35, 1.1.35, and 0.0.35 all as version
numbers ;) Just have to send Ralf Brown another email as my previous
mod to interrupt.f will be obsolete.
Anyway most references other than RBIL tell that the serial number isn't
used as such.
www.htl-steyr.ac.at/~morg/ pcinfo/hardware/interrupts/inte2zlc.htm
tells us that
- the OEM serial number is a rarity, though some older OEM DOS
versions implemented this feature.
Most likely 32RTM wouldn't run on those older OEM DOS versions either
then.
--- cvs/kernel/kernel/inthndlr.c 2004-07-25 20:12:50.0 +0200
+++ src/kernel/kernel/inthndlr.c 2004-08-13 12:05:56.0 +0200
@@ -698,10 +698,8 @@
case 0x30:
lr.AL = os_setver_major;
lr.AH = os_setver_minor;
- lr.BH = OEM_ID;
- lr.CH = REVISION_MAJOR; /* JPP */
- lr.CL = REVISION_MINOR;
- lr.BL = REVISION_SEQ;
+ lr.BX = (OEM_ID 8) | REVISION_SEQ;
+ lr.CX = 0; /* serial number must be 0 or buggy 32RTM thrashes
stack! */
if (ReturnAnyDosVersionExpected)
{
This patch won't apply without manual tweaks Lucho, please fix your
email client. Lines were wrapped and indentation also messed up (hard
tabs?). There's also a pointless optimization, that the compiler can do
for us as well.
So here's my version:
--- inthndlr.c 25 Jul 2004 08:04:54 - 1.89
+++ inthndlr.c 15 Aug 2004 08:15:32 -
@@ -704,9 +704,9 @@
lr.AL = os_setver_major;
lr.AH = os_setver_minor;
lr.BH = OEM_ID;
- lr.CH = REVISION_MAJOR; /* JPP */
- lr.CL = REVISION_MINOR;
lr.BL = REVISION_SEQ;
+ lr.CX = 0; /* do not set this to a serial number!
+32RTM won't like non-zero values */
if (ReturnAnyDosVersionExpected)
{
Bart
---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] 32RTM Bug Found, no good fix
On Sun, 15 Aug 2004, Luchezar Georgiev wrote: Hallo Bart, There's also a pointless optimization, that the compiler can do for us as well. Will Watcom (the only compiler you recognise) do this? Of course, I'm not going to state this without checking. Borland won't, I'm sure. So my optimisation is NOT pointless. We'll make a deal. If Borland fixes their bug in 32RTM as part of open sourcing their old 16bit targetting compiler (even lower than the chance that RBIL will be updated) I'll go for it ;) I do recognize other compilers but... http://marc.theaimsgroup.com/?l=freedos-kernelm=106373357329924w=2 re: BC optimizations: BC isn't a target for freedos optimizations; there's one and only one target to optimize for : WATCOM. so BC specific optimization is a waste of time (ours and yours) tom This just being tom's opinion but I still agree -- I even agree more than I did a couple months ago, that's why I rejected my own idea of using _seg * pointers. I played for a while again with Turbo C++ back then but in the end decided that the difference was just too big. Bart --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] 2035 findfirst bug: attr a8 treated as 08 if local
On Thu, 12 Aug 2004, Erwin Veermans wrote:
issue he raised here but good enough for testing. Unfortunately
it broke mkdir so this would need a bit more work than the
3 patch-lines I got from Eric.
Hmm. Stange that it broke mkdir.
[Eric's incomplete patch-proposal]
dosfns.c DosFindNext:
wrong --
if (dmp-dm_attr_fnd (D_DEVICE | D_VOLID))
return DE_NFILES;
correction --
if (dmp-dm_attr_find (D_DEVICE))
return DE_NFILES;
ok, that's bit clearer than his email (which was about 10x longer than
necessary, but obviously I'm the only one here who thinks that?).
The dosfns.c correction here is wrong IMHO. What it means is:
if the direntry *found* in the findfirst has VOLID or DEVICE bits set
then we aren't searching any further
This is not the same as the search attribute in dm_attr_srch, it merely
reflects the fact that we only want to find *one* volume label or device.
I'd propose to *only* apply the patch to fatdir.c, i.e. what's below.
In my own testing mkdir still works.
Bart
--- fatdir.c.~1.47.~2004-05-24 06:28:18.0 +1200
+++ fatdir.c2004-08-11 20:35:37.0 +1200
@@ -384,7 +384,7 @@
/* directory and only searched for once. So we need to open*/
/* the root and return only the first entry that contains the */
/* volume id bit set. */
- if ((attr (D_VOLID|D_DIR))==D_VOLID)
+ if ((attr ~(D_RDONLY|D_ARCHIVE))==D_VOLID)
i = 3;
/* Now open this directory so that we can read the */
/* fnode entry and do a match on it.*/
@@ -406,7 +406,7 @@
/* Copy the raw pattern from our data segment to the DTA. */
fmemcpy(dmp-dm_name_pat, SearchDir.dir_name, FNAME_SIZE + FEXT_SIZE);
- if ((attr (D_VOLID|D_DIR))==D_VOLID)
+ if ((attr ~(D_RDONLY|D_ARCHIVE))==D_VOLID)
{
/* Now do the search*/
while (dir_read(fnp) == 1)
---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: 32RTM bug
On Thu, 12 Aug 2004, Luchezar Georgiev wrote: [added by me]: Michael wrote: Using the -X option bypasses the InDOS function call, so you don't see a problem when you use that 32RTM option. But the InDOS call just does: case 0x34: lr.ES = FP_SEG(InDOS); lr.BX = FP_SEG(InDOS); break; What could be wrong here? Copy and paste is broken where you are. The InDOS flag value itself? with lr.BX = FP_OFF(InDOS); it would be correct. But that's what it does in my source so... Stack usage during the call? that's what I suspected. Eric suggested (in a private email) to make int21/ah=34 reentrant like we did for 25 and 35. However than it would completely execute on the user stack and that stack seemed to have been the problem (only 30 words?). Since you said commenting out calls to the int2a handler didn't help... The only other extra stack user is the macro for 386 registers. Perhaps compiling for 386 or pushing/popping these on the kernel stack would work around that. Bart --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] HiNTOS
On Wed, 11 Aug 2004, Luchezar Georgiev wrote: HiNTOS is a DOS extender and Windows emulator that converts Windows console programs into programs that run in both Windows and DOS. It's the only one that can convert *fixed* PE executables (WDOSX can't!). Just in case you didn't know, there's yet another program in this department: HX, see http://www.japheth.de. Japheth has been very helpful in finding bugs in DOSEMU's built-in DOS extender (yes even though the DPMI spec doesn't mention it, a DPMI server will have to provide some DOS extender services to be compatible just because Windows' built-in DPMI server does that too). Bart --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] More kernel bugs and incompatibilities
Hi Tom, one reason for different behaviour *might* be that smartdrv traps int25/int26, which is used differently in FreeDOS (not everything is rooted through it) I don't think other DOSes route things through int25/int26 either, I tested that a few years ago. It would be a major headache anyway as int25/26 would reset the DOS stack pointer! RBIL explicitly mentions 480h 384 BYTEs disk stack (functions greater than 0Ch, INT 25,INT 26) in the SDA. To make a long story of Eric short, later versions hook at the device driver level, ie. what execrh.asm calls for FreeDOS. Searching a bit on google groups: interesting, this link talks about smartdrv but also about config.sys processing order: http://groups.google.com/groups?selm=1993Mar12.001843.20281%40microsoft.com Jen Kilmer posted more informative posts about smartdrv. If you even go further back you find posts from Mark Zbibowski (MZ) e.g. http://groups.google.com/groups?selm=8697%40microsoft.UUCP from 1984. Bart -- Usenet is a strange place -- Dennis M. Ritchie --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: 32RTM bug
On Tue, 10 Aug 2004, Michael Devore wrote: Some way or another, it looks 32RTM is unhappy with what is going on with the stack on the call to function 34h. I don't think the InDOS pointer itself is what causes the failure because the exception can occur during or immediately after return from the Get InDOS simulate call. From your story it sounds that the int21 entry code uses too much space on the user stack. The only place I could find in entry.asm where this could be a problem is in - ; ; end Dos Critical Section 0 thur 7 ; ; dos_crit_sect: mov [_Int21AX],ax ; needed! pushax ; This must be here!!! mov ah,82h ; re-enrty sake before disk stack int 2ah ; Calling Server Hook! pop ax ret - I don't understand the comments here. Who wrote this code? Does re-enrty sake before disk stack mean that this code has to be executed on the user stack? Anyway, one could experiment by commenting out all call dos_crit_sects in entry.asm. Bart --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] More kernel bugs and incompatibilities
On Mon, 9 Aug 2004, Luchezar Georgiev wrote: OK, this is a good attestation, but perhaps if there wasn't the current absurd that using MS-DOS® in any way is illegal (unless you've bought a legal second hand copy or bought it long ago - hey, I even have a Certificate for Authenticity for MS-DOS 6 - just in case the cops intrude here! ;-) everybody would use MS-DOS 7.10 which guarantees 100% compatibility (and even BUG compatibility :) Still won't help though. Anyway, from what I heard you can still get licenses from MS to allow you to redistribute DOS 7.10 (but you do not want to know how expensive that is, see http://pub50.bravenet.com/faq/show.php?usernum=4220517151catid=3726#q2 ). This is from another guy in the data recovery business, www.diydatarecovery.nl. By the way, he specifically mentioned that if the partition table loops (recursive problem), MSDOS just hangs but FreeDOS checks for it and happily uses the partitions that are fine. Not to mention the fact that the FreeDOS kernel's disk and memory footprints (40K vs. 50K in HMA) are smaller than those of MSDOS 7.10. Even if MSDOS would have a Borland museum style download it still wouldn't help me. It's redistribution and no restrictions on commercial/non-commercial use that count here. Most Linux distributions would also refuse to ship a binary-only free DOS with DOSEMU. Bart --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] exeflat (2035a) start segment must be variable
On Sat, 7 Aug 2004, Luchezar Georgiev wrote: exeflat.c of build 2035a (not 2035) has a problem. The start segment is an argument so it's a variable and its value - 2 must be loaded into DI instead of the constant 0x5E. Here's a fix: --- cvs\kernel\utils\exeflat.c2004-07-09 04:16:30.0 +0200 +++ src\kernel\utils\exeflat.c2004-08-07 13:16:38.0 +0200 @@ -303,6 +303,7 @@ 0x33,0xFF,/* 27 xor di,di */ 0xFF,0xE7,/* 29 jmp di; jmp 0 */ }; +*(short *)trailer[3] = start_seg - 2; *(short *)trailer[15] = (short)size + 0x20; *(short *)trailer[20] = start_seg + header.exInitSS; *(short *)trailer[25] = header.exInitSP; Hi Lucho, This is against exeflat.c of 2035a-UNSTABLE. Neither 2035a (i.e. CVS HEAD) nor 2035 have this problem. Bart --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] exeflat (2035-Arkady) start segment must be variable
On Sat, 7 Aug 2004, Luchezar Georgiev wrote: This is against exeflat.c of 2035a-UNSTABLE. Neither 2035a (i.e. CVS HEAD) nor 2035 have this problem. I didn't know that there are TWO kernel builds called 2035a... Perhaps you should call yours 2035b where b = Bart (a = Arkady ;-) I was just reflecting what it reports from version.h -- that's the info Jeremy put in, neither Arkady nor myself. In CVS HEAD I see: #define BUILD 2035 #define SUB_BUILD a #define KERNEL_VERSION_STRING 1.1.35 /*#REVISION_MAJOR . #REVISION_MINOR . #REVISION_SEQ */ #define KERNEL_BUILD_STRING 2035a /*#BUILD SUB_BUILD */ but in CVS UNSTABLE I see #define BUILD 2035a #define SUB_BUILD -UNSTABLE #define KERNEL_VERSION_STRING 1.1.35a /*#REVISION_MAJOR . #REVISION_MINOR . #REVISION_SEQ */ #define KERNEL_BUILD_STRING 2035a-UNSTABLE /*#BUILD SUB_BUILD */ I don't know why some people started calling 2035a-UNSTABLE plain 2035a... perhaps just too lazy to type -UNSTABLE. But it reports that on the screen right? Bart --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Versions and builds, conservatism
nor removal of phrases like All Rights Reserved. that are useless now Pat sent an email to this list -- here's your chance if you really care about this! The Buenos Aires Convention (1911) that required this was superseded by the Universal Copyright and Berne conventions. More on this at http://www.cni.org/Hforums/cni-copyright/1999-01/0196.html Honestly I believe you're right here -- the issue is that changing copyright messages without agreement of the original author is a bit shaky IMHO. If you just get Pat's go ahead for the change then I'm all for it. Note that the GPL doesn't use all rights reserved, it gives an example like Gnomovision version 69, Copyright (C) year name of author Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. This is free software, and you are welcome to redistribute it under certain conditions; type `show c' for details. FreeDOS could, say, show the full message if you press a certain F key(as it waits for F5/F8 anyway), like this FreeDOS kernel build 2035a-WHATEVER. Copyright... This kernel comes with ABSOLUTELY NO WARRANTY and you are welcome to redistribute it under certain conditions; press F1 for details. It's more difficult than a simple removal. If you'd simply replace all fnode references with SFT's you'll see a substantial increase in code size (because SFT's are FAR). Also fnodes are used in situations where SFTs can't do the job (dir operations). You're right - there are for example cluster fields that must be 32 bit and not 16 bit for FAT32. Well those can be dealt with, a bit awkward though. IIRC Win98 stores these clusters in the various SHARE related fields. Not sure how many DOS programs (if any) depend on these on FAT32 though. Maybe SMARTDRV and DOSLFN or LFNDOS? However -- replacing the use of the persistent fnodes that are now in the HMA by SFTs is a good idea IMHO. This is just a question of time, it may never happen but it can happen if somebody does it and it works well. I see. What about including the SFT in the F-node structure and removing all duplicating fields? As all SFTs are pointed to by a linked list, I think that this is possible. What do you think? IMHO easiest to copy those fields across that matter, and then then delete them from the persistent fnodes. i.e. the far fnodes would be able to become different from the near ones, and xlt_fd() and save_far_fnode() would no longer use fmemcpy but copy individual fields. Another difference is the way that directory entries are addressed: SFT's use (sector number, entry in sector), where fnodes use (starting cluster number of dir, entry in directory). And if you don't keep the whole directory entry in memory then dir_write would have to become read/modify/write instead of simply write. Takes a fair bit of time of course, it just depends how motivated one is. Bart --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] More kernel bugs and incompatibilities
On Sat, 7 Aug 2004, Luchezar Georgiev wrote: [problems with DOSLFN and SMARTDRV and some obscure problems for nonstandard configurations] So, as a prospective user of the kernel, after contributing to it for more than an year, I can conclude than it's good enough for simpler tasks not involving writing a lot of long named files on a FAT32 partition. For more complex tasks, however, MS-DOS 7.1, PC-DOS 7.1 and ROM-DOS 7.1 are more suitable. You can find a good comparison betweent the different DOS versions on the page of Wengier Wu (, China DOS Union) http://newdos.yginfo.net/dosfat32.htm (page is in English). Of course this is since the DOSLFN author apparently isn't interested in running it on FreeDOS and most FreeDOS developers aren't interested enough in DOSLFN (it's useless on networked drives for instance, which makes it almost useless in DOSEMU!). Same for SMARTDRV, anyway why SMARTDRV if we have LBACACHE? In any case these China DOS Union guys seem to think they can freely redistribute MSDOS 7.10 so if they think that's all fine and it works for what they want then I wish them good luck. PC-DOS 7.1 never seems to have been officially released but just appears to be what's used on Norton Ghost's boot disks. Remember that Steve Gibson went round trip back to FreeDOS after evaluating several other DOSes so this means that FreeDOS can't be that bad :) I just hope that if I ever need spinrite myself Steve can pay back by giving me a free copy ;) Bart --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] daily tarballs no longer daily
Cron was disabled on SF, see http://sourceforge.net/docman/display_doc.php?docid=2352group_id=1 so the daily tarballs are no longer that (in fact the last one is from July 12). Somebody would have to manually update or run a cron job from an outside machine. Or just wait until SF sorts out the problem. Bart --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Strange bug in kernel 2035
On Mon, 26 Jul 2004, Eduardo Casino wrote: There are. If I understand it correctly, when calling DOS with ss:920, the flags and return address are trashed because DOS sets ss:920 on entry, again. No. The whole point of calling int2f/ax=12xx is that this stack setup is bypassed. i.e. *without* any swapping in NLSFUNC you'd have int21/ah=38 = DOS switches to internal stack = NLSFUNC (still uses DOS stack) = int2f/ax=12xx = back in DOS at a lower place on the same stack. Now it's just very easy to use too much stack in this setup and that's the whole problem. - Switch to a local stack - copy anything in between the original ss:sp and ss:920 to a temp area - call DOS ints - restore from temp area - switch to original stack - return Does anybody see any additional problem with this? you should not use a local stack when you call int2f/ax=12xx. As RBIL states: SS = DOS DS (must be using a DOS internal stack) Bart --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721alloc_id=10040op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Strange bug in kernel 2035
On Sat, 24 Jul 2004, Eduardo Casino wrote: El sáb, 24-07-2004 a las 13:50, Bart Oldeman escribió: It's a difficult question. Essentially there are two ways we can go: 1. if the kernel very carefully minimizes stack usage on the code path taken and NLSFUNC itself only uses a couple bytes of stack in between it's possible to just do it. or 2. nlsfunc would have to copy anything in between ss:sp and ss:920 (_disk_api_tos, that's the top of the stack used here in any DOS = 4.0) to a temp area (max 384 bytes), set sp to 920, and with that call DOS. Then after the call adjust the stack pointer, then swap it back, then return. Just curious, what about a 3rd possibility: implement the 2f12xx calls as documented in RBIL? For example, 2f1228: sets user stack frame pointer to dummy buffer, moves BP to AX, performs LSEEK, and restores frame pointer. (This is the what, my problem is how :) The user stack frame pointer is poined to by a global variable user_r in the FreeDOS kernel. It points to the user stack which is yet another stack. It sits in the SDA at 264hDWORD pointer to stack frame containing user registers on INT 21 What normally happens is that: 1. user calls int21/ah=42 2. registers are pushed on the stack (entry.asm) 3. ss:sp stored in user_r 4. ss:sp moves to DOS stack 5. DOS does the lseek using the values pushed in 2. 6. DOS updates the registers on the user stack Essentially the RBIL comments says that, in MSDOS, 2f1228 changes user_r to point to a dummy place, moves the value of BP to the AX-slot in the dummy user_r stack, calls steps 4-6, restores user_r, and returns. In FreeDOS that would mean something like this: case 0x28: old_user_r = user_r; user_r = tempplace; user_r-AX = r.BP; int21_service(user_r); user_r = old_user_r; break; This has nothing to do with switching kernel stacks, in fact if FreeDOS would do things this way (instead of calling DosSeek directly) it would use even more stack space. This all goes to say that RBIL is a strange place, sometimes it doesn't report much at all (about error codes for instance), and sometimes it reports about such obscure implementation details. Bart --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21alloc_id040op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Strange bug in kernel 2035
Hello Tom, apart from the drawbacks there is another problem: --- mov bp, [bp + 20] ; store id (in SS:) unless it's NULL or bp, bp jz nostore mov [bp], bx nostore: --- if (*id) *id = r.b.x; The first * in this part is wrong, and also id lives on the stack, but SS!=DS here (!), see the comments elsewhere in nls.c. it would need to be if (id != NULL) /* or if (id) */ poke(_SS, id, r.b.x); returning a long (or a struct with two ints, but I'm not sure if all compilers we use put that in dx:ax) would be another way to avoid this, and save a bit of stack space too. Bart --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721alloc_id=10040op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] ludivmul.inc
On Mon, 19 Jul 2004, Arkady V.Belousov wrote: 20-éÀÌ-2004 00:55 [EMAIL PROTECTED] (Bart Oldeman) wrote to [EMAIL PROTECTED]: BO encouraging... In any case, I appreciate that a bug was found in BO ludivmul.inc; the same bug was in fact present in the 64 bit version I BO adapted it from! Well I notified the original author. BTW, may you point me place, where I may see the prove that present algo is correct? I myself prove this, but my prove not looks beauty to include into comments as explanation. :( I'm not aware of any direct proofs but you'll get a long way with Donald E. Knuth's book The Art of Computer Programming, Volume 2, Seminumerical Algorithms. He covers 2n-base / 2n-base division if only n-base/n-base division is provided. A bit of simplification is possible if 2n/n already exists. My bugfix-list for umb_init() includes 7 positions. How I may isolate bugfixes from new umb_init() edition?! Try to optimize something else, namely instead of how do I fix it while saving as many bytes as possible in the kernel you play the game how do if I fix it while saving as many lines as possible in the diff. Anyway, I already tried to explain you too many times, I presume it doesn't help then. Bart --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21alloc_id040op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] About Eric's CLUSTER v ULONG remarks.
Hi Eric, please be aware that some structs (such as fnodes) are free-style, but most are dictated by RBIL. It's best to use CLUSTER in internal parameters and fields etc. because this is either 16 or 32 bits. Just like those freedos specific open flags they are completely kernel-internal and have no meaning to the outside world. However, when mirroring an RBIL-dictated structure we should use ULONG (which is FD kernel speak for a 32 bit unsigned integer, I'm not terribly happy about the naming, but hey, we know what it means and what it does by now), it can never be 16-bits. Using CLUSTER there would just be obscuring things -- what if some weirdo makes CLUSTER 64 bits? It would completely break the mirroring. Also be careful with LSEEK. The offset you feed to it really is signed -- on the other hand with two-s complement it doesn't really matter. The Not Yet Implemented part about this 2GB files thingy is that normally opened files have to fail reads and writes if the current offset is beyond 2GB, perhaps also int21/ah=3d should refuse opening files 2GB. A special flag for int21/ah=6c is needed to enable 2Gb opens. Bart --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721alloc_id=10040op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] ludivmul.inc
On Tue, 20 Jul 2004, Bart Oldeman wrote: I'm still not sure if and when I really return, the archives aren't really encouraging... In any case, I appreciate that a bug was found in ludivmul.inc; the same bug was in fact present in the 64 bit version I adapted it from! Well I notified the original author. I should add that while serious it presently can never be triggered in the fd-kernel. All but 2 U4D's use 16bit divisors. The 2 places that use a 32bit divisor are in initdisk.c. But these two places aren't interested in the remainder. Bart --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721alloc_id=10040op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] About Eric's posts.
Eric, please please, if you discover that you made a mistake in a post then please edit the post while you still can. IMHO It's very annoying to read: Hmmm this must be the case. Oh no, sorry, what I said above was wrong, it is like this. This makes your already long post even longer than necessary, and adds unnecessary noise. You're not talking on the phone or IRC here. Of course this is true for everyone, it's just that Eric seems to make a habit out of it. Sorry, maybe you think it's cool to write that way but I'm afraid many people will ignore the rest of your post if you start rambling like this. Bart --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721alloc_id=10040op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] [announce] kernel 2035 and bye
Hi, I've uploaded kernel 2035 to http://sourceforge.net/project/showfiles.php?group_id=5109 important fixes: Fix problems with USBASPI.SYS, DI1000DD.SYS Fixed invalid opcode with debug foo.txt, same with netware redirected logins. Don't move the EBDA by default. Use switches=/e:-1 if you want the auto-sized movement (#1771) Made int21/ah=25,35 reentrant. Solves problem with Intel PRO/1000 driver. Fix dir corruption bug if you delete the first entry in the root directory on FAT32. Fix non-working F5/F8 for autoexec.bat (#1777) With this I'm leaving FreeDOS for the next couple of months at least. I may put up an update for MEM but that's it. There was a bit of noise on the mailing list but the main reason is that I'm generally happy about the kernel, all I wanted in the beginning is to get it to cooperate nicely with DOSEMU. That's done and more. Squeezing even more bytes out of the kernel and fixing even more bugs is certainly possible, but it's time to leave that to someone else as my (volunteer) job is finished. Thanks for your attention and help, Bart --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel config.c,1.86,1.87
Hello Tom, +if ((unsigned)(GetBiosTime() - startTime) = timeout * 18u) + return 0x; } + while (r.flags FLG_ZERO); This is not good way to calculate delays - around midnight (when system timer will be reset) above expression will be calculated wrongly (because GetBiosTime() will be lesser than startTime). bla. blubber. blabla. the original code reads: if (GetBiosTime() - startTime (unsigned)timeout * 18) break; and now I want to get an example when this breaks. Menu timeout set at 10 seconds. Boot kernel with menu at 23:59:55. Timer expires at 00:00:00 (0-1.5M = very large number) instead of 00:00:05. The (unsigned) cast for (GetBiosTime() - startTime) makes absolutely no difference in this respect. Signed numbers won't help either. Bart --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel config.c,1.86,1.87
Hi Tom, Menu timeout set at 10 seconds. Boot kernel with menu at 23:59:55. Timer expires at 00:00:00 (0-1.5M = very large number) and that's exactly the wanted behaviour. is it? At least the comment doesn't say so, maybe it was in your head though. instead of 00:00:05. and to wait precisely 10 seconds in the case that someone boots FreeDOS at midnight AND is sitting at the keyboard AND thinks it's a bug that the timer gotes off early is simply not worth the code to handle this case. well I do agree it's a highly unlikely situation. +if ((unsigned)(GetBiosTime() - startTime) = timeout * 18u) and the original code uses long arithmetic on purpose. The original code only pretends to use long arithmetic: if (GetBiosTime() - startTime = (unsigned)timeout * 18) break; The reason is that (unsigned)timeout * 18 is a 16 bit value. GetBiosTime() - startTime will under normal circumstances (outside midnight) *never* be = 0x1, since it increases step by step from 0 and bails out before it gets even close. Hence it is perfectly OK to cast to (unsigned). If you have a purpose to use long arithmetic then the original code needs to be: if (GetBiosTime() - startTime = (unsigned long)timeout * 18) break; Now what am I missing here? Bart --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: Reference compiler (was Re: [Freedos-kernel] Re: patch: inthndlr.c)
On Mon, 10 May 2004, Arkady V.Belousov wrote: It works (compiles programs). I even already prepared ATTRIB edition, which compilable by TC/BC/OW, and delay its release only because wait, if I found some new ways to reduce RTL (by replacing some RTL functions) - currently ATTRIB.EXE after BC uses 3914 bytes, after OW 4044 bytes. Oh yes, feel free to send me this to see where it can be reduced -- I remember you asked a while ago. The attrib 2.1 source I can see here uses fputs so that would be an obvious one to replace with one that just does a call to _dos_write if you don't need the buffering. Bart --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] bug: talloc.c
On Mon, 10 May 2004, Arkady V.Belousov wrote: __O\_/_\_/O__ d:\lang\tc\tcc -c -Id:\lang\tc\include -I..\hdr -DFORSYS -DWITHFAT32 -Ld:\lang\tc\lib -mt -a- -k- -f- -ff- -O -Z -d talloc.c Turbo C Version 2.01 Copyright (c) 1987, 1988 Borland International talloc.c: Error talloc.c 21: Type mismatch in redeclaration of '__brklvl' Warning talloc.c 66: Non-portable pointer assignment in function malloc Warning talloc.c 80: Non-portable pointer assignment in function malloc _ O/~\ /~\O Strange, I don't see this. Where is __brklvl defined for your Turbo C? As for your other patches, they take a lot of time to digest for the reasons I gave you already, so be patient. Bart --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Splitting patch
On Sun, 9 May 2004, Eric Auer wrote: why did you only mention in THIS mail what the MEANING of your patches is? You normally send a mail with subject like patch: filename.c and then there is ONLY the patch, zero explanation of any kind, nobody except you will know what you are trying to tell us and why your patch is supposed to improve things. So please 1. send some description along with the diff and 2. comment the changes in-line before you run diff and 3. tell us why the patch is good and whether you expect it to be good for all compilers or only for one certain compiler. Agreed except with 2.: I don't like commenting your change in-line. This produces very noisy code. Comments should tell why the code does something not what it does differently from what it does before. Otherwise you get code like: foo(); /* this call added by Eric Mar 2003 */ bar(); /* changed by Tom Apr 2002 */ baz(); /* bart changed this from hat() in June 2001 */ About Barts decision to take a break from FreeDOS kernel development: Could you please try to stabilize the current CVS version as 2034a release? I can try but the fixes will need to be isolated first from the patches that are floating around. Also I seem to have requests to: a) repair the EECHO command in config.sys so that it really works. b) disable the EBDA-move by default c) move the EBDA-move to after loading device drivers. Well implementing and testing all that will take quite a bit of time so I can't promise much right now. Bart --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] CVS access (was re: fattab.c...)
On Sun, 9 May 2004, Bernd Blaauw wrote: Bart seems to be the only one with CVS access. No. Everyone has CVS read (anonymous) access. The tarballs are just there for those are cannot or can't be bothered to install a CVS client, and also sometimes the SF anon access can be a little flaky (it was a couple of months ago, it's better now). The people with CVS write access are: bartoldeman Project Admin jhall1 Project Admin jimtabor Project Admin perditionc Project Admin (Jeremy) reifsnyderb Project Admin roncemer Project Admin skaus Project Admin (Steffen) tomehlert Project Admin all these people can add new people too. From looking at the CVS logs it seems that each project only has one person committing to a project but that's not how the permissions are -- I am able to change the FreeCOM CVS files if I like to (in fact I did so once but that was a very small obvious change, I didn't want to step on Steffen toes too much here). BTW if CVS sounds to complicated and you're on Windows you can check out http://www.tortoisecvs.org/ is Lucho still (silently?) active? yes. Bart --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] patch: config.c
On Sun, 9 May 2004, Arkady V.Belousov wrote: - small optimization: `init' and `inittail' now assigned to .cfgInit and .cfgInitTail statically. - removed COMMAND statement. TGROUP reduced from 0e1d1h to 0e1c6h; INIT_TEXT reduced from 3b71h to 3b66h; ICONST reduced from 9b8h to 996h; I_BSS reduced from 0e7ch to 0df6h; IDATA increased from 57ah to 5fah. I don't think it's good to reduce BSS at the cost of DATA. Some people like uncompressed kernels to be as small as possible too and the BSS isn't showing up in kernel.sys :) (except for MSVC) Even for compressed kernels having all zeros at the end helps: less entropy. Bart --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel fattab.c,1.21,1.22
On Sat, 24 Apr 2004, Arkady V.Belousov wrote: 24-áÐÒ-2004 15:53 [EMAIL PROTECTED] (Bart Oldeman) wrote to [EMAIL PROTECTED]: +++ fattab.c 24 Apr 2004 15:53:21 - 1.22 -idx = (unsigned) unsigned)Cluster1 1) + (unsigned)Cluster1) 1) - % dpbp-dpb_secsize; - +idx = (((unsigned)Cluster1 1) + (unsigned)Cluster1) % dpbp-dpb_secsize; Bug: in my patch was Cluster1 1 - difference is that code above computes 3*Cluster1 instead 3*Cluster1/2. Sure I already found that and corrected. But please note that replacing fbp by bp-buffer[foo] really doesn't produce better code for Watcom. There is a good reason why I didn't apply these blockio.c patches either. Bart --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg297 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel fattab.c,1.21,1.22
On Sat, 24 Apr 2004, Arkady V.Belousov wrote:
24-áÐÒ-2004 16:37 [EMAIL PROTECTED] (Bart Oldeman) wrote to
[EMAIL PROTECTED]:
BO fbp by bp-buffer[foo] really doesn't produce better code for Watcom.
BO There is a good reason why I didn't apply these blockio.c patches either.
:) For OW I don't review listings yet, only for BC. I plan do this for
OW today-tomorrow, though, this is much longer (up to 10 minutes with BC for
recompilation, up to 20 with OW). Probably, I should force my efforts in
optimization of makefile (collect names of changed files in one file, then
pass this list at once for compilation).
if you want to check things quickly, simply do
wcc -i..\hdr -os -r -s -j -d1 -DWITHFAT32 foo.c
(perhaps via some batch file)
wcc (wpp neither) can't compile multiple files at the sametime. You can
only try to decrease the load time of wcc.exe Maybe compressing it or
binding with a dos extender helps. Maybe not.
wpp is not good -- the kernel is written in C, not C++, and some small
differences like sizeof('a') (1 in C++, sizeof(int) in C) maybe
responsible for what you see. It's also bigger so just slows things down.
Bart
---
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg297
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] cvs refresh
On Sat, 24 Apr 2004, Arkady V.Belousov wrote: When latest patches will be reflected in CVS snapshot on site (kernel.tgz?)? I wish to check how they are applied in complete. every day at 10am GMT Bart --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-devel] Re: [Freedos-cvs] kernel/kernel blockio.c,1.30,1.31 dosfns.c,1.61,1.62 int2f.asm,1.27,1.28 proto.h,1.61,1.62 task.c,1.41,1.42
On Thu, 22 Apr 2004, Arkady V.Belousov wrote: Current CVS against latest official release. freedos-cvs@ is a good place to publish alone patches with comments, but they are often (as now) crosses and have other troubles with applying (I ask about this questions, but have no answers). if you apply them in the right sequence then there should be no problems. If there are then you are quite capable to sort them out yourself -- just a question of your time versus my time and i prefer to be lazy :) Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] TDSK volume locking failure
On Fri, 16 Apr 2004, Steve Gibson wrote: Just a note that the 2032 kernel fails volume locking on the tdsk.exe turbodisk device. mov bl, CurrentDosDevice; 1-based current device xor bh, bh ; lock level 0 mov cx, 084Ah ; category / lock logical mov ax, DOS_IOCTL SHL 8 + BLOCK_DEVICE_IO int 21 I get ax=0, no carry with kernel 2034rc. Doesn't seem like a problem to me. Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] FORCELBA Kernel option
On Sat, 17 Apr 2004, Steve Gibson wrote: Could someone briefly explain the function of the kernel's FORCELBA option? The command shown by sys.com is Always use LBA if possible. So I suppose I'd like to understand why or when the kernel would not use LBA when it's available? If a partition isn't marked as LBA (with the partition id) then the kernel will uses CHS, unless it's beyond cylinder 1024. This is because some TSRs like to hook int13 and expect DOS to use the old int13 CHS style calls. If you don't like the somewhat inefficient LBA-CHS (by the kernel) and then CHS-LBA translation (by the BIOS) you can set ForceLBA. Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] kernel 2034rc for testing
On Fri, 16 Apr 2004, tom ehlert wrote: one thing I don't understand: MEM /F will show a 1K dataarea, between 2 FILES drivers, at ~2a6:0 this existed also in ke2033, and possibly before. as it *seems* to be unused, what is it? That would be the relocated EBDA. I should improve MEM to detect that one properly. BTW: I fullheartily disagree with your efforts to move share_check() into assembly, and I will never like #pragma aux, even if that saves a few byte. IMO this is dos-C, and should be coded in C (which is possible mostly) you'd have to be consistent. Most of the remote functions use assembly. So why have just one using intr()? Either use intr() for all of them or use external asm files for all of them. Since the resident code had only 4 or so intr() users it was easier to go for the external assembler. I left all the intr()s in the init code as is though -- since it's the predominant technique there. As to #pragma aux, this helps the Watcom optimizer quite a bit (about 350 bytes for the asmsupt.asm interfaces) -- without it even a memcpy in C would make a smaller kernel (but in the past you argued to do memcpy in assembly). Ironically as soon as you throw a normal __cdecl or pascal assembly function into the equation (whether intr() itself or anything else) the whole optimizer chain collapses. Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] kernel 2034rc for testing
On Thu, 15 Apr 2004, Arkady V.Belousov wrote: BB I include this 2034 kernel in the next FreeDOS distribution, next Sunday. BB there have been a few times where a kernel was released, and a few days BB later a new kernel followed it because a larger public found a few bugs. :) Kernel shoul be re-release slightly often and it number should be function of release date. With this, quick re-releases shouldn't be a problem. :) kernel released when i like and with number i like keep in mind that proper release takes lot more time than simple daily tarball produced by cron job. besides general public will get just distributions so good sync this with bernd -- distribution (beta9) arent labelled date either basta --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel config.c,1.75,1.76 config.h,1.3,1.4 kernel.asm,1.50,1.51 main.c,1.70,1.71 segs.inc,1.17,1.18 task.c,1.40,1.41
On Tue, 13 Apr 2004, Arkady V.Belousov wrote:
13-áÐÒ-2004 11:54 [EMAIL PROTECTED] (Bart Oldeman) wrote to
[EMAIL PROTECTED]:
+++ task.c13 Apr 2004 11:54:09 - 1.41
+ fstrcpy(Shell + strlen(Shell), MK_FP(FP_SEG(Config), Config-cfgInitTail));
endp = Shell + strlen(Shell);
fstrcpy(endp = Shell + strlen(Shell),
MK_FP(FP_SEG(Config), Config-cfgInitTail));
this won't work. We need the strlen of Shell after the fstrcpy. This is
really an fstrcat except that's not in asmsupt.asm.
endp = Shell + strlen(Shell) + strlen(Config-cfgInitTail);
fstrcpy(Shell + strlen(Shell), MK_FP(FP_SEG(Config), Config-cfgInitTail));
would work but I don't see the point.
STATIC VOID InitPgm(BYTE * pLine)
{
+ static char init[NAMEMAX];
+ static char inittail[NAMEMAX];
+
+ Config.cfgInit = init;
+ Config.cfgInitTail = inittail;
As I understand, these assignments may be performed statically.
Especially, if cfgInit and cfgInitTail fields will be moved out from Config
structure.
??? I don't understand what you mean here.
+ mov cx,-2 + init_end wrt INIT_TEXT ; word aligned
BTW, does (or not) NASM supports TASM/MASM compatible syntax:
mov cx,offset INIT_TEXT:init_end - 2 ; word aligned
NASM doesn't support offset.
Bart
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id70alloc_id638op=click
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] patch: batch and make files
On Mon, 5 Apr 2004, Arkady V.Belousov wrote:
PS: config.h also may be removed, because it is dummy (for this only
required to remove reference in globals.h). When (and if!) it will be
required, it may be added back.
config.h contains
struct config { /* Configuration variables */
after Lucho's patch
PS2: kernel\nls\001-437.hc is desynced with kernel\nls_hc.asm.
It was accidentally checked into CVS as ascii instead of as binary, so I
had to correct that and fix the CRLF at the time (the .asm didn't change).
PS3: header files in globals.h and init-mode.h included in different order.
is that a problem?
PS4: repeat for my previous question: why to duplicate clean and
clobber? Another one: who make files status.me, *.cod, *.las?
ask Pat Villani. AFAICS clobber is a little more thorough than clean,
where clean removes enough to force a kernel rebuild, clobber tries to
remove all generated files (incl. kernel.sys).
Bart
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel buildall.bat,1.3,1.4
On Sat, 27 Mar 2004, Arkady V.Belousov wrote: Batch file: __O\_/_\_/O__ @echo off ver/r set a=1 set b=if %%a%%== echo b set c=if not %%a%%== echo c %b% %c% _ O/~\ /~\O now try with set a= and for me it still echoed c. That was the problem. also try set d=echo %%a%% %d% Das war wohl Nix ;) Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] patches
On Fri, 26 Mar 2004, Arkady V.Belousov wrote: Hi! 26-íÁÒ-2004 19:33 [EMAIL PROTECTED] (Bart Oldeman) wrote to [EMAIL PROTECTED]: And let me remind you two more bugs, which you don't fix yet: first one is in INT 21/6C (lost check for nonzero AL) BO that's not a bug, we discussed this before -- see Luchos reply This is bug. When Lucho says that this is patch from me, I quote him my letter where was _not_ sayed, that check for AL should be removed - there was discussed only checks for DL. That's a misunderstanding: Date: Mon, 2 Feb 2004 21:03:52 +0300 (MSK) From: Arkady V.Belousov [...] 2-æÅ×-2004 10:58 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to [EMAIL PROTECTED]: if ((lr.DL 0xef) 0x2) First, losted AL check (for AX=6C00) - should be if (lr.AL || ((lr.DL. LG You probably forgot about that. Check for AL=0 was deliberately removed! LG File history.txt says: * inthndlr.c: Remove AL=0 check for AH=6c (from Arkady) Optimize DL check. The (from Arkady) here refers to Optimize DL check. because it's stated like this: + Changes Lucho: * inthndlr.c: Remove AL=0 check for AH=6c (from Arkady) Optimize DL check. There really are DOS programs that use int21/ax=0x6c02 or something like that where they really mean to use extended open. This was discussed here around October last year. Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
