> >> 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
Hello Lucho,
> the build & version dualism (e. g. version should be 2.0.35), but I know
> that neither this,
Actually a couple of years ago it was build 1937 for version 1.0.2 ;)
> nor removal of phrases like "All Rights Reserved." that
> are useless now,
Pat sent an email to this list -- here'
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 w
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:
Cron was disabled on SF, see
http://sourceforge.net/docman/display_doc.php?docid=2352&group_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 p
On Sun, 25 Jul 2004, Kenneth J. Davis wrote:
> This is largely a cvs issue regarding line endings. Several batch
> files were committed with \r\n line endings from a non-EOL converting
> cvs client, as such on those clients they check out as \r\n, but on
> clients (such as I use) they are convert
> > 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.
>
> Excuse me if I'm a bit thick in the head. Do you mean that it makes no
> sense to implement the int 2f122[6-9b]
On Mon, 26 Jul 2004, Steffen Kaiser wrote:
> DOS has three internal stacks, how about switching to the Critical Error
> stack and defer any calls when the stack is in use?
You'd automatically overflow into the Critical Error stack anyway. I
wonder about "defer" though -- how do you defer a critic
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. *witho
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 a
On Sat, 24 Jul 2004, Eduardo Casino wrote:
> Tom, your patch seems to cause some problems (now the wrong DS is passed
> to some nlsfunc calls. It happens with a modified nls.c, I can send you
> the code and the details if you are interested)
If you don't initialize r.ds in a call to intr there is
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)
>
Hi Eduardo,
the fix below fixes your problem as well.
To Tom: I appreciate the fact that you find intr() easier to use and less
bug prone, but there is a minor and a major problem with it in resident
code (as opposed to init code where there is only a very minor problem).
Minor:
- not using in
Hi,
this patch speaks for itself. I guess Arkady won't like it and Tom thinks
I'm crazy to even look at this code (though it does save 1.5K on
HMA_TEXT, that's tempting). But anyway, who cares :)
For me this search and replace exercise is simply necessary to make sense
out of the code without
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 versi
On Tue, 20 Jul 2004, Arkady V.Belousov wrote:
> 20-éÀÌ-2004 10:09 [EMAIL PROTECTED] (Bart Oldeman) wrote to
> [EMAIL PROTECTED]:
>
> BO> Improved diagnostics (Eric Auer) Adjusted help.
> BO> +++ mem.c 20 Jul 2004 10:09:00 - 1.8
> BO> +while (mlist!=NULL
On Mon, 19 Jul 2004, Arkady V.Belousov wrote:
> You develop the fnode structures, so should know the better.
No, I just changed them.
> Thus, may you yourself fix the bugs in lfnapi.c (where used removed
> f_dmod field instead F_DMOD mask)?
Maybe, it's not very urgent as right now lfnapi
On Mon, 19 Jul 2004, Arkady V.Belousov wrote:
> 19-éÀÌ-2004 22:36 Arkady V.Belousov wrote to
> [EMAIL PROTECTED]:
>
> BO>> Essentially for Turbo C the compiler helpers are extracted from the c
> BO>> compiler RTL to be absolutely sure we only link those and nothing else from
> BO>> that library.
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
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
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 ha
Hi Arkady and others,
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.
What I
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 t
On Wed, 26 May 2004, Arkady V.Belousov wrote:
> Why DosUmbLink() tries to join free blocks (in low memory) when
> uppermem_link switched from 1 to 0 (but not when it switched to 1)? I think,
> this is wrong: blocks joining should be performed (by RBIL) only for memory
> allocation in DosMemAl
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 t
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
On Mon, 24 May 2004, Arkady V.Belousov wrote:
> 23-íÁÊ-2004 21:50 [EMAIL PROTECTED] (Bart Oldeman) wrote to
> [EMAIL PROTECTED]:
>
> >> /* DELETED (0x5) || EXT_DELETED (0xe5) ? */
> >> if ((UBYTE)(name[0] & ~0xE0) == DELETED)
>
> Ops, mistype. Should
On Mon, 24 May 2004, Arkady V.Belousov wrote:
> STATIC void swap_deleted(char *name)
> {
> /* DELETED (0x5) || EXT_DELETED (0xe5) ? */
> if ((UBYTE)(name[0] & ~0xE0) == DELETED)
> >-^^^
> *name ^= EXT_DELETED ^ DELETED; /* 0xe0 */
> >
On Thu, 13 May 2004, tom ehlert wrote:
> when testing USB support for DOS
> with USBASPI.SYS and DI1000DD.SYS, the kernel simply crashed.
>
> the patch below helps.
>
> for unknown reasons, the temp_buff is required; using
> deblock_buff instead of temp_buff doesn't work.
that's very strange. I t
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) 198
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 af
Hi Tom,
> You don't remember correctly.
> the kernel reference compiler has been for a long time TC 2.01 (which
> is free), and has been changed to OW because it generates better
> (smaller) code, and because it's free and open.
Aitor remembers correctly -- he simply goes a few years further back
On Mon, 10 May 2004, Eric Auer wrote:
> You optimized less than 0x10 bytes but you sent a diff of probably
> far more than 100 lines. Most changes involve removing comments, changing
> indendation, replacing code like "foo = bar; if (foo == ...)" by
> code like "if ((foo = bar) == ...)" which is l
On Mon, 10 May 2004, Arkady V.Belousov wrote:
> 9-íÁÊ-2004 21:15 [EMAIL PROTECTED] (Bart Oldeman) wrote to
> [EMAIL PROTECTED]:
>
> >> - small optimization: `init' and `inittail' now "assigned" to .cfgInit and
> >> .cfgInitTail statically.
> >
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 9
On Sun, 9 May 2004, Arkady V.Belousov wrote:
> __O\_/_\_/O__
> long DosRWSft(int sft_idx, size_t n, void FAR * bp, int mode)
> XferCount = network_redirector_mx(mode == XFR_READ ? REM_READ : REM_WRITE,
>
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
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
On Sun, 9 May 2004, Arkady V.Belousov wrote:
diff -ruNp old/kernel/break.c new/kernel/break.c
--- old/kernel/break.c 2004-04-14 08:40:36.0 +
+++ new/kernel/break.c 2004-04-24 11:55:44.0 +
@@ -53,13 +53,13 @@ unsigned char ctrl_break_pressed(void)
unsigned char check_han
On Sun, 2 May 2004, Bernd Blaauw wrote:
> Bochs has no PCI, so UMBPCI does not work.
> any comments on the original message I posted?
sorry I meant loading HIRAM and then HIMEM. Not UMBPCI.
The way UMBPCI works when you load it first thing is that it simply
programs the chipset so that the m
On Sun, 2 May 2004, Bernd Blaauw wrote:
> DOS=UMB is causing a lot of problems.
> Unfortunately it's not possible to use UMBPCI (want to exclude EMM386 as a
> cause..) on Bochs.
I'm not sure what you want to accomplish exactly but from the DOS point of
view it doesn't make a difference if the
On Wed, 28 Apr 2004, Arkady V.Belousov wrote:
> Bart, what wrong with next macroses?
the plural of macro is "macros".
> __O\_/_\_/O__
> #include
>
> #define lonibble(v) (0x0f & (v))
> >^^
> #define hinibble(v)
On Sat, 24 Apr 2004, Arkady V.Belousov wrote:
>
> __O\_/_\_/O__
> /* MSC places uninitialized data into COMDEF records,
>that end up in DATA segment. this can't be tolerated in INIT code.
>
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 spons
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 ap
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)Cluste
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)
On Mon, 19 Apr 2004, Steve Gibson wrote:
> Using the 2034 kernel and fdxms.sys, I have two systems where FDXMS.SYS
> refuses to load because it mistakenly detects that VDISK is present.
is this new in kernel 2034? Or does it also happen with 2032 or 2033?
Bart
---
FreeDOS kernel 2034 is released at the usual place. Since no new
critical problems were found with 2034rc it is the same as kernel 2034rc
except for the updated history.txt and the version string.
Some important user visible changes (full log in history.txt):
Memory savings: saved ~1100 bytes of
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 par
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
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 d
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.
>
> :) Ker
On Wed, 14 Apr 2004, Arkady V.Belousov wrote:
> 14-áÐÒ-2004 17:16 [EMAIL PROTECTED] (Bart Oldeman) wrote to
> [EMAIL PROTECTED]:
>
> BO> http://freedos.sourceforge.net/kernel/kernel.sys (45k)
> BO> The daily tarball is at the usual place (same directory, kernel.tgz, 334k)
>
Hi,
I've done what I wanted to do for kernel 2034, but there have been quite a
few changes -- so if anyone can point me to any regressions which I missed
myself it would be very helpful and I (and Bernd too this weekend) can
avoid that brown paper bag.
Saved ~1100 bytes of resident code over kern
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
On Mon, 12 Apr 2004, Arkady V.Belousov wrote:
> 6-áÐÒ-2004 23:51 [EMAIL PROTECTED] (Bart Oldeman) wrote to
> [EMAIL PROTECTED]:
>
> > +++ inthndlr.c6 Apr 2004 23:51:33 - 1.68
> > case 0x11: /* normalise ASCIIZ filename */
>
>
On Mon, 12 Apr 2004, Arkady V.Belousov wrote:
> [EMAIL PROTECTED]:
>
> > in kernel.asm. Use std for the memory move: helps if there's overlap
> > (PCs with a very low amount of RAM).
> > +++ inithma.c 10 Apr 2004 14:18:24 - 1.24
> > - else
> > - {
> > -/* might overlap */
> > -f
On Mon, 12 Apr 2004, Arkady V.Belousov wrote:
> > RCS file: /cvsroot/freedos/kernel/kernel/makefile,v
> > +entry.obj: entry.asm segs.inc $(HDR)stacksinc$(TARGET).lnk
> > +int2f.obj: int2f.asm segs.inc $(HDR)stacksinc$(TARGET).lnk
>
> Bug: missed dot before "inc".
OK, thanks.
On Sun, 11 Apr 2004, tom ehlert wrote:
> well - you are going to do it.
Even -- I already did it.
> c) this imposes a limt of (ham_text+init_text) < 64K; not a real
> problem *now* and with good compilers.
> However LFN seems to be ~12-16 K code; should this ever go into some
> (conditional comp
On Sun, 11 Apr 2004, tom ehlert wrote:
> Well, I don't exactly see the point.
> What is saved if you drop it?
As long as we have MSCL8 in there people will try to compile with it and
then wonder why it doesn't work. By dropping it these people won't waste
their time. i.e. bitrot.
> *every* chang
Hi,
I'm proposing to drop MSCL8.MAK since
a) last time Lucho reported the compiled kernel doesn't work and nobody
stepped up to fix it.
b) I don't have MSCL myself so can't fix it myself without trying to find
a copy.
c) MSCL uses one of the ugliest builds. patchobj can be completely avoided
for B
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
On Mon, 5 Apr 2004, Luchezar Georgiev wrote:
> > Hi, in the FAQ, somebody claims that file handle 4 should default to PRN:
> > http://fd-doc.sourceforge.net/faq/cgi-bin/viewfaq.cgi?faq=incoming/224
> > Any idea why this would work at all? And why it works in MS but not in
> > FreeDOS? Used languag
On Thu, 25 Mar 2004, Arkady V.Belousov wrote:
> - bug: blockio.c/AllocateHMASpace(): wrongly freed extra buffer because
> "FP_OFF(bp+1) >= lowbuffer" expression (should be ">").
If your patch would just correct this I would apply it straight away.
But sorry, there's too much extra stuff in ther
On Fri, 2 Apr 2004, Luchezar Georgiev wrote:
> On Thu, 1 Apr 2004 21:46:29 +0100 (BST), Bart Oldeman wrote:
>
> > I sent this to Ralf Brown at the time that Matthias Paul did a desperate
> > call for updates because RBIL62 could be released any day (that was in
> > Ap
On Sun, 28 Mar 2004, Luchezar Georgiev wrote:
> Here's my conventional memory usage by various DOSes after our "great
> fnode breakthrough":
>
> FreeDOS 7.1: 10688
> MS-DOS 7.1: 9680
> PC-DOS 7.1: 9456
>
> What's in the 760 more bytes of FreeDOS (other than the 2 * 60 = 120 bytes
> for near
On Sat, 27 Mar 2004, Arkady V.Belousov wrote:
> 27-íÁÒ-2004 16:33 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to
> [EMAIL PROTECTED]:
>
> >>> So all that was necessary was to replace "call default" by "call
> >>> default.bat".
> >> No. :(
> LG> Why? Bart's latest patch works for me!
>
> Becua
On Sat, 27 Mar 2004, Erwin Veermans wrote:
> I used the daily tar.gz where the latest mod-time/date is
> 27-03-2004 01:35 for inthndlr.c
>
> So the current kernel is still panicing on fnodes ...
can you check again with the patch below applied to fatfs.c? It's in the
CVS but not yet in the daily
On Sat, 27 Mar 2004, Luchezar Georgiev wrote:
> On Sat, 27 Mar 2004 17:32:19 +0100 (MET), Eric Auer wrote:
>
> > while you are in an interrupt handler you are in CLI state.
> > So an HLT without a STI before it would hang the system.
> > The _int28_handler is only an iret as far as I remember, and
On Sat, 27 Mar 2004, Arkady V.Belousov wrote:
> 27-íÁÒ-2004 12:18 [EMAIL PROTECTED] (Bart Oldeman) wrote to
> [EMAIL PROTECTED]:
>
> >> LG> Bad news: the new build batch files don't do anything in 4DOS, probably
> BO> it's picky about
> BO> call co
On Sat, 27 Mar 2004, Arkady V.Belousov wrote:
> 27-íÁÒ-2004 12:40 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to
> [EMAIL PROTECTED]:
>
> LG> Bad news: the new build batch files don't do anything in 4DOS, probably
> LG> because of the %'s :-(
>
> Details, please! What mean "don't do anything"
On Sat, 27 Mar 2004, Luchezar Georgiev wrote:
> On Fri, 26 Mar 2004 22:22:20 + (GMT), Bart Oldeman wrote:
>
> > Can you check again? I think I solved at least Lucho's problem during the
> > init phase -- when fnodes could overlap disk buffers! Weird things
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%
>
> >> Also, where documented VDISK header (where I may read about this)?
> BO> It's in the VCPI spec. Available at many places including here:
> BO> www.dose.se/docs/osdoc/unsorted/ProtectedMode/VCPI.txt
>
> No, there sayed only about signature and showed how to copy word value
> from offset 0x
On Thu, 25 Mar 2004, Arkady V.Belousov wrote:
> 25-íÁÒ-2004 08:48 Arkady V.Belousov wrote to
> [EMAIL PROTECTED]:
>
> AVB> ; the HMA area is filled with 1eh+3(=sizeof VDISK) = 33 byte dummy data,
> AVB> ; so nothing will ever be below 0x:0031
> AVB> begin_hma:
> AVB> times 10h
> > >> The patched kernel behaves very strangely! :-( It outputs an error
> > >> for DEVICE=C:\DOS\HIRAM.EXE line and doesn't load it and repeates
> > >> this with many other lines (but not all). For my simpler floppy
> > >> configuration, it doesn't load HIMEM64.EXE without even showing an
> > >>
On Thu, 25 Mar 2004, Luchezar Georgiev wrote:
> On Thu, 25 Mar 2004 00:28:45 + (GMT), Bart Oldeman wrote:
>
> > (I'm cross-compiling on Linux nowadays mostly
>
> But how? With an OpenWatcom cross-compiler for Linux?
Yes, how else would that be possible (except fo
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
On Fri, 26 Mar 2004, Arkady V.Belousov wrote:
> 26-íÁÒ-2004 21:03 Arkady V.Belousov wrote to
> [EMAIL PROTECTED]:
>
> BO>> not rejected, just haven't got around to look at them closely.
>
> And let me remind you two more bugs, which you don't fix yet: first one
> is in INT 21/6C (lost check f
On Thu, 25 Mar 2004, Arkady V.Belousov wrote:
> Bart, what wrong wit my latest patches for batch files and for sources?
> They are small and they are tested - which reason to silently reject them?
not rejected, just haven't got around to look at them closely.
Bart
---
On Wed, 24 Mar 2004, Luchezar Georgiev wrote:
> I got 95 bytes for OpenWatcom FAT32/386. Perhaps we measure that
> difference in different ways. I just compare the sizes of the old and new
> object files... ;-)
Ah I see. That's not a very reliable way. For instance for your new patch
I get (I'm c
On Wed, 24 Mar 2004, Erwin Veermans wrote:
> > >> The patched kernel behaves very strangely! :-( It outputs an error
> > >> for DEVICE=C:\DOS\HIRAM.EXE line and doesn't load it and repeates
> > >> this with many other lines (but not all). For my simpler floppy
> > >> configuration, it doesn't load
On Wed, 24 Mar 2004, Luchezar Georgiev wrote:
> But the inodes have NRV (Not Really Vanished ;-) and their new place (UMB)
> could be HMA instead. Are there any problems moving them there? Because
> UMBPCI doesn't make too many UMBs :(
They can be in the HMA unlike the SFTs (like Tom said).
> >
On Wed, 24 Mar 2004, tom ehlert wrote:
> So I recommend setting the default to
>stacks=8,256
>
> which the user may overwrite as he likes.
OK. Too bad but not much we can do about that.
>
> >Now the code (HMATEXT) overhead is ~300 bytes, plus we have those two low
> >fnodes that take 120 byte
On Tue, 23 Mar 2004, Arkady V.Belousov wrote:
> Bart, let me remind me %subject% issue: why FD returns nonzero field
> for FAT32 in (and only in) current BPB?
most likely because of dsk.c: pbpbarray->bpb_ndirent = 512;
Why that line is there? I don't know. It was already in the first FAT32
I now have (for the FAT16 kernel) for
DOSEMU (no memmgr necessary) 644992 bytes free
on a real machine with HIMEM64+UMBPCI 641200 bytes free
I think (am not 100% sure though) we have beaten both MSDOS and DRDOS
(without QEMM) in that respect then. Ought to have a virtual beer if
that's true.
The
On Tue, 23 Mar 2004, Luchezar Georgiev wrote:
> The following patch saves almost 100 bytes in our largest function,
> inthndlr.c:int21_service().
How did you get 100? I only get 46 bytes (for the biggest kernel,
FAT32/8086).
Just to make sure I don't miss anything...
Bart
---
On Tue, 23 Mar 2004, Bernd Blaauw wrote:
> I tried various FILES=nnn settings to determine memory usage.
> with increased numbers for files=nnn setting I get more conventional
> memory used.
> Is this what is supposed to happen with DOSDATA=UMB setting?
yes, DOSDATA=UMB is just a shortcut to impl
On Mon, 22 Mar 2004, Luchezar Georgiev wrote:
> >> But what if it was the first entry in the root directory? Then the
> >> "new_diroff++" in dir_read() will make it -1!
> >
> > remove_lfn_entries() checks for fnp->f_diroff == 0. The first entry can't
> > have any LFN entries connected to it.
>
> O
On Mon, 22 Mar 2004, tom ehlert wrote:
> AVB> (BTW, is "protection"
> AVB> from wrapping HMA pointer into IVT by replacing wrapping into start of HMA
> AVB> worth of code?)
> a working kernel is worth a lot of code (even if you don't see the
> reason immediately)
>
> HANDS OFF THE KERNEL, please.
On Mon, 22 Mar 2004, Luchezar Georgiev wrote:
> But what if it was the first entry in the root directory? Then the
> "new_diroff++" in dir_read() will make it -1!
remove_lfn_entries() checks for fnp->f_diroff == 0. The first entry can't
have any LFN entries connected to it.
Bart
---
On Mon, 22 Mar 2004, Luchezar Georgiev wrote:
> > ":\elv_3e5.1"
> I mean "i:\elv_3e5.1"
> Sorry for my typo!
should be fixed now. remove_lfn_entries() calls dir_read with the offset
== -1 which is not possible for normal directories (. and ..) but is
possible for root directories. So the 65535 ch
On Mon, 22 Mar 2004, Luchezar Georgiev wrote:
> On Mon, 22 Mar 2004 10:29:28 +0000, Bart Oldeman wrote:
>
> > Make f_diroff an entry offset so it can be 16bits. Enforce the 65536
> > entry limit in dir_read(). Saves 80 bytes or so + 2 bytes in every
> > f_node.
>
>
On Mon, 22 Mar 2004, Eric Auer wrote:
> Hi, about add_far() pointer normalization: I think it would be
> better to normalize earlier. If you have a pointer, you normally
> have a pointer to a STRUCTURE. If the end of the structure ends
> up with an offset > 0x then having the POINTER normalize
On Sun, 21 Mar 2004, Luchezar Georgiev wrote:
> http://linux.tu-varna.acad.bg/~lig/freedos/CVSPATCH.TXT
I had a look now -- Arkady: will look at the default bpb issue later.
It appears that ^C has to be echoed to stdout. This is easy to test, I'm
using a simple test0a program, see below.
If you
On Wed, 17 Mar 2004, Luchezar Georgiev wrote:
> The patch below should fix the ZIP media change not detected bug, *if* my
> assumption about ZIP driver setting both DF_FIXED and DF_CHANGELINE is
> right. Never hurts to assume that this MAY happen though...
If the ZIP drive has its own device driv
> That's strange. Then MS-DOS DEBUG would also leak handles...
the difference is that msdos debug calls int21/ah=26 instead of 55. Here's
a kernel bug inspired by the RBIL comment "this function is implemented
using the same code as AH=26h" taken too literally...
Reality is that the only things t
On Tue, 16 Mar 2004, Luchezar Georgiev wrote:
> >>> Run "DEBUGRESULT".
> Damn, you're right! :-( It's the same with 4DOS! Moreover, the redirected
> file actually DOES contain the data but it's probably not properly closed,
> because after this operation, CHKDSK says that the disk has one lost
>
On Mon, 8 Mar 2004, Luchezar Georgiev wrote:
> OK, so I'd prefer changing the c type to unsigned char then. It could be
> just char but it's better to be unsigned char indeed to emphasize that
> 8-bit characters are valid too.
There's just one advantage using "signed char" or "int" instead of an
101 - 200 of 236 matches
Mail list logo
