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
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
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
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 ?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
2Bh
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
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
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
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
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
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
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)
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
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
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),
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
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]
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
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
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
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.
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
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
--- 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 */
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
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
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.
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
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
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,
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
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
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);
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
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)
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
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
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
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
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
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
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
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:
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 =
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
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
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
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
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
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
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
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
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
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.
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
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)
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
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
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
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
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
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
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
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
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,
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
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, 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;
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
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
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
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
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
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
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
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
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
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 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%
_
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
1 - 100 of 115 matches
Mail list logo
