Hi kernel readers :-)
Looking at the development of dosemu2, I find that the
many changes there have moved away from freedos SO far
that backporting became hard, without me ever noticing.
There was the announcement of fdpp in 9/2018, one year
after development started, which morphs the kernel i
Hi HPA! The boot sector takes a BIOS drive number of the
to-be-booted drive from the MBR, which can take it from
the BIOS. There also are patches to take the MBR item by
pointer from the MBR, but those are not used by default.
So I guess the kernel could take the drive number from a
boot sector,
Hi again,
I have tried to investigate this problem further by comparing 3 files:
> https://sourceforge.net/p/freedos/svn/HEAD/tree/kernel/trunk/boot/boot32lb.asm
> https://sourceforge.net/p/freedos/svn/HEAD/tree/kernel/trunk/boot/boot32.asm
> https://sourceforge.net/p/freedos/svn/HEAD/tree/kerne
As SYS is part of the kernel sources, maybe somebody on the
kernel mailing list has an idea for me...? Thanks! :-)
Hi everybody,
apparently the same SYS update which introduced FAT32 LBA support also
broke FAT32 CHS support: On Dimitris' PC, CHS based FAT32 boot always
fails, but his BIOS lack
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, so I guess the gurus are
awake at the moment...
QUESTION: Would it be possible to improve UMB handling su
Hi HPA and Joao,
support for EXT3 in the kernel would indeed be large/complex.
Only supporting EXT3 READS already would take circa 10 kB of
code, taking the size of the EXT2/3/4 GRUB module as example.
I like MEMDISK bootable ramdisk style: MEMDISK can be booted
by boot loaders which are able t
Hi Roy,
> Is there any guide that can help on compiling custom kernel with less-used
> function(for example, NLS functions) removed/stubified?
Well FAT32 is a compile time option and I think RayeR made
a slightly stripped kernel for his "DOS in your flash BIOS
chip" micro... ehh... distro, but
Hi!
Your vision on DOS is somewhat, well, interesting ;-) So
there is a lot to chat about, although I am not sure if
the KERNEL list is the right place for this topic. DPMI:
> I would expect performance gain to be minimal. Maybe there could be
> Low/HMA/UMB memory savings with a different archi
Hi Louis,
sort of a long response - it seems hard to make a short point here:
> FreeDOS Roadmap, as goals and stretch goals for the project. I read
> (paraphrasing): built-in networking, built-in USB, integrated DPMI, 32-bit
The fd32 project works or worked on the DPMI aspect. As far as I
reme
Hi Louis,
if I understand your patch correctly, you only changed the
build configuration to check how it affects the size of
the compiled kernel before UPX compression, which also is
an indicator of RAM size of the kernel? You changed the
config.b, build.bat, buildall.bat files and generic.mak
an
Hi sparky,
(PS: Please decide on which of the 3 lists this should be discussed)
> FreeDOS's mem program output only 4 GB of detected memory out of the
> machine's total 16 GB Dose this mean FreeDOS can only detect 4GB
> maximum?
This is NOT related to the kernel: MEM only reports what EMS,
Hi Chris,
>> I'll link to the 1.0 boot floppy image, under the "FreeDOS 1.0" section.
>> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.0/fdboot.img
That is a bit old so I am still preferring Ruffidea ;-)
Also because it is easier to delete than to add stuff,
for the lat
Jack, kernel people (now CCed),
>> When DOS detects an unreliable floppy change line hardware,
>> it should use the floppy label / serial / similar to detect
>> changes in software ...
>
> How does DOS ever detect that any hardware is "unreliable"??
I do not know, but earlier in this thread, so
Hi Bernd,
>> (untested, just "history.txt" __IS__ updated this time)
>>
>> but nobody annouced it :-D
Yes, why?? I forward a message from RayeR in the forum below.
> It's a secret to everybody!
> (hm, too much Zelda)
>
> The pre-386/memdisk detection is a good thing, finally a unified kernel.
Hi Czerno / Bertho,
> Hi Eric! On the freedos-kernel list, you voiced such opinion about
> the future of big sector disks:
>
> " that has low priority imho, as drives with large sectors are a
> temporary thing, will be gone with GPT partitions. "
This refers to the following quote from an ear
Hi Chris, Jeremy,
> Commit 1705 renames a particular LoL field CPULevel and adds a comment
> correctly claiming that MS-DOS sets this field to 1 on 386+ CPUs and to 0
> otherwise. The commit however makes the boot loader store the detected CPU
> level (0, 1, 2, or 3) there instead. I don't
Hi Jeremy, Chris, others,
> I am aware they are different...
That is risky - even for a demonstration implementation,
consistency seems important to keep code maintainable...
> dynamically adjusted same as MSDOS. That currently is not done.
that has low priority imho, as drives with large sec
Hi Jeremy :-)
>> Replaying a 12 May 2005 mail :-)
>>> [Freedos-kernel] Analysis: Support for sector sizes != 512 bytes
> Thank you for reviewing and providing a suggested road map.
Well, that old mail is nice for reference, but I would still say:
> So I suggest to support nonstandard sector si
Replaying a 12 May 2005 mail :-)
> [Freedos-kernel] Analysis: Support for sector sizes != 512 bytes
Hi, I have browsed the CVS kernel a bit, and got the impression
that it would not be too hard to support sector sizes below 512
bytes (32, 64, 128 and 256 bytes should be possible). For sector
siz
Hoi Bernd,
> I'm in a situation where I got Syslinux bootloader on an USB flash
> drive. It loads the MEMDISK ramdisk module with a floppy image as
> contents which is then executed (as drive A:).
> I'd like to get into a situation where the USB flash disks doesn't get a
> driveletter assigned
Hi!
>>> My silly FATPLUS.EXE maybe ???
>> Was that the hack to go above 4 GB file size?
> NO: http://www.fdos.org/kernel/#fatplus
License evilness. Better to have the EDR DOS style
hack for files above 4 GB file size than "that".
Or of course turn LTOOLS into a drive letter driver
to support EX
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
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 ???
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. Ho
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 si
Hi Tom,
>>> 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 (
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 itsel
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
incr
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 f
Hi dos386 :-)
> 1. No new details to the "Crosslink-BUG" ... cluster size is 4 KiB :-|
However, it is very interesting that it involves broken high 16 bits
on FAT32 on almost full disks. I hope this helped Bart to zoom in on
potential causes for the bug :-).
http://sourceforge.net/support/track
Hi Tom, DOS386,
>> 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 multi
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
Hi all,
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
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 sup
Hi Aitor,
> 2009/4/26 Christian Masloch :
>>> Examples:
>>>
>>> - handling of floppy before disk is inserted / unformatted partitions
>>>
>>> - initdisk CHS geometry fix and BSS init fix from RayeR
>>>
>>> - int 21.1c non-FAT / non-existing drive handling fix from Tom
>> If anyone wants to contri
Hi Jeremy,
>>> * 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?
> I did merge in the improved chunk copying method; however I ke
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 w
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! h
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 ker
Hi Christian,
Please explain in what way Win 3 uses virtual(?) machine numbers
and why supporting them is needed to get a Win compatible SHARE.
I also wonder what enumerates machines and how in a real network.
MS probable does not use anything fancy like checksum of IP/name?
Regarding the new A
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
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 n
Hi Christian,
> I don't know what Japheth has to complain about it, but I know that
> DOS-C's SHARE:
>
> - is a C program that stays in memory without usage of any assembler code.
True. It might be interesting to rewrite it in pure Assembly, for size.
> Increases memory usage much.
Alread
Hi Ibid,
> 1470 builds and works fine (not much testing done though).
> cd \ works again
Good...
> HDPMI (HX 2.15 dpmi server) loads.
What was broken before?
> Regarding the "patch" I saw mentioned, here's the thread:
> http://sourceforge.net/mailarchive/forum.php?thread_name=482838EE.7020707
Hi Aitor,
> I support this idea, but that means that odd numbers (2039) would go unstable.
Actually Bart already ported country sys support from unstable,
combining it with built-in country support. He is also working
on f-node free operations in stable. This means that version
2039 will be the
Hi everybody,
There is a new sourceforge file release of the FreeDOS kernel:
Version 2038 is now available with OpenWatcom 8086 FAT16 and
FAT32 binaries and as source code download. No 386+ or Turbo C
binaries this time, but please email if you want / made those.
Bart is already working on featu
Hi Ibid,
> mess ... with Win98 and FreeDOS (Freedos starts, Windows doesn't
You can dual-boot with Win98 and FreeDOS actually sharing the
same C: drive, using a suitable boot menu and file locations.
You should use only the Win98-DOS kernel for starting Win98.
>> UDF is popular for rewritable d
Hi Jeremy,
> The Windows specific patches are minor but add a small amount of code
> hence the extra work to enable (Windows is the only application for
Can you give an example of the changes in code size in RAM / on disk?
> them). The kernel worked with windows 3.11 in enhanced mode except for
Hi Bart,
> well, at the time of setting up SVN I asked Jim if he could
> set up sourceforge so the patches to go to the existing
> freedos-cvs mailing list (where CVS commits were sent)
I do not know how many people read that list, but my suggestion
was more to talk about the code rather than re
Hi Bernd, Tom, Bart, others,
> * external Country.sys support (including MODE, DISPLAY, NLSFUNC etc)
Definitely useful. I hope it can be combined with compiled-in
2038 style basic support: Things like date/time/number format.
While only external country.sys adds sort/uppercase/lowercase
override
Hi dos386!
Can you forward details about that dmidecode / bttr forum thing?
>> PS: I would like to quote IBID_AG
>> 4. I would rather see more of the features from 2037 in stable
Ask IBID... country sys support is very useful for SOME languages,
but which other features of 2037 are really hot?
Hi Bernd, Pat, Jeremy,
>> Pat, Jeremy: Please FIRST update history txt BEFORE we make
>> a sourceforge file release of kernel 2038. Thank you :-).
I just uploaded updated history.txt / readme.txt / contrib.txt
as subversion revision SVN r1412 for Pat :-). NOTE: Please ONLY
updated those 3 when m
Hi, as there was no reaction to the mail of dos386
ten days ago, I would like to repeat it as new thread:
> Tested and didn't find anything eclatantly evil so far :-)
>
> - It works mostly, see shot:
> http://img211.imageshack.us/img211/4611/ker2038.png
This screenshot shows a 46208 byte kern
Hi Bart,
>> svn diff -r1386:1388
>> gives a diff of 14 kilobytes, 12 files modified,
>> 46 lines changed, 170 lines added. Quite a lot.
> Do you think the change is too big?
Too big to say "read the diff" instead of explaining
what and how you changed, but not too big as patch :-)
Many of your
Hi, I found another patch on my disk which probably has not
been applied to the stable kernel yet - please have a look
and comment :-)
- handle unusual floppy types
- change some initdisk messages
- re-enable DF_NOACCESS flag (correctly, I hope?)
- change InitializeAllBPBs to avoid "FAT16 FAT32 a
Hi Bart,
> Can you be more specific? Did you look at the svn diff at all?
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 auth
Hi Bart :-)
> 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-comp
Hi Christian,
>> Still no reason to add experimental things to stable now :-)
>> The solution is easy: Add it to the UNSTABLE fork
>
> No. Because first, I don't develope DOS-C, and second, forking is bad and
> makes merging changes back in harder. Since your opinion seems to be that
> files
Hi Pat,
> This sounds liuke a good strategy.
>> I would say 2038 as default, 2037 (including winkrnl) as option--unless
>> 2039 shows up first (doesn't look likely). If 2039 gets something
>> worthwhile, 1.11 is an option.
I agree - same as in 1.0, the stable kernel is the
default and the unst
Hi Christian,
> I don't want to change everything. The only extension I asked
> for was to support FAT+, of course in the "stable" (or "trunk") kernel
> branch because "unstable" isn't developed by anyone currently and
> developing it would proceed the forking of these branches.
Still no r
Hi!
Indeed JAM only works on non-FAT32 kernels because of different
data structures... JAM apparently needs the start cluster of
the compressed disk file so it can use lowlevel (int 25/26...?)
calls to access that file without causing reentrancy while the
kernel accesses files on the compressed d
Hi Bart,
>>> [fnodes] are ancient relics that should be done away with. There is no
>>> need for them anymore. I'd like to put that high on the priority list
>>> for kernel development.
>> in theory you are right. in praxis fnodes are everywhere throughout
>> the file system (as you probably kn
Hi Jeremy,
> Kernel 2038 tagged and available at http://www.fdos.org/kernel/latest/
> Someone with access, please upload to ibiblio and release on SF.
Please update history.txt - it represents the state of 13 months ago...
While you are at it, could you update my email to mceric at
users.sourcef
Hi Tom, Christian,
>> Which app crashes from running on a FAT+ kernel?
Those which assume that DOS runs FAT filesystems and
uses 32 bit size fields in directory entries or file
offsets and so on. Potentially many normal DOS apps.
>> because EVERY new or extended filesystem breaks them.
Only th
Hi!
>> And again: Tell me ONE thing where you want files above 4 GB size
> Hello DVD/BluRay disc images :)
Maybe we should have DVD playing software and a DVD-
compatible version of DOSCDROAST first... :-p. And
I repeat my earlier argument: Just split the bluray
image into a few files, very eas
Hi Abrahan,
> Ex-FAT support instead of FAT+ or FAT32+??
>
> This idea seems more good like FAT+ instead :-)
>
> And how is the support for Windows 3.1 / 3.11?
While it is called FAT, exFAT seems to differ a lot
from FAT. Also, exFAT is heavily patented... Talking
about FAT+... I really wonder
Hi Jeremy,
>> You misunderstand me :-) Of course we should support files of 2-4 GB
>> size in the STABLE kernel very soon! Just do not support ABOVE 4 GB
>
> There are no longer multiple active branches, there is only trunk.
Trunk is stable, but there also is devel / unstable:
http://freedos.s
Hi Christian,
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.
>> I agree - modifying FAT to support files > 4 GB is asking
>> for tro
Hi Jeremy,
> Currently I am working on the 2038 release. That is, going through
> reviewing, modifying (usually comments), and committing the set of
> patches/bugfixes outstanding. This weekend I am going to tag and
> release 2038 - I lost most of my access to SF and all to ibiblio so I
> will
Hi Tom, Jeremy,
>> 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.
I agree - modifying FAT to support files > 4 GB is asking
for trouble. Of cou
Jeremy,
>> I could not find any LOAD*.* file in the zip, though... Maybe
>> this whole experiment is something different than IBID meant?
> See http://www.seasip.info/Gem/gemxm.html (I'm not sure if its the
> same/newer/older than the one from the OpenGEM site)
> This version of GEM/XM include
Hi Jeremy, Bart, IBID,
>>> I tried 2038rc1svn out _briefly_. It works about the same as prior builds
>>> (runs edit, mem, command, gem; loads ctmouse, gcdrom, himemx,jemm386,
>>> shsucdx; still does not run GEM/XM).
...
> OpenGEM variant of FreeGEM (http://gem.shaneland.co.uk/) provides the
> G
Hi ibid_ag at lavabit com,
> I tried 2038rc1svn out _briefly_. It works about the same as prior builds
> (runs edit, mem, command, gem; loads ctmouse, gcdrom, himemx,jemm386,
> shsucdx; still does not run GEM/XM).
> If anyone else wants to test GEM compatibility, I would suggest
> downloading th
Hi Bart,
thanks for making the patch much shorter, very "commitable" now :-)
Why did our old code do that complex "put bp at [bp+2]" thing? And
what does the "cpm_error jump decision now inverted" patch mean?
Eric
> This is a minimal fix for [entry.asm]
...
> -pushbp
Hi Bernd,
>> Offtopic: fdos.org was down temp because I forgot to update...
> Hi Jeremy, good to hear from you.
Definitely :-)
> This would probably be a bad time for announcing I've lost fdos.org ftp
I did not even know you had one! So you could actually have
fixed some of the way outdated
Hi Bart, admins, others,
>> Would you like to have access again? Should be no problem :-)
> Sure!
Apparently only Aitor, Jim and Pat can give you SVN write
access but I think that would be a *very* nice idea... ;-).
I noticed Pat already uploaded your SYS OW 1.8 fix :-).
If you plan to patch
Hi Christian,
>> - handling of floppy before disk is inserted / unformatted partitions
>> - initdisk CHS geometry fix and BSS init fix from RayeR
>> - int 21.1c non-FAT / non-existing drive handling fix from Tom
> If anyone wants to contribute to discussions about this patches
> he can do that
Hi Christian,
>> If you're waiting for further improvements to 2038 before you release
>> 2038, then you're doing this wrong. [...] I'd strongly recommend
>> making 2038 available, and putting the "few pending improvements" in
>> 2039.
>
> The problem is that Eric holds back at least three neces
Hi Bart,
> here's a patch to be able to compile SYS with OW 1.8. I've lost SVN
> commit access...
Would you like to have access again? Should be no problem :-)
> +#if defined(__WATCOMC__) && __WATCOMC__ < 1280
>unsigned short date, time;
> +#else
> + unsigned date, time;
> +#endif
Questio
Hi Tom,
- 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.
[patch to preserve DS:BX and set AL=-1 if FatGetDrvData... == NULL]
> should get the job done
Indeed, test for NULL as return value of FatGetDrv
Hi Roberto,
result of a quick test in dosemu: I used the install tool
to set sound to none for fm, speaker for voice and then
selected "update" to store settings. Now start,bat starts
some endless loop of animation. Running "indark2 8 0" by
hand without the "-d" of the batch file lets me access a
Hi Hans,
> The easy fix to this is use Watcom 1.2.
The current versions are 1.7 and 1.8 release candidate,
where and why would one download a years-old OW 1.2...?
I must say that the kernel compiled well with OW 1.3 of
2004, but I wonder whether newer versions work better.
> I use latest versio
Hi Tom,
here is one of two diffs for patches that I have not
commited to SVN because I was waiting for review...
Topic: Handle floppy type 6 and use DF_DISKCHANGE and
DF_NOACCESS as well as InitializeAllBPBs in a way which
should help disk tools to avoid confusion about FAT1x
versus FAT32.
Ques
Here is the IsShareInstalled patch which also does
not seem to be commited to SVN yet?? The goal is
to reduce the share install check call floods that
FreeDOS would normally cause. The side effect is
minimally later detection of share, should be fine.
Thanks for commenting :-)
Eric
diff -bur f
Hi Tom :-)
>> - 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.
Unfortunately I do not know to what value DR DOS sets BX/CX/DX,
only got the information that they looked kind of random...
In any case AL has to b
Hi Roberto,
> Hello, this is the first time that I write in this list and I´m not very
> good in English.
>
> Some days ago I tried run Alone in the Dark 2 in Freedos and it failed. This
> message appeared:
>
> JemmEx: exception 06 occured at CD:EIP=0
> 000:000B, ERRC=
> SS:ESP=326E
Hi, as nobody replied to this thread started 22 dec 2008,
I am following up myself with a more dramatic subject ;-)
However, trying FTE-HX in dosemu, it seems that we did
NOT break ctrl-c handling in 2038. Instead, it seems that
ctrl-c handling is broken in FTE-HX for both FreeDOS 1.0
kernel 2036
Forwarding to the kernel list...
Original Mail is from Japheth.
You can check the SVN for 2036
to 2038 changes, probably in
conio or the ctrl-c handling.
Date: 2008/12/21
Subject: [Freedos-user] Tiny Kernel incompatibility introduced in 2038?
To: FreeDOS User
Hello,
in the latest FreeDOS k
Hi Michael,
continuing the topic on freedos-kernel instead of
freedos-user, maybe one of the kernel list readers
has a precompiled kernel for you or can compile a
kernel or several with debug options according to
your choice enabled :-).
> For now, please link to the debug version!
> Well, is
Hi Hans,
> infamous "Bad or missing Command Interpreter" error
This means FreeDOS looked for the boot files on the
wrong drive or failed to access any drive at all. If
it cannot open fdconfig.sys, it will try config.sys
next, and if it cannot open that, it will use a built-
in default configurat
Hi Hans,
> I also noticed that it won't build correctly
> without UPX. As a quick hack I removed the UPX
> arguments from exeflat (in kernel/makefile)
> which fixed the issue.
That should be configurable via config.bat isn't it?
>>> Now it seems to get struck in the int 21h/1a handler,
>>> isn'
Hi Hans,
> 1Mbyte of RAM with the top 8Kbyte taken by the BIOS.
> All ram is available
Exotic :-)
> the BIOS test the first 704Kbyte...
Ah okay... well 640k are enough and "more expected".
You could also check at b800:xx to check if DOS apps
try to do screen output there...
> I used 704 as th
Hi Hans, replying via freedos-kernel...
> My system seems to boot until it starts init_device() in kernel/main.c.
> InitIO calls init_device 12 times before my system crashes (see below)...
> KERNEL: Entering init_kernel()...
> HMA moving 0268: up to 9fde: for 9cdf bytes
This message is
Hi!
> 1) new disk was used with Linux, but a first primary partition was made
> but never formated
Make sure it is flagged as fat32 and as lba. Check possible
messages from initdisk early during freedos boot as well.
I recently tried making a DOS bootable partition on a new
disk, too, and found
Hi!
On Fri, 5 Sep 2008, Koike Toshio wrote:
> The patches are uploaded here.
> http://us.f13.yahoofs.com/bc/48b6f314_185bc/bc/freedos/patch080818.zip?bfh__vIBxIiwN9fQ
Redirects to a non existing hostname:
http://bcvrf.yahoo.com/bc/48b6f314_185bc/bc/freedos/patch080818.zip
> Problem 1: Maxell n
Hi!
> I'd have to check the sources I have here for several dos versions
Please avoid getting in touch with source code for dos versions
that are supposed to be closed source. Mixing any information
from such sources into our development would be inappropriate.
Note that share has a call that c
Hi,
dunno how other DOSes do this, but I suggest that
FreeDOS only calls int 2f.1000 SHARE install check
when files are opened/closed, not on each access
(merge_file_changes, DosRWSft, DosLockUnlock).
Background: FreeDOS at the moment calls the SHARE
install check 100s of times even for really t
Hi Christian,
> BUFFERSHIGH is also mentioned in the FreeDOS kernel documentation
> (http://www.freedos.org/kernel/docs/config.txt):
>
> Usage: buffers=nn[,n] where nn is in range 1-99 & n is in range 1-8
> Memory buffers used by the kernel; primary[,secondary]
> The secondary buffer option is a
Hi Christian,
> seems to be an older issue, but BUFFERSHIGH is not recognised by
BUFFERS are always in the HMA as soon as FreeDOS uses the HMA
(DOS=HIGH) unless the BUFFERS are too many to fit in the HMA.
Of course one could make BUFFERHIGH a synonym for BUFFERS? ;-)
> FreeDOS. Buffers are load
Hi Travis,
> ... it still did the same thing. Can you please tell me where
> to find the classic kernel (less FAT32 support) ...
you should not take "classic" too literally. Check the kernels
on the rugxulo.googlepages.com homepage and try one which has
a 16 instead of a 32 in the filename. The
1 - 100 of 290 matches
Mail list logo
