Hi Marcos, Bernd,
I'm now using the 32-bit 2040 kernel, because none of these
errors has ever appeared under the previous 32-bit kernels...
Thanks for reporting the issues you're experiencing with the FAT16
kernels, multiple versions. Do you have a way of verifying...
FreeDOS has no
Op 15-7-2011 0:42, Eduardo Casino schreef:
Hi Bernd,
hello Eduardo, good to see you're around :)
Because it is harmless. Is it really necessary to treat that case in a
different manner than a successful installation? If it is, I'll look
into that, it is trivial to modify.
it's not really
Hi dos386,
PS: You could also compare EDRDOS+UIDE with FreeDOS+UIDE.
IIRC I tested some caches in the past. Result: NO SPEEDUP at all for a
single big file.
Maybe only helps with the sparse hack ;-)
unless dos386 describes what program(s) he used
My silly FATPLUS.EXE maybe ???
Was
Op 10-7-2011 13:11, Eric Auer schreef:
Hi dos386,
Ninja-ing thread here slightly:
Can kernel 2040 please be mirrored to Ibilio? Can't be found yet at
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/kernel/
PS: You could also compare EDRDOS+UIDE with FreeDOS+UIDE.
IIRC I tested some caches in the past. Result: NO SPEEDUP at all for a
single big file.
the data are useless :(
NOT that bad ...
unless dos386 describes what program(s) he used
My silly FATPLUS.EXE maybe ???
on what hardware to
I am working on updating my site as I move files to my new host.
www.fdos.org/kernel is updated.
Anyone can please upload the __correct__ HISTORY.TXT file for
the 2040 kernel release on some place where it is easily discoverable ?
Both SF and fdos.org ?
Op 10-7-2011 3:10, dos386 schreef:
Anyone can please upload the __correct__ HISTORY.TXT file for
the 2040 kernel release on some place where it is easily discoverable ?
Both SF and fdos.org ?
http://sourceforge.net/projects/freedos/files/Kernel/2040/
It's history.txt inside the doc
It's history.txt inside the doc directory, inside the zip archive.
No, it's outdated: 2011-04-09 ...
http://freedos.svn.sourceforge.net/viewvc/freedos/kernel/trunk/docs/history.txt?revision=1640view=markupsortby=datepathrev=1640
--
~~~ wow ~~~
I'm really sorry, I admit my description was quite confusing. All of
this is not exactly a problem to me, I could just format the pendrive
with the desktop BIOS geometry 974/128/63 and be done with it. I am
just being stubborn, trying to understand if there is a technical
reason that FreeDOS
Hi Ranieri,
try
SYS CONFIG KERNEL.SYS FORCELBA=1
after that
SYS CONFIG KERNEL.SYS
to list current option
this will force the freedos kernel.sys to always use LBA
and ignore CHS completely.
Tom
am 7. Juli 2011 um 15:41 schrieben Sie:
I'm really sorry, I admit my description was
try
SYS CONFIG KERNEL.SYS FORCELBA=1
after that
SYS CONFIG KERNEL.SYS
to list current option
this will force the freedos kernel.sys to always use LBA
and ignore CHS completely.
Tom
I have already been told to do that. If SYS CONFIG changes the file
KERNEL.SYS itself, then it
If all is well, your pendrive's boot sector(s) use the 1021/124/62 geometry.
I think the partition is properly set as 1021/124/62 because the
desktop refused to boot Syslinux in the pendrive earlier. Since I had
set the geometry this way it can boot from the pendrive.
You can always use SYS
If all is well, your pendrive's boot sector(s) use the 1021/124/62 geometry.
I think the partition is properly set as 1021/124/62 because the
desktop refused to boot Syslinux in the pendrive earlier. Since I had
set the geometry this way it can boot from the pendrive.
You can always use SYS
Hi Ranieri,
now I am booting FreeDOS from a FAT16 partition taking only the
last cylinder of the HD (8 MB). Perhaps I should start over with a
cleaner setup.
If your disk is more than 8 GB, the last cylinder cannot be
reached without LBA anyway, so FORCELBA should not make a
difference.
More tests: http://jafile.com/uploads/dos386/perftest.txt
unless dos386 describes what program(s) he used on what hardware
to produce these results, the data are useless :(
...you can try first writing some dummy data at where the file
will end, then close it and re-open (without truncate
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
More tests: http://jafile.com/uploads/dos386/perftest.txt
unless dos386 describes what program(s) he used on what hardware
to produce these results, the data are useless :(
...you can try first writing some dummy data at where the file
will end, then close it and re-open (without truncate of
- write 1 byte of data at this place
Shouldn't it be sufficient to seek to the desired size (as offset), then
do a write with length zero there? (Writing with length zero extends or
truncates the file to the current seek offset.)
- close the file
- open file for writing (no truncate)
I would
Hi Christian,
- write 1 byte of data at this place
Shouldn't it be sufficient to seek to the desired size (as offset), then
do a write with length zero there? (Writing with length zero extends or
truncates the file to the current seek offset.)
Possibly, but I wanted to keep things simple
More tests: http://jafile.com/uploads/dos386/perftest.txt
--
~~~ wow ~~~
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance,
Also available for download at fdos.org
http://www.fdos.org/
Content has not yet been moved to this host - please visit
http://www.fdos.info (mirror) in the meantime
http://www.fdos.info/
This page last updated - July 17, 2006
http://www.fdos.info/obten.html.en
FreeDOS Beta8 (Nikita)
I am working on updating my site as I move files to my new host.
www.fdos.org/kernel is updated. But I only have a little bit of time that I
split among development website updates.
--
All of the data generated in your
Hi!
You tested copying a 2.2 GB file...
More tests: http://jafile.com/uploads/dos386/perftest.txt
...you can try first writing some dummy data at where the file
will end, then close it and re-open (without truncate of course)
and do the actual copy. That should bundle the FAT updates and
Hi!
The pendrive geometry is 974/128/63 according to the desktop BIOS. In
the MBR its formatted as 1021/124/62, that is how linux sees it and
that is what is seen by the notebook BIOS.
That is an odd geometry, but you can use SYS CONFIG to patch some
settings in the kernel.sys binary itself
In my tests 2039 turned out to be unusable so please use 2040 ;-)
--
~~~ wow ~~~
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application
Kernel 2040 has been tagged and should be made available on
Sourceforge file releases within next few days
It is now: http://sourceforge.net/projects/freedos/
+ it does boot (no further tests yet)
- history.txt is lowercase and not updated:
2011 Apr xx - Build 2040
Jeremy Davis,
Op 30-6-2011 1:29, Santiago Almenara schreef:
Thanks Eric!
I'll try 2040 instead of 2030.
Just for everyone's information, I'm still able to hit a double BAD FAT
INFO - Run CHKDSK error message from the kernel occasionally
The only situation in which I sometimes am able to trigger that, is
Op 25-6-2011 16:06, Kenneth J. Davis schreef:
Hello all.
Kernel 2040 has been tagged and should be made available on
Sourceforge file releases within next few days.
Nice to have an official updated kernel.
Also available for download at fdos.org:
installer compatible form -
Op 21-6-2011 4:24, perditi...@gmail.com schreef:
If there are no objections, then this week (tomorrow if I have time) I
plan to tag the kernel at 2040 and make release builds available.
By all means go ahead :)
I suppose it includes Bart's earlier fixes, your modifications for
Memdisk
Bart's later fixes based on I think dos386's feedback (could
be Christian Masloch, can't recall right now who reported).
For the record: If you're talking about the FAT crosslinking issues, I
didn't report anything regarding that.
Here's a report again not regarding FAT crosslinking issues:
Did you try out this kernel?
Not yet (my ToTest pipeline is crowded ...)
--
~~~ wow ~~~
--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
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 ?
Does this mean that it has been fixed?
Alain
Em 03-05-2011 04:03, dos386 escreveu:
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
On Sat, Apr 9, 2011 at 6:56 PM, Eric Auer e.a...@jpberlin.de wrote:
Hi Pat, kernel gurus Jeremy and Bart,
You can release it [an updated kernel], but I want to put
it together with other updates and finally generate v1.1.
You mean a FreeDOS 1.1 BASE ISO image? That would be nice,
but you
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 Pat, kernel gurus Jeremy and Bart,
You can release it [an updated kernel], but I want to put
it together with other updates and finally generate v1.1.
You mean a FreeDOS 1.1 BASE ISO image? That would be nice,
but you can of course use many already pre-packaged updated
packages from the
You can release it, but I want to put it together with other updates and
finally generate v1.1.
Pat
On Fri, Apr 8, 2011 at 10:48 PM, Bart Oldeman
bartolde...@users.sourceforge.net wrote:
Hi,
thanks to Damien Guibouret the problem with file corruption in kernel
2039 finally seems to be
Hallo Herr Ibidem,
am 1. April 2011 um 07:56 schrieben Sie:
I tried building svn revision 1560 with Turbo C 2 and a 16-bit nasm
0.9x (FAT32/186). It started building, but then when build.bat hit
SYS, I got this:
Error sys.c 629: Expression syntax in function initOptions
I REM'd out SYS
It's still active of sorts. I'm in the process of defining the road map,
and input like this is very useful.
We have FDAPM, but I'm not familiar with your GPU, and have no idea if it
works with FDAPM. I don't know if there's anyone else that has an answer
for you.
Pat
Project Coordinator
On
There is work going on, but noe estimate to completion.
I would tend to agree, use 2038 until it is fixed.
Pat
Project Coordinator
On Fri, Jan 8, 2010 at 3:03 AM, dos386 dos...@gmail.com wrote:
I have prepeared a new FreeDOS distribution for REAL USE in the field
Is there anyone working
I made a very simple distribution, close to the original MS-DOS disks.
Main carachteristics:
- Single floppy
- Single language
- No fancy program or interface at all, but complete functionality
- Simple batch menu, with most functions are for partitioning, formating
and installing.
- Config
Hi
1. No new details to the Crosslink-BUG ... cluster size is 4 KiB :-|
Why do you refer to an obsolete mail ?
Half of it is not a bug, the other half is...
What ???
This is because DIR tells you how much space is used / free.
the which you mention, you force a recalculation...
I
Well, the tracker entry is 28 days old, this discussion is 12 days
old, and ... this is not the first time I have to whine about the
user base of FreeDOS, if such a thing exists at all. At least, this
time the BUG got opened by http://sourceforge.net/users/tnavratil/
Tnavratil, not me.
So new
Date: Mon, 23 Nov 2009 23:13:25 +0100
From: Eric Auer
Alain mentioned that it is hard to keep an overview which
kernel file is which version, for example if you want to
report a problem or want to compare kernels. For that it
would be a great help to put for example the SVN release
Well, got __STRANGE__ news:
1. No new details to the Crosslink-BUG ... cluster size is 4 KiB :-|
2. Discovered a NEW BUG:
- present in both 2038 and 2039
- not critical
- possibly related to the Crosslink-BUG (probability not very high ...)
- reproductability as ALWAYS :-)
Steps to repropduce:
I'm having a look
Thanks :-)
how large is your FAT partition exactly?
Cca 6 GiB , have to check the other PC ...
There is always the GB/GiB confusion...
1 GiB = 2^30 Bytes
1 GB = ??? (don't know don't use)
what is the cluster size (I'm looking for potential overflows)
4 or 8 KiB , have
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
of course you are right. but maybe you are missing the point why the
original author (m2) wrote it exactly as it is: to save precious 2 bytes in
the boot sector code
Tom
am 6. Dezember 2009 um 00:32 schrieben Sie:
Hi,
the LBA detection of the FAT12/FAT16 boot sectors (both for the FreeDOS
of course you are right. but maybe you are missing the point
...
why the
original author (m2) wrote it exactly as it is: to save precious 2 bytes
in
the boot sector code
This is a problem for the FAT12 OEM boot sector only, all other boot
sectors can be assembled with this patch
Hello Pat, Eric, and everyone else,
Clarification:
Formerly, Ikon was sold as an OS (for a short period from September to
November this year), with the FreeDOS kernel and some other GPL code
included in binary form. The source for GPL programs was available as a
separate download.
The Ikon GUI
You need to go to
https://lists.sourceforge.net/lists/listinfo/freedos-kernel, as shown on the
bottom of the email, and follow instructions on that page.
Pat
On Mon, Nov 30, 2009 at 3:39 PM, m...@pixoled.com wrote:
UNSUBSCRIBE
Hi Pat,
Allow me to make this perfectly clear: the FreeDOS kernel
*IS NOT PUBLIC DOMAIN* and will never be.
Please do not spread such rumors.
I do not see such rumors but...
OFFTOPIC: JaguiD (Java with GUI for DOS) might be worth testing;
the Ikon GUI, offered commercially this fall as an
Thank you. I will follow through on that.
Pat
On Sat, Nov 28, 2009 at 8:26 AM, Eric Auer e.a...@jpberlin.de wrote:
Hi Pat,
Allow me to make this perfectly clear: the FreeDOS kernel
*IS NOT PUBLIC DOMAIN* and will never be.
Please do not spread such rumors.
I do not see such rumors
Alain mentioned that it is hard to keep an overview which
kernel file is which version, for example if you want to
report a problem or want to compare kernels. For that it
would be a great help to put for example the SVN release
number in there. SYS CONFIG can then be used to show it
for any
Your Nov 15 build (http://www.fdos.org/kernel/sys/sys.com) works here,
while the last build (Nov 13) still had the bug. So I guess you fixed it;
the only question is what changes made the difference.
I tried sys with these options:
c: c:\large.bin
d: d:\small.bin /bootonly
c: large.bin /bootonly
On Fri, Nov 13, 2009 at 3:14 PM, ibid...@lavabit.com wrote:
Hello everyone,
First, I have a bug report against the 1497 fdos.org build of sys
(OW386/FAT32/UPX)--
if I specify a file to write the bootsector to (sys c: large.bin, with or
without /BOOTONLY or /BOTH), sys crashes with Invalid
The kernel may need to work around the Linux VFAT patent avoidance HACK
in Linux kernel 2.6.30+, which writes 100% illegal names to the SFN entry
when LFNs are used. Christian was going to include a workaround in Rx-DOS
(NASM GPL code); it may help to see that.
COOL. Now really nobody can
Am 21.10.2009, 03:47 Uhr, schrieb dos386 dos...@gmail.com:
The kernel may need to work around the Linux VFAT patent avoidance
HACK
in Linux kernel 2.6.30+, which writes 100% illegal names to the SFN
entry
when LFNs are used. Christian was going to include a workaround in
Rx-DOS
Paul,
I have got this working with the 2038 kernel version. I modified as less as
possible since the kernel size is not that important to me. Using minor
modifications allows me to migrate to new kernels more easily.
The problem was that I did not use UPX which was pointed out to me by an
other
I have a need for the same feature, so I downloaded the 2039 build and made
tweaks from there. I had no trouble with my combination of OW1.8 (DOS
native), NASM 2.07 (DOS native), and UPX 3.04 (Win32).
I also confirmed that I can compile and boot using other combinations,
including TC2.01,
Hi Christian,
I remember that eltorito.sys tries to autodetect whether the BIOS
lets you access the CD/DVD as 2048 byte per sector drive or rather
as 512 bytes per sector, so the idea of different sized sectors is
not new... Floppy supported 128 to 1024 bytes, for example... Yes,
FreeDOS only
Hi Eric,
not new... Floppy supported 128 to 1024 bytes, for example... Yes,
FreeDOS only supports 512 bytes at the moment. For unknown reason,
this became even more hardcoded than it was before short ago. As
far as I remember, the biggest that MS DOS supported was 4096 for
WORM, but only
Ooops, true, I have mistaken both lists, thanks Eric!
Aitor
2009/9/4 Eric Auer e.a...@jpberlin.de:
Hi Aitor,
2009/4/26 Christian Masloch c...@bttr-software.de:
Examples:
- handling of floppy before disk is inserted / unformatted partitions
- initdisk CHS geometry fix and BSS init fix
Hello Bart,
I added the hook... very sorry about this delay...
Aitor
2009/6/5 Bart Oldeman bartolde...@users.sourceforge.net:
Hi Eric,
2009/6/5 Eric Auer e.a...@jpberlin.de:
Bart seems to work on this a lot, but unfortunately there is
nothing about the progress on the mailing list.
Hi,
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
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
b) why there isn't a 386-fat32 binary available (hardly anyone even
knows where he might see a real 8086 machine), and the 386 resident code is
~1,5 KB smaller
Point out the file(s) that were missed and I'll do an update.
IMO the most useful kernel configuratiion is FAT32, compiled for 386
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
Bart Oldeman wrote:
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
On Thu, Aug 6, 2009 at 12:01 PM, Tom Ehlert t...@drivesnapshot.de wrote:
*** SNIP ***
just wondering, why
a) this wasn't advertised on this list and
Oversight.
b) why there isn't a 386-fat32 binary available (hardly anyone even
knows where he might see a real 8086 machine), and the 386
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
On Sun, Aug 2, 2009 at 9:29 PM, Bart
Oldemanbartolde...@users.sourceforge.net wrote:
*** SNIP ***
Or you can try the new 2039 release -- see sf.net/projects/freedos but
not yet officially announced.
Having trouble logging into ibiblio. When I get it uploaded there,
I'll make the
Pat, I'm taking care of it. It's the least I can do to help u guys.
On 7/31/09, Pat Villani p...@monmouth.com wrote:
Hi Folks,
Sonmeone is having trouble and it's up on one of the yahoo sites:
http://answers.yahoo.com/question/index?qid=20090730064519AAdKTRN
Can someone here have a look at
Thank you.
Pat
On Fri, Jul 31, 2009 at 1:33 PM, Jackie McBride able...@gmail.com wrote:
Pat, I'm taking care of it. It's the least I can do to help u guys.
On 7/31/09, Pat Villani p...@monmouth.com wrote:
Hi Folks,
Sonmeone is having trouble and it's up on one of the yahoo sites:
Pat, I am having him/her go into bios make sure that booting from cd
as well as the boot order are set properly. If that doesn't help, then
we've gotta modify the boot iso, which is gonna be fun, especially
since I don't know his/her expertise level.
I wish I knew how to do all the stuff u guys
Pat, as a forencisist, I can tell u that the hp bios is pretty
problematic, that may be where some of the difficulty lies.
On 7/31/09, Pat Villani p...@monmouth.com wrote:
I've been seeing reports of FreeDOS crashing on machines it's installed on.
I've also gotten some direct email from people
Eric Auer wrote:
You can manipulate initdisk.c, in particular BIOS_nrdrives() and
the loops from 0 to nHardDisk to make FreeDOS ignore all your
harddisks. For compilation, you should have NASM, UPX and the
OpenWatcom C compiler. A tiny distro of the latter should be
on
Jeremy,
Do you have a binary of what you will be tagging? I'd like to test it.
Pat
P.S., I can't build it because my development notebook is dying.
On Wed, Jul 29, 2009 at 10:23 AM, Kenneth J. Davis jere...@fdos.org wrote:
Assuming no objections, I will tag and make available kernel 2039
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
Hi Bart,
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!
On Wed, Jul 29, 2009 at 2:06 PM, Eric Auer e.a...@jpberlin.de wrote:
*** SNIP ***
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
Hi,
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
Hi Pat,
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!
Sure :-) Maybe we could also
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
On Wed, Jul 29, 2009 at 5:06 PM, Eric Auere.a...@jpberlin.de wrote:
Hi Bart,
...
* New SYS, merged from unstable branch.
I hope it still uses the much faster cached copying :-)
Could you add a small but useful option to force either
CHS or LBA mode boot sectors, in particular for FAT32?
On Wed, 29 Jul 2009 13:23:51 -0400, you wrote:
Hi Jeremy (or anyone),
Any official announcement of when new kernel release?
Since FreeDOS works excellent on USB finger, MS-DOS 7.1 have difficulty in
making it bootable.
Glad to see lot of people working hard to improve the kernel.
Rgds,
As FreeDOS project coordinator, just email here and you'll contact me. So
you just did ;-)
Way back in the dark ages, Jim and I had a discussion about licensing and we
pretty much settled on GPL. These licensing discussions continue today as
well. I won't bore you with the details, but we
Hi Thomas,
I'm building a freeware HDD disk wiper, checking and cloning application.
It runs fine with FreeDos except that I get some errors messages when a
disk is not partitioned. Since I'm not relying on any DOS calls for HDD
access and the nature of the program I would prefer the kernel
On Mon, Jul 27, 2009 at 10:44 PM, ibid...@lavabit.com wrote:
...
In the discussion I refer to, relicensing was mentioned. I am curious who
should be contacted for such requests, or if relicensing would be allowed,
etc.
The kernel source says Portions copyright Patrick J. Villani.
Would that
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
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.
exactly as the
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
On Sat, Jul 18, 2009 at 10:37 AM, Bart
Oldemanbartolde...@users.sourceforge.net wrote:
Jeremy,
I was wondering what your reasoning is for changing
It has to deal with debugging the kernel, especially during
initialization. I choose this method as the kernel does not usually
have many strings
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
Hello all,
It is true that no DOS provides pipes. HX makes up for this by creating
a
new file and opening 2 instances (1 read only)--per the HX docs that I
looked at on Sunday.
This is very similar to what COMMAND.COM (/FreeCOM/4DOS/RxCMD) does for
I/O redirection and pipes between
Hi Bart,
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.
Given the
Hi Christian,
I know about the OEM ID and the DOS-C release string which can be
retrieved by Int21.33FF. I don't see how SHARE could use that...
I suppose there's no way to get the kernel's build number for SHARE then?
The revision number (eg 38 for 2038) is returned in BL
if you call int
Given the number of hooks, some of which are not even documented,
I would say that the current implementation of SHARE is smoother.
I agree.
This format of share exe hooks table about MS SHARE lists:
- a routine of unknown purpose, probably not called
Since SHARE of MS-DOS 3.3+ is
Am 06.07.2009, 10:00 Uhr, schrieb Eric Auer e.a...@jpberlin.de:
Hi Christian,
I know about the OEM ID and the DOS-C release string which can be
retrieved by Int21.33FF. I don't see how SHARE could use that...
I suppose there's no way to get the kernel's build number for SHARE
then?
Please explain in what way Win 3 uses virtual(?) machine numbers
and why supporting them is needed to get a Win compatible SHARE.
MS-DOS usually sets the net machine number (offset 1Eh of SDA, table at
Int21.5D0B) to zero (indicating local) inside its Int21 dispatcher,
unless the server
101 - 200 of 1070 matches
Mail list logo
