> the FreeDOS kernel is seriously slower then MSDOS when doing
> larger copy/xcopy operations.
> the cause: the disk I/O code avoids transfers that cross a 64K
> boundary, and splits these transfers into 3 (smaller) transfers.
> this was needed for floppy controllers in the 1980's, but is certain
Hi everybody,
the FreeDOS kernel is seriously slower then MSDOS when doing
larger copy/xcopy operations.
the cause: the disk I/O code avoids transfers that cross a 64K
boundary, and splits these transfers into 3 (smaller) transfers.
this was needed for floppy controllers in the 1980's, but is ce
if exist K:\NUL echo K: is present
is broken in kernel 2042
the bug is caused by a change in TrueName(), where code was changed
from
cdsEntry = get_cds(result);
if (cdsEntry == NULL)
return DE_PATHNOTFND;
to
dhp = IsDevice(src);
cdsEntry = get_cds(result);
if (cdsEntry ==
ink/slashdot
> ___
> Freedos-kernel mailing list
> Freedos-kernel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Mit freundlichen Grüßen/Kind regards
Tom Ehlert
+49-241-79886
---
Hi,
> Was using FreeDOS 1.1 2040 kernel? previously and could check for
> drive or directory existence with the NUL device:
> If exist c:\nul echo C: exists
> If exist c:\mydir\nul echo C:\mydir exists
> This behavior is broken with 2042, no longer being able to identify if a
> drive/dir exi
>>From the point of view of protecting this system from counterfeiting &
> unauthorised access, is it possible to interrupt processing config.sys? I
> had read about pressing F5 to bypass config.sys and autoexec.bat. Also that
> this can be disabled in config.sys.
modify kernel.sys by using
sys
> Hi kernel experts,
> I vaguely remember that there is a pending patch where the kernel
> is using a memcopy-style function residing in memory that already
> got "freed" at that moment during boot,
to be precise: during INSTALL=
> so I guess the gurus are awake at the moment...
> QUESTION:
the problem, brought up by Bret:
during config.sys processing,
INSTALL= \freedos\MEM.EXE /F
will report ~24 K used at 99f0:0
however the kernel will crash if memory below this is overwritten.
source for the bug:
CONFIG.C, DoInstall() sets up a memory arena, and releases memory
below the
> INTERLINK issue has not been resolved, and still requires
> option to load low.
Why not?
crashing the kernel when a driver calls DosAlloc() is not so smart an
idea. disabling dosalloc for drivers is possibly suboptimal, but at least
prevents a crashing kernel.
of course a better fix would be n
mmit
> changes from git to svn.
> On Feb 5, 2016 11:04 AM, "Tom Ehlert" wrote:
> Bret,
>
>> Eric/Tom:
>
>> I used to use INTERxxx a lot many years ago using the special
>> parallel cables designed for that purpose (I think I still have a
>> c
> I wanted to ask: to what degree does FreeDOS implement the redirector
> interface? Are there any known incompatibilities?
it should right work.
all known redirectors
CD/DVD drivers
MS Lan Manager
NTFSDOS
NTFS4DOS
VMSMOUNT (with source)
for DOS work without (known) problems
>
> Sorry for the link I haven't used thus machine to send emails in a long
> time. The antivirus tags it with it. I had suspected that I wouldn't
> be able to kernel merge, but it's nice to have thoughts. The multiuser
> will have to wait whilst I wait on the response from Caldera, They have
> an
> I am interested in writing a new driver, one that would allow you to
> boot and run dos on a EXT3 partition.
booting from EXT3 would require to make EXT3 part of the kernel.
not going to happen.
otoh there is virtually no disadvantage to have a loadable TSR to make
EXT3 available as a redirecto
> Maybe, but ext3 was designed as a multithreading FS. The
> multithreading becomes single threading so performance would far
> worse, and possibly even worse than FAT16/32 or ext3
of course a multithreading FS (read ahead and write behind caching)
has a huge number of advantages which aren't ava
> I am an E.E./Comp. Sci. student, but I want to contribute to the FreeDOS
> Kernel. Would it be fine if I began setting up a multiuser/multitasking
> system like Digital Research's DOS 5, and begin the work to get Forth
> into the kernel?
the kernel is definitively not the right place
to integ
> If I want to remove fdconfig.sys support, break, numlock, echo, switches,
> country, HLT idle, and menus in CONFIG.SYS options,
> and hardcoded NLS page, and all NLS stuff(replaced with stub)
> How much I can shrink?
a) how much of what?
filesize of kernel.sys? resident memory used?
b) take a
> We were working on PDOS development particularly interrupt number
> Int 21/AH=0Eh(Select Default Drive). While testing the PDOS function
> i came across a particular behaviour in FreeDOS, according to the
> description given in the documentation
> "http://www.ctyme.com/intr/rb-2570.htm";
>
> I'm not sure how you can say the FreeDOS project isn't interested in a BC5
> kernel.
because I was around when the kernel was ported to MSVC, BC5, OW (in
that order)
> The BC5 makefiles I found in the kernel sources I didn't write.
> Bart last worked on them 9 years ago.
right. an since OW beca
> What's the difference between wcc & wcc386?
code generation for 16 bit (DOS) or 32 bit (windows)
> Does wcc386 generate code that could be used in the kernel?
no
>> Big wins could be had on 586 with FPU memcpy 64-bit versus the 16-bit asm
>> in the kernel now and possibly the string function
> Kernels with FAT32:
> 086: 68358 bytes
> 186: 67180 bytes (286 same)
> 386: 66044 bytes
> 486: 65948 bytes (586 and 686 same)
> It is interesting that even 186 instructions do make a
> quite big difference and that there is a difference at
> all between 386 and 486. With 186, you get pusha an
> I use the Kernel 2041 and found follow strange:
> If I press the key for singlestepping and then the key to skip a
> command, the
> singlestepping-process of the FDCONFIG.SYS is skipped.
I implemented it this way because AFAICT MSDOS 6.2 behaves this way
> Under MS-DOS the key skips only th
> that has low priority imho, as drives with large sectors
> are a temporary thing, will be gone with GPT partitions.
MBR partitioned disks will be gone shortly after the famous gate A20
is gone ;)
currently *visible* 4KB sectors exist for a single purpose:
to support disks > 2TB for Windows XP.
>> Dear PerditionC,
>>
>> UBYTE DiskTransferBuffer[MAX_SEC_SIZE];
>>
>> wastes 3,5 KB low memory for *everybody*, not only when it's needed.
>> regarding how much time we have spend until we had 64 byte free
>> I think this is a bad idea
> please see my previous messages, I know exactly h
Dear PerditionC,
UBYTE DiskTransferBuffer[MAX_SEC_SIZE];
wastes 3,5 KB low memory for *everybody*, not only when it's needed.
regarding how much time we have spend until we had 64 byte free
I think this is a bad idea
I also think that these experiments should NOT be in the stable
branch.
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
&g
buffer, size)) != 0) {
into copy. c
> My suggestion was to pre-grow the
> file, not only pre-create it. Something like, ca 2 GB example:
I would prefer code to suggestions.
use your keyboard to write code, not emails ;)
Mit freundlichen Grüßen/Kind regards
Tom Ehlert
+49-241-79886
>> 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
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 S
> As already pointed:
> http://sourceforge.net/support/tracker.php?aid=2901916
> there is a CRITICAL BUG in FreeDOS kernel 2039 :-(
> I can well reproduce it (not always, though) when COPY'ing files onto
> a FAT28 volume. There can be even multiple crossy bunches per multiple
(>>=2) files. Also
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 FreeDO
>> 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
The kernel developers have just finished up 2039 for release a
few days ago (mostly bugfixes), so you can download it at ibiblio (
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/kernel/2039/
or at sourceforge (
http://sourceforge.net/projects/freedos )
just wondering, why
a) this wa
> 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
> * Windows 3.1x support
seriously: is ANYBODY using Windows 3.x ?
IMHO Windows 3.x is 100% obsolete, so why would anybody want windows
3.x support ?
>>> & WfW support in stable, these might be handy.
> Windows for Workgroups , which is a flavor of Microsoft Windows 3.11
WfW support will probabl
>> 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. i
> Which app crashes from running on a FAT+ kernel? (Presuming you don't even
> have that large files, or that the app doesn't access these files.)
> Excluding low-level disk utilities such as defragmenting or disk checking
> programs of course, because EVERY new or extended filesystem breaks the
> The
> main bug/feature that I plan to work on is FAT+ support, the working
> with 4GB files goes along with this since it adds support for 4+GB
> files.
Please keep this out of production kernels.
this involves the risk of breaking stuff inside the kernel, and is not
(and never will be) support
>>> - int 21.1c should report invalid drives via AL (keep other regs?)
>>> News here: DR-DOS modifies BX/CX/DX but not DS for inv drives.
/* Get Drive Data */
case 0x1c:
{
BYTE FAR *p;
if (p = FatGetDrvData(lr.DL, &lr
>> and after he verified this private version, may be even put it on
>> ibiblio to be used by others ?
> I hope you did see the mail earlier this week which says that
> kernel 2038 is almost ready anyway ;-).
whatever 'ready' means when nobody (except you self) tested it so far.
in the good old
Hi Eric,
how about compiling this for Christian ?
not everybody likes to download watcom, find out how to get kernel
sources compiled ...
and after he verified this private version, may be even put it on
ibiblio to be used by others ?
Tom
-
> Hopefully someone can found the bug and fix it, my pathetic knowledge
> forbid me to help.
to fix any bug, it must be reproduced first.
As noone has ghost 5, 'the bug' can't be reproduced, and so can't be fixed.
end of story.
Tom
-
>> >1658 Ghost 5.1 fails: Needs somebody with Ghost 5.1 to fix
> Maybe true, but I do not have ANY version of Ghost to test :-(
> If a newer version of Ghost works, then we could indeed set
> the bug status to "wontfix" and mention that newer versions
> do work fine. Or we could lower bug priority
gt; - Arkady and Bart in 2004
> - Bart in 2001
> - Bart in 2004 (moved fnodes into HMA)
> - Lucho in 2004
> - Tom in 2001 (created inithma.c)
the HMA buffer logic came much later ;)
Mit freundlichen Grüßen/Kind regards
Tom Ehlert
+49-241-79886
---
>>NOTE that both versions have a typo: "... the any key ..."
> It's not a typo! Damnit! Still haven't found the any key?
see http://www.computergear.com/pressanykey4.html
and http://www.gadgetizer.com/2006/04/03/any-key-mistery-solved/
or just google for "the any key" ;)
Tom
-
> 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/
> ___
>
> - int 2f.4a00.cx=0 the kernel has to call this before it displays
>the "Insert diskette for drive B:" (or A:...) message, to let
>Win3 and the like show a GUI dialog instead of the message, DOS 5.0
seems to have been lost; should be
STATIC WORD play_dj(ddt * pddt)
{
/* play the DJ ..
e
that I understand. At least I can't complain about possible bugs introduced
by some experimental feature ;)
Mit freundlichen Grüßen / Kind regards,
Tom Ehlert
+49-241-79886
---
This SF.net email is sponsored by: Splunk Inc. Do you gr
looking at.
it's not a freecom problem.
but the kernel will simply not (re)detect coming and going partitions.
remember FDISK ?you HAVE to reboot.
Mit freundlichen Grüßen / Kind regards,
Tom Ehlert
+49-241-79886
---
This SF.Net
Hello Kenneth,
> The main issue with FreeCom would be the location of its resources
> changing.
under normal circumstances, FreeCom-xmsswap will have it's resources
loaded at startup and touch them never again.
Tom
---
This SF.Net email is s
Hello Eric,
> While we are at it, I would suggest a new category "not planned at all
> unless you tell us why it is useful or alternatively send us patches"
> for the list: http://fdos.org/ripcord/fdos_1_0/official/post.htm
> Candidates are: drivparm / driver sys / 3rd floppy support (kernel, sys
Hello Eric,
> Comments about useful sector sizes would be welcome:
> Smaller (64, 128, 256), normal 512, Bigger (1024, 2048, others).
512.
> Thanks for your comments! Trying to wake up the kernel list a bit :-)).
add code to support dynamic disks.
Tom
--
Hello Geraldo,
> is possible to implement a virtualfilesystem layer on
> freedos kernel?
it has already: the network redirector interface.
> what do you think about create a hardware abstraction layer
> on freedos kernel?
> it is interesting to make freedos "portable" to others
> architectures
it
Hello Alain,
Tuesday, January 11, 2005, 1:24:48 PM, you wrote:
> Arkady V.Belousov escreveu:
>> Hi!
>>
>> 4-Янв-2005 19:05 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to
>> [EMAIL PROTECTED]:
>>
>>
>>>Fix divide error message text
>>>+++ entry.asm 4 Jan 2005 19:05:08 - 1.27.2.2
>
l,
> almosthttp://www.thinkgeek.com/sfshirt
> ___________
> Freedos-kernel mailing list
> Freedos-kernel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-kernel
--
Kind regards,
Tom Ehlert
mailto:[EMAIL PROTECTED
Hello Arkady,
>>> Small optimization: because BC doesn't knows, that exit() doesn't
BO>> I don't think optimizing exeflat.exe's size is very important though ;)
> Sure. :) But why not make more optimal code from scratch in any case,
> without thinking "will this code often used"?
And wh
Hi Bart,
good to see you alive and around :)
> http://freedos.sourceforge.net/kernel/exeflat.c
> (the file is smaller than the diff would be)
there are probably a couple of changes to makefiles & batches ?
> To use it you need to change the makefile to remove the explicit UPX call:
> this call
This is a forwarded message
From: Jose Antonio Senna
Subject: FreeDOS kernel disk routines
===8<==Original message text===
Excuse me for sending this directly to you, but I am still unable to post
on Freedos lists.
I do not know who (if anyone) mantains the FreeDOS ker
Hello Eric,
> Hi, I tried to check SFT compatibility of FreeDOS, quick conclusion:
> sft_dcb is never accessed
> sft_stclust is never accessed
>...
> sft_ifsptr is never accessed (nor initialized to 0?)
you may be right. and it may be easy to replace (most of) the fnode
data by the corresponding
Hello Eric,
> Hi, Steve reports that while things were fine in kernels
> 2030 ... 2033 (both with and without FAT32 support), kernel
> 2034 WITH FAT32 support and all 2035 kernels fail to read
> the (fd) config sys file when booting from floppy.
*ALL* kernels 2023..2035BTom boot from 1.44 floppy,
Hello Eric,
> Hi, I exchanged some mails with Udo from DR DOS improvement project,
> and the conclusion might be that FreeDOS is not missing much for 386Enh
> compatibility - it only has one thing too much: fnodes.
From what follows, it real seems to be easy to make FreeDOS Win3.1
compatible.
So
Hi Jeffrey,
actually the kernel tries to finish CD harddisk emulation
before booting from HD (main.c, EmulatedDriveStatus)
unfortunately this doesn't seem to work (in your case, with your CD
burning software,...)
tom
---
This SF.net email i
Hello Eric,
> - Tom has added only the best few lines of the Lucho / Arkady patches,
> those which OBVIOUSLY fix bugs, but will have missed several bugfixes
> which were hidden between optimizations
that might have happened.
But for sure I missed some bew bugs hidden between optimizations.
>
Hello Luchezar,
Tuesday, September 14, 2004, 12:18:08 PM, you wrote:
> Sorry Bart, I was wrong AGAIN. I will add creation times again, and this
> will END my participation in the FreeDOS project. I feel that I'm NOT good
> for such activity anymore. Jack R.Ellis was right to never participate in
Hello Luchezar,
> Do you mean
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg01070.html
yes
> (It doesn't contain other comments but those in the patch.) If you
> confirm, I can apply it.
yes.
>> it happens if a int24 handler returns to itself directly, instead of the
>> 'normal' way to ret
Hello Luchezar,
>> and removes (parts? of) tom's patch.
> As you wrote youself, it's better to have the whole patch than parts of
> it. And even better is to solve entirely the problem which this kludge
> solves partially. But we don't know the problem :-(
at least I know the problem - and desc
Hello Luchezar,
>> "D:"==second disk? Second disk is a 81h value.
> Only 0 and 80 are used by MS-DOS. All other values are "FreeDOS
> extensions" ;-)
are you SURE ?
I remember a BIOS that had the option to boot from 2'nd drive.
this only makes sense if DOS then boots from 0x81.
tom
Hello Luchezar,
>> In FreeDOS 2035a, NSSI crashed.
>> In the newest unstable kernel, NSSI works excellent!
>> Get NSSI at http://www.navsoft.cz
> Thanks for the information! Unfortunately if UDMA or CD-ROM driver is
> loaded, it hangs at the "checking memory for viruses" stage under the
> unstabl
> In FreeDOS 2035a, NSSI crashed.
as it works for me (a different 2035a), could you
give some details (like config.sys).
in particular: does it crash with an empty config.sys ?
tom
> In the newest unstable kernel, NSSI works excellent!
> Get NSSI at http://www.navsoft.cz
> Interon
--
Hello Aitor,
> I have started watching kernel source files, and trying to understand
> its logic by reading sources.
good luck ;)
> (1) why are there STRINGS.C and MISC.C, apparently with the same
> functionality and same routines in the same programming language?
historical reasons. it was so
Hello Aitor,
> 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
> (provided that, for copyright issues, the COUNTRY.SYS of the
> "c
Hello Luchezar,
>>> Not only Bulgarians. 3/4 of the world thinks so. And many Americans and
>>> Germans too, by the way.
>>
>> there is a german saying 'hey guys - eat shit! Billions of flies can't
>> be wrong'
> So we're just billions of flies to you. Very well :) Otherwise it's a
> great anti
> _______
> Freedos-kernel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/freedos-kernel
--
Best regards,
Tom Ehlert
mailto:[EMAIL PROTECTED]
+49-241-79886
---
Hello Luchezar,
>>> It's not worth a penny because it can be freely downloaded from Vietnam
>>> (I posted the URL here ;-)
>>
>> I know bulgarians think that way.
> Not only Bulgarians. 3/4 of the world thinks so. And many Americans and
> Germans too, by the way.
there is a german saying
'hey
Hello Luchezar,
> It's not worth a penny because it can be freely downloaded from Vietnam (I
> posted the URL here ;-)
I know bulgarians think that way. It's still theft.
tom
---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Bl
Hello Luchezar,
> Hallo Eric,
>> does FreeDOS already support int 2f.122f, set DOS version number?
> Now it does - see patch below ;-)
according to RBIL:
INT 2F U - DOS 4.x internal - SET DOS VERSION NUMBER TO RETURN
AX = 122Fh
DX = DOS version number (h = return true DOS v
Hello Eric,
>> - lr.CH = REVISION_MAJOR; /* JPP */
>> - lr.CL = REVISION_MINOR;
>> + lr.CX = 0; /* serial number must be 0 or buggy 32RTM thrashes
>> stack! */
> I would vote for lr.CH = 0 lr.CL = *letter*
MSDOS votes cx=0. end of story.
tom
---
Hello Luchezar,
>> There you have it folks. A dumb bug in a Borland product that by purest
>> happenstance fails under FreeDOS and not MS-DOS. I don't have any idea
>> how to gracefully fix the problem other than to have FreeDOS change its
>> serial number. And it shouldn't have to do that.
An
Hello Luchezar,
>> one reason for different behaviour *might* be that smartdrv traps
>> int25/int26, which is used differently in FreeDOS (not everything is
>> rooted through it)
> What isn't routed through it?
the kernel talks directly to int13 and never uses int25 internally.
>> a) he implemen
Hello Luchezar,
> I use IOCTL every day and that's how I found that the XMSDSK lock bug that
> prevented SCANDISK from checking the XMSDSK drive had come back as Arkady
> moved the lock check too low. Without anger, I wrote a patch for this, he
> accepted it with some minor changes, and - voila! P
>> 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 :)
a) other DOS's were just too expensive
b) his problems seem to have been entirely related to the 2033 kernel
default stacksize of 128 byte
c)
Hello Luchezar,
>> or call the 'optimized' kernel keUNSTABLExxx or keARxxx, as the main
>> stream kernel should concentrate on FIXING bugs, rather then introducing
>> new ones.
> 100% agreed. Since I use "unstable" kernel every day in practice, I think
> it has no more bugs than the "stable" one.
Hello Luchezar,
> I didn't know that there are TWO kernel builds called 2035a... Perhaps you
> should call yours 2035b where b = Bart (a = Arkady ;-)
or call the 'optimized' kernel keUNSTABLExxx or keARxxx,
as the main stream kernel should concentrate on FIXING bugs, rather then
introducing new
Hello Luchezar,
> OK, long live the holy conservatism that saves the FreeDOS world
> from the Arkadifying hell ;-G By
100% agreed
tom
---
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal
downloaded ke2035ar.
just did what I did for 3 years in a row: copy my old CONFIG.BAT
saidc:>BUILD
and got Compilation was aborted!
congratulations :((
tom
---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterpri
Hello Eduardo,
> I've found what seems an odd bug in the kernel (version 2035) while
> testing a first alpha version of nlsfunc and it is driving me mad:
> In nls.c:muxLoadPkg(), the value of cp becomes 0 right after the first
> call to muxGo() (the one that does the installation check).
solved:
Hello Arkady,
> Some times I report about bugs in SYS. Unfortunately, these reports was
> completely ignored. (tom, what about "discussion"?)
to make one thing clear - once and for all time:
you post about 10 changes to this list - do you really expect that
everyone reads, tries to understa
Hello Arkady,
> Eric offers:
- memcpy(bs->>OemName, "FreeDOS ", 8);
+ memcpy(bs->>OemName, "FRDOS4.1", 8);
> Otherwise, Win9x/.. will sometimes ignore boot sector BPB (yuck!).
> Value must be 5 uppercase letters, a digit (4 or 5), a dot, then a digit.
> Is there any objection against this
Hello Arkady,
> - may/should be `static dmatch Dmatch;' in fcbfns.c moved to stack in the
> FcbFindFirstNext() (as in other functions in fcbfns.c)?
I' abolutely NOT sure about that.
you are right - it doesn't seem to make much sense.
I have some dark memory, that I changed that (back in the d
Hello Eric,
>> EA> LBA_Transfer should call the appropriate int 2f.xx function before
>> EA> calling play_dj - or play_dj should call it itself: This allows
>> EA> GUIs to return "okay, notified, please suppress DJ text message".
> INT 2F CU - DOS 5+ - FLOPPY-DISK LOGICAL DRIVE CHANGE NOTIFIC
Hello Arkady,
>>> For drives beyond lastdrive, get_cds result protects from crashes,
>>> but in between, access to unformatted disks returns nonsense for
>>> int 21.36 and even crashes while trying to do critical error dialog
te>> really ?
te>> please provide exact code sequence where it DOE
Hello Eric,
>> > DosGetFree (FatGetDrvData int 21.1c/21.36) can crash, maybe because of
>> > a NULL navc pointer.
>> If so, please submit some code to make the kernel crash.
>> if not, shut up.
> I did. Read and shut up:
> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/format/forma
Hello Eric,
> DosGetFree (FatGetDrvData int 21.1c/21.36) can crash, maybe because of
> a NULL navc pointer.
If so, please submit some code to make the kernel crash.
if not, shut up.
> I wonder if it is really desirable that the
> current implementation fakes bigger cluster sizes to allow cl
Hello Eric,
> Somebody else already tuned the clock driver:
> ticks = ((ticks / 59659u) << 16) + ((ticks % 59659u) << 16) / 59659u;
> ... scaling factor 1193180/6553600 = 59659/327680 = 59659/65536/5 ...
done by Bart and me ~2002 (50% by me, and Bart gave it the final touch)
compared t
->>> BREAKS FreeCOM and possibly also FDAPMs "Am I run from INSTALL=?"
> 1. MS-DOS-style mean two \0 and 2035a produces two \0.
EA>> So Arkady has optimized away 4 "wasted" bytes in environment,
> 6.
PLONK.
tom
---
This SF.Net email
Hello Arkady,
BO>> Or ULONG or u32 or uint32_t or uint_least32_t or simply "unsigned long".
BO>> These structures aren't portable anyway. What's in a name?
> Nothing in C/C++ is portable, this is nature of these languages, which
> present only machine specific types. But BYTE/WORD/DWORD type
Hello Eric,
> I am sure 2035a fixes several bugs of 2035
found the ret_ah bug. if that has real world implications is unknown.
found the Ulong 32%32 bug - impressive, but 100% irrelevant to the
kernel as all real world use will work 100% ok.
claims to have found a bug in umb_link code for a001:
EE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_idG21&alloc_id040&oplick
> ___
> Freedos-kernel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/freedos-kernel
--
Best regards,
Tom Ehlert
mailto:[EMAIL PROTECTED]
+49-241-79886
Hello Bernd,
>>BB> to work out his changes. At a given moment, he should probably issue a
>>BB> code-freeze and then make stuff more readable/review-able
>>
>> May you point, what in my code isn't readable (or, at least, less
>>readable, than in original code)? :(
well - he skipped the 'revie
My dear Mr. Belousov,
> _I_ _report_ bug in FreeCOM. If now FreeDOS is closer to MS-DOS and
> FreeCOM now incorrectly works in both under MS-DOS and FreeDOS (with empty
> environment), who wrong?
do you really think a new kernel that breaks all installed FreeCOM's
in the wild is an improveme
Hi Bart,
> In any case, I appreciate that a bug was found in ludivmul.inc
so do I
> What I don't like is that the fix from Arkady (for the 1000th time...)
> does 3 things at the same time -- formatting, fixing, and optimizing.
neither do I like that.
> This makes it impossible to see where thin
1 - 100 of 159 matches
Mail list logo
