[Freedos-kernel] Kernel bug fixes need backport from dosemu2 fdpp
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 into a Linux lib for dosemu2: https://github.com/stsp/fdpp (excuse the extreme simplification of my description) But there apparently never was a discussion about the improvements in fdpp here, very few people at dosemu2 were in the mood to backport things, possibly inspired by the lack of bugzilla readers here and the very few original FreeDOS kernel people who took the effort to cherry pick patches apparently have not shared their capacity bottlenecks here. E.g. Andrew Bird has sent https://github.com/PerditionC/fdkernel and https://github.com/FDOS/kernel some patches and Jeremy has started some cherry picking himself? So what have we missed during all that time, 2.5 years? - fdpp solves obscure MCB / UMB related problems which made FreeDOS unable to use UMB at a000:0 including stack overflows and reboot troubles? - dosemu2 needs some FreeDOS-only "boot work-around" if hdiskboot -1, hdisks >0 and hdisk 0 is not bootable...? (probably to help us to boot from D: drive or similar) - some boot changes (not sure whether dosemu2 specific) on https://github.com/dosemu2/fdpp/commit/10507295bdea1dee3109ed115dc0dc38f98d2565#commitcomment-35887845 - FreedOS 1.2 and older has no int 2f.121f, just 2f.1217, but that might have been fixed back in FreeDOS recently? - many games work better with fdpp than with FreeDOS, says https://github.com/dosemu2/fdpp/releases/tag/beta-9 (Test Drive 2, Tetris Classic, Elite Frontier, Empire Soccer, Virtual Chess, Alone in the Dark, Alpha Waves) - however, for example int 21.71a6 in fdpp may only be used in conjunction with dosemu2, according to the same site?? - fdpp fixes something related to Volkov Commander: https://github.com/dosemu2/fdpp/releases/tag/rc-1 This also mentions 2 of the above games "resize PSP to 0 and then terminate it" which apparently MS DOS accepts - probably a lot more Note that fdpp development seems much faster than freedos kernel devel in part because dosemu2 disciples love their toolchain, but dispise the tools available for real DOS? Please, it is nice to have a few very active experts in a few DOS related projects, but why do I have to feel like an eavesdropper when figuring out which bugs get fixed and which features get added? It looks a lot like many of those probable improvements never made it to FreeDOS kernel sys because people fail to talk about them across projects. So please talk about those things on freedos-kernel! If you know about a bug in FreeDOS, talk about it. If you know about a fix in fdpp and lack the time to backport it to FreeDOS, at least mention it here. If you know about compatibility issues, do not just drop from this list and install fdpp or MS DOS. Talk about it! For those who have not experienced dosemu2 yet: Note that it has less magic guest drivers, so you WILL have to LOAD them in your config sys. Read their pre-installed config. Dosemu2 is a QUICKLY moving target and following their github feels like spying on a private chat, but most of the time the improvements outnumber the regressions and it work much better than the stalled classic dosemu :-) I hope there are still some people HERE who are keen on kernel improvements. Maybe we can wake up and at least find out how FreeDOS 1.3 (and up) kernels COULD improve. Thank you! Regards, Eric PS: Excuse the cross-post CC to freedos-devel. It is for the case that there are not enough kernel readers left. ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] EXT3 support
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, which at the moment is easy because the boot sector stores the value from the MBR in the drive byte of the boot sector loaded into RAM, which is a predictable location in general. Might be fun for booting from 0x81. >> support for EXT3 in the kernel would indeed be large/complex. Would not do that, but would boot DOS by MEMDISK and load a full EXT3 driver from there later :-) Same for ISO9660, but there "read files from ISO root dir" might be quite small, so boot without MEMDISK might be interesting as well... >> Regarding the idea to have the kernel "natively boot from a >> RAMDISK in HIGH MEMORY which would NOT be A: or C: ... Well, >> on modern computers it should not be a problem to "hog" the >> drive letter of the A: floppy drive - you probably have at >> most ONE real floppy next to that ramdisk anyway and letter >> B: is still free :-) So in that sense, MEMDISK is ok for me. Exactly :-) > So this is a horribly stale discussion, but it seems that all that is > needed is the ability to hide somewhere a preferred drive letter for the > FreeDOS kernel to pick up and use. It is trivial to add support for > passing such information along in MEMDISK. > > -hpa -- ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] FAT32 CHS boot sector problems since we introduced FAT32 LBA support?
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/kernel/trunk/boot/boot.asm > Left-bound text is about LBA or FAT1x code, while > indented text is about FAT32 CHS in this email. Some items are at different places but hopefully (?) do not get overwritten: > boot32lb: fat_secshift [selfmodifying] > fat_sector@+0x44 fat_start@+0x48 data_start@+0x4c > boot32: fat_secshift@+0x68, CHS boot sector > fat_sector@+0x48 fat_start@+0x5e data_start@+0x62 fat_secmask@+0x66 The initial calculations seem to achieve the same in different ways: > fat_sector = dd 0 > done much later in CHS case, but early enough as far as I can tell > fat_start = data_start = dd nHidden + word bsResSectors > di:si and fat_start okay, check data_start > data_start += dd (byte followed by 2 dw 0?) [bsFATs] *signed dd [xsectPerFat] > ax = db bsFATs cbw > di += ax * dw xsectPerFat HIGH, ignoring overflows > data_start = dx:ax = di:si + (ax * dw xsectPerFat LOW), 16x16=32 bit However, the "secshift" calculations are rather different here... Note that the FAT12 / FAT16 boot sector reads the entire FAT into RAM first, so THAT does not have to know which sector of the FAT contains info about which cluster. > fat_secshift = 7 for 128 FAT items per 512 byte sector > ax = 512 > while ax not bsBytesPerSec > ax <<= 1 > fat_secshift++ > endwhile > cx = fat_secmask = (dw bsBytesPerSec >> 2) - 1 > cx++, now (dw bsBytesPerSec >> 2) which is FAT items per sector > ax expected to be 0 after movsw > do > ax++ > cx >>= 1 > while cx not 1 > fat_secshift = AL, low byte of ax > fat_sector LOW = fat_sector HIGH = cx-- (is 0 now) Mixed other differences which might be relevant: > only boot32lb uses 386+ code and calls print which modifies AX BX SI > convert_cluster: cmp eax,fff fff8 jnc EOF > convert_cluster: cmp dx,fff jnz okay cmp ax,fff8 jnc EOF? > > next_cluster uses shr dx,1 rcr ax,1 in a loop to shr DX:AX by fat_secshift > ... ((di and secmask) << 2) + fat_start ... And from the comparison FAT32 CHS to FAT12 / FAT16 boot code: > note: FAT12 / FAT16 boot sector readDisk changes CX, ADD COMMENT HERE! > note: FAT1x boot does not retry in readDisk, plus used extra buffers > "inc ah or cl,ah" versus "or cl,ah inc cx" for 1-based sector The next_cluster, convert_cluster and readDisk calls all juggle with plenty of registers in strictly defined ways, I might have overlooked some unintended register changes somewhere. Cheers, Eric -- ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] FAT32 CHS boot sector problems since we introduced FAT32 LBA support?
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 lacks LBA support. After installing MBR-based disk drivers to add LBA support and support for 4 instead of 2 harddisks, FreeDOS boots fine with modern FAT32 LBA boot sectors. Before that, he had to use ancient CHS-only-for-FAT32 SYS to get a working boot sector. I was busy trying to find out what broke and when, but cannot find it. Maybe you can help me out here... :-) - old SYS sets drive number to -1 but it gets overwritten on boot anyway - new SYS sets drive number to 0x80 but it gets overwritten on boot, too - new SYS uses signed byte to word comparison in cluster code (fff fff8 versus fff -8) but source code is unchanged, maybe a NASM auto tune?) - r751 moves the load location far pointer to inside the code, while it was at +5a in the variable area before. Not sure why that was changed? Apparently both good and bad are AFTER this diff, so that should be safe? The r321 to r343 patch makes CHS calculations small but obscure: > https://sf.net/p/freedos/svn/343/tree//kernel/trunk/boot/boot32.asm?diff=321 This leaves the main "calculate parameters at runtime, instead of using SYS to hardcode them" patch as suspicious change. We have this patch to keep FAT32 partitions bootable even when you resize them with 3rd party tools. Of course the patch adds yet more obscure code to the boot sect: > https://sf.net/p/freedos/svn/652/tree//kernel/trunk/boot/boot32.asm?diff=382 Note that this r382 to r652 patch also drops the last call of "print", so we could drop that function to gain some space for making the code a bit less unreadable by "un-optimizing" some bits. Apparently somebody simply forgot to drop print after dropping the last place using it ;-) Not sure why, but the patch also moves around the offsets of 4 variables by 4 bytes each: fat_start, data_start, fat_secmask, fat_secshift, which makes the before / after the patch situation a bit harder to "diff" now. The basic function of the patch is to add some code after the setup of stack, segments and registers and relocation to 1FE0:, but before the first call to "find sector for cluster" and "read sector from disk" after which the root directory is scanned and, when a kernel is found, the kernel file is loaded by cluster chain: dword fat start [+5E] = DI:SI = dword hidden [+1c] + word reserved [+0e] DI = DI + (byte fats [+10] * word sec per fat HIGH [+26]) [+62] = DX:AX = (byte fats [+10] * word sec per fat LOW [+24]) + DI:SI word sec mask [+66] = CX ... = (AX >> 2) - 1 AX = 1 ... do CX >>= 1 AX++ while CX not 1 byte sec shift [+68] = AL (the above is my attempt to summarize what the code actually does, see the source code for the description of what it wants to do - as said, I fail to see a problem here, but the symptom still is a failed boot!) Thanks for helping out! Cheers, Eric PS: Of course the boot sector stores DL to byte drive [+40] before it starts juggling with DX:AX, so that value seems to be safe as well. -- ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] UMB question
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 such that the kernel supports SEVERAL providers of UMB at the same time, for example UMBPCI for hardware-UMB and in addition EMM386 to "map" a few more UMB to areas where normally a memory gap would be, such as the "monochrome video memory" area? Might be interesting to have even more UMB flexibility :-) Regards, Eric -- Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San Francisco, CA to explore cutting-edge tech and listen to tech luminaries present their vision of the future. This family event has something for everyone, including kids. Get more information and register today. http://sdm.link/attshape ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] EXT3 support
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 to boot Linux, and it can use any diskimage accessible by such boot loaders, including an image on EXT3 disks. Boot loaders either pre-compute a list of sectors to read files or load extra driver modules, which only have to support reading and which are not kept in RAM. Regarding the idea to have the kernel "natively boot from a RAMDISK in HIGH MEMORY which would NOT be A: or C: ... Well, on modern computers it should not be a problem to "hog" the drive letter of the A: floppy drive - you probably have at most ONE real floppy next to that ramdisk anyway and letter B: is still free :-) So in that sense, MEMDISK is ok for me. A ramdisk is often very small in RAM, so I think the benefit of compiling one into the kernel would be small compared to simply using pre-existing 3rd party ramdisks like MEMDISK. However, for the fans of really tiny settings, have a look at: http://www.rayer.g6.cz/romos/romose.htm This project features a "bios" version of the FreeDOS kernel, by booting the kernel from a 63 kB virtual floppy. The module including the floppy takes 64 kB in the option ROM area, so you could compare it to booting FreeDOS from UMB ramdisk ;-) In totally unrelated notes, I think it would be cool if the FreeDOS kernel could parse GPT PARTITION TABLES and find FAT partitions in them. And I think it might be interesting to be able to read files from the root dir of ISO9660 media if I/O is provided by BIOS ElTorito calls: That way, the kernel could load config sys and a CD/DVD driver after some special boot sector has loaded the kernel directly from CD/DVD :-) Cheers, Eric PS: I admit that the last idea is similar to having read-only EXT3 support in the kernel, but I believe ISO takes << 10 kB. -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] removing functions?
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 there is no one size fits all answer to your question. If you can make a list of the things you want to remove, then people on this list could tell you how much size difference it would make and how bad of a hack removing those functions would be :-) Note that you do not want to spend much effort for this: Most users have much bigger disks and with DOS extenders and already by simply having DOS=HIGH in the HMA, kernel size is not an issue anyway. Also, the FreeDOS kernel is designed to be nice and small compared to the big feature set... :-) Regards, Eric -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Any interest in 486, 586, 686 kernels?
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 architecture. Hard to say. Well there could, but why would it matter? More heavy DOS software normally uses DOS extenders / DPMI anyway, which means it does not care about how much low DOS RAM is free. The HMA is mostly used for the kernel and buffers, so as long as the kernel fits in there, no others have a heavy need for it. Only a few drivers may use it UMB style. Also, caches put bigger buffers in XMS, not needing HMA. Finally UMB is mostly used for drivers: You could write drivers that use DOS extenders / DPMI if you really have a lack of space. Actually the simulation of SoundBlaster 16 that comes with SoundBlaster PCI works like that. Probably also some commercial NTFS drivers, because NTFS is complex and you do not want to spend 100s of kilobytes of DOS memory only for loading a filesystem driver... USB, PXE and CD/DVD/BD drivers as drivers / in memdisk: I lean this way too w/respect to drivers. Built-in's biggest advantage is You still have to configure built-in drivers, you only avoid the risk that you forget to include the file in your boot disk ;-) simplicity in user configuration. However, networking seems to be lacking throughput speed with either mTCP or Watt32 apps. I'm not sure if it's a packet driver, TCP/IP stack, app (doubt), or kernel (doubt) issue. Networking in DOS means that your app has a compiled-in network stack which communicates with a packet driver to get the low-level hardware stuff done. You often have a small buffer for that and little concurrency. There may be a bit of IRQ and DMA, but big operating systems are more relaxed about juggling with multiple streams of net data with support from complex chips on your network card. Note that this is just an educated guess: Ask our experts! guess is that it's a 16-bit MOV/LD* loops, the lack of zero-copy networking, and the switch between kernel and app. I've seen some No switch: The kernel does not network at all and there is only one app at a time using the network. Depending on how your packet driver and network stack library work, you do not need many steps of copying either and the transfer to or from a buffer is unlikely to be a big bottleneck with modern CPU, I think. However, as said, you probably work with little bits of data and small buffers in DOS, because you may have less orchestration between stack and driver. reference to the same ... USB drivers as well (USB 1.1 speed from USB 2.0 devices or 3.0 devices). And there seems to be 3 ways to get USB That problem far much more trivial than you might think: USB 2 and 3 are controlled in ways that differ a lot from USB 1, so many drivers simply do not talk USB 2 or 3 at all. This is not like AGP, PCI or PCIe where you flip a few bits and suddenly I/O to your graphics card is fast. It is more like the difference between paged graphics at a000:0 and a linear framebuffer, to stay in the example. However, there is no linear USB. Talking USB the 2 or 3 way is just a quite different language, but as you know, at least one shareware driver speaks it and knows the dialect of at least some relatively widespread chips... working on DOS: USBDOS, DOSUSB, Panasonic/ASPI Method. I need to play Enjoy :-) And maybe do some benchmarks. Even the shareware driver should work long enough for that - I think it just blocks after a while after each boot, but is not locked in terms of how many days or years you have it installed. On the other hand, I think it would be an interesting experiment to have a kernel which can load files from at least the root dir of ISO9660 or UDF disks and similar (ext2? ntfs?) and which can directly interpret GPT partition tables... Yes! I agree! The FD Kernel needs to speak MBR, GPT, ISO9660 UDF (including El Torito), NTFS, Ext2/3/4 to stay relevant. Probably HFS+ as well. Linux and/or FUSE should be helpful here. Uhm no. You do not agree ;-) Yes the kernel should speak both MBR and GPT. Something about 4k sector size is also a good idea. However, El Torito is only so-so as CD/DVD/BD driver and Jack's drivers are probably better. It would be fun from an academic point of view to have ElTorito-ISO9660-GPT in a kernel, but even Linux works great with kernels-without-any- disk-drivers when you put the drivers in the boot-ramdisk to load them as separate files from there. DOS with MEMDISK is basically the same. Having (separately loaded) drivers for ISO9660 (we do, even with long file name support) and UDF (only experimental and abandoned??) is indeed important for DOS. Also, somebody may want to undust the old EXT2 semi-drivers called LTOOLS, they probably still have some sort of ancient limitation such as lacking LBA support or getting
Re: [Freedos-kernel] Any interest in 486, 586, 686 kernels?
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 remember, the performance gain was minimal, but consider interest in terms of style to consider a protected mode kernel which has both DPMI and VM86 visibility. It would be a sort of DOSBOX then. Regarding built-in networking and USB, I am personally more for the existing loadable driver model. The BIOS gives you enough support to reach the point where you can load drivers in config sys. Even when booting via network (PXE) or from CD/DVD/BD, you can still use a MEMDISK (bootable ramdisk) to get started... On the other hand, I think it would be an interesting experiment to have a kernel which can load files from at least the root dir of ISO9660 or UDF disks and similar (ext2? ntfs?) and which can directly interpret GPT partition tables. The latter would have significant practical use. Not the former: When you boot from CD/DVD/BD, you do typically want a writeable ramdisk anyway, so you can just as well boot with the help of a MEMDISK which lets you load DOS CD/... drivers from there, making drivers for that as fixed parts of the kernel less interesting. Also, they are harder to update than separate drivers and you cannot easily skip them at boot to save DOS memory. Good question whether you want built-in USB: I would say no, you already need the BIOS to help to boot from USB. After that, you want a modular system of USB drivers (unless the BIOS provides support for all relevant USB devices) to let you access disks, sticks, mice, keyboards and so on. Also, devices for which there is no popular DOS or BIOS interface, such as network or sound, cannot have kernel drivers in a useful way. For networking, the packet driver interface is just one facet in a complex world, we could think about some additions to make it easier to write new drivers or to do common things with the network. For sound, the lack of popular interfaces means that you basically have to use protected mode to simulate a popular HARDWARE (SoundBlaster etc) and then let your actual driver play whatever the soundblaster would have played given the detected I/O with the simulation. 64-bit support, device driver imports, automated regression testing. Some automated or semi-automatic quality checks seem interesting. One could think of code style checks, audits, automated comparison of how well different artificial test cases or real software runs work with different kernel (micro-) versions in some VM etcetera. Regarding 64 bit support, there are some experiments with letting DPMI drivers use more than 4 GB of RAM. To make better use of it, you would have to define new interfaces (XMS, EMS, DPMI, VCPI...) and hope that DOS software would be written which uses them. Just using 32- or 64-bit calculations (not RAM addresses) is another story: Probably the kernel can be smaller by using more 32-bit calc but not really faster. Using memcopy optimized for more modern CPU (32, 64, 128, ... bit, FPU, MMX, SSE, ...) will also not make a real difference, as the DOS kernel itself does not move a lot of data. In short, there are certainly points in which DOS can be extended, but I personally doubt that many or even any of them should start in the kernel. Separate drivers and other software fit better. Maybe we should discuss the roadmap again in the first place? Regards, Eric -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] [Freedos-user] FreeDOS Boot Disc
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 latter you have to download things first. On the other hand, I think Jeremy once had some sort of automated builds with always fresh kernels online? For people like Georg who need just a minimal bootable DOS this would be a good source of boot floppy images. Kernel on that image uses 386+ instructions... and it seems as if it does that without (properly) checking for the presence of a 386. That is correct, as a kernel cannot be both optimized for 386 and compatible with 8086 at the same time. We had some specifically PC-XT compatible boot floppies mentioned on the list in the past, e.g. by somebody who made a virtual PC-XT in Java if I remember right? That it's a 386+ kernel is just an oversight (or should be documented for the image), but if 386+ kernels really do not abort with an appropriate message on non-386 CPUs, that's a bug. I disagree here. Without a kernel, you cannot do any useful DOS stuff. However, I once made some tools for Bernd to have a boot disk which automatically picks boot files depending on your available CPU, as far as I remember also related to MEMDISK detection? You CAN make a NON minimal boot disk which automatically can fall back to 8086 that way. However it is VERY rare to find pre-386 hardware today, so I would really say that it is better to have separate downloads: Normal boot floppy for 386+ and special 8086 compatible boot floppy for people with really ancient hardware (or a virtual ancient computer, as the one mentioned above). Of course it is a different story for EMM386, HIMEM, USB drivers and similar: THOSE can automatically say that they cannot load on incompatible hardware, then return to DOS. Users can still use DOS then and sure it is nice to not crash on old hardware but show some message. But a kernel? It cannot skip itself and jump to a command prompt with only the 8086 part loaded ;-) The file kernel.asm (SVN r1705) is this one: http://freedos.svn.sourceforge.net/viewvc/freedos/kernel/trunk/kernel/kernel.asm?revision=1705view=markup Note lines 194 to 196, where precisely in this latest r1705, Kenneth added the comment TODO display error if built for 386 running on 8086 etc. Well if it really makes you happy... Note that also a number of boot loaders only work with 386 anyway now. Regards, Eric -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] [Freedos-user] Virtual floppy change problem and slow VirtualBox UIDE2 init problem
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, somebody said that the numbering of FAT filesystem exists, among other reasons, to help DOS detect floppy changes even if there is no change line available. As you know, int 13.15 can even report that a floppy has no change line at all. MS DOS might, on top of that, have a list of BIOS versions with weak change lines? Related kernel sources: init_readdasd, make_ddt, maybe also DosDefinePartition. Apparently FreeDOS has drive types hard- disk, floppy with change line, and other here... Int 13.16 which actually queries the change line can return invalid command, drive not ready / not present, no change or change line active or not supported. NOTE that calling the check also clears the status, so only ONE caller will notice each change and only ONCE! Lbacache takes special care here. Related kernel sources: FL_DISKCHANGED, fl_diskchanged, floppy_change, mediachk, diskchange... If you have NO change line, diskchange returns not changed if you very recently accessed the disk, and unknown otherwise, I believe?) For M_DONT_KNOW, mediachk returns disk changed iff the serial of the filesystem changed compared to the current DDT info. Finally, media_check is described to trigger on unknown, changed or definitely changed. It does setinvld and calls the D_BLDBPB block device driver function and converts the BPB to DPB then. Note that int 21.7302 get ext dpb calls flush_buffers, flags a fake disk change, calls media_check. DosGetFree can behave similarily depending on arguments... Maybe update_dcb is also related. I think D_BLDBPB is done by rqblockio and the bldbpb function and getbpb, which also calls RWzero to re-read the boot sector? As you see, a very long chain of events exists around all DOS block device related things, but that is necessary to be fully compatible with MS DOS... You also see that I did NOT mention calls to int 13.0 disk reset here - I have not seen any (apart from fl_reset / FL_RESET calls in reaction to I/O errors deeper in the RWzero chained LBA_Transfer). I agree that it is nice to disable floppy caches, but maybe the kernel actually does something detectable in REACTION to detecting a floppy change? For example it might issue an Int 13h drive reset command which in turn can be caught by the UIDE2 driver and treated as a flush cache for THAT drive event? ... What do you mean maybe?? You and others are the kernel experts for FreeDOS, not me, as I still run V6.22 MS-DOS!! As you see above, handling of floppies and their changes is a complicated thing which is not easy to walk through, even for me :-) Also, I say again that I am NOT interested in any specific logic from the MS-DOS kernel, or the FreeDOS kernel, or in fact ANY kernel, for detecting diskette changes. My worry is that such logic may NOT be generic, and I want... As far as I can tell, you could make int 13.0 (disk reset) and reads of the boot sector flush events. That might flush a bit more often than necessary, but at least not LESS often than necessary, assuming that you ALSO trap int 13.16 return values already and trigger flushes when you see change line activity :-) UIDE2 to run on all DOS systems. Checking the BIOS media- change status has always worked in my drivers for diskettes See above - if you ACTIVELY call int 13.16, you could hide the floppy change from DOS because int 13.16 returns changed status only for the first call after a disk change even with working change lines... Finally, as noted before in this forum, UIDE and UIDE2 make NO run-time DOS system calls and I also want to keep THAT I agree that it is good to not call DOS in a DISK cache and actually it should not be necessary to call DOS either :-) Note that things might be different for block device based caches instead of BIOS / hardware based caches like ours... By the way, any chance to work around the VirtualBox huge-delay problem? Not without knowing WHY they take such a huge delay! In any case, UIDE and UIDE2 must scan for PCI-bus devices... If I understand your code correctly, you scan all 256 bus, 32 device and 8 function locations which can be expressed, using the BIOS. You could save a lot of time by scanning only those bus numbers that are used and not scanning sub functions for devices that are installed at all. It also is a lot faster to use mechanism #1 port I/O and not call the BIOS for each access, but you might be using the BIOS deliberately to also support ancient mechanism #2 boards? If the VirtualBox people cannot fix the huge delay... I think UIDE2 now takes 2-3 minutes on VirtualBox when that uses a virtual PIIX3 chipset, so if you really do a scan of all locations, scanning only those locations where a
Re: [Freedos-kernel] Commit 1705
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.
For the VERY exotic case that you have a bootdisk which
boots from memdisk on 386 and without on older 386, if
you can still find any... And the exotic case where the
two styles of booting still share the same config sys?
Right until someone does a append FD={INSTALL=FORMAT C: /Z:SERIOUSLY}
You might want to use a login to protect advanced boot
menu options. However, if people can boot DOS from a
memdisk - I assume this is NOT now they boot from C:!
then they can just boot ANYTHING from another portable
boot drive and whether they can mess up how your DOS
portable boot drive acts is a relatively small worry.
Having 2041 out when maintainers had time for it relieves them from
pressure for implementing stuff and releasing new versions.
I do not understand... Anyway, here is what RayeR says:
posted by RayeR(R) Homepage, CZ, 19.02.2012, 17:39
Thx for notification. Let's see what's new:
2012 Feb 07 - Build 2041
Jeremy Davis
+ Changes Jeremy
* r1637 fix out of range byte in country.asm
* r1685 add int 2f subfunc 122B and 122D from Eduardo Casino
* r1697 from Pete Batard, do not display CHS mismatch warning
during booting when forcing LBA mode option set
* r1702 improve handling for sectors not 512 bytes in size
(up to 2048 bytes, larger sizes not yet working)
* r1705 add cpu detection so memdisk args supported in 8086 build
Seems like minor changes except the support for 2048 sectors?
Where is it used? I know that CDROM use 2kB sectores but it was
handled by driver for a long time. I also read that some new HDDs
have 4kB sectors but AFAIK they still emulate 512B sectors for system.
---
DOS gives me freedom to unlimited HW access.
--
Virtualization Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re : Support for 4k byte
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 earlier 4 kB related mail: I stumbled upon a couple pages that say otherwise : the industry has agreed to sell AF disks only *until the end of 2014*! It was actually you yourself who said that on 25 Jan 2012 ;-) AF = Advanced Format = 4096 byte per sector, i.e. Advanced meaning if you find 512 byte better, you are not modern :-p It is a bit like APS Advanced Photo System - a nice buzzword for a strange idea that is made look good for the end user. Also, advanced format lets more data share less ECC error correction data, squeezing out a tiny bit of extra capacity and a bit of extra resistance to data errors... Wikipedia claims that Windows Vista, 7 and 2008 have hotfixes for drives with natively larger sectors which allow access in 512 byte emulated sectors - in other words, the hotfix is just fixing the performance loss caused by not knowing that the underlying hardware sectors are big - while those Windows versions apparently do NOT support native big sectors yet, at least not for the boot drive... Reference for this: http://support.microsoft.com/kb/2510009 In other words, Windows Vista / 7 / 2008 makes sure to always access aligned blocks of 8 sectors of 512 bytes together, to improve performance, when it knows that the physical disk has 4 kB sector size but uses 512 byte per sector I/O protocols. That is very vaguely similar to what LBACACHE TICKLE and other read-ahead tools can do for you, if configured properly... ;-) Manufacturers have no interest to reverting to 512 bytes sectors - since 4K sects allows them to advertise higher capacities No. As Tom said, large sectors are only a workaround for WinXP and similar MBR partitioned operating systems. With GPT, you have no relevant limit to the number of sectors any more and sectors can be small again :-) On the other hand, everything is pretty virtual today anyway, and SSD / flash have better performance with access in larger blocks, but that does not mean that block has to equal sector. It could also equal cluster and FORMAT already supports making clusters of 4 kB or bigger align with 4 kB boundaries... ;-) The virtuality will also mean that you eventually have to load a PC BIOS interrupts legacy API module for EFI BIOSes. Luckily those also exist as open source, if vendors get lazy. Eric PS: As you say you read this on freedos-kernel, but are only on freedos-user (where you mailed) I took the freedom to CC both. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Commit 1705
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 think it's necessary to use the field in an incompatible manner, and neither is the new 21.33 I totally agree. Reporting 386 versus older is more compatible and good enough. Only in rare cases when you want to know exactly, you would have to fall back to a tool such as CPULEVEL, but for a kernel flag, 32 bit CPU is exact enough information :-) subfunction that the commit adds, because no one uses it yet. Even so, You do not need an unused API function to read a rarely read field because the very few tools interested in the field can read LoL :-) the subfunction does not require using that particular field to store the detected CPU level. Even that... And by the way, I agree with Tom that flexible sector sizes are a bit shaky and the default compile should use 512 byte. However, a CONFIG.SYS option to modify the max sector size at boot would be a good compromise between hardcoding this at compile time and spending code and effort on automatic sizing at boot initdisk. Eric -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Regarding commit 1702 (large sector sizes)
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 sectors are a temporary thing, will be gone with GPT partitions. For the same reason, I suggest to NOT put efforts into incompatible put 8 small sectors in each 4k buffer on mixed sector size computers BUFFERS code of any sorts. Note that larger caches already do put multiple sectors in one slot, but for other reasons and without mixing. BUFFERS=COUNT#,READAHEAD#,SECTORSIZE# or would it be better to add a whole new command MAXSECSIZE=SECTORSIZE# ? (the latter seems simpler so the one I will plan on for now). MAXSECSIZE will be fine, thanks :-) And really useful. Changeable drives are en vogue, so figuring out needed sector sizes at boot time is not always useful, and it is probably a lot of work as well... For my personal taste, a MAXSECSIZE, with a default of 512, would be a good small-amount-of-code way of having enough large sector support for those who need it. When you encounter a drive/partition with unsuitable sector sizes for the current settings, skip it with a message. agreed, though currently any value 3KB causes memory corruption evil again... you said you already have an idea to debug? I don't see us using max sector size 512, but using tdsk with smaller than 512 sector size does seem to work - though at this The last time when we discussed OTHER sector sizes on the lists, it was exactly for that reason - small RAMDISKS with small sectors and less fragmentation at the expense of slightly larger FATs. So I do think it would be useful to support BUT only with sectors of at least 64 bytes size (FAT32: 128, although without FSINFO). I suggest to NOT spend any code for BPB wraps sectors or such: sectors below 128 bytes are just way too exotic and support for dir entry sized micro sectors is more a theoretical exercise. Fun extra exercise: Make a bootable FAT12/16/32 sector with 128 bytes per sector, loading a 2nd stage loader (reserved sectors). Then construct a drive and BIOS for such drives, or ROM/MEMDISK. Regards, Eric -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] [Freedos-user] Re : Support for 4k byte sectors
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 sizes above 512 bytes (e.g. 1024 and 2048), each element in BUFFERS and the DiskTransferBuffer would have to be bigger. Are there DOS versions which support big sectors? How do they solve the buffering problem? I think sector sizes below 64 bytes cannot contain enough of a BPB to be useful. Sector sizes below 32 bytes are definitely not useful, not even a single dirent fits in them. Sector sizes above 512 bytes are at most useful for the 1024 byte (far-east 1.2 MB diskette format / drives which support full 64 MB of a single XMS2 handle as ramdisk without having to support the DOS3.x+ 32bit sector number calls) and 2048 byte (raw sector size on CD-ROM and maybe on magneto-optical drives) cases. Comments about useful sector sizes would be welcome: Smaller (64, 128, 256), normal 512, Bigger (1024, 2048, others). Next part: I believe that the BIOS / kernel drives (diskette, harddisk) only have to handle 512 bytes per sector. Otherwise, you would have to adjust: CalculateFATData, DosDefinePartitions, the kernel driver IOCTLS (e.g. format track), LBA_Transfer, max_transfer (the DMA wrap checker) and maybe floppy_bpb (and -_bpbs). In case you have wondered, directory handling already reads the current sector size from the BPB, so it is flexible. If you want drives with bigger sectors to be detected at boot time, you not only have to get BUFFERs and DiskTransferBuffer bigger and adjust _maxbksize (in the global SDA data structure, which is, by the way, not yet read by FreeDOS itself, as only 512 bytes per sector are supported anyway) but you also have to make InitDiskTransferBuffer bigger as well. For boot purposes you just have to make SYS able to pad unused parts of the boot sector to allow bigger sector sizes - BUT you also have to make SYS able to adjust the boot sector code to that, I remember that not all our boot sectors actually used the BPB bytes-per-sector value (there was not enough space to process it). Smaller sector sizes are simply too small to be bootable anyway. I wonder if you should be able to boot from nonstandard sector sizes at all - for example a CD- ROM does not even have a FAT filesystem, so why would you boot from a (raw!) CD-ROM then? So I suggest to support nonstandard sector sizes ONLY for drives which are connected to separate drivers (e.g. ramdisks, USB drives, ZIP...). To make that possible, BUFFERS and DiskTransferBuffer handling would have to get better (even for smaller sectors - for bigger sectors, the BUFFERS and DiskTransferBuffers themselves, being only _maxbksize big, will be the problem). In addition, getbpb and dskxfer (THE central send/receive a sector to/ from a device driver function) have to be made independent from the hardcoded SEC_SIZE. Instead, they have to use the sector size from the BPB of the drive. Hint: getbpb assumes that the boot sector magic word is at offsets 1fe and 1ff. This IMPLIES a sector size of 512 bytes, too. The GOOD part is that FreeDOS hardly uses anything else than getbpb and dskxfer to communicate disk contents (for which it uses BUFFERS and DiskTransferBuffer as intermediate storage places). rqblockio does call block device drivers directly, too, but not to access sectors, for example, and the other functions all use dskxfer or getbpb directly or indirectly. I hope I have not overlooked things in this review... Summary: - To support bigger sectors, raise _maxbksize and make each element of BUFFERS and DiskTransferBuffer bigger - To support nonstandard sector sizes at boot time, CalculateFATData, InitDiskTransferBuffer and DosDefinePartitions have to be modified - To support nonstandard sector sizes for harddisk / diskette (kernel built-in drivers), you have to adjust the IOCTLs (format track...), LBA_Transfer and max_transfer - To support nonstandard sector sizes at all, you have to modify dskxfer and getbpb and the BUFFERS and DiskTransferBuffer handling has to accept sectors in other sizes than SEC_SIZE, including e.g. sectors which are smaller than _maxbksize... - SYS and boot sectors can only support bigger, not smaller, sector sizes, and SYS might have to do extra patching for those of the boot sectors which do not actually use the boot sector BPB sector size info We should probably start by using _maxbksize in BUFFERS and either only DiskTransferBuffer or both DiskTransferBuffer and InitDiskTransferBuffer to get things a bit clearer... Then we should make SYS and boot sectors able to support bigger sector sizes (not because it is really useful but because this part is more self-contained / easier to maintain than the rest of the kernel). Then the first WORKING support for nonstandard sector sizes can be added by
Re: [Freedos-kernel] [Freedos-user] Re : Support for 4k byte sectors
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 sizes ONLY for drives which are connected to separate drivers (e.g. ramdisks, USB drives, ZIP...). To make that possible... For my current taste, this also implies that we do not NEED any support for sectors ABOVE 512 bytes. It makes memory footprints of buffers etc larger and we would only support 4096 byte sector size for non-boot disks for the moment anyway, where an EXTERNAL (not in the kernel but loaded in config.sys) block device driver could easily map things into a virtual 512 byte sector size. Of course in general, it is nice to be flexible. And some users of ramdisks and romdisks would be happy about support for some SMALLER sector sizes. As for the LARGER than 512 byte sectors, I would really like a CACHE based solution to make access more large block oriented. Maybe including write pooling. SSDs and USB flash sticks would be happy about 4 kB, 32 kB or even more minimum write sizes, of course also with block-aligned writes. I do NOT recommend a full delayed write cache: It is a lot of work to make sure that writes always go to disk before you do something stupid (reboot, crash, change disks) and you already gain a lot of performance with a SMALL pooling buffer IMHO. I have a few other things in my todo queue but once done I will look further into this. I would like to add support for GPT disks first, which I think will be much simpler and I can test... I totally agree and as you see in my mail from a few hours ago, GPT is not hard to implement as long as you only care about FAT. I have a little bit of time off in February so maybe I can make significant progress then. Maybe a strange off-topic, but I have some time off this spring, but instead of programming, I wanted to visit some FreeDOS people in western Europe :-) If you are interested, contact me off-list. Regards, Eric -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] possible to disable initdisk?
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 by the kernel when it loads but only after the DOS USB driver stack is loaded. You can hook int 13 function 8 (get drive parameters) and make sure that for dl = 80 or higher, it always returns carry set and dl = 0 to pretend having no harddisks. Of course DOS does a lot of work for you to parse partitions, so it is a bit odd to pretend you have none only to do that again manually later. To that end there seem to be 2 options: 1) /memdisk initrd=floppy.img pause followed by removing USB disk and pressing a key to continue. Later on, insert again. You could also do the above and/or temporarily make int 13 access to all harddisks behave as if all disks are empty bit buckets. I hope you will not try to format later ;-) 2) keep kernel disk scanning/enumerating code intact but don't execute it for drive 0x80 and up, at startup at least. This way the drivers can be loaded, set interface to max supported speed, recognise devices, and get a driveletter assigned (C: likely) See above. You can do it with a relatively simply int 13 fake. Is the kernel designed to allow such a specific scenario #2 ? There is no built-in function in the kernel, although you can SYS CONFIG the lba support away and hide your partitions after the first 1024 cylinders. Later, when you load USB drivers to do the processing on DOS block device level, you can get along completely without int 13 CHS / LBA access anyway, depending on what style of USB drivers you use, I guess. Again, in this scenario, the USB driver will have to do all partition table (MBR, chain of extra partitions) processing itself because DOS and int 13 itself has not int 13 disk hot-plugging. Luckily it is okay for DOS to have many drive letters managed by 1 driver. It's very un-DOS-like to delay giving out driveletters. Initdisk.c seems to suggest scanning can be disabled [SCAN_PRIMARY], but I guess that's a permanent option instead of only for boot-time. The scan constants are only for doing some things in some passes of scanning the partition table and other things in other, with some things being skipped then. It is not about skipping disks. Eric :-) -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] [Freedos-user] Kernel 2040 16-bit
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 32bit kernels, there's a FreeDOS32 project somewhere but that hasn't gotten very far yet. The 16 and 32 for FreeDOS kernels purely indicate what they support: * either FAT12 and FAT16 filesystems * or FAT12 and FAT16, but also FAT32 filesystems Actually there are at least FOUR types of kernel that you can compile with FreeDOS, so to avoid some misunderstandings: - the kernel supports different types of FAT, but you can omit FAT32 support to get a smaller kernel. All kernels support FAT12 and FAT16, however. - the kernel can be compiled for 386 or newer CPU, which makes it a bit smaller and faster. Classic kernels can run even on 8086, if you can still find a PC-XT or so. So the good question is of course: Which of the kernels are giving you filesystem troubles on which of the FAT types? You can test FAT12 on a floppy, for the others you should use a harddisk (USB stick often possible but likely to be slow and/or might need drivers). You can also test everything in a virtual PC simulating disks. Of course if your problem only affects FAT32 partitions, you will not even be able to access them using a -16 kernel because 16 in the kernel name means FAT32 support not included... If your problem only affects FAT16 and/or FAT12 partitions, but only with kernels which do support FAT32 then it is likely that the FAT32 module interferes with FAT12/FAT16 handling or detection... Interestingly, kernel 2040 claims to FIX a bug of that sort which seems to affect 2039 but as far as I understand not 2038? :-) If your problem only affects 386 kernels, then maybe at some point 32 bit registers are not preserved nicely while calling some driver, for example. A kernel which only does 16 bit calculations would not be hurt by that. Note that only the calculations are 32 bit: In FreeDOS32, even the pointers are (not 16+16 but really 32) while in normal FreeDOS, the kernel will only use the first 1.1 MB of your memory. In BOTH versions, applications can use so called DOS Extenders to use 32 bit pointers to application data. Good examples are all applications compiled by DJGPP (GNU C/C++ for DOS), freebasic or freepascal and many old games which use DOS4GW or similar... The latter should be replaced (drop-in) by DOS32A on modern machines, you can just rename the exe and copy one over the other for that. DOS applications with 32 bit pointers can use up to 3 GB of RAM for sure, sometimes closer to 3 GB and sometimes closer to 4 GB depending on how much PCIe or PCI or AGP graphics card RAM you have and how much the BIOS uses in ACPI and similar ways. As DOS itself only uses the first 1.1 MB, you can have almost all your RAM for your apps :-) Latest FreeDOS CHKDSK is 0.92 ( http://users.telenet.be/imre/FreeDOS/ckdsk092.zip ). You can also compare DOSFSCK (dosdosfsck-2.11c.zip) which you run simply as dosfsck -v c: for a verbose check. It also has options for repair, surface scan and more. One very interesting setting is -r -v -V which will ask you how to repair things, then SIMULATE the repair and then ask you whether you want changes to be actually written to disk, after checking the simulated filesystem first. Regards, Eric -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on Lean Startup Secrets Revealed. This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel 2040 released
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 that the hack to go above 4 GB file size? Evil... on what hardware to produce these results Almost documented: ATA-33 and XDMA UDMA, probably. does not specify which int21 functions Block size 56 KiB | AH=$3F AH=$40 ??? http://www.ctyme.com/intr/rb-2783.htm Hadn't known there would be more ... Better use a multiple of cluster size and a power of 2. 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.) Not yet tested the sparse hack ... my bad :-( I hope it helps :-) Eric -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security 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 https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] USB-HDD booting and LBA-to-CHS conversion
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. However, FORCELBA should help you to boot from USB flash drives where the geometry is sometimes ambiguous because they do not actually have any :-) But 8 MB is very small even for DOS, I would suggest 50 MB or even 250 MB: Gives you some space to play with DOS and is not really a noticeable loss for other OSes anyway. You could use e.g. GPARTED (from a boot CD/DVD/USB maybe) to resize partitions but make sure to fully shut down other operating systems first - do not resize while a system is just hibernating. The pendrive partiton is type 0c. I also tried MSDOS 7.1 from a Grub4dos-mapped floppy image and it recognizes the pendrive, So if I understand correctly, grub4dos and the floppy image are also on the USb stick from which you boot? I somehow do wonder what is D: then - the last-8-MB harddisk partition? Or something on the stick? Is the floppy image A: and the rest of the stick C:? Then you could boot from the bulk of the stick instead, without a floppy image, using grub4dos or syslinux or similar. dir d:\ returns the correct list. I uploaded the 1st MB of the partition in case anyone is interested. http://www.box.net/shared/56e5ojjvhx7i2n6tkgr3 The first MB of the partition on the stick? On harddisk? Regards, Eric -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security 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 https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel 2040 released
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 and foolproof. - close the file - open file for writing (no truncate) I would suggest not to close and re-open the file. If it does improve the operation's performance, then just committing the file should improve it in the same way. If performance isn't improved by it, the close and re-open sequence can be removed without replacement. Same reason as above. Also, there is a small chance that some implementations of commit are weaker than a full close / open. So I went for the more explicit and possibly safer style here. In any case, the performance penalty of close and re-open in a situation where pre-growing fails to help is very neglible. Eric -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security 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 https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel 2040 released
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 increase performance significantly :-) Eric PS: You could also compare EDRDOS+UIDE with FreeDOS+UIDE. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security 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 https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] USB-HDD booting and LBA-to-CHS conversion
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 to make it use only LBA. FreeDOS assumes the correct partition beginning is in CHS from disk, converts it to LBA and back to CHS using the BIOS values. What if the CHS is wrong because the disk was formatted in another computer? See above. Apparently CHS was more compatible in some cases... * The CHS values in the boot sector are used at a higher level. The CHS * that DOS uses in various INT21/AH=44 IOCTL calls are converted to LBA * using the boot sector values and then converted back to CHS using BIOS * values if necessary. Internally we do LBA as much as possible. And I hope that SYS CONFIG will set both initdisk and higher level I/O. Eric -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security 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 https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel changes
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 fdupdate repository and also the updated installer from Jim for that... There is another problem, though: People why try to download a current kernel end up e.g. on fdos.org which is long dead, but used to contain an automated regular build of the kernel and a minimalistic boot floppy image containing that. Maybe the tradition of having daily builds somewhere could be resurrected, for those who cannot or do not want to compile kernels from the subversion repository manually. This would also be nice for tasks like binary search for when things in a regression bug broke and/or got fixed, etc :-) An SVN source tarball can be obtained at: http://freedos.svn.sourceforge.net/viewvc/freedos/kernel/trunk/?view=tar An 8086/FAT32 OW1.9 compiled kernel.sys binary for testing at: http://dosemu.org/bart/kernel.sys I am impressed how many changes from 2039 to 2040 have already accumulated, but to be honest I am also a bit disappointed that none of them was mentioned on this mailing list before. Yes I know that there are ways to automatically follow SVN commits, but I mean more something like a low traffic announcement and occasionally discussion list about kernel changes... * r1567 ... add explicit byte overrides for older versions of NASM for more compact code, It is good to hear that things were perfect apart from the size even with older NASM already before that improvement :-) * r1565 sys/sys.c: Change // to /* comments for Turbo C Thanks. * r1564 kernel/dosfns.c: If handle valid, close file in PSP table before the low-level close + (perhaps) critical error. Avoids closing the file twice (and hitting the critical error twice) on abort/program termination. Sounds like a good catch. Also, close can only return error 6 (DE_INVLDHNDL), not 5 (DE_ACCESS), see RBIL. Just wondering, maybe it was 5 to mimick a particular DOS? * r1563 kernel/task.c: From Christian Masloch: set flags to 0x200 (IF set) when transferring to int22 termination address. Interesting, I assume that fixes a hang in a specific situation? * r1562 kernel/fatfs.c: Check errors for callers of dir_write and shrink_file. Fixes: Bug: File creation does not check whether buffers are written correctly [also r1561] Good to know that this is fixed - since when it was broken? * r1560 kernel/kernel.asm: Enlarge clock and block driver stacks... Were the old stack sizes to be the same as some other DOS or were they just picked to be a bit more than minimally needed? I am asking because I wonder whether side effects could exist. * r1559 kernel/fatfs.c: Fix value that is used before being initialised. This lead to a drive to not be considered as FAT32 despite it is (or vice-versa). That sounds like a very important fix, thanks! * r1499 kernel/makefile: With the stack changes the DOS segment has moved to 0x79. Any side effects expected? * r1498 kernel/irqstack.asm: New irqstack.asm: irq 2, 3, 4, 5, 6, 10, 11, 12, 14, 15 now use the IBM interrupt sharing protocol for STACKS... Nice. Did other DOSes also do this? I assume RAM and CPU cost is tiny? Thanks again for all those recent updates. Regards, Eric -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] NOT PUBLIC DOMAIN (was Re: Possible size optimizations, kernel build 2039 bug in tracker)
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 OS with some (unspecified) FreeDOS kernel, is now public domain/unmaintained --it should work with FreeDOS. Well only the GUI is public domain, but if their download still contains some unspecified FreeDOS kernel then you could ask them to make licensing clear on their page and in their download. If you sense a GPL violation, you can ask Shane for advice, he is an expert for handling that. Eric -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] suggestion - put kernel svn revision version number in sys config data
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 any kernel file without having to boot with the file. Example: Current SVN version of the kernel is 1499 since 22 Aug 2009, or if you include SYS: 1500 since 13 Nov. The latter calls itself version 3.6e by the way, but SYS can easily show a version of itself, a kernel cannot :-). The SYS update is for handling SYS X: bootsect.bin runs. You can get automated builds from fdos.org/kernel/ which also has http://fdos.org/kernel/latest/ which is the most recent SF.net file release, FreeDOS 2039, SVN 1494 if the history.txt in there did not miss any :-). Looks good! The config would still be less than 16 bytes with version number in it. I think it would be a valuable small extra. Putting the SVN release number will only add a 16 bit int. Opinions? Comments? Eric PS: FD Changes since 1494: 1495 update history.txt itself, 1497 update LSM to have only placeholders instead of real version/date and add BAT to fill in data, 1498 support IBM int sharing for STACKS, 1499 adjust RAM layout build. PPS: Sorry for my big silence in the last few months, I should really make some time free to read more DOS mail! -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] [Freedos-devel] newer motherboards and [U]EFI, large-sectored drives
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 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 with driver.sys? Blu-Ray seems to have 8192 here. Another source mentions 2048 bytes used for MO drives... And wasn't there some far-east floppy format with 1024 byte sectors, too? http://support.microsoft.com/kb/67321 writes that sector sizes other than 512 bytes are exotic apart from for some ramdisk. http://www.computerhope.com/formathl.htm says that Win9x FORMAT supports up to 128 sectors per cluster but that sector sizes can be between 512 and 2048 bytes in this system (implicitly). Note that supporting bigger sectors will need bigger buffers at some point and some way of detecting actual sector size. I do not know whether MS DOS ever could BOOT from drives with big sectors. LARGE SECTOR DRIVES: There is also the issue of large-sectored disks coming after the 2TB drive, if anyone plans on purchasing one of those. by large-sectored I mean drives that have 1024, 2048, 4096 byte sectors. Note that we should also check whether kernel, FORMAT, FDISK, DOSFSCK and maybe other tools have sign overflow problems for 512 byte per sector drives above 1024 GB. Can anybody test that? Of course as long as FDISK is happy (or you simply use Linux FDISK) you can limit your self to drive letters of at most 1024 GB each, avoiding any problems. Microsoft has warned of this. large-sectored drives allow you to use the existing 32-bit-LBA MBR until the UEFI+GPT becomes established as a standard. Talking about GPT and UEFI: Tom often mentioned that we should add GPT handling to our partition table parser (initdisk.c). Note that this might make the parser significantly more complex - not sure. what large sectors affects is disk management utilities such as fdisk and chkdsk and defrag, and partition growing utilities that have hard-coded 512-byte sectors into their code (like I used to). FreeDOS's kernel also has 512 byte hardcoded as sector size for some reason. I don't know about the Int13 low-level stuff yet, but the DOS-internal buffer structure is fixed to 512 byte data and DOS's list of lists field which specifies the maximal sector size is initialized as 512 and never used by any code. As said above - int13 can do other sizes, but FreeDOS became lazy and ignores other sizes. On the other hand, not THAT many places would have to be changed to make FreeDOS aware of other sector sizes, at least if only block devices loaded AFTER boot would have to support other sizes. Eric PS: I think LinuxBIOS (however it is called at the moment ;-) has a plugin to provide legacy BIOS services (int 10, 13, that stuff) to classic systems such as DOS. PPS: A list of BIOS services needed by FreeDOS can be found here: http://fd-doc.sourceforge.net/faq/cgi-bin/viewfaq.cgi?faq=General_Information/277 www.mail-archive.com/freedos-u...@lists.sourceforge.net/msg07697.html www.nabble.com/Running-Free-DOS-on-the-OLPC-XO-td17286577.html (int 11, 12 - simple / int 14, 17 - only if COM/LPT used / int 19 - only reboot / int 1e - only floppy / int 1a - CLOCK / int 10 - VGA / int 16 - KEYB / int 13 - DISK ... See the URLs for exact info :-) ) -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] new kernel release pending
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! history.txt needs updating. I'll do that tomorrow. There's nothing else I can think of that is urgent. A good (per svn commit) history.txt is very valuable, thanks! * ability to cross-compile from Linux Nice :-) * fnodes are eliminated, except for internal use inside DOS calls (2 fnodes in the SDA remain); SFTs are now compatible with MSDOS which helps some programs that look at these structures. Also good, but probably needs much testing? Can you give potential testers some hints what they should play with? 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? By the way - I believe support for files between 2 and 4 GB in size already got added, also by you, several weeks ago? * Fix rename in full root directories (Bugzilla bug 1908) * Fixed Int21/AX=4409 for drives from device drivers. What was wrong? * Add COUNTRY.SYS support (from unstable, Eduardo Casino). Cool :-) * Findfirst/findnext are more MSDOS compatible. Please explain. * 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? * Avoid calling media_check() too often (to get fewer Abort/Retry/Ignore prompts if you press I) Which also leads to the question: Do we call it often enough, and is DF_NOACCESS enabled and fully working? * Check BPB instead of DPB to check for FAT32 after a BUILDBPB device call, to fix a problem with USBDRIVE. Interesting! Will this also fix potential other issues or are there also other things related to disk changes that might need improvement? I am sure Alain would be very interested to check and comment on the new disk change handling, as he had issues with the old :-). 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 mention the fdos.org auto builds on the webpage? Is there a way to include some automatic current build is from date X snippet...? Eric -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] new kernel release pending
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 mention the fdos.org auto builds on the webpage? Is there a way to include some automatic current build is from date X snippet...? What testing have you been doing on recent releases? Actually not much: I read some of the SVN diffs, trying to find out what changed and which parts look safe and which look risky, and tried to ask about details about the parts which I did not understand or which looked fishy... There was not much on the list about work in progress, so there was also nothing about suggestions for review or testing. It is always good to have complex updates discussed, as it gives extra chances to find flaws or regressions that you might otherwise only notice much later in everyday use :-) Eric -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] FreeDOS kernel without any harddisk support.
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 would not touch the HDDs at all. 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 http://rugxulo.googlepages.com/ somewhere... :-). You can get the current sources via SVN, of download the 2038 zip if a somewhat older kernel is acceptable for you. Eric -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Past bugs and CONFIG dot SYS
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 number of hooks, some of which are not even documented, I would say that the current implementation of SHARE is smoother. This format of share exe hooks table about MS SHARE lists: - a routine of unknown purpose, probably not called - something called on open and something called on close - routines called by DOS when int 21.5d02/03/04 are requested (so share implements those close-all-matching things for dos) - routines to lock/unlock regions and check for locking - a get open file list access thing - something possibly about updating FCB from SFT and knowing clusters - a routine to close file if duplicate for process - something to close the most recently opened files? - a routine to update directory info from SFT entries (size, time) Most of those MS SHARE hooks use DOS SS and DS and manipulate kernel data structures instead of having normal call parameters. Certainly not a nice API either, compared to FreeDOS SHARE which uses custom extensions to the int 2f SHARE API for open, close, check, lock and unlock. Note that I do think it might be nice to support int 21.5d02/03/04, but you can also put that bit into the kernel instead of into SHARE. share exe as part of the kernel is of course a trade-off: it's natural for an OS, but for DOS you'd like the base kernel small and only include things that most people use (and most people don't need SHARE). Good question - what apart from Windows uses SHARE? Maybe MSCLIENT? I also wonder how big, roughly, a kernel built-in SHARE would be. Eric -- ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Past bugs and CONFIG dot SYS
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 21.30, which also returns OEM ID 0xfd for FreeDOS :-). The functions in question (Int21.5D subfunctions 02h..05h) interestingly aren't supported by Novell/DR-DOS too. The functions are: Close file by name, Close all files for given machine number [probably used by networking?), Close all files for given machine number PSP, Get open file list entry (provides ASCIZ filename of a specified SFT to applications, might be useful). This is an old missing feature - while I know no software that uses it, I agree that it would be potentially useful, both the get open file list entry and the close-some ones. - is currently tied to Borland Turbo C compilers - options are to [1] update to be more compiler neutral C, [2] convert to OW compatible only, [3] merge into kernel so not a standalone app any more, [4] rewrite in assembler, or [5] something I missed. I am not sure how big 3. would be but the main RAM usage is in data tables... It might be interesting to put those into HMA when SHARE would become a part of the kernel. I also do think that 4. might be a nice idea :-). As mentioned in the SHARE source code (at the Int2F handler code), the inline assembler hack used for interrupt processing should be replaced by an external object module if the code stays C (thus options [1] and [2]). True... Eric -- ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Past bugs and CONFIG dot SYS
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%40freenet.deforum_name=freedos-user (second post, by Eric, claims Arkady wrote a patch) Eric, can you clarify? You wrote that you later read more of the thread and found out, but what did you find out? Can you give a summary? Otherwise we all have to read the whole old thread again. I guess SHARE might be something to test w/ HX. Japheth's documentation claims that SHARE is needed for pipes, Cygwin requires pipes, and FD SHARE is too crippled to work. If Japheth knows about a bug, he should explain what EXACTLY is wrong so somebody has a chance to fix it... Note that any DOS does not support real pipes at all as far as I remember. Eric -- ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Past bugs and CONFIG dot SYS
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. Already much better than some years ago: Just a few kB now. - uses an interface on Int2F which probably isn't as good as an internal hook. (MS-DOS uses a number of hooks partly documented in RBIL, I use one You mean table 01636, format of share exe hooks? Note that our SHARE does not implement int 21.5d02/03/04/05 yet. I wonder which apps actually use those functions, though. hook which dispatches to different functions using the function number in ax. The latter will of course be described within the release's documentation.) I assume that means you introduce a whole new API and claim it is better just because you did not like the old one...? ;-) - can't be removed once installed. I think this limitation isn't just in SHARE but also in the kernel. It is also in every other version of SHARE that I know. Shrug... If I had to re-invent SHARE anyway, I would actually make it a PART of the kernel, lowering memory footprint. Of course you cannot unload it then either. You could still have some way to resize the data structures used, on the fly, after booting... - doesn't provide a dedicated installation check. The original MS-DOS SHARE.EXE installation check Int2F.1000 is most unreliable. For example, Win3.x reports that SHARE.EXE is installed disregarding whether it actually is, as do a number of TSRs designed to fake file sharing support. The int 2f.1000 install check works fine, thank you. Apps which respond to the check usually do so because they already support what SHARE does. I think Windows 3 implements the share stuff itself for DOS apps started from Windows? Of course you can and probably will invent a new API, the yes the only good SHARE, the one from Christian, is loaded, but what will call it? ;-) - doesn't use the (under Win3.x virtual, else network) machine number at all. Since SHARE also works without access to SFTs, the sharing records require a new field to support the machine number. I do not get the point you are trying to make here. But maybe this means that our SHARE is not workgroups compatible yet? - was written by people that probably understood first sharing mode and first access mode wrong. There is no single first mode. The first mode fields in the sharing record are unnecessary. The allowed mode table must be applied between the mode of EACH existing open and that of the new open for the same file. I think the problem doesn't just ignore subsequent more restrictive opens of a file (allowing too much for new opens), but could also carry on restrictions of one open after it was already closed (disallowing too much for new opens). I am not familiar enough with the intricate details of SHARE to comment on that. Suggest a patch if you want to... ;-) - uses a complicated allowed mode (and exception) table that can be simplified, since entries that create critical errors (value 2 in the table) are simply all entries disallowing the new open (otherwise value 1 in the table) where the new open is in compatibility mode. Sounds like a tuning possibility - suggest a patch :-) - allows opening the same file two times in compatibility mode always, but it should only be allowed if the (virtual/network) machine number of the opening process matches. (This isn't documented in RBIL, the tests were apparently done without usage of Win3.x or the Server Call Int21.5D00.) Since SHARE doesn't know about machine numbers anyway, this can't be done. Basically you say SHARE misbehaves if you use network drives and apps on different computers open the same file after you already said that SHARE does not yet support network node addresses anyway. - (according to the commentary) returns sharing record numbers of 0..32767 (positive 16-bit values) to indicate success on opening the file. The kernel should increase such a returned value before using it as sharing record number in the SFT. Value 0 indicates the file isn't handled by file sharing in MS-DOS. As said above - I do not know enough about details to comment on this. - doesn't check whether it runs on the correct DOS version. It doesn't even check whether it runs on its kernel at all. Even if it would, since the kernel provides no way to get its version number, it couldn't check for that anyway. If by the kernel you mean the FreeDOS kernel - there are enough ways to get the version number. Most basic would be getting the normal DOS version number, possibly checking for OEM is 0xfd and version is at least 3.something. You can also check for true number and even get FreeDOS specific version information if you want to be very picky. I initially
Re: [Freedos-kernel] Hello again
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 next version of stable. I think it also means that we will gradually port more things from unstable into the stable branch, but have no new unstable versions (-numbers) to be released in the next few months. It would be good to update the wiki page about unstable here... http://sourceforge.net/apps/mediawiki/freedos/index.php?title=Unstable_Kernel_Branch ...to have a better view on which features are port-worthy. I agree that the freedos distro should by default include the stable branch of the kernel :-). Note that the discussion in mid-may was about experimental filesystems. I still think it would be better to play with those only in the unstable branch. That branch can serve as testing ground for experimental things and as a pool for carefully (!) porting features into stable. Of course it would be useful to port some updates from stable to unstable first, to make the unstable branch more useable. Eric -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] kernel 2038 discussion stuck? history.txt changes
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 reading it :-). After all, I can read the SVN commit list and diffs easily via the web interface or my SVN client, but this does not tell me what the code changes mean and what the background of their design is ;-). Anyone with admin rights, Aitor? Jim? Pat? you can do this on SF: click Project Admin click Feature Settings click manage next to Subversion add an svnnotify hook, and type freedos-...@lists.sourceforge.net as the email address. Sourceforge.net seems to have problems at the moment but it seems that Aitor and Pat are indeed the people to ask :-). * there are only two near fnodes, and almost all operations use the first fnode, fnode[0] except for dos_rename(), which also uses fnode[1] I remember part of that, and I think it is a good idea that you now hardcode the 0 / 1 index now instead of the old alloc scheme. Actually by making dos_rename the first f-node-free implementation you could already get down to a single global f-node :-). * file state is only kept in SFTs: an open/creat uses fnode[0], then copies the state to an SFT a read/write copies state from the SFT to fnode[0], does its work on fnode[0], then copies back to the SFT. a close copies from the SFT to fnode[0], and closes the file. F-nodes largely overlap SFT afair, but also have the dir entry (relevant for performance?). Looking at your changes, it seems you move towards dynamic transformations between SFT and F-Node shape of the data, to make F-Nodes more virtual and get them closer to being abandoned. Certainly not trivial :-). * For FAT16 kernels, the SFT layout is documented in RBIL * For FAT32 kernels, the SFT layout follows that of MSDOS 7.10 (not documented in RBIL). Documented in MSDN then? Could this cause significant classic DOS app / driver incompatibilities when using FAT32 kernels? * the share support also needed some changes, because it needs to walk the SFTs instead of the far fnodes to merge changes. That sounds really interesting. Does it mean we need FreeDOS specific SHARE now and will be able to use any DOS SHARE in the future? Note that our SHARE could use tuning to reduce the memory footprint (or rewrite in ASM?) and that people have made patched versions (Japheth?) for compatibility reasons... Otherwise I would ask why r1416 rmdir drops the 00/eof check (does it?) and why r1397 drops the dos_commit-only way of close(?) and how get_f_nodes_cnt works, among other things... r1416: Look at what dir_read(fnp)==1 means in fatdir.c... You mean it already implies end of directory? r1397: dos_commit was no longer necessary: a commit (int21/ah=68,6a), in DosCloseSft() just calls dos_close() without closing the SFT. Still do not get it, but I assume you know what you are doing :-) get_f_nodes_cnt() was an intermediate function that no longer exists (to keep individual changes small) It just walked the SFT chain and computed the FILES= value. Strange, seems to be meant the other way round: The user sets FILES and then the SFT uses the available number of handles, with the JFT of each task saying which SFT items are in use? Eric :-) -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Clarifications forever and ARF
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 disks, writing on the fly and large disks with large files, in the CD and DVD world. Many DVDs and CDs still have normal ISO9660 instead, sure. So--where else will you get 4G+ files? That is my point - DOS apps do not use such big files, and the handful of apps which process DVD or BD diskimages in DOS can do so by splitting the images into smaller files. The point is that FAT32+ and ExFAT, while _potentially_ useful, are getting ahead of what DOS can do. Once we have UDF/whatever else can use 4G files, it's time to start work. But now, it seems a misplaced priority Yes :-) I would suggest to make XMS, no EMS, no UMB the default and keep the menu (yes, sorry :-p) to select options like with JEMM386 or run only DOS, do not start the installer or maybe even no driver minimal mode. Yet the latter is already covered when you use F5... ;-). That sounds good (maybe with UIDEJR.SYS for universal cd driver) If it could include ELTORITO support with the same amount of BIOS bug workarounds as the classic ELTORITO SYS driver? configuration tool assigns a 4 or something else that doesn't. Very old and easy to fix bug - config sys menu items only work if the kernel can see that they are in use. Add 4?echo item 4 to your config sys or fdconfig sys to fix :-). them). The kernel worked with windows 3.11 in enhanced mode except... I should have said 386enh instead of WfW. Hmmm you mean 386enh in 3.1? Or do you mean WfW 3.11 default mode? In WfW 3.11, the non-enhanced mode is just a minimal safe mode... Abort, Retry, Fail? An A should abort, F should fail. But it takes several iterations That is a small bug in FreeCOM: It tries for COM EXE and BAT even if the first attempt already gives an error which would make it obvious that it is not useful to try the two other possibilities. Eric -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] kernel 2038 discussion stuck? history.txt changes
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? :-) WfW support in stable, these might be handy. WtF is WfW ??? Windows for Workgroups 3.11 - quite different from Windows 3.0 and 3.1, because WfW always runs in 386enh mode (unless you call a sort of minimal safe mode running). FreeDOS runs Windows 3 in standard mode easily, but support for 386enh mode is even an experimental compile-time extension of the experimental 2037 kernel. Pretty unstable, in other words :-). As for SYS, I think I'll keep both versions (stable and unstable) due to different feature sets. Actually I had forgotten to point this one: there used to be SYS 3.5 or 3.6 back in 2005 ... that's what EDR-DOS SYS was forked from ;-) This is simply the unstable branch of SYS - Udo of course likes the ability of that SYS to make other operating systems bootable, in particular EDR DOS :-). But yeah - we should take care with the version numbers, otherwise we get 2 totally different SYSes which have the same version number! Eric -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] kernel 2038 discussion stuck? history.txt changes
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 possibilities, people with mostly ASCII languages can still enjoy the (smaller on disk, easy to use) built-ins. Can you find other useful and reasonably easy to port features on http://apps.sourceforge.net/mediawiki/freedos/index.php?title=Unstable_Kernel_Branch http://freedos.svn.sf.net/viewvc/freedos/kernel/branches/UNSTABLE/?sortby=dateview=log Would be interesting to know :-) * That FNODES stuff (Bart seems to be working occasionally on this, but now based on 2038) Bart seems to work on this a lot, but unfortunately there is nothing about the progress on the mailing list. Otherwise I would ask why r1416 rmdir drops the 00/eof check (does it?) and why r1397 drops the dos_commit-only way of close(?) and how get_f_nodes_cnt works, among other things... Windows for Workgroups , which is a flavor of Microsoft Windows 3.11 Actually people who say Windows 3.11 almost ALWAYS actually mean Windows for Workgroups 3.11 ... There is also a year 2000 patch for Windows 3.1 which is called Windows 3.11 but that is by far the less frequently used type of Win 3.11. Windows 3.0 and 3.1 are quite different. I disagree that they would be useless without 386enh mode. I remember WIN /S still was quite useful for me but then I do not use Win32s based (Win9x-ish) software that would require 386enh mode... :-). Tom, can you give details on this: WfW support will probably never come; WfW was tighly coupled to the kernel (at least according to Schulman et. al., WfW is MUCH more then just a flavour of Windows 3.11) What is Schulman et al? I wonder whether the experimental patch for the experimental 2037 branch was for making 3.1 enh mode or 3.0 enho mode or rather WfW work in FreeDOS, or maybe several of them, does anybody know? Note that it is hard to run old Windows on modern hardware with any DOS. It can help to tell your HIMEM to show only max 256 MB of RAM, avoid EMM386, avoid Windows direct disk access drivers and maybe do other config tricks. Windows 3 is probably not extremely obsolete - I remember even that 3.0 worked, 3.1 did not of the deliberate DR DOS incompatibility long ago really hurt DR DOS market... What does UDF support do? Enable copying video DVD? UDF is popular for rewritable disks, writing on the fly and large disks with large files, in the CD and DVD world. Many DVDs and CDs still have normal ISO9660 instead, sure. Jeremy Davis created SYS 3.5 yes with support for several other DOS-based operating systems by generating their bootsectors. Found some old info at my ancient Blog on Jeremy's server http://wiki.fdos.org/Blog/Bernd ] I seem to recall that SYS did not support FAT32 bootsectors for Windows 95OSR2.x and Windows98/98SE/ME. it's possible to modify the kernel enough with additional code so that it could read a Isolinux/Memdisk commandline including arguments? Possible of course, desirable no ;-). There is that GETARGS tool and you can use it in autoexec. You can also use DEVLOAD if you want to use the fetched text for device driver options. Followed by searching for a config=x option where x=[0..9] and then executing that menu option in (fd)config.sys. The benefit of this is taking away 1 keypress Bad ratio between benefit and exotic feature ;-) Currently it's : 1) select to boot FreeDOS from CD 2) select which menu option you want. You can also use SYS CONFIG to enable Tom's function to skip STARTING DOS and boot the next drive instead with a hotkey. Then the ISOLINUX / GRUB4DOS / ..: menu could be configured to always LOAD DOS without choice. but means there's no support for loading device drivers (and specially DOS=HIGH, DOS=UMB, the kernel and FreeCOM I would suggest to make XMS, no EMS, no UMB the default and keep the menu (yes, sorry :-p) to select options like with JEMM386 or run only DOS, do not start the installer or maybe even no driver minimal mode. Yet the latter is already covered when you use F5... ;-). Eric PS: For those who want to use the can boot other OSes unstable variant of SYS, please consider porting six updates of stable to make a more stable version first: - 1315 update OEM name - 1342 fix FAT32 and LBA handling - 1342 make copy much faster, in particular for SYS A: B: with 1 drive - 1352 preserve file timestamps, improve copy and alloc code - 1356 update backup boot sector as well in FAT32 - 1367 fix compilation for odd OW 1.8+ headers -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a
[Freedos-kernel] kernel 2038 discussion stuck? history.txt changes
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 kernel, 15550 byte SYS 3.3, the latter still lacking a Force LBA / Force CHS command line option for FAT32 use, alas. It also shows the output of a tool which tests int 21.7303 and displays the values: ver 0 size 2c sec/cluster 8 bytes/sector 200 free clusters c333 total clusters c334 free sectors 61998 total sectors 619a0 free clusters' c333 total clusters' c334 free space c333000 / 204681216. Version text says build 2038 May 16 2009 compiled May 16 2009. - my GetDiskFreeSpaceEx bug seems fixed Nice :-) - history.txt neglects any development, oops Eric already pointed it, also, Yes, still waiting for any reaction on my 18 May mail here... Can we update the history txt file for www.fdos.org/kernel/latest/ and on SVN soon? It is a pity that we already have post 2038 updates even though 2038 itself is not complete yet. In spite of all the warnings during the last year that documentation or lack thereof was the main thing which blocked official release. the filename should be HISTORY.TXT and not history.txt of course DOS filenames are not case sensitive. Actually lower case names are better if you want to keep case sensitive OSes happy. SourceForge page still shows 2006-May-21 (3 years old !!!), so, those having the power please fix this now or give the power to someone else. Pat, Jeremy: Please FIRST update history txt BEFORE we make a sourceforge file release of kernel 2038. Thank you :-). Eric Here is a suggested history.txt section for 2038 based on http://freedos.svn.sf.net/viewvc/freedos/kernel/trunk/?sortby=dateview=log http://freedos.svn.sf.net/viewvc/freedos/kernel/trunk/docs/history.txt?revision=1364 In short, SVN revisions 1365 to 1385 are undocumented...! Also, Bart already made 2039 related revisions - 1411 ;-) His changes are f_node / SFT and tuning things... It would be nice to have a web page where the unified diffs can be looked at for proofreading. Revisions 1386-1388 are about Linux cross compilation, 1385 bumps version.h to 2039-svn. A bit unrelated is 1396 sft.h: 0b start cluster is not set (RBIL 01642) or high part (Bart?) of if FAT32 kernel, file size and position (incl rel cluster) are unsigned and some fields at offset 1b-1e (current cluster/sector) change a lot. Is the sft_status sft_cuclust sft_ifsptr really correct?? - *please change*: Build 2038 is May 2009, not Apr 2008, and my email is the one I use now, not eric at coli. - *please add*: + Changes Jeremy 2009 * r1381-r1384 update bugs.txt, version.h, LSM, tag SVN for 2038 release * r1374, r1380 fcbfns FCB open old GEM compat (bigsize/recsiz/recno...) * r1379 dosfns.c fatfs.c proto.h from Eric: only check for SHARE on open/close, avoid extra 2f.1000 calls. * r1378 dsk.c from Lucho: Press any key, not Press the any key ;-) * r1377 initdisk.c from RayeR: Use total cyl count, not max cylinder (fixes off by one bug on non-LBA PC) fix overflow by ULONG cast. Improve DebugPrintf calls, fix format string (only in debug kernels) * r1376 inthndlr.c from Tom: 21.1c return AL=0xff for invalid drives (fixes bug for apps which use int 21.1c to find FAT drive letters) * r1372, r1375 process.h/entry.asm make CP/M call PSP[5] work (1 line jbe versus ja fix plus detailed comments, by Bart) This fixes SF tracked bug 2421577. * r1373 kernel.asm add : after _HMATextAvailable avoid nasm warning * r1371 watcom.mak make sure even Windows Watcom C builds a DOS SYS (would otherwise make a SYS meant for use in Windows by default) * r1370 default bat make compiling without UPX possible again * r1369 let DosGetExtFree 21.7303 accept drive with and w/o slash This fixes SF tracked bug 2380828 (GetDiskFreeSpaceEx if no slash) * r1368 tag for ke2038test - *please change*: Please add to the Changes Bart + Eric part: * r1367 sys.c from Bart: 32bit date/time if WATCOMC 1279+ (OW 1.8) * r1366 config.c, config.txt allow BUFFERSHIGH as alias to BUFFERS, buffers are in UMB, we use HMA anyway. Drop unused int 16.1 call. * r1365 inthndlr.c allow/ignore type hints in int 21.7305 disk read - *please add to r1334 comments*: Fixes SF tracked kernel bug 2362450: http://sf.net/tracker/?func=detailaid=2362450group_id=5109atid=105109 PS: I would like to quote IBID_AG: 1. I have checked out the latest build (kernel 2038-32). It works fine with GEM/XM. (So did the 2nd RC.) Nice :-) 2. Congratulations on a great kernel/OS 3. PLEASE stop the flame wars--the last few digests have looked rather (?!) 4. I would rather see more of the features from 2037 in stable than get more oddball features in unstable (ExFAT, FAT+). Once we get COUNTRY.SYS WfW support in stable, these might be handy. And SHSUCDX with
Re: [Freedos-kernel] kernel 2038 discussion stuck? history.txt changes
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 making a zip, otherwise you would make a zip of kernel almost 2039. This history.txt update describes ONLY the changes until 2038, not the newer changes, to make it easier to use my updated history.txt for a kernel 2038 zip :-) http://freedos.svn.sourceforge.net/viewvc/freedos/kernel/trunk/docs/?sortby=date#dirlist http://freedos.svn.sourceforge.net/viewvc/freedos?view=revsortby=daterevision=1412 In case you want to have a quick look without using a SVN tool: http://freedos.svn.sourceforge.net/viewvc/freedos/kernel/trunk/docs/history.txt http://freedos.svn.sourceforge.net/viewvc/freedos/kernel/trunk/docs/readme.txt http://freedos.svn.sourceforge.net/viewvc/freedos/kernel/trunk/docs/contrib.txt As ideal as this seems, I'm glad there's a 2038 now. There was a 2038 snapshot before, on http://rugxulo.googlepages.com/ What I mean is: When we put a fresh 2038 kernel zip file on http://sourceforge.net/project/showfiles.php?group_id=5109 it must include documentation / changelog about 2038 :-). Feel free to make a history.txt for 2039, as you seem to mention This documentation was only about 2038 and you must have a proper changelog if you want users to understand what they download and what they can expect in a new version. there's some patches already again anyway (which would mean a 2039 isn't too far away). There are dozens of patches between each two versions and I am sure that Bart will update history.txt after each block of patches to document changes, for example explaining the details on how he removed fnodes and in which C/H/ASM files. As for SYS, I think I'll keep both versions (stable and unstable) due to different feature sets. The unstable-branch SYS is more like a boot manager ;-) As for FreeCOM, guess we're stuck with the old one. Should we offer 4DOS as an option during installation time of any distribution? I would put 0.82pl3 as default but the install scripts as triggered by FDPKG / installer in FreeCOM 0.84 / 4DOS zip packages can be interactive and ask the user whether he wants to make 4DOS / 0.84 the SHELL line if he prefers that way :-). Eric PS: Other pending things are add force LBA or CHS option to SYS for FAT32 configuration, get explanation of SVN r1396 on sft.txt (offsets 0b, 1b-1e, sft_status _cuclust _ifsptr...), check UDF-CDEX possibilities, check which features beyond the COUNTRY SYS support from unstable are interesting for porting, http://apps.sourceforge.net/mediawiki/freedos/index.php?title=Unstable_Kernel_Branch -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Cross compilation from Linux
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-compile than fire up DOSEMU or another VM and do the compilation there. I hope it is useful to some others and also clean enough: mostly DOS understands / fine but some commands in makefiles need to use $(DIRSEP) to get either \ or /. The batch files obviously can't be used but the top level makefile can do the trick using make all, make clean, and make clobber. 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? :-) Eric -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://www.creativitycat.com ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Cross compilation from Linux
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 author would have saved some time here, of course ;-). - segs.inc: ifdef owlinux then define WATCOM - kernel makefile: make DIRSEP a variable instead of using backslash - k. makefile: various target names: use slashes instead of backslash? - kernel makefile: replace copy command name by a CP variable - kernel makefile: remove ECHOTO target - build.txt: add section about Linux (config.mak is Linux config bat?) - watcom.mak: use DIRSEP in C flags instead of using backslash - generic.mak: define DIRSEP RM CP ECHOTO CLDEF - generic.mak: use slashes instead of backslash for includes? - generic.mak: if CLDEF not 0 then do something with CLT CLC? - owlinux.mak: new file, similar to generic.mak it seems - owlinux.mak: defines ECHOTO as echo which looks odd... - exeflat.c: add ' around something in cmdbuf, add trailing NUL - utils makefile: use DIRSEP, drop use of INCLUDEPATH? - utils makefile: use CLT CLC instead of CL - utils makefile: drop TINY, CFLAGSC,CFLAGST? - config.m: new file for Linux, looks like a config bat - config.m: is preconfigured for 8086 FAT16, interestingly - makefile: make the default target only show a help message - makefile: change all target into build target which does build? - makefile: add some Linux section and some defaults (and DOS?) - makefile: rewrite all/clean/clobber targets, big changes? - drivers makefile: add explicit .obj for LIBOBJS names - drivers makefile: change backslashes to slashes in deps/targets - drivers makefile: change backslashes to DIRSEP in RM options - sys makefile: use DIRSEP in CFLAGS - sys makefile: use slashes instead of backslashes for deps/targets - sys makefile: use CP instead of copy - sys makefile: use slashes instead of backslashes for bin2c options Are you sure this still works on DOS, even with Turbo C etc? :-) Eric -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://www.creativitycat.com ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] pending kernel differences
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 ambiguity
Eric
Index: kernel/initdisk.c
===
--- kernel/initdisk.c (Revision 1389)
+++ kernel/initdisk.c (Arbeitskopie)
@@ -318,7 +318,7 @@
type = regs.b.b.l - 1;
if (regs.flags 1)
type = 0; /* return 320-360 for XTs */
- else if (type 6)
+ else if (type = 6)
type = 8; /* any odd ball drives get 87=0: the 320-360 table */
else if (type == 5)
type = 4; /* 5 and 4 are both 2.88 MB */
@@ -592,7 +592,7 @@
if (nUnits = NDEV)
{
-printf(more Partitions detected then possible, max = %d\n, NDEV);
+printf(more Partitions detected than possible, max = %d\n, NDEV);
return; /* we are done */
}
@@ -734,7 +734,7 @@
lba_bios_parameters.sectors 0x ||
lba_bios_parameters.totalSectHigh != 0)
{
-printf(Drive is too large to handle, using only 1st 8 GB\n
+printf(LBA drive properties implausible, using only 1st 8 GB\n
drive %02x heads %lu sectors %lu , total=0x%lx-%08lx\n,
drive,
(ULONG) lba_bios_parameters.heads,
@@ -1286,7 +1286,7 @@
pddt-ddt_driveno = driveno;
pddt-ddt_type = init_getdriveparm(driveno, pddt-ddt_defbpb);
pddt-ddt_ncyl = (pddt-ddt_type 7) ? 80 : 40;
- pddt-ddt_descflags = init_readdasd(driveno) | flags;
+ pddt-ddt_descflags = init_readdasd(driveno) | flags | DF_DISKCHANGE | DF_NOACCESS;
pddt-ddt_offset = 0;
pddt-ddt_serialno = 0x12345678l;
Index: kernel/dsk.c
===
--- kernel/dsk.c (Revision 1389)
+++ kernel/dsk.c (Arbeitskopie)
@@ -374,8 +374,8 @@
unsigned secs_per_cyl;
WORD ret;
- /* pddt-ddt_descflags |= DF_NOACCESS;
- * disabled for now - problems with FORMAT ?? */
+ pddt-ddt_descflags |= DF_NOACCESS;
+ /* was disabled - problems with FORMAT ?? */
/* set drive to not accessible and changed */
if (diskchange(pddt) != M_NOT_CHANGED)
Index: kernel/main.c
===
--- kernel/main.c (Revision 1389)
+++ kernel/main.c (Arbeitskopie)
@@ -126,14 +126,10 @@
}
/*
-InitializeAllBPBs()
-
-or MakeNortonDiskEditorHappy()
-
-it has been determined, that FDOS's BPB tables are initialized,
-only when used (like DIR H:).
-at least one known utility (norton DE) seems to access them directly.
-ok, so we access for all drives, that the stuff gets build
+InitializeAllBPBs() or MakeNortonDiskEditorHappy() - FreeDOS
+does DPB setup on demand (eg DIR H:, via media_check, bpb_to_dpb)
+so we touch all drives to make sure DPB are filled in. For some reason,
+this was described as init BPB to make Norton Disk Edit happy...?
*/
void InitializeAllBPBs(VOID)
{
@@ -145,6 +141,14 @@
if ((fileno = open(filename, O_RDONLY)) = 0)
close(fileno);
}
+ /* chdir(A:\\) would need intr.asm/init-mod.h ext. but nicer than open() */
+#ifdef WITHFAT32 /* mark drive as not FAT32 to allow int25/26 access */
+ /* floppy is DF_NOACCESS until 1st media_check or int 21.440d.0847 */
+ LoL-DPBp-dpb_fatsize = 1; /* not 0, that would be FAT32 */
+ LoL-DPBp-dpb_next-dpb_fatsize = 1; /* not 0, that would be FAT32 */
+ /* bpb_to_dpb(ddt_defbpb...) would be perfect but is not accessible */
+ /* media_check(get_dpb(0)); / int 21.32 etc would access phys drive */
+#endif
}
STATIC void PSPInit(void)
--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing,
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, Big Spaceship. http://www.creativitycat.com ___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Which kernel
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 unstable branch is available as an option for those who want to have extra features at the expense of less stability :-). Of course it would be nice if some patches from the stable branch could be added to unstable first, to make the pain for users of unstable smaller... ;-). Eric -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] kernel 2038
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.sourceforge net in contrib.txt and other places? Thanks! Please test and report any new issues to the mailing list. Depending on any reported issues, 2039 scheduled to be released in about a month. Comments about new or existing bugs to focus on for next release welcome. Interesting :-) Eric -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Hello again
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 know), and there's a reason we left them in the kernel the last few years. it's probably fairly easy to convert a stable kernel into unstable by trying to convert this. There are fewer and fewer fields for which the difference SFT versus fnode still matters, so I would suggest to slowly phase out the old uses of fnodes, field by field and very carefully... Well, now we have two kinds of f_nodes, the near ones and the far ones. The far ones are copied to and from near ones using 4 fmemcpy's in fatfs.c Replacing the fmemcpy's by a convert fnode to/from SFT function should be able to eliminate the far fnodes. I'll give that a go. Once that's done at least some of the fatfs.c functions can be converted to use SFTs directly. Though this is not as easy as it looks because fnodes are also used as internal structures for directories. See above - I also think that converting frequently on the fly is not very pleasant performance and complexity wise. No need to hurry in getting rid of the fnodes, so I somehow prefer phase out style. Eric -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Hello again
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 reason to add experimental things to stable now :-) The solution is easy: Add it to the UNSTABLE fork and, while doing so, show that there are people who are interested in new experiments with DOS! This will also draw more attention to this branch and make it more likely that safe goodies can be found in there and ported to stable and that on the other hand UNSTABLE will finally get updated with some of the fixes that stable received in the last few years... :-) As Udo (Kuhnt, from EDR-DOS) put it, the unstable branch was and is seen only as testing area for features that won't be added to the stable I disagree on this. There is way too little review on UNSTABLE but if you read the changelog and tech changelog, you see that also normal useful but complex features such as COUNTRY SYS support found a testing ground in the unstable branch :-). The next challenge is to review / proofread the better few of those features and add them to stable as well after that. Carefully. At least I didn't yet see anything changed in stable which was derived from unstable Actually not much apart from COUNTRY SYS support in unstable has very favorable risk/complexity versus gain in features ratio at the moment, unfortunately... , and improvements of stable aren't added to unstable either. This is because more or less the only developers were Jeremy, Lucho and Arkady - the latter is kind of missing and Jeremy just returned a few weeks ago from being so busy with the real world real life that he simply had no time to continue working on the unstable branch. Lucho now has other big things as 4DOS. Effectively unstable is forked off. Recent efforts to add some features of unstable back to stable (such as COUNTRY.SYS loading) support this: If the branches were maintained together, or even created from the same source with IFDEFs, it won't need much effort to add features from the testing branch to the official one. If they were IFDEFed then you would have no chance understanding either ;-). The stable / unstable diff is maybe 1000s of lines. Notice that I started working on a different DOS kernel (RxDOS) because I prefer to write such programs in Assembler. In a way, I want to change everything compared to DOS-C (The FreeDOS Kernel) which is written in a high-level language, and that's the reason I choose not to develop it. Tastes differ. One of the original goals with DOS-C was using more C :-) Although I'm not exactly interested in developing most of the FreeDOS programs, I did already point out a few bugs. I'm of course not fixing them myself (well, at most providing small patches) because I'm in no position to take over development of these programs. Still you are welcome to point out tech details of bugs if you find them, as we often have only vague it somehow does not work type bug reports and no time or hardware/software to reproduce/debug them. Eric -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Hello again
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 trouble. Of course you can add it to the unstable branch so people can try it there nevertheless... Uhm, now that seemingly some people are working on the kernel again, it's good to proceed the forking? I agree that FAT+ support is controversial, but it doesn't have to be build into unstable only. This would just differentiate unstable more from stable again. Sorry but it IS an unstable feature, actively breaking compatibility. Of course you can implement it in a way that makes it easy to port but honestly - I think changing several data structures into NON DOS compatible variants is a very bad thing to plan for a stable patch. And again: Tell me ONE thing where you want files above 4 GB size and where you have more than a single app that would use them, as that single app can just as well split the big data over N files. Also - do not overestimate the number of developers we have. I have the feeling that you love adventure and features, so I would say it would be a good idea if you start by completing the technical overview page of the unstable branch. Then you can do several things...: Find suitable patches for backporting to stable. Help with that third kernel branch. Do careful review of the too experimental patches and help on the long road to making unstable more stable again. Or, of course, add more fancy things, such as FAT+, to unstable ;-). The technical overview of the unstable branch wiki page is here: http://apps.sourceforge.net/mediawiki/freedos/index.php?title=Unstable_Kernel_Branch On the other hand, you've a point here. Why tie 4 GiB file size support to FAT+? 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 because the latter would be severely incompatible with everything. If you ask me, it would be even better to have a MINIMAL (eg only readonly, only root directory) ISO9660 / EXT2 / NTFS / whatever driver in the kernel and load a separate full driver for that file system later. Well, that's almost what DOS-C currently does. The minimal driver here is the boot sector which loads the kernel file. The kernel then continues to access the same filesystem with its own FAT drivers... That is not what I meant... The boot sector loads only the kernel. A minimal built-in driver would be able to load FURTHER drivers from a non-FAT filesystem, such as NTFS4DOS or EXT2 drivers... Note that it would be bad to have those linked into the kernel binary - they are way too big for that and there are license issues. to play nice for FAT16 apps and as a side effect lure FORMAT into making 8 GB almost-FAT16 filesystems when it tries to hide FAT32. To explain: EDR DOS tries to return as FAT16 style as possible data even for FAT32 filesystems, to make life easier for lowlevel (!) DOS apps of the old times which do not know FAT32 yet. This has the bad side effect that apps might actually believe that the drive really IS FAT16 but of course then you get miserable failures of OTHER lowlevel tools... Note that this is not related to support for 64kB and 128kB clusters, even FreeDOS supports 64kB clusters although I strongly suggest to use FAT32 in cases where you would need 64kB clusters for FAT16 :-). First, there are no EDR-specific extensions to the BPB, you're talking about the DPB here. (The difference is important!) Second, 4 of 6 additional bytes are required for better FAT16 MS-DOS compatibility I am talking about the int 21.7302 FAT32 DPB. Instead of that compatible structure, EDR DOS uses a strange modification of the FAT16 DPB, related to the reasoning mentioned above. You cannot improve FAT16 MS DOS compat of what actually is a FAT32 filesystem because FAT32 just is no FAT16. Or to put it in other words: If you make the trunk of an elephant look like a cat, it might smell though the cat door but it will still break your house when the rest of the elephant follows, so you better keep the elephant looking like an elephant :-p. should *not* be limited to hack for EDR-DOS only because other DOS versions might use larger DPBs too... Name one... One that is reasonably compatible, that is. Not PTS-DOS... And since you mention only EDR-DOS's tweaks requiring a better DEVLOAD, shouldn't I add that DEVLOAD already contains handling for some DR-DOS oddities and therefore contains proper DR-DOS detection code anyway? Actually I had hoped DR DOS would eventually grow *more* compatible so devload could be simplified at the cost of only supporting new DR DOS. I THINK you could make some components compile time omitable but I also think that support only OW is a risky idea as... This was a
Re: [Freedos-kernel] Hello again
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.svn.sourceforge.net/viewvc/freedos/kernel/trunk/ http://freedos.svn.sourceforge.net/viewvc/freedos/kernel/branches/UNSTABLE/ The problem is that there were almost no changes in UNSTABLE in the last 3 years, so it will need undusting before it can be useful for new experiments. I suggest to put the main focus on careful, non-experimental bugfixes for trunk for the moment. Please move any discussions of FAT+ to a different topic I agree :-) because my main point is to ensure the kernel behaves stable and predictable when encountering files 2GB. I never mentioned adding any destabilizing or incompatible functionality Then this FAT+ thing sneaked in... It is indeed unrelated to the topic of support for files sized between 2 and 4 GB :-) intent is to only support OW so I can simplify some... There are good reasons to support multiple compilers... Ohhh I smell a misunderstanding :-) I had assumed you or Pat were planning to make a fresh minimalistic start with a DOS kernel that can only RUN OW. This is partly because there is another DOS clone which was actually made to be good enough to RUN Borland compilers, too :-). the more compilers supported the more chance of unnoticed bugs or warnings being found and more chance others will contribute Interesting point :-) However, supporting more compilers means more chance changes will break (runtime or compile time) builds with one of the lesser True... Still worth trying ;-) Eric -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Freedos-kernel Digest, Vol 29, Issue 1
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 which DOS apps would be happy about support for files bigger than 4 GB at all? The support for Win 3.1 / WfW 3.11 is as follows: Any normal FreeDOS runs standard mode (Win /s in 3.1 or safe mode of WfW 3.11) but for 386enh mode of 3.1 or default mode of WfW 3.11 you have to run a special version of the unstable kernel branch. In freedos 1.0 the package is called winkern. This is a compile-time experimental option of the experimental unstable kernel branch which is not enabled in default compiles :-). Eric -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Hello again
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 course you can add it to the unstable branch so people can try it there nevertheless... Support for files between 2 and 4 GB size, on the other hand, is very well-defined, compatible and safe to add, I already have some notes about which knobs need fiddling for that :-). this involves the risk of breaking stuff inside the kernel, and is not (and never will be) supported of any other operating system. If you ask me, it would be even better to have a MINIMAL (eg only readonly, only root directory) ISO9660 / EXT2 / NTFS / whatever driver in the kernel and load a separate full driver for that file system later. Or, even easier, load DOS in a MEMDISK via anything that can load Linux (grub4dos, grub, lilo, syslinux...) and put filesystem drivers there. The need for using extremely big files in DOS is minimal but having compatibility to any other OS is extremely useful :-p. Actually the only large file app that I can think about would be one that juggles with DVD diskimages... That one app could split the diskimages over 3 files, each smaller than 4 GB :-). EDR already supports this. who cares ? My personal opinion that some recent filesystem tweaks in EDR DOS are a big pain for lowlevel tools... For example EDR DOS might try to play nice for FAT16 apps and as a side effect lure FORMAT into making 8 GB almost-FAT16 filesystems when it tries to hide FAT32. Another example are EDR-specific extensions of the FAT32 BPB that make it necessary to modify DEVLOAD to work with EDR DOS etc ;-). Eric -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel build 2038rc1 testing
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 GEM/XM (multitasking variant) http://gem.shaneland.co.uk/downloads/OpenGEMXM.zip and the OpenGEM SDK (link on main page, basically all the stuff needed to run and build programs for GEM including full source). From what I've read, GEM/XM was a branch of GEM v2, so both use FCBs. ... Hmmm I do not understand the problem here... I downloaded the OpenGEMXM file and unzipped it... Then I found a GEM BAT file where I had to adjust some paths. The first attempt to run it failed, because apparently you cannot(?) SUBST dosemu magic drives which are just a DOS view on a Linux directory. But after copying the files to a FAT drive (diskimage) and some GEM BAT editing to adjust paths again, GEM just worked :-). I could not find any LOAD*.* file in the zip, though... Maybe this whole experiment is something different than IBID meant? Eric PS: Attempting to use SUBST to create a drive letter backed by a directory in a dosemu magic drive creates a drive which does not contain any files. I did not check why. PPS: I also had to change my LASTDRIVE setting in config sys to Z because GEM BAT wanted to create X and Y drive letters. Tests done with 8/2008 made 2038rc/SVN kernel, dosemu 1.4.0. -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] PATCH: sys fix
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 ; trash old return address -mov bp,sp -xchgbp,[2+bp] -pop bp +add sp,2; trash old return address ... cmp cl,024h -jbe cpm_error +ja cpm_error ... -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] PATCH: sys fix
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 things overlapping those things listed below, please announce so we can coordinate. You may also want to read the state of kernel 2037 and state of kernel 2038 threads on the freedos-user in Feb 2009. High on the wishlist for 2037 would be extending that SVN changelog wiki page and a backport of country sys support to 2038 stable. Eduardo may be considering to work on that backport... For SYS, I would suggest an option to enforce either LBA or CHS style boot, in particular for FAT32, via the command line. The wishlist for the stable 2038 kernel is quite short: Insert patches listed below, update changelog file and make a SF file release :-). Patches waiting here for review, comments, uploading: - *Bart*: SYS compileability with OpenWatcom C 1.8 and newer (in SVN) - Eric: dosfns.c / fatfs.c / proto.h SHARE tuning (safe afair) - Christian: entry.asm revamp to fix the CP/M call (review!) http://sf.net/tracker/?func=detailaid=2421577group_id=5109atid=105109 - Any: (?) update changelog, update my email addr in the docs http://freedos.svn.sourceforge.net/viewvc/freedos/kernel/trunk/?view=log - RayeR: init-mod.h always say BSS_INIT(x)=x (workaround OW bug?) - Tom: inthndlr.c bugfix for int 21.1c no-FAT case - RayeR: initdisk.c CHS cyl off-by-one and total_sectors overflow and DebugPrintf drive param format string fixes - Any: If DSSI points to partn (00 or 80) in FAT16/32 boot sector then take partn offset from DSSI+x (I *had* a patch but where??) - Eric: re-enable drive access flag handling to make unformatted drives more properly unformatted, disk tools should be fine now? - Christian: patch related to exit/resident if self-owned PSP (he pasted the patch in a recent thread on the mailing list) - Any: (Eric?) support 4 GB file size by changing sft_size, sft_posit to unsigned (dir_size, f_offset already are) and changing lseek error reporting (no longer treat negative as fail) - seems you can let SftSeek accept ANY dos_lseek retval as errors are already checked by SftSeek itself before calling dos_lseek? DosSeek just calls SftSeek, needs no changes. The sft_size / sft_posit change might require adjustments to that at some places in the code. - Any: (?) support that extended open flag which allows sizes above 2 GB: DosRWSft should throw error 5 access denied if you try to write beyond that file offset if that flag is not set (shrug ;-)) - Any: implement int 2f.1228?? Apparently exists but commented out?? Thanks for the explanation of OW 1.8 / 1280 get/setftime un- DOS-ification of headers to gain MS VC / DJGPP compat ;-). Eric -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] PATCH: sys fix
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 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 they do it? - when did they do it, what is version 1280? - what are the hopes that they fix that regression? Eric PS: Is the kernel compilation itself affected, too? -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] [Freedos-user] was: Windows 3.1 - Pending kernel patches 2037/2038
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 necessary patches, of There are also patches waiting for feedback / review / testing. Saying you have to modify this like that is one thing, discussion is another. 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 seems Eric doesn't exactly want to be the kernel maintainer, you need someone else for that. Uhm you do not exactly motivate me but I can repeat the state of things: The 2038 kernel needs mainly doc updates plus some feedback for a few small pending patches. The lists are too silent on that. Of course I could just push the patches and assume they will work, but that is the non-preferred choice. The mentioned patches are: None of those patches is necessary for the 2038 kernel but on the other hand some of them are definitely useful, yes :-). - Terminating self-owning PSPs (parent PSP field set to the PSP) doesn't work. There's a patch for this in inthndlr.c but it's wrong and leads to crashes. The patch in inthndlr.c (below case 0x4c of the main Int21 handler) has to be removed, and the condition of a self-owning PSP has to be handled like a TSR termination in the return_user function in task.c. 2037 is affected by this, too. Afair, self-owning PSPs happen in shells and in DEBUG etc, but I do not remember having problems with leaving DEBUG. Leaving the main SHELL is not a good idea anyway. Plus the origins of your inthndlr.c / task.c patch are a bit fishy copyright-wise. - CALL 5 interface is broken, and probably crashes the system. Note that only CP/M programs use this, software from the seventies. The Assembly code in entry.asm that handles such calls is screwed up. I can provide working replacement code or patch it to work how it's supposed to. 2037 is affected by this, too. The patch was long ago and I remember the discussion about it was aborted too early. It should have been on the list, too. I believe it was a do what I say or forget it request ;-). - The seek position (and various other fields) of the SFT isn't declared as unsigned. Eric reported that the seek function reports errors using negative return values. This has to be changed so that it can work with files up to 4 GiB. Depending on when the seek function is called (whether it's already determined that the handle references a valid SFT, and that the origin in al is valid) you might just remove any error reporting of it, since the actual seek operation never returns errors in MS-DOS (as mentioned in RBIL and UDOS too). 2037 seems not to be affected by this, at least the case 0x42 in inthndlr.c should work with larger seek positions. I agree that supporting files above 2 GB size is high on the wishlist and reasonably easy to implement. Will work on it :-) I've CCed the Freedos-kernel list, too. Okay, so I guess I have to CC both lists, too :-) Eric -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] [Freedos-user] was: Windows 3.1 - Pending kernel patches 2037/2038
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 now. I guess I should first re-send the patches somewhere for discussion? Or should I just upload them to SVN already? The latter is probably easier, in particular as I do not expect real bugs here anyway... - Terminating self-owning PSPs (parent PSP field set to the PSP) Okay okay so paste your diff -u for inthndlr.c and task.c again and we can discuss it... As usual, minimal patches are preferred :-). - CALL 5 interface is broken, and probably crashes the system. Note that only CP/M programs use this, software from the seventies. Yes, and DOS is mainly software from the eighties and nineties ;-) The Assembly code in entry.asm that handles such calls is screwed Same as above - paste a diff for that one, too. Be aware that the entry.asm stack layout is sort of critical so I would prefer to get any type of comment from any of the old experts before sticking the CP/M-ish call 5 fix into the stable branch. Maybe it could also be added only to the unstable branch first? I think one of the problems with your original patch was that it made the stack footprint bigger so if you can modify your patch to avoid/reduce that side-effect...? - The seek position (and various other fields) of the SFT isn't declared as unsigned. Eric reported that the seek function reports errors using negative return values. This has to be changed so that it can work with files up to 4 GiB... Indeed - several functions will have to pass a pointer to an extra return status argument to work around this complication, but on the other hand, the patch will still not be very complex, I hope. Maybe it can also be an alternative to support files up to 3.999 GB and leave a small range of values reserved for error codes? Also depends on which of the methods has which impact on kernel size and speed? since the actual seek operation never returns errors in MS-DOS I seem to remember this point from an earlier discussion yes... Eric -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Free version of Alone 2
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 menu with the ESC key but nothing fancy happens apart from that. Without the 8 0 options, the game tries to open PAK files with nonsense names or crashes, so it probably makes the PAK filenames by inserting the options into strings. A typical reaction to other options than 8 0 is that the main exe tries to open etage00.pak or etage0/.pak ;-). It also sometimes starts up without complaining but showing only a black screen while playing (the menu still works unless you block it with the -d option). As there are no docs explaining the options, I cannot tell much more. The install tool is mouse-controlled MCGA, but it does not seem to allow you changing drive, path or graphics mode. You just unzip the file into the drive or path you want and then run the install tool, it seems. FM music choices are: None, Adlib, Soundblaster, Soundmaster. Sample/DSP soundcard choices are: None, PC Speaker / Buzzer, SB with DMA, Voice- master, Soundmaster, SB without DMA. It seems the install tool sometimes sends data to the printer port and/or thinks you want to exit it, so better unconnect your printer first. Maybe this is part of some Covox sound detection routing? Setting the FM sound to adlib seems to crash the game demo at once when you start it in dosemu - as this is the default setting, you should make sure to use the setup tool ;-). All FM options seem to crash for me, actually. As for the DSP sound: SB DMA sounds a lot better than the PC Speaker / Buzzer option, even in dosemu :-). Not all actions have sound effects though. I guess the plot of the demo is: A man breaks into a house, tries to rescue somebody, a clown puppet somehow kills him. Not really my taste :-p By the way, if you select Voice Master then you see that it actually means Voice Master II, Speech Thing or DAC. This is just another wording for Covox D/A on the printer port ;-). The SB-without-DMA setting is silent for my in dosemu, dunno. Some other soundcard options for sampled sound effects crash. Eric http://baixatudo.globo.com/Baixatudo/Categoria/Jogar/0,,DOA30330-7644-ALONE+IN+THE+DARK+2,00.html there is a free demo version of Alone in The Dark 2 to do tests. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Error compiling - SYS.C OpenWatcom version differences
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 version of Open Watcom and NASM 0.98
sys.c(1050): Warning! E1176: Parameter 2, pointer type mismatch
sys.c(1050): Note! I2003: source conversion type is 'unsigned short *'
sys.c(1050): Note! I2004: target conversion type is 'unsigned int *'
sys.c(1050): Note! I2002: '_dos_allocmem' defined in: c:\watcom\H\dos.h(161)
1046 /* allocate dos memory */
1047 #ifdef __TURBOC__
1048 if (allocmem((unsigned)((*filesize+15)4), theseg)!=-1)
1049 #else
1050 if (_dos_allocmem((unsigned)((*filesize+15)4), theseg)!=0)
1051 #endif
1052 {
1053 printf(Not enough memory...
The filesize variable is a pointer to unsigned 32 bit integere here.
The theseg variable is unsigned 16 bit integer here. Which versions
of OpenWatcom expect which _dos_allocmem parameter types? It seems
plausible to use 16 bit segments if you ask me...
Do both OpenWatcom 1.7 and 1.8 complain? Maybe a regression?
sys.c(1079): Warning! E1176: Parameter 2, pointer type mismatch
sys.c(1079): Note! I2003: source conversion type is 'unsigned short *'
sys.c(1079): Note! I2004: target conversion type is 'unsigned int *'
sys.c(1079): Warning! E1176: Parameter 3, pointer type mismatch
sys.c(1079): Note! I2003: source conversion type is 'unsigned short *'
sys.c(1079): Note! I2004: target conversion type is 'unsigned int *'
sys.c(1079): Note! I2002: '_dos_getftime' defined in: c:\watcom\H\dos.h(188)
1078 #if defined __WATCOMC__ || defined _MSC_VER
1079 _dos_getftime(fdin, filetime-date, filetime-time);
1080 #elif defined __TURBOC__
1081 getftime(fdin, filetime);
1082 #endif
This is related to:
160 #ifdef __TURBOC__
161 typedef struct ftime ftime;
162 #else
163 typedef struct
164 {
165 unsigned short date, time;
166 } ftime;
167 #endif
It seems newer OpenWatcom versions like using int a lot, but why?
Since when is this the case? Do you know a macro for making the
line 165 depend on the version of OpenWatcom? Or maybe better, is
there a header file which makes using _dos_getftime / _dos_setftime
easier, if possible version independent in OpenWatcom?
Eric
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] state of kernel 2038
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 freedos/kernel/dosfns.c rayer/kernel/dosfns.c
--- freedos/kernel/dosfns.c 2007-07-28 18:40:25.0 +0200
+++ rayer/kernel/dosfns.c 2008-11-30 18:38:06.0 +0100
@@ -289,7 +289,7 @@
/* a block transfer */
/* /// Added for SHARE - Ron Cemer */
- if (IsShareInstalled() (s-sft_shroff = 0))
+ if (IsShareInstalled(FALSE) (s-sft_shroff = 0))
{
int rc = share_access_check(cu_psp, s-sft_shroff, s-sft_posit,
(unsigned long)n, 1);
@@ -581,7 +581,7 @@
}
/* /// Added for SHARE. - Ron Cemer */
- if (IsShareInstalled())
+ if (IsShareInstalled(TRUE))
{
if ((sftp-sft_shroff =
share_open_check(PriPathName, cu_psp,
@@ -625,7 +625,7 @@
else
{
/* /// Added for SHARE *** CURLY BRACES ADDED ALSO!!! ***. - Ron Cemer */
-if (IsShareInstalled())
+if (IsShareInstalled(TRUE))
{
share_close_file(sftp-sft_shroff);
sftp-sft_shroff = -1;
@@ -755,7 +755,7 @@
return dos_commit(sftp-sft_status);
/* /// Added for SHARE *** CURLY BRACES ADDED ALSO!!! ***. - Ron Cemer */
- if (IsShareInstalled())
+ if (IsShareInstalled(TRUE))
{
if (sftp-sft_shroff = 0)
share_close_file(sftp-sft_shroff);
@@ -1354,7 +1354,7 @@
return remote_lock_unlock(s, pos, len, unlock);
/* Invalid function unless SHARE is installed or remote. */
- if (!IsShareInstalled())
+ if (!IsShareInstalled(FALSE))
return DE_INVLDFUNC;
/* Lock violation if this SFT entry does not support locking. */
@@ -1444,10 +1444,13 @@
}
/* /// Added for SHARE. - Ron Cemer */
+/* Eric 8/2008: only re-check (2f.1000) on open/close, not on each
access */
-BOOL IsShareInstalled(void)
+BOOL IsShareInstalled(BOOL recheck)
{
extern unsigned char ASMPASCAL share_check(void);
+ if (recheck == FALSE)
+return share_installed;
if (!share_installed share_check() == 0xff)
share_installed = TRUE;
return share_installed;
diff -bur freedos/kernel/fatfs.c rayer/kernel/fatfs.c
--- freedos/kernel/fatfs.c 2008-04-04 17:36:58.0 +0200
+++ rayer/kernel/fatfs.c2008-11-30 18:34:28.0 +0100
@@ -447,7 +447,7 @@
f_node_ptr fnp2;
int i, fd;
- if (!IsShareInstalled())
+ if (!IsShareInstalled(FALSE))
return;
fd = xlt_fnp(fnp);
--- freedos/kernel/proto.h 2008-04-04 17:36:58.0 +0200
+++ rayer/kernel/proto.h2008-11-30 18:34:56.0 +0100
@@ -112,7 +112,7 @@
COUNT DosRenameTrue(BYTE * path1, BYTE * path2, int attrib);
COUNT DosMkRmdir(const char FAR * dir, int action);
struct dhdr FAR *IsDevice(const char FAR * FileName);
-BOOL IsShareInstalled(void);
+BOOL IsShareInstalled(BOOL recheck);
COUNT DosLockUnlock(COUNT hndl, LONG pos, LONG len, COUNT unlock);
int idx_to_sft_(int SftIndex);
sft FAR *idx_to_sft(int SftIndex);
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] state of kernel 2038
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.
Question: Are there any side effects?
Thanks for commenting :-)
Eric
$ svn diff freedos/
Index: freedos/kernel/initdisk.c
===
--- freedos/kernel/initdisk.c (Revision 1365)
+++ freedos/kernel/initdisk.c (Working Copy)
@@ -318,7 +318,7 @@
type = regs.b.b.l - 1;
if (regs.flags 1)
type = 0; /* return 320-360 for XTs */
- else if (type 6)
+ else if (type = 6)
type = 8; /* any odd ball drives get 87=0: the
320-360 table */
else if (type == 5)
type = 4; /* 5 and 4 are both 2.88 MB */
@@ -577,7 +577,7 @@
if (nUnits = NDEV)
{
-printf(more Partitions detected then possible, max = %d\n, NDEV);
+printf(more Partitions detected than possible, max = %d\n, NDEV);
return; /* we are done */
}
@@ -719,7 +719,7 @@
lba_bios_parameters.sectors 0x ||
lba_bios_parameters.totalSectHigh != 0)
{
-printf(Drive is too large to handle, using only 1st 8 GB\n
+printf(LBA drive properties implausible, using only 1st 8 GB\n
drive %02x heads %lu sectors %lu , total=0x%lx-%08lx\n,
drive,
(ULONG) lba_bios_parameters.heads,
@@ -1269,7 +1269,7 @@
pddt-ddt_driveno = driveno;
pddt-ddt_type = init_getdriveparm(driveno, pddt-ddt_defbpb);
pddt-ddt_ncyl = (pddt-ddt_type 7) ? 80 : 40;
- pddt-ddt_descflags = init_readdasd(driveno) | flags;
+ pddt-ddt_descflags = init_readdasd(driveno) | flags | DF_DISKCHANGE
| DF_NOACCESS;
pddt-ddt_offset = 0;
pddt-ddt_serialno = 0x12345678l;
Index: freedos/kernel/dsk.c
===
--- freedos/kernel/dsk.c(Revision 1365)
+++ freedos/kernel/dsk.c(Working Copy)
@@ -374,8 +374,8 @@
unsigned secs_per_cyl;
WORD ret;
- /* pddt-ddt_descflags |= DF_NOACCESS;
- * disabled for now - problems with FORMAT ?? */
+ pddt-ddt_descflags |= DF_NOACCESS;
+ /* was disabled - problems with FORMAT ?? */
/* set drive to not accessible and changed */
if (diskchange(pddt) != M_NOT_CHANGED)
Index: freedos/kernel/main.c
===
--- freedos/kernel/main.c (Revision 1365)
+++ freedos/kernel/main.c (Working Copy)
@@ -126,14 +126,10 @@
}
/*
-InitializeAllBPBs()
-
-or MakeNortonDiskEditorHappy()
-
-it has been determined, that FDOS's BPB tables are initialized,
-only when used (like DIR H:).
-at least one known utility (norton DE) seems to access them directly.
-ok, so we access for all drives, that the stuff gets build
+InitializeAllBPBs() or MakeNortonDiskEditorHappy() - FreeDOS
+does DPB setup on demand (eg DIR H:, via media_check, bpb_to_dpb)
+so we touch all drives to make sure DPB are filled in. For some reason,
+this was described as init BPB to make Norton Disk Edit happy...?
*/
void InitializeAllBPBs(VOID)
{
@@ -145,6 +141,14 @@
if ((fileno = open(filename, O_RDONLY)) = 0)
close(fileno);
}
+ /* chdir(A:\\) would need intr.asm/init-mod.h ext. but nicer than
open() */
+#ifdef WITHFAT32 /* mark drive as not FAT32 to allow int25/26 access */
+ /* floppy is DF_NOACCESS until 1st media_check or int 21.440d.0847 */
+ LoL-DPBp-dpb_fatsize = 1; /* not 0, that would be FAT32 */
+ LoL-DPBp-dpb_next-dpb_fatsize = 1; /* not 0, that would be FAT32 */
+ /* bpb_to_dpb(ddt_defbpb...) would be perfect but is not accessible */
+ /* media_check(get_dpb(0)); / int 21.32 etc would access phys drive */
+#endif
}
STATIC void PSPInit(void)
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Bad or missing Command Interpreter
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 configuration which just loads command.com ... and fails with that, too, in your case :-). My BIOS sets the Equipment List word (0040:0010) to 043C (no floppy) and returns this value by INT11. I believe recent versions of the kernel install two dummy drive letters for A: and B: then. If you say you only have 1 floppy, you get A: and B: sharing a drive, with that change disk and press key message or similar to switch between the drive is A: now and the drive is B: now... I think DOS is used to having some A: drive, so you could try what happens if your BIOS says that A: exists but always returns no disk in drive error messages ;-). The kernel probably does not mean drive A: when it says drive 0, I guess it means harddisks[0] then, which is drive 0x80. The kernel will normally check both A: and all harddisk drives which exist, based on some int13 how many installed harddisks? call. Your BIOS, MBR (if applicable) and boot sector have to pass the boot drive number (see RBIL, I believe it was passed in BL or DL) to let FreeDOS know which drive - either A: or C: - has to be used for loading the (fd)config.sys file :-). B maps to A and A maps to C if A and B do not exist? No, harddisks always start at C:, and drives A: and B: will be either 2 floppies, 1 floppy and a clone of it, or two dummy drive letters, all depending on how many floppy drives you have. My BIOS INT13 only support one hardisk (drive=80h) and will return 0Ch (unsupported track or invalid media) in AH if the kernel tries to access any other drive I do not know by heart, but I would say there should be a return value for invalid drive, too. And do not forget to set/reset the carry flag on error/success. DYNDATA:allocating ddt - 1 * 104 bytes, total 104, 0..104 DYNDATA:allocating ddt - 1 * 104 bytes, total 104, 104..208 Probably the two dummy floppy drives... DSK init: found 1 disk drives drive parameters 80 - 196854-32-26 total size 7MB That is the harddisk... Error reading partition table drive 00 sector 0 drive parameters 80 - 196854-32-26 total size 7MB Note that harddisks have to be partitioned, maybe you had an unpartitioned CF and DOS treated boot sector contents as a pointer to a partition at a bad location, or maybe there is some other issue with your BIOS... On the other hand, the boot sector apparently was okay, otherwise you would not have gotten that far :-). SDA located at 0x00d3:0320 DYNDATA:allocating DPBp - 2 * 33 bytes, total 66, 208..274 init_buffers (size 532) at (8cee:) done Preliminary: f_node 0x8f87: sft table 0x00d3:00cc CDS table 0x8c5f: DPB table 0x00d3:1a7a Preliminary allocation completed: top at 7c60:fff0 truename(AUX) CDS entry: #0 @8c5f: (2) 'A:\' Absolute logical path: A:/AUX ... truename(fdconfig.sys) CDS entry: #0 @8c5f: (2) 'A:\' SUBSTing from: A:\ ... As you can see, FreeDOS believes you booted it from floppy, because it wants to read files from A: and not from C: ... You have to pass the right register values from int19/BIOS to the MBR. The MBR should then pass the values to the boot sector and that should pass them to the kernel, but if you use the standard MBR and boot sector, I would say that the problem is probably in your BIOS int 19 code ;-). Eric PS: When you are done with all this, you could write a summary about all the caveats of making an embedded system ready for running FreeDOS, a howto maybe :-) - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] [Freedos-user] init_device crash/hang
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 that was one of the values used in the anonymous bios source code which is floating on the web. Quite exotic. How about using a maintained open source BIOS? I mean okay the Bochs / Qemu / ... LGPL-ed BIOS is way more than 8 kB, but you can probably cut and paste parts to pimp your BIOS. As long as you follow the LGPL, of course... No real problem, I assume your BIOS works okay :-). Changing it to 640 resulted in: HMA moving 026e: up to 8fbd: for 9e3f bytes Hmm. More or less plausible. I use OpenWatcom 1.7a. I had to change DOS.H slightly to force the else prototype //#if defined(__NT__) || ( defined(__OS2__) (defined(__386__)||defined(__PPC__)) ) //_WCRTLINK extern unsigned _dos_allocmem( unsigned __size, void **__storage ); //#else _WCRTLINK extern unsigned _dos_allocmem( unsigned __size, unsigned short *__seg ); //#endif Can you explain this in more detail? Maybe OW 1.7 somehow failed to realize that your target is compiling for DOS... I will install Watcom 1.2 as this is the recommended version. Makes sense, but we should also know whether OW 1.7 can work. I think this is my mistake, please ignore :-) What was it? PS: SOURCE_DATE_STRING being set to Sep 09 2005 indicates you do not use the most recent sources - please update to SVN or http://rugxulo.googlepages.com/ke2008mar8-src.zip Interestingly this version gets a lot further To suggest another experiment - try a precompiled kernel from Rugxulo's page. There are OW and TC kernels, FAT16 and FAT32 kernels and x86 and i386 kernels. Pick one of your choice from the zip and rename it to kernel dot sys. Avoids the risk of introducing problems while compiling your own variant of kernel... ;-). You should also check whether you can tune things in the build batch config batch file, might be useful somehow. FreeDOS kernel build 2038 [version Mar 9 2008 compiled Oct 26 2008] Kernel compatibility 6.22 - WATCOMC (C) Copyright 1995-2006 Pasquale J. Villani and The FreeDOS Project. Sigh, remind me next month to fix that to say 1995-2008 ... KERNEL: Calling InitIO.. NUL CON PRN AUX LPT LPT LPT COM COM COM COM CLO NUL KERNEL: Calling InitPrinters.. KERNEL: Calling InitSerialPorts.. KERNEL: Calling DOS_PSP.. You mean PSPSet... KERNEL: Calling set_DTA.. Now it seems to get struck in the int 21h/1a handler, isn't debugging with printf statements fun ;-) So PSPInit is not reached? Note that DOS_PSP is #defined to 0x60... if you modify the boot loader or the build batch file to use another location then you will have to adjust DOS_PSP as well. The constant also appears as LOADSEG in the ASM source of the boot sectors and as command line argument for exeflat in the build batch file as well as in the sys sources as load_segment (command line changeable). Eric - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] [Freedos-user] init_device crash/hang
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 a bit misleading - the kernel is moved to the end of DOS RAM instead of to the HMA (I assume you do not have HIMEM loaded yet ;-))... What worries me here is that moving 40 kB to a location only 0.5 kB before the end of the first 640 kB of RAM means that a part of the kernel will end up AFTER that - it could fall into a hole without any RAM, or it could end up in the VGA RAM if it exists?? Maybe your int 0x12 handler reports too much DOS RAM? Or maybe your _CS or FP_SEG have problems? Do you use the recommended OpenWatcom or Turbo C 2 compilers or something else? I must say the calculation of the arg for MoveKernel (lpTop) looks a bit like black magic... KERNEL: Calling InitIO()... *InitIO* *InitIO* *InitIO* *InitIO* *InitIO* *InitIO* *InitIO* *InitIO* *InitIO* *InitIO* *InitIO* *InitIO* At which place did you insert that InitIO printing? If in init_device, then maybe you can make it show which device it handles. Normal sequence would be: nul, con, prn, aux, lpt1, lpt2, lpt3, com1, com2, com3, com4, clock$, blockdevices Invalid Opcode at 0F68 00D0 3286 00D0 D400 8227 1332 7003 E000 7C27 7CAD FEAD 72FF ... whatever ;-) It is also possible that initio worked and you crashed in InitPrinters instead, which calls int 0x11 and 0x17.0100? Eric PS: SOURCE_DATE_STRING being set to Sep 09 2005 indicates you do not use the most recent sources - please update to SVN or http://rugxulo.googlepages.com/ke2008mar8-src.zip - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Big disk - 500Gb
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: 1. I had to mimick a fdisk /mbr to make anything boot 2. I had to say my partition is LBA and bootable. 3. I had to tell sys-freedos-linux that the disk and offset are 255 (auto) and 63 (see fdisk -u -l in Linux) respectively as mkdosfs had failed to set those. I also told sys-freedos-linux to use LBA style boot sectors to avoid any geometry troubles but that was optional :-). 2) booted FreeDOS 1.0, and with fdisk deleted everything and creared only one primary partition for the whole disk Why did you delete the partition and make a new one again? Same bugfix suggestions as for step 1. 3) rebooted 4) fdisk /mbr (to remove grub) 5) format c: /s /u Try without /s. Use the /d option to get debugging messages. Use the combination /q /u unless you insist on waiting for days until format completes. Really. So: FORMAT C: /Q /U /D I get this message: FATAL: Cliuster size is not 0.5, 1, 2, 4, 8, 8, 16, 32, or 64k but 0.0k. [Error 58] This means the kernel did not suggest any cluster size for that partition. Maybe it is the wrong FAT type for the size. See the suggestions for step 1. And make sure you use a recent kernel, for example http://rugxulo.googlepages.com/ (kernel from disk one of the distro there for example) :-). Eric - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Two problems and patches related to Floppy Disk
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 new FD has No 55-aa magic number in boot sector. You might have fixed that the wrong way round... FreeDOS tries too much to behave well for unformatted disks, which should be fixed in www.coli.uni-saarland.de/~eric/travis.zip ... the idea is to make clear that disks are not in standard format instead of trying to treat them as if they were. The QUESTION is whether all your disk tools enjoy the patch :-). The GOOD thing is that things should be safer the Travis way. The BAD thing is that you will probably have to (quick-) format your Maxell disks once before the Travis style kernel lets you access them. Please try :-). Problem 2: Floppy disk change recognition problem. Implementing int 13 hooking can be quite complex, how long is your patch and did you check it and have it reviewed? Our own UNSTABLE kernel branch for example had int 13 hooking as work in progress but I think it was not smooth yet. You can find the source of this branch in our SVN repository :-). Eric Problem 1: Maxell new FD has No 55-aa magic number in boot sector. When we used Maxell FD, we encountered strange phenomena. We wrote files to FD. Write process was looking good. But there is no file in checking the FD on Windows... getbpb... if non 55aa then FreeDOS assumes 720k (??)... ROM-DOS, PC-DOS and Windows has no problem with the Maxell FD. So I think FreeDOS is too strict in checking boot sector format. Original FreeDOS checks 55-aa magic number and sector size (=512). My patch disables checking of 55-aa magic number and only checks sector size... fdos-maxell-fd-patch-080818.diff modifies kernel/dsk.c. Problem 2: Floppy disk change recognition problem. When we write two FD on our application, the first FD's directory entries was copied onto the second FD. This problem was not occurred on ROM-DOS and PC-DOS. After precise investigation, I found that our application is calling BIOS int-13h AH=02h(Sector read) before the second FD write. Ouch. Test program DISKCHG.C demonstrates this problem through steps as follows. 1. insert disk-1 2. write A:FILE1 calling DOS 3. change FD to disk-2 4. read FD boot sector calling BIOS int-13h AH=02h Probably to verify that disks were changed, but in FreeDOS with the side effect that DOS itself misses the change... 5. write A:FILE2 calling DOS Disk-2 directory entry contains two files FILE1 and FILE2. Normally disk change is notified on calling BIOS int-13h AH=00h-05h,08h, 15h-18h. But disk change notification from BIOS is the ONLY ONCE. Exactly... So on the subsequent call of BIOS int-13h AH=16h(Detect disk change) from FreeDOS kernel, no disk change will be notified and FD cache in kernel will NOT be flushed. Then the first FD's directory data will be written into the second FD. My patch introduced int-13h hooking. Disk change status on calling int-13h AH=00h-05h,08h,15h-18h is memorized and reported on the call of fl_diskchanged(). What motivated your selection 0-5,8,15h-18h? Sounds okay :-) Perfect disk change recognition will be accomplished by the patch. Possibly ;-) Though I have not examined other DOSs(PC-DOS, ROM-DOS), the same hooking may be used. Good idea - avoid touching closed source software while writing GPLed software to stay on the cleanroom side :-). Eric - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] share install check called too often?
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 can be queried at any moment to see whether share is installed. However, freedos stops asking as soon as it gets the answer yes share is there. It would be easy to change that into asking again from time to time to be aware of share shutdowns. But... I believe share cannot unload anyway? Share needs to be checked during delete operations as well That might be interesting to do but probably low priority... 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). Eric - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] BUFFERSHIGH not recognised in config.sys
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 loaded correctly into HMA, nevertheless FreeDOS tells me that it does not like this option while it is parsing the config.sys. Other options like FILESHIGH, LASTDRIVEHIGH etc. are all found and defined in config.h / config.c. As far as I remember, FILESHIGH / LASTDRIVEHIGH is something from Windows 95/98 DOS which puts the data structures in question into UMB, not into HMA...? What you would/should do in FreeDOS is DOSDATA=UMB which puts all FILES, LASTDRIVE and so on data which can be moved into UMB into UMB :-). Eric - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] initdisk floppy error bpb set up dpb empty
Hi everybody, I need some advice from kernel experts: when checking the error reported by Travis in the freedos-user thread Travis I found that initdisk does setup the DDT BPB and default BPB correctly for A: and B:, but fails to setup the DPB. As the latter is used to check if int25/26 access is okay for a drive, attempts to use int25/26 fail until something triggers a media_check (e.g. DIR A:). To check your own system: Use int 21.52 to get the ES:BX addr of the List of Lists, first entry is a far pointer to the DPB array. Entries in the DPB array are 0,0,[empty],70:5bc,0,ff*,[-next],[empty] for A: and 1,1,[empty],70:5bc,0,ff*,[-next],[empty], with the ff triggering an update on media_check. With DOSEMU, entries for redirected Linux directory as DOS drive suffer from the same emptiness, while all real harddisk style drives have their DPB data filled in properly. My problem: WHAT, WHY and HOW does set up the DPBs during boot? For floppy, the BPB are initially set to the BPB for the default capacity, so there is no need to access the (possibly empty) drive at boot for that. But the DPBs have to set up as well, as explained above. The FsConfig in main.c seems to init the CDSp[...] array entries and their pointers to DPB blocks and update_dcb adds yet more data for block devices added via DEVICE/DEVICEHIGH or (even before FsConfig) from dsk_init (the kernel block device driver setup for BIOS int13 disks). Actually FsConfig is called twice, before and after configsys is processed. Something quite interesting is InitializeAllBPBs which tries to open a nonexisting file on C: and all later drives but not on A: and B: - this is described as make Norton Disk Editor happy by initializing BPB tables (probably meant to say DPB tables). This is called at the end of init_kernel after all FsConfig. Is there a more elegant way than opening a bogus file? Is this where the DBP get set up? Looks like not only Norton but also the FreeDOS kernel itself needs proper DPB setup at boot even though the comment claims that FreeDOS sets up BPB tables (DPB?) only when used. Maybe the problem is something different: inthndlr.c int2526_handler uses get_dpb and maybe that one is supposed to use media_check? Extra questions: Should make_ddt set ddt_descflags to indicate DF_DISKCHANGE and/or DF_NOACCESS? (initdisk) Does anybody expect any problems when I re-enable the old disabled problems with FORMAT DF_NOACCESS for disks in getbpb if RWzero fails for that drive or if the boot sector of that drive does not look like FAT? I mean somebody with some test drives could test if FORMAT still works, but which other apps and kernel issues might be triggered by the NOACCESS? Personally, I think it is a bad idea that FreeDOS now pretends that an invalid FAT drive is already sort of okay. Nice to help FORMAT, but probably bad side effects... Thanks for your feedback guys :-) Eric - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] initdisk floppy error bpb set up dpb empty
Hi again... I finally found a way to make a not overly
intrusive patch which hopefully fixes Travis' problem:
http://www.coli.uni-saarland.de/~eric/travis.zip has
a diff and a binary. The patch changes several things:
- init_getdriveparm would overflow for int 13.8 returning bl=7
but this is kind of unlikely to trigger (odd floppy drive types?)
- secs64k / heads64k / size2t is typically not drive too large
but broken LBA info, message changed. QUESTION: is this also
triggered by disks 500 GB? Can anybody test? Booting FreeDOS
with any such harddisk connected to the PC is enough to test.
- as DosDefinePartition already did, make_ddt (used for floppy) now
inits ddt_descflags to DF_NOACCESS (+DF_DISKCHANGE) in initdisk
- dsk.c getbpb uses DF_NOACCESS again - somebody had commented that
out long ago to make life easier for FORMAT, but it had the side
effect that unformatted/absent disks behaved too much almost ok!
The current FORMAT can change the disk access flag to get int25/26
access even to unformatted drives so things SHOULD be okay. I only
did a quick test with A:, can anybody test on a (virtual) harddisk?
- main.c InitializeAllBPBs seems to be a misnomer, so I tried to at
least correct (?) the documentation a bit... The core patch which
hopefully fixes Travis' problem is to force the empty DPB to say
at least this is not FAT32, so int25/26 are allowed. Yet you do
still have to change the disk access flag. This implicitly happens
as soon as you access a file or directory on a floppy, too :-).
Question for Travis: Does the patched kernel work for you? If not,
then you can try a classic kernel without FAT32 support. Or you can
make your tool disk access flag aware (DOS 4+ access to unformatted
or formatting-state-unknown disks compatible). Or of course you can
just drop the whole int25/26 stuff and use good old BIOS int13 or a
straightforward DOS file access for your is there a writeable disk
in the floppy drive at this moment? check routine in your tool...
Question to everybody else: Please let me know what you think about
the patch! As it is not so big, I just paste it in the mail below.
Cheers, Eric
Index: initdisk.c
===
--- initdisk.c (Revision 1364)
+++ initdisk.c (Working copy)
@@ -318,7 +318,7 @@
type = regs.b.b.l - 1;
if (regs.flags 1)
type = 0; /* return 320-360 for XTs */
- else if (type 6)
+ else if (type = 6)
type = 8; /* any odd ball drives get 87=0: the
320-360 table */
else if (type == 5)
type = 4; /* 5 and 4 are both 2.88 MB */
@@ -577,7 +577,7 @@
if (nUnits = NDEV)
{
-printf(more Partitions detected then possible, max = %d\n, NDEV);
+printf(more Partitions detected than possible, max = %d\n, NDEV);
return; /* we are done */
}
@@ -719,7 +719,7 @@
lba_bios_parameters.sectors 0x ||
lba_bios_parameters.totalSectHigh != 0)
{
-printf(Drive is too large to handle, using only 1st 8 GB\n
+printf(LBA drive properties implausible, using only 1st 8 GB\n
drive %02x heads %lu sectors %lu , total=0x%lx-%08lx\n,
drive,
(ULONG) lba_bios_parameters.heads,
@@ -1269,7 +1269,7 @@
pddt-ddt_driveno = driveno;
pddt-ddt_type = init_getdriveparm(driveno, pddt-ddt_defbpb);
pddt-ddt_ncyl = (pddt-ddt_type 7) ? 80 : 40;
- pddt-ddt_descflags = init_readdasd(driveno) | flags;
+ pddt-ddt_descflags = init_readdasd(driveno) | flags | DF_DISKCHANGE |
DF_NOACCESS;
pddt-ddt_offset = 0;
pddt-ddt_serialno = 0x12345678l;
Index: dsk.c
===
--- dsk.c (Revision 1364)
+++ dsk.c (Working copy)
@@ -374,8 +374,8 @@
unsigned secs_per_cyl;
WORD ret;
- /* pddt-ddt_descflags |= DF_NOACCESS;
- * disabled for now - problems with FORMAT ?? */
+ pddt-ddt_descflags |= DF_NOACCESS;
+ /* was disabled - problems with FORMAT ?? */
/* set drive to not accessible and changed */
if (diskchange(pddt) != M_NOT_CHANGED)
Index: main.c
===
--- main.c (Revision 1364)
+++ main.c (Working copy)
@@ -126,14 +126,10 @@
}
/*
-InitializeAllBPBs()
-
-or MakeNortonDiskEditorHappy()
-
-it has been determined, that FDOS's BPB tables are initialized,
-only when used (like DIR H:).
-at least one known utility (norton DE) seems to access them directly.
-ok, so we access for all drives, that the stuff gets build
+InitializeAllBPBs() or MakeNortonDiskEditorHappy() - FreeDOS
+does DPB setup on demand (eg DIR H:, via media_check, bpb_to_dpb)
+so we touch all drives to make sure DPB are filled in. For some reason,
+this was described as init BPB to make Norton Disk Edit happy...? */
void InitializeAllBPBs(VOID)
{
@@ -145,6 +141,14 @@
if ((fileno =
[Freedos-kernel] networkish drive cdrom detection question
Hi, I am told that int 21.4408 and 21.4409, check if block device is removable / is remote, should also work for network drives such as cdrom. As far as I understand ioctl.c, you would need a suitable IOCTL function number in the cmd table for AL=8 and 9 for this to work. Any suggestions? What else would need to be patched? Or would you just return some flags from the CDS array entry for the drive in question? Or ask int2f (net redir and/or shsucdx) in some way? Eric :-) - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Suggestion: Int 0x21, AX=0x7305, CX=0xFFFF handler
Hi Christian, the Int 0x21, AX=0x7305, CX=0x handler (FAT32 - EXTENDED ABSOLUTE DISK READ/WRITE) found in inthndlr.c, 355 ff., is implemented in a very strict way ... it corresponds to www.ctyme.com/intr/rb-3229.htm This is RBIL, Ralph Brown's Interrupt List - usually pretty useful. but some DOS applications I recently used do not set SI to 0x00 on read operations, instead they set this value (incorrectly?) to 0x6000 (as write operations are set correctly to 0x6001 - see bits 14-13)... This is interesting. The RBIL item D-217305CX explains that the low bit of SI is 0 read / 1 write while bit 13/14 indicate the accessed area: 0x0001 write any, 0x2001 write FAT, 0x4001 write directory, 0x6001 write file. It also says that reads do not specify such a type flag, but I agree with you that there is no need to reject typed reads. following code in inthndlr.c: if (r-CX != 0x || ((r-SI 1) == 0 r-SI != 0) || (r-SI ~0x6001)) ... DE_INVLDPARM ... This implementation is in int int21_fat32(lregs *r) case 0x05... the test says that no bits beyond 0, 13, 14 may be set, but it also says that if bit 0 is 0 then no type may be set and this is what breaks your compatibility. However, if you relax the test, you also have to change this: if (r-SI == 0) -- do not leave this test as ... == 0 ... Otherwise all typed reads would turn into writes! I suggest the following patch. If there are no objections, it can go into stable kernel 2038 :-). Christian, please do test this patch to see if it fixes your problem. In inthndlr.c: - if (r-CX != 0x || ((r-SI 1) == 0 r-SI != 0) - || (r-SI ~0x6001)) + if (r-CX != 0x || (r-SI ~0x6001)) - if (r-SI == 0) + if ((r-SI 1) == 0) /* while uncommon, reads CAN have type hints */ The rest of this mail is more philosophical... Read it only if you are interested in better kernel performance ;-). QUESTION to the kernel experts: It seems that only getblk but not dskxfer does anything with BUFFERS and, while doing so, would be able to actually use the type of sector contents hint for anything? Plus you would HAVE to use type hints when you write things (because if it is fat, update both copies)? See uses of BFR_DATA BFR_DIR BFR_FAT type hints for BUFFERS, in blockio.c, fat*.c and inthndlr.c although the latter only clears the type hint for a buffer with the boot sector. Note that rwblock (file and directory cluster access) can call dskxfer directly, too. Calling getblk happens via getblock or getblockOver, mostly from fat*.c for files and directories; fat*.c contains rwblock which calls dskxfer for multi sector access and getblock* for single sectors. Would it make sense if int21_fat32 could call either dskxfer or getblock* depending on whether you are doing multi sector access? Would it make sense to give getblock* and/or rwblock an optional parameter for the type hint flag, for example for more efficient or safer use of BUFFERS? Eric PS: What happens if you access the same sector via getblock and via dskxfer but the BUFFER used by getblock is dirty? Will dskxfer realize that there is conflicting write data? - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Suggestion: Int 0x21, AX=0x7305, CX=0xFFFF handler
Hi Tom, Alain, whatever 'ready' means when nobody (except you self) tested it so far. While there were no official sourceforge file releases, there are updated versions on the rugxulo distro page http://rugxulo.googlepages.com/ and I did mention those on our lists from time to time. His homepage contains a small diskette distro with FreeDOS BASE and mixed other free open source goodies, available as zips and as disk images, as well as mixed useful DOS downloads such as the mentioned FreeDOS kernel snapshots :-). In other words, the SVN snapshot kernel is part of the only useable diskette distro of FreeDOS after 0.9sr2, the Rugxulo distro :-). PROBLEM with the Rugxulo distro is that it still does not provide a download of all the sources in one file. ADVANTAGE of the Rugxulo distro is that it provides all of FreeDOS BASE and is so up to date that it is basically a prerelease of FreeDOS 1.1 :-). Of course the Joris 1.0 single diskette distro is also nice but that one is tuned towards running on 8086, so there is no 286/386/newer specific stuff available in it. Note that there is also a classic FreeDOS 1.0 diskette distro, but this contributed distro is 88 diskettes, but you can install BASE using the first 4 diskettes - which are 1680 kilobytes each. The 2-3 diskettes of the Rugxulo distro are simply 1440 kilobytes each... Actually I would appreciate it if somebody made a single 2880 kilobyte image from it, then people could use it for bootable CD/DVD :-). Note that the Rugxulo distro is just a FreeDOS which WORKS, not a FreeDOS which has to be INSTALLED on a harddisk. You can install the Rugxulo distro with SYS and some XCOPY ;-). www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/unofficial/floppy/ http://rugxulo.googlepages.com/ (Rugxulo 8086 and 386+, 2-3 disk distro) http://www.xs4all.nl/~rjoris/freedos.html (Joris 8086, 1 disk distro) in the good old times, we had a couple of prereleases, In the good old times - yes. Today it is even very hard to discuss any patch at all. Typically somebody writes me off-list about a bug, I write a patch, unless that patch is totally obvious I then describe it on freedos- kernel and ask for comments... ...and then nobody replies for a week so I assume that everybody is happy with the patch and I move on. Still suggestions for a more elaborate way of releasing the FreeDOS 2038 kernel are okay. With one exception: I do not want to wait until N people have commented/tested/ whatever, because that might take forever. Waiting time is only acceptable if defined in terms of time, where time is relatively SHORT. Otherwise we end up having a release cycle of more than 2 years per version :-(. and also of post release fixes. the times they are a-changing Yes. Now nobody even knows how to reach Jeremy. Unless you want to give his snailmail address a try, maybe... the latest published kernel on ibiblio, freedos 1.0, etc. www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/kernel/2036/ is from august 2006. I believe that this is because Jim only posts official releases on ibiblio, and the first official release after 1.0 will be 2038? At least there were no requests from anybody to publish any sort of prerelease of kernel 2038, and I certainly did tell about the wish to make an official kernel 2038 file release, probably on this list, and in quite clear words. Would not be surprised if I started doing so over a year ago... Anyway. No use to keep complaining about the past. The point is that quite a few patches have accumulated, none of which are very revolutionary. They are rather evolutionary, gradually bringing the kernel into better shape over the last two years. The updated kernel exists in actual distros, outside compile- your-own-svn-snapshot places for the geekish :-). So there is some actual experience with this kernel... Nobody complained, but some told the kernel fixes problems for them. Fair enough. I think the current kernel certainly is a good thing to release. If there are post release fixes, fine. But if you had wanted several pre releases, you should have asked one year ago. Eric PS, reply to Alain That is a good idea, Eric, why not redase a 2038rc1 Answer: http://www.coli.uni-saarland.de/~eric/christian.zip actually IS a release candidate for 2038. *Please test it everybody.* I planned to change only the version string from Christian to 2038 to make 2038. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] FreeDOS kernel 2038 changelog and updates - review please
Hi everybody, please have a look at the updated FreeDOS kernel changelog :-) http://freedos.svn.SF.net/viewvc/freedos/kernel/trunk/docs/history.txt?view=markup While only the first 130 lines are new, comments are welcome for the first 300 lines. Overview of the lines: Line 275-299 Build 2035a (for reference) Line 133-272 Build 2036cvs (may need cleanup / contain 2037 stuff) Line 67-130 Build 2038pre (basically the FreeDOS 1.0 kernel) Line 10- 64 Build 2038 (upcoming kernel release :-)) Line 3- 7 General information about bugzilla and SVN www page The sections about 2038pre and 2038 involved a lot of help from Geraldo, who condensed our long SVN log to a manageable summary. Thanks for that, Sir :-). Please check the changelog for bugs and let me know if there are kernel issues which should be fixed yesterday. Otherwise I would like to make a SourceForge file release for kernel 2038 soon, if possible this week :-). As our internal version number can count to 255, we can move to 2039 as soon as we want, which is why I would suggest not to wait for further patches for 2038. The changes for 2038pre and 2038 can be grouped in: - changes between 2036cvs and FreeDOS 1.0 (only 4 items) - changes merged from Tom's extra stable fork of kernel 2035a - changes from Bart and me for 2038pre - changes from Bart and me for 2038 I hope it is okay that I did not sort changes further into Bart's changes and my changes. This allowed me to keep the changelog close to being chronologically sorted. As far as I can tell, kernel 2038 should fix the following 7 bugs: - 1748 DATE fails to store (or read?) year 2000 on AMD SC400 embedded system - 1793 djgpp grep called from within rhide doesn't end - 1840 a:sys b: requires numerous disk swaps with single floppy system - 1854 Turbo c++ 3.0 fails to run - 1862 CHDIR fails on substituded drives - 1953 21h/29h returns 0 (valid) for all drive root names up to LASTDRIVE - 1956 All file opens fail under specific conditions Several other bugs were fixed even before they arrived in Bugzilla :-) Thanks in advance for reviewing the changelog, and have a nice start of the summertime period if your timezone has one :-). Cheers, Eric - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] FileSystem Suggestion
Hi, suggesting a new filesystem witch in my opinion I think is easy... Your suggestions are mostly userspace, so let us discuss your suggestion on freedos-devel, not on freedos-kernel. You do suggest device files, but remember that the kernel already has that: Device files like LPT1 are in no particular directory - they can be opened in any directory :-). You can add devices by loading drivers during boot or, with DEVLOAD, even from the command prompt. Eric - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] patch suggestion for bios year 2000 bug workaround
Hi everybody, I have been thinking about the issue described in bug 1748: freedos.sourceforge.net/bugzilla/cgi-bin/show_bug.cgi?id=1748 On some embedded systems, when you set the date to = 2000 with DOS and reboot, DOS will report a date of 1980. My theory is that this is because that embedded system BIOS fails to really store the century first, and FreeDOS CLIPS 1901 to 1980 while other DOSes like DR DOS and MS DOS might just ignore the century and WRAP 1901 into 2001 which is the date the user tried to set. While RBIL gives evidence that DOS could even hook BIOS int 1a to fix y2k issues in a lowlevel way, I suggest that FreeDOS should only have a fix inside DOS itself, without hooking yet another BIOS interrupt. See: kernel/initclk.c drivers/*clk.asm kernel/sysclk.c and kernel/systime.c ... Init_clk_driver will call int 1a.2 and 1a.4 and then call int 21.2b. SUGGESTION: Add fold 1900-1979 to 2000-2079 before callint int 21.2b in initclk.c (note that DOS date keeping uses DaysSinceEpoch as set via int 21, initially by Init_clk_driver, so the date is fetched from the BIOS once at boot time, not later...!) Index: kernel/initclk.c === --- kernel/initclk.c(revision 1354) +++ kernel/initclk.c(working copy) @@ -58,6 +58,8 @@ dosregs.a.b.h = 0x2b; dosregs.c.x = 100 * InitBcdToByte(regsD.c.b.h) /* century */ + InitBcdToByte(regsD.c.b.l);/* year */ + /* A BIOS with y2k (year 2000) bug will always report year 19nn */ + if ((dosregs.c.x = 1900) (dosregs.c.x 1980)) dosregs.c.x += 100; dosregs.d.b.h = InitBcdToByte(regsD.d.b.h); /* month */ dosregs.d.b.l = InitBcdToByte(regsD.d.b.l); /* day */ init_call_intr(0x21, dosregs); Are there any objections against that initclk.c modification? Bonus QUESTION: Why is YearsSince1980 and daysSince1980 never modified? See kernel.asm, it is stuck to 0 and -1. The whole area of date related things in the SDA seems to be dummy...?? ( CALL int 1ah, ah=4, carry cleared in case BIOS leaves carry unchanged will RETURN carry cleared if okay and the BCD encoded date as century CH, year CL, month DH and day DL... ) RBIL has several interesting notes about int 1a.4: START RBIL NOTES Notes: DR-DOS 7.02 (after 1998-06-06) and 7.03 hook this function and correct the century to 20xx if the reported year is 1900..1980 to auto-fix ROM-BIOSes which are not Year 2000 compliant. On a running system, it would also correct the rollover bug from 1999/12/31 to 2000/01/01. The latter can be turned off using the new CONFIG.SYS YEAR2000=ON|OFF command, as hooking INT 1Ah can sometimes cause compatibility problems with 3rd party software... Using EXCLUDESTEALTHINT=1A, though, will allow QEMM's Stealth features to coexist with the DR-DOS Year 2000 rollover support... PC DOS 7 plus Y2K fixes and PC DOS 2000 provide similar, though not identical means, which cannot be switched off. MS-DOS and older issues of PC DOS do not provide any such means, and thus requires extra Y2K-TSRs to be loaded when run on buggy BIOSes... END RBIL NOTES - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] kernel patches for more secure fat handling
Hi everybody, please check some patches for fat*.c at: www.coli.uni-saarland.de/~eric/fatsecurity-updates.diff.gz For convenience, you can find a compiled kernel and the fat*.c at: www.coli.uni-saarland.de/~eric/fatsecurity-updates.zip I made the patches because somebody mailed me that whenever he gets an unwanted reboot while files are open in certain states on his embedded DOS data logger, he gets cross linked files later. He cannot teach his users to shut down FreeDOS nicely and he cannot always close the file between writes... My changes focus on the most lowlevel FAT processing of DOS, and I added a pile of comments both for old and new code. Here is a tech overview of the fattab / fatfs changes in the patch: - always check if link_fat returns an error (was: never :-p) and try to do something useful on error (abort stuff)... - modify link_fat to trap more invalid input values and improve the run CHKDSK... warnings of link_fat and next_cluster - modify next_cluster to do on the fly consistency checks Now next_cluster reads up to 1 slot more, but thanks to BUFFERS, the performance impact is mostly limited to CPU - use a simplified next_cluster function is_free_cluster when scanning for / counting free clusters, to avoid the abovementioned performance impact. Using next_cluster instead would check chains for breaks as side effect :-p - review all link_fat calls to see from which to which value category a FAT entry is supposed to change where. Usually, the existing code already ensured a sane context anyway... - write the newly allocated slot before making the previous slot (or if file was empty: the dir entry) point to it in extend() FAT updates: Better lost than dangling chains ;-) - typically also check for FREE whenever checking for ERROR when trying to follow an existing chain, to prevent falling off a chain and to prevent walking around/into in a vacuum - flush buffers after chain shrinks but not after delete/grow (more flushes help with stability but otoh hurt performance) - avoid marking BUFFER with FS INFO disk sector as dirty if it did not really change... Each FAT write tries to update the FS INFO because we have no explicit periods during which it is unknown. Suggestions for start/end points are welcome. - trap error condition where we try to grow a file at any other point than the end - this could conceivably happen when FAT chain length and file size info mismatch and it could create lost chains and other weird things... ;-) The patched kernel is ca 100 bytes (UPXed) bigger than the previous (9/2007) version and should have similar disk load as the previous version in most situations. Only CPU load is expected to go up notably, in particular for seeks and file size changes. Yet I expect the bottleneck to stay on the disk side even for slow CPUs, so no problem :-). Please have a look and comment. Unless there are bad issues with performance, I would like to add all changes to the official upcoming FreeDOS 2038 kernel. It might be okay to reduce checks again which can only trigger if you break the FS at exactly the wrong SHORT moment. As said, without the patch, wrong moment is too long: boot while file open. Thanks :-) Eric - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] roadmap for freedos kernel 2038
Hi Johnson, 1658 Ghost 5.1 fails: Needs somebody with Ghost 5.1 to fix Just try Ghost 8.0 and Ghost 2003, if they work don't stick to Ghost 5.1, there MAYBE problem due to 5.1. You're wasting precious time on outdated programs. 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 to wish. 1842 HMA usage fails: sounds more like himem bugs Try other XMS manager. The problem is that we do not know who has the problem on which hardware with which XMS manager. So the testing of the bug is actually harder than the fixing here. 1956 extending JFT (FILES=...) fails: Fixed in SVN :-) Did you mean set the FILES=2 really have 2 buffers? No. DOS programs can give the DOS kernel their own RAM when they want to have more files open than FILES, but the previous FreeDOS version had a bug which means that it did not believe that you can use more open files after giving the kernel your own RAM for it. Eric - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] roadmap for freedos kernel 2038
Hi everybody, Tom just said in the A Poll of sorts thread on -devel: just kick out the useless 2037 kernel (merge any useful stuff into 2038); that's it Unfortunately, 2037 has an immense amount of changes and is based on 2035a. Still it would be interesting if people could mention some examples of 2037-things that would be useful for 2038 or 2039. Preferably things which are of limited complexity, not something like remove fnode subsystem :-). I think we should release a stable 2038 kernel before we start merging 2037 / unstable stuff into the main stable/trunk 2039 kernel again... Check our Bugzilla to see what is already fixed in SVN and what should be fixed (soon!) for 2038. Current major items are: 1658 Ghost 5.1 fails: Needs somebody with Ghost 5.1 to fix 1842 HMA usage fails: sounds more like himem bugs 1862 SUBST/CHDIR errors: Fixed in SVN :-) 1908 REN needs a scratchpad dir entry: A patch is in bugzilla? 1956 extending JFT (FILES=...) fails: Fixed in SVN :-) 1959 FILES table is fragmented: usually this is what you want, but a config option all in 1 low RAM chunk might help...? There are 20 normal, 2 minor and 12 enh bugzilla entries at the moment. The latter could be moved to the sourceforge wish (feature request) tracker, and one of them is already fixed in SVN (another, the int13 boundary DMA helper, has a TSR workaround available). The minor items are about the style of initdisk partition error messages and DJGPP RHIDE graphical bugs, need a tester. Three of the normal items are, as far as I can tell, fixed in SVN: 1793 DJGPP GREP vs RHIDE, 1854 Turbo C++ 3, and 1953 int 21.29 vs drive existence. Several other normal items may in fact be fixed already but nobody has tested that yet ;-). It would be quite nice if we could do the REN fix and file table fragmentation config thing, and finally find out why Netware has problems. Then we should release an official 2038 FreeDOS kernel. Writing a nice changelog will be a considerable part of the work for that. Let me know if you want to help :-) We need: tester help, coder help and doc/changelog writer help. Thanks! Eric - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] [Freedos-devel] flaws in user HMA memory allocation?
Hi Japheth, (changing subj from Some FreeDOS kernel bugs reported by Jack R. Ellis and moving the issue to freedos-kernel...) ... just reported a bug/issue found in the FreeDOS kernel: http://www.bttr-software.de/forum/... I guess a few people will have bad mood after reading this, so it might have been better not to mention that URL ;-) The language is angry there, but the summary is very short. For some reason, Udo banned Japheth for a moment (??), and Lucho is great, in particular his LZ 7.10 MS DOS (ever heard of copyright?). FreeDOS, on the other hand, is not ;-) FreeDOS has 2 big problems compared to LZ MS DOS: 1. It uses all free HMA space for BUFFERS even though LZ DOS shows that, when you also use a separate disk cache, using more than BUFFERS=3 gives no further improvement anyway. The HMA should be available for more useful things instead :-). 2. It is way slower in file copy/compare than other DOSes. (maybe we should make FAT and DIR data access smarter?) I would like to comment on 1, please correct me if I am wrong... Experts should be Bart, Arkady, Lucho and Tom :-). - you can say BUFFERS=-5 if you want 5 and not more than 5 (as opposed to BUFFERS=5 which is at least 5 in FreeDOS) - HMA allocation (int 2f.4a0n) in FreeDOS should allow apps (such as Jack's drivers) to use the free HMA space beyond the user- selected BUFFERS. So even if we fill all space with extra buffers while the space is unused, we free that space for more useful things as soon as some app asks for it. Maybe there is a bug in int 2f.4a0n handling and/or config.c? It LOOKS okay for me, though: Jack uses int 2f.4a01 - check returned BX and later int 2f.4a02.bx - check returned ES, DI, BX ... When I use DEBUG to call int 2f.4a01, FreeDOS says bx=2fef es=-1 di=d010 and after int 2f.4a02.1000, it says bx=1000 es=-1 di=d010 and when I call int 2f.4a01 again after that, I get bx=1fef es=-1 and di=e010, so everything looks okay at first glance...? This is on a system without any BUFFERS=... line. With BUFFERS=10, I get: bx=44b7 di=bb48 / bx=1000 di=bb48 / bx=34b7 di=cb48 :-). With BUFFERS=-10, I get the same (but fewer actual buffers, as explained above). Background reading: kernel/inthndlr.c int2F_12_handler (only 4a.02 and 4a.other distinguished in the stable kernel) and AllocateHMASpace kernel/config.c config_init_buffers (6..99 ok for min buffers) ... firstAvailableBuf = pbuffer + wantedbuffers; ... (so buffers after that point can be reused by other HMA users) Note that pbuffer is a struct buffer FAR * while wantedbuffers is a number and firstAvailableBuf is a char FAR * ;-) kernel/inithma.c HMAalloc function and HMAFree pointer (which is moved towards the end of the HMA when you allocate space) kernel/int2f.asm calls int2F_12_handler for ax=4a01 and 4a02 and for ah=12, which means that Win95 DOS int 2f.4a03 is NOT yet implemented. Int 2f.4a01 is query free HMA space and int 2f.4a02 is allocate HMA space. FreeDOS supports those :-). Note that we do not round up allocations to paragraphs! kernel/blockio.c AllocateHMASpace (a bit of a misnomer...) this function removes buffers which are inside the specified range of offsets, so the selected space can be used for other things after calling AllocateHMASpace. The HMA, if used by DOS, contains code first, then fnodes, then buffers, unless buffers are too many to fit in the HMA. There are two limits: firstAvailableBuf and HMAFree. The latter can indeed say everything used but the former will say the user only wants BUFFERS=... so the rest is only used for extra BUFFERS because nobody else asked for HMA space for other things yet People who have worked on user HMA allocation: - Arkady and Bart in 2004 - Bart in 2001 - Bart in 2004 (moved fnodes into HMA) - Lucho in 2004 - Tom in 2001 (created inithma.c) Some possibly relevant revisions and patches: config.c 164-167 in 2001 (inthndlr.c 164-167 seems unrelated) 854-863 (new rounding up) in 2004 (824-825 unrelated?) 382-403 in 2002 (?), 274-278 in 2001 (216-232 limit 64-99) inthndlr.c 844-862 in 2004 and 833-844 in 2004 (274-278 unrelated? 216-232 unrelated?) inithma.c 880-903 in 2004 (off by 1) and 274-278 in 2001 (align HMAFree to paragraph in HMAalloc - only used in config.c but not in inthndlr.c ...) I hope one of the experts can have a look at the code and find out whether we have a bug here. Thanks :-) Eric - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] flaws in user HMA memory allocation?
Hi Tom, thanks for your feedback :-) 2. It is way slower in file copy/compare than other DOSes. (maybe we should make FAT and DIR data access smarter?) ... FreeDOS allocates always the lowest unused cluster, even if the file should be enlarged by a large ( 1 cluster) amount. ... which also means more fragmentation ... I think we agree that it would help to remember the location of the first free / last allocated cluster. FAT32 even has a special nfreeclst field for that... One could make read/write_fsinfo work for all FAT types by storing the info in RAM for non-FAT32 drives. This would affect fatfs.c and fattab.c ... Can you explain how find_fat_free decides where to start searching? It might also make a difference to limit how often the FAT32 fsinfo sector is written to disk - depends on how BUFFERS and priorities are processed, you can probably estimate the performance better than I here. search for a bunch of clusters that are able to fit this request could accelerate this I think I prefer searching a cluster at a time but in a linear fashion, using a next free cluster pointer instead of searching from the start of the FAT each time you need one more cluster. If that is easier, you could start by only implementing it for FAT32, then users can already start doing experiments / compare the FAT32 performance to FAT16 performance :-). b) COMPARE if enough (small) files in large enough directories with enough directory depth are compared, it might matter that fastopen isn't implemented. Anybody ? Hmmm well I agree that FASTOPEN can be useful in other ways than a cache, but does any MSDOS version have a kernel built-in FASTOPEN? I thought they dropped all FASTOPEN around DOS 5 because they thought that a generic disk cache would be enough? Does FreeDOS for example remember the starting cluster of the current directory and / or a directory which is being findnext-ed at the moment? - you can say BUFFERS=-5 if you want 5 and not more than 5 (as opposed to BUFFERS=5 which is at least 5 in FreeDOS) - HMA allocation (int 2f.4a0n) in FreeDOS should allow apps (such as Jack's drivers) to use the free HMA space... yes and no; see www.bttr-software.de/forum/forum_entry.php?id=867 Ah interesting... user allocation is only possible after all DEVICEs are loaded because only then buffers are moved to HMA? Yet BUFFERS and FILES are processed before DEVICE afair, and FreeDOS starts using the HMA for the kernel code as early as possible afair (right after the DEVICE=HIMEM line) so... Are there good reasons to delay HMA buffer / fnode allocations? Anyway. An obvious solution would be to DEVLOAD the UDMA / UDVD drivers to let them enjoy userspace allocation of HMA space. Could anybody test that? :-) Eric - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] patch for the rename function, please check
Hi all,
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 across directories. If both old and new name
are in the same directory, the new version should only
change the old dir entry in place. So that should even
work if you rename files on a disk with full root dir...
Caveats:
- it is possible that renaming directories on a disk with
full root directory still does consume an extra dir entry,
as I am not sure whether my does the rename take place in
the same directory test captures that case as well.
- if you rename a directory across directories, then the
.. entry for the directory itself is not updated. Note
that neither FreeCOM command.com nor MOVE use the int21
rename interface for such activities at the moment (?).
I would really appreciate if some experts (Bart, Arkady,
Jeremy, Tom, ...?) could have a look at my patch. It does
seem to work, but it is hard to know for sure I would say.
Note:
- if ((ret = remove_lfn_entries(fnp1)) 0)
-return ret;
+ if ((ret = remove_lfn_entries(fnp1)) 0) {
+dir_close(fnp2);
+return ret; /* remove_... already closes fnp1 on error */
+ }
This sub-patch is supposed to fix a fnode leak, and it
is not related to the primary purpose of my patch, the
be able to rename without consuming dir entries one.
Thanks for having a look :-)
The bug description is here:
www.freedos.org/bugzilla/cgi-bin/show_bug.cgi?id=1908
From there, you can follow the link to my patch:
www.freedos.org/bugzilla/cgi-bin/attachment.cgi?id=43
Eric
PS: Current major kernel bugs are
1658 norton ghost failure on 2029+ (??)
1842 dos=high fails in beta9sr2 (??)
1862 subst troubles (fixed in SVN revision 1357?)
1902 ren fails on full disk (fixed by my suggested patch?)
1956 all file opens fail if... (fixed in SVN revision 1323?)
1959 opening lots of files fails (because SFT not in 1 block?)
I suggest to release 2038 when 3 of those 6 bugs are fixed :-)
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] freedos boot menu line change suggestion
Hi, what do you think about the following patch: --- config.c(Revision 1354) +++ config.c(SUGGESTED) @@ -1918,16 +1918,16 @@ printf( (Selection=%d) , MenuSelected); if (MenuTimeout = 0) - printf(- %d \b, MenuTimeout); + printf( %d \b, MenuTimeout); else printf(\b\b\b\b\b); if (MenuColor != -1) printf(\r\n\n ); else - printf( -); + printf( ); -printf( Singlestepping (F8) is: %s \r, singleStep ? ON : OFF); +printf( Singlestepping (F8) is %s \r, singleStep ? ON : OFF); key = GetBiosKey(MenuTimeout = 0 ? 1 : -1); Background: The current menu line with non-full-screen menu is: Select from Menu [012], or press [ENTER]- 2 - Singlestepping (F8) is: OFF This is too long - if you have too many menu items, it wraps around. My patch simply makes the line minimally shorter: Select from Menu [012], or press [ENTER] 2 Singlestepping (F8) is OFF If you hit space, the old version changes to: Select from Menu [012], or press [ENTER - Singlestepping (F8) is: OFF OFF This has two errors: The ] is removed and OFF is visible twice. A good menu line should show the menu choices, hint people about the F5 and F8 key (if you ask me, F8 does not need to be a toggle, it can also be hit it at least once to enable single stepping) and about the time left until the default choice is selected. It could even show which selection is the default one. It would be good to have better suggestions than my patch above, to get a really nice menu line :-). As far as I remember, the unstable kernel shows an even longer menu thing which is 3 lines long (which is not nice if you want to read the messages of your BIOS POST) and uses gotoxy (which is not so nice if you use a serial console). I think the 3 line style has the F5/F8 hint and status at the bottom, choice list 2 lines above, timeout line in the line between both lines. What I would want is a ONE line menu thing. Example, the [2] would be the timeout-for-default countdown: Select from Menu [012], ENTER for default, F8 for singlestepping [2] If you hit F8 at least one, this could change to: Select from Menu [012], ENTER for default. Singlestepping is on! [2] Instead of ENTER for default, one could write ENTER for [1] where 1 is the default in this example. Whatever. Suggestions please :-). Thanks! Eric - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Questions on FreeDOS interrupt services
Hi Lucas, your mail did indeed arrive as html... FreeDOS does in general support the same interrupt services as other DOS versions. A good list of such services is in Ralf Brown's Interrupt List (RBIL) which is mirrored on many pages. Main location is: www.cs.cmu.edu/~ralf/files.html I would suggest to download all 6 parts and to concatenate the main files into one intlist.txt - less and pg can handle such big files :-). You can read in docs/intfns.txt in our kernel sources which intr services are supported and which are not. SVN view on sourceforge: freedos.svn.sf.net/viewvc/freedos/kernel/trunk/docs/intfns.txt?view=markup Note that there is no detailled list about which int2f services are supported. Sometimes some extensions are not supported in int21, for example the extended open file 2 gb flag, which means that while Win98 supports files up to 4 gb size on fat32, freedos only supports up to 2 gb size at the moment afair... Unsupported are: int 21.4b05 exec state, 21.5d0n close all files with property X / commit all files / get open file list (all interacting with SHARE) and int 21.63nn multibyte char dbcs support. For long file name int 21.71nn, you have to load a separate driver, for example doslfn. To detect if you are running in freedos, use int 21.3000, get dos version, and check if bh is 0fdh after the call. It would be 0 for IBM, 0eeh for DR DOS, 66h for PTS, and so on. Eric PS: Maybe somebody could mention this in our FAQ, but I have the feeling that it is already discussed there? - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Kernel, Sys and Freecom TODO items
Hi all, For the next file release of FreeCOM 0.84xyz and kernel 2038 / sys, I would be happy if somebody could figure out and fix the following problems: - SUBST somehow breaks getcwd / chdir in the kernel?? - when you write a char dev, the kernel tries to read it to detect ctrl-break, which crashes ROT13DEV (I did write some suggestions about how to fix it on the list) See the 24 Apr 2007 mail possible freedos kernel bug for char devices for some ideas for getting started... Unfortunately, I did not get further to reach a fix. - FreeCOM stops to run external commands sometimes (internal commands keep working) - FreeCOM leaves a batch file or (if you are not inside one) even shuts down completely when you use pipes or redirects and the input runs dry for internal commands. A very old bug but maybe worth fixing before the next file release: - SYS sometimes uses FAT32 CHS (or other?) boot sectors for FAT32 LBA drives, so add a command line override to force either LBA or CHS style there? - the history.txt files need a lot of updating, any doc- writing volunteers for that? You would have to read the svn log and summarize it, and check which updates are for stable 2038 and which are in the unstable branch. The latter has not changed for a while, but history.txt of stable might contain unstable items labeled as stable 2036 by accident... Logs are online, start at 1190 or 1302: freedos.svn.sourceforge.net/viewvc/freedos/kernel/trunk/?view=log A list of interesting bug numbers at the moment, view with www.freedos.org/bugzilla/cgi-bin/show_bug.cgi?id=NUMBER ... The fixed in svn need feedback (does it really work?) and should then be updated with a comment fixed in svn but should not be marked as closed / fixed bugs until we have a file release of kernel 2038. 1793 djgpp grep vs rhide: I think somebody fixed that in svn? 1959 opening many files: maybe related to bug XXX 1908 rename should work in-place, without consuming a new directory entry, for rename inside the same local dir 1854 Turbo C++ 3 TC fails to run: Fixed in svn? :-) 1862 CHDIR (getcwd?) fails on SUBSTituted drives!! 1887 char access to CLOCK$ driver hangs the kernel (other drivers like himem/emm have the same weakness) 1890 timestamps wrong on network files - still the case? 1923 initdisk hang with CF disk - would need a tester? 1800 hang even before initdisk on ATA flash? needs a tester. 1810 Ranish FAT32 boot fails (SYS bug?) - needs a tester. 1821 SYS hangs for CF unless compiled with Watcom - testers? 1945 SYS may fail to detect LBA support per drive letter (obvious, hard to fix) - add a command line override? 1840 SYS needing too many disk swaps: Fixed in svn? :-) 1953 int 21.29 to check for valid drives: fixed in svn? 1956 extending the file table makes open fail: fixed in svn? 1960 partitions outside the reachable range should not be ill. partition table but should give a better message 698 kernel has no int 13 dma boundary helper: true, and a fix will have to wait, but I made a workaround TSR :-) www.coli.uni-saarland.de/~eric/lowdmaplus.zip 1139 dir .foo / dir foo. should behave as dir *.foo / dir foo.* 1720 some F8 related FreeCOM keyboard issue found by Bernd 1848 dir crashes on size overflow (maybe fixed?) 1888 copy implementation troubles (appending etc) 1901 copy implementation troubles (appending etc) PS: FreeCOM TYPE replaces [CR,LF]+ by CRLF, MS TYPE doesn't 1946 dir /p and cls support for pre-EGA 1951 echo strips too many control chars, for example FormFeed 1946 pipe / redirection internal cmd EOF aborts batch or FreeCOM Examples: ECHO ON | DATE (uses stderr) DATE EMPTY.TXT 1962 FreeCOM tries to close handle -1 All feedback, testers and patch contributions are welcome :-) Eric PS: Which regressions bugs exist in FreeCOM 0.82pl3 which did not exist in 0.82pl2, Bernd? I think 0.82pl3 is very nice unless you need LFN support :-). - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] fix truename and report version 6.22?
Hi all, please check the current kernel updates with Bart's FASTBOOT versus STACKS fix and some DOS 6 compatibility updates from me: Binaries: www.coli.uni-saarland.de/~eric/svn-binaries-freedos.zip Something else: Rugxulo tested the executable-unpacker IUP (ftp.sac.sk/pub/sac/pack/iup067.zip) and found that it fails to rename temp files. I tried, too, and found that IUP gives no temp file name template. FreeDOS behaves as MS DOS 5, it creates the temp file in the root directory. I believe newer and older MS DOS versions would create it in the current dir? Added to FreeDOS: The root dir style is now only used for version 5. Maybe we should report DOS version 6 instead of 5 anyway? Added to FreeDOS: The FAT16 kernel version is now reported as 6.22. I checked for differences in RBIL and found: Other AH in TRUENAME (int 21.60), other temp file names (21.5a :-)), I tried to add that to TRUENAME but it seems to always return 0 while it should return 3a for char devices, could somebody have a look at what I have missed to update? ext country lowercase table (21.6503) in country sys but only for Cyrillic CP866, maybe also int 21.f8/f9 oemint21 hooks. That would be only for the UNSTABLE branch which has more country / nlsfunc support, I guess? MS DOS 6 also comes with newer apps/tools, himem, smartdrv, keyb, dblspace, emm386, other tools. MS DOS 7+ also has a new version check (2f.4a33) and lots of other new stuff. Something in some int 2f.5500 command.com share parts of loaded code between instances is also DOS 6 specific. And so on ;-). To make a long story short: Let us update TRUENAME and MKTEMP and COUNTRY to MS DOS 6 style, and let us change FreeDOS kernel to report that it is version 6.0 or 6.22: This will make DOS apps happy in general and it is easy Done :-). PS: Does any interface support cross-directory rename Still not answered...? You can review the source code changes here: SYS FAT32 access fix Bart - added modify dx flag: http://freedos.svn.sourceforge.net/viewvc/freedos?view=revrevision=1342 Stacks / Fastboot / Irqtext new fix Bart: http://freedos.svn.sourceforge.net/viewvc/freedos?view=revrevision=1343 Documentation update Eric - please discuss int 21.5d0n: http://freedos.svn.sourceforge.net/viewvc/freedos?view=revrevision=1344 Mktemp if DOS not 5 / Truename if DOS 6 / Version changes Eric: http://freedos.svn.sourceforge.net/viewvc/freedos?view=revrevision=1345 Please try and comment :-) Eric - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] fresh freedos svn kernel updates
Hi Bart, 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. Actually I think it might take man-months or more to review all the MANY changes between unstable and stable, plus merge all the fixes of stable into unstable first. or two on FreeDOS. There are funny space savings in text strings just so that Lucho could get the compressed kernel under 40K. I found one bug in the inittext.c optimizations by Arkady. And so on. Space should not be everything. But for people who do care a lot about space, it would be better to have several subsystems compile time selectable, for example any COUNTRY support at all, internal or external or FCB support and so on. Many patches of UNSTABLE are indeed peephole optimizations which can make the code very hard to read. Be glad you did not try to debug CuteMouse, for example ;-). So one has to be very careful / meticulous (?) / thorough / diligent when porting things from the UNSTABLE kernel to the stable / svn trunk branch. the BIOS int13 does not support any other size AFAIK I think there were Japanese diskette formats with 1k sector size? Probably not bootable, though. Same for optical WORM drives. External country.sys and more windows 3.x support never hurt. Yes. Especially the int2f stuff should be reasonably easy to port. Removing the internal country table makes things a little bit more dependent (Tom's point of having the internal table is that you don't need a country.sys file if all you want is the correct date-month-year display). Of course the internal table is not good for the 40K aim. I do like the internal table a lot and it UPXes well afaik but, as said, one could make the internal table and support for external country sys both a compile time option, including the option to compile a kernel with neither of the two enabled. In either case, there are still - few - unimplemented functions which should be added to stable before we start adding tuning stuff from unstable into stable if you ask me. Bugfixes from unstable are welcome in stable, of course, esp if smallish. Eric - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] fresh freedos svn kernel updates
Hi Bernd, Only KERNEL2.SYS works for me, better than the Fastboot supporting kernel I downloaded (I think) a while ago. KERNEL.SYS in your zip hangs my machine at the HMA/BUFFERS message. Yes, I have the same problem :-(. What I did to create kernel2 is to undo the changes of SVN revision 1325: http://freedos.svn.sourceforge.net/viewvc/freedos?view=revrevision=1325 This change adds FASTBOOT support but also moves irqstack into another segment. I have no idea why, but this and all later revisions crash when the kernel tries to load the shell and/or tries to move into the HMA (it even happens when no HIMEM is loaded, though) in Bochs. It never crashes in Dosemu, though! The only relevant difference I could find is that the DOS_PSP at 60:0 shows that int 22..24 vectors moved from d1:xx to d4:xx (and that JFT and SS:SP differ, of course). I did a binary search to find where the crash got introduced, starting at 1315 and 1333 (1334 is fcbfns.c int 21.29, 1335 is initial lastdrive, 1336/1337 are 8086 compatibility and cli in int19, 1338-1340 are by me). It is possible that some OTHER version in 1326-1332 range works. Bart, as you did most changes in that range, could you please test and comment? I did not know whether you are on the kernel list, so I CCed you, just in case... So what went wrong here? The new IRQ handling / FASTBOOT support? Or maybe a later revision fixed that and introduced some other issue, related to the new UPX / exeflat style added there? 1. This should make Robert happy. The kernel now produces messages as UMBs unavailable! instead of (Dutch) UMB's unavailable! Dutch is the only language where plural's are correct, I think. Depends, normally the [s] is added, but some english terms like 'baby' are plural with ['s]. Also depends what the kernel is trying to say: *UMB ['s/is] unavailable *UMBs unavailable *UMBs are unavailable I would not shorten the is into 's in any other context than it's nice and similar. Other sounds, hmm, very spoken language. But baby never has a plural with 's outside the Dutch language :-p. Merriam Webster: www.m-w.com/cgi-bin/dictionary?book=Dictionaryva=baby 3. Usage: keybuf=n[,m] Relocate keyboard buffer from the default location at 0x40:0x1e-0x3e to 0x40:n-m... what's the benefit of this? a larger keyboard input buffer like Dos 7.10 (1024chars) ? Yes! I did not know MS DOS 7.10 has this, details? Rugxulo uses a device driver which allocates 0.5k (256 chars) and moves the buffer there (only works if device ends up in first 65 kB of RAM). I found out that Bochs uses 40:b9 for VBE, so if I move the buffer there, I break FDAPM's Bochs-detection, so it crashes in APMDOS mode again as the Bochs APM BIOS has a bug. Plus VBE stops working ;-). As you can see, KEYBUF is not super tame. However, 0x120-0x1d0 (maybe even 0x108-0x1e0) works perfectly in all tested contexts, 108 chars is already much better than the default 16 chars :-). offtopic questions: are Japheth's drivers compressed by UPX or I can gzip them to 2/3 of their normal size, so I would say they are not compressed at all. You should ask Japheth if this is by design (cannot be UPXed) or just because he did not compress them. A single binary '286 XMS driver' + '386 XMS driver' + '386 EMS/UMB/VCPI/VDS driver' + '386 XMS/EMS' driver would be fun :) As said several times, I dislike the XMS+EMS combined style of JEMMEX because you cannot test the XMS/HMA and EMS/UMB part separately any more. But that may be a question of taste. If you had a XMS only mode in JEMMEX, then it would probably be a very different implementation compared to a classic HIMEM. Having built-in 286 drivers does not sound useful to me. The few people with a 286 should better use special 286 drivers. Eric - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] fresh freedos svn kernel updates
Hi again, after checking http://freedos.svn.sourceforge.net/viewvc/freedos?view=revrevision=1325 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) failed in Bochs at some point around the PostConfig kernel relocate moment, even if no HMA was available. No idea why - 1341 is based on intuition and experiments, not on theoretical knowledge why IRQTEXT was bad. Please test :-) Sample kernel binary: www.coli.uni-saarland.de/~eric/ke2007jul21.zip Eric PS: Summary of the 1341 patch: 1. kernel/segs.inc -group LGROUP _IRQTEXT _LOWTEXT _IO_TEXT _IO_FIXED_DATA _TEXT +group LGROUP _LOWTEXT _IO_TEXT _IO_FIXED_DATA _TEXT -segment_IRQTEXTclass=LCODE 2. kernel/irqstack.asm -segment_IRQTEXT +segment_LOWTEXT - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] fix truename and report version 6.22?
Hi Bernd, I have tested the new kernel a bit in Bochs already. Sample kernel binary: www.coli.uni-saarland.de/~eric/ke2007jul21.zip same filename yet updated release? Yes, it was still 21jul :-). Updated kernel, kept kernel2. Something else: Rugxulo tested the executable-unpacker IUP (ftp.sac.sk/pub/sac/pack/iup067.zip) and found that it fails to rename temp files. I tried, too, and found that IUP gives no temp file name template. FreeDOS behaves as MS DOS 5, it creates the temp file in the root directory. I believe newer and older MS DOS versions would create it in the current dir? As you cannot rename to another directory (or do some MS DOS versions support that?) with DosRenameTrue, the rename fails unless the to-be-unpacked file is also in the root directory. I suggest to change FreeDOS to create temp files in the CURRENT directory, not the ROOT directory, if no template is given for the name. I believe this would clone MS DOS 6 style - according to RBIL, we already use MS DOS 6 A-P instead of MS DOS 6 hex style temp names anyway. Maybe we should report DOS version 6 instead of 5 anyway? I checked for differences in RBIL and found: Other AH in TRUENAME (int 21.60), other temp file names (21.5a :-)), ext country lowercase table (21.6503) in country sys but only for Cyrillic CP866, maybe also int 21.f8/f9 oemint21 hooks. MS DOS 6 also comes with newer apps/tools, himem, smartdrv, keyb, dblspace, emm386, other tools. MS DOS 7+ also has a new version check (2f.4a33) and lots of other new stuff. Something in some int 2f.5500 command.com share parts of loaded code between instances is also DOS 6 specific. Internal KEYB data (2f.ad80) also depends on DOS version. Hm. Did you know FORMAT calls int 2f.adc1 before it asks for a disk, if /SELECT option given, letting a tool called SELECT show another message first? To make a long story short: Let us update TRUENAME and MKTEMP and COUNTRY to MS DOS 6 style, and let us change FreeDOS kernel to report that it is version 6.0 or 6.22: This will make DOS apps happy in general and it is easy for us :-). Other DOS 5 - 6 differences are only outside the kernel anyway :-). FreeDOS with FAT32 support already reports MS DOS 7.10 compatibility, time to fix the rest. Eric PS: Does any interface support cross-directory rename in DOS officially? If so, I would like to add if you rename a directory cross-directory, update .. there :-). - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] fresh freedos svn kernel updates
Hi Rugxulo, Robert, kernel people, I finally figured out svn at home, so I updated three areas of the stable branch of the FreeDOS kernel in svn. Actually only UNSTABLE is a branch, stable is the default. Anyway. The three changes vary a lot in complexity. Fixing language glitches was easy. The keyboard trick is purely in config.c and the documentation. The HLT thing was much harder, as two new global items had to be introduced... The changes are: 1 fixed Dutch plurals at various places 2 added IDLEHALT config sys option (see below) 3 added KEYBUF config sys option (see below) Bart, could you check my lsm / version / history changes and add your changes to the history file? As suggested a while ago, I added myself to the maintainer list in the lsm. Jeremy, is that okay? Are there any volunteers to maintain the UNSTABLE branch of the kernel? Rugxulo, KEYBUF should obsolete having a keyboard extender around. Kernel people, IDLEHALT does not obsolete FDAPM APMDOS but it gives you some energy-saving even without FDAPM. I hope both can be used in parallel w/o problems. Please check / test / comment! Thanks :-) Sample kernel binary: www.coli.uni-saarland.de/~eric/ke2007jul21.zip Eric 1. This should make Robert happy. The kernel now produces messages as UMBs unavailable! instead of (Dutch) UMB's unavailable! Dutch is the only language where plural's are correct, I think. 2. Usage: idlehalt=n where n can be -1, 0, 1 or higher (default 0) Activates built-in kernel energy saving functionality if n is not 0. Value -1 enables all hooks, 1 enables only safe hooks, CPU halted only if kernel is waiting for CON char device input. Further hooks for n=-1 and n0 depend on the kernel version... ... 3. Usage: keybuf=n[,m] where n is in 0xac-0xde or 0x106-0x1de range and m is = 0x200 Relocate keyboard buffer from the default location at 0x40:0x1e-0x3e to 0x40:n-m. The buffer must be more than 32 bytes and must not touch offsets 0x100-0x105. Default for m is next multiple of 0x100 after n ... A reasonably safe choice should be keybuf=0x140,0x1c0. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] freedos tabstop handling problem?
Hi Bart, Arkady, other kernel people, what do you think about the following problem: We only have ONE scr_pos variable in the SDA but several functions use it for several char devices as far as I can tell. So tabstop calculation will probably go wrong when you mix accesses to, say, CON and AUX. How can this be avoided, how does MS DOS or DR DOS behave in this context? We could limit the use of scr_pos to CON only. That might make users of CTTY AUX unhappy. Still acceptable? If not, what are the alternatives? Or are there already enough checks in the existing code to some- how ensure that scr_pos is only used for CON...? Affected functions are: update_scr_pos - uses categories CR, BS, LF, BELL, other cooked_write_char - calls update_scr_pos, special-casing TAB write_char_stdout - as cooked_write_char but skip if CONOUT read_line - works with (update_) scr_pos for LF and BS over TAB DosRWSft - calls read_line via read_line_handle if cooked READ CONIN and also - calls update_scr_pos if BINARY (raw?) WRITE CONOUT Directly reachable are: write_char_stdout int - as 21.1 / 21.2 / 21.9 and read_line - as int 21.a, others are used by int 21 indirectly. Note also that DosRWSft assumes that input handle == output handle when it invokes read_line_handle, while int 21.a calls the read line function with STDIN and STDOUT as arguments. Thanks for having a look :-) Eric - 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/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Use of DJGPP under FreeDOS
Hi Andris, I think Bart Oldeman recently fixed the GNU SED problem... Some time ago I submitted am error report for DOSEMU about problems running DJGPP port of GNU SED from configure scripts http://sourceforge.net/tracker/index.php?func=detailaid=1429741group_id=49784atid=457447 and also tracker for FreeDOS. It took me some time to build working FreeDOS kernel from CVS sources under DosEMU-1.4.0. Do you want to say that the CVS sources have a bug in the build scripts and you had to repair them first? Please explain. The problem when GNU SED writes output file up to 2GB (when DOSEMU quits) now seems to be fixed. I assume this is due to the fix by Bart :-). So does the old kernel www.coli.uni-saarland.de/~eric/stuff/soft/by-others/kernel2036-binary.zip have the SED problem and the CVS one fixes it? Please compare. touch.exe (from DJGPP fileutils) fails with an error message: touch: setting times of `foo': Input or output error (EIO) Please compare two cases: A Linux directory simulating a drive in DOSEMU and a diskimage simulating a drive in DOSEMU. There might also be a long file name problem, try $_lfn_support=(0) in your DOSEMU configuration file, and try touch FOO instead of touch foo... :-). Thanks! Eric - 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/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] New FreeDOSers Monthly Reminder
Hi Nick and everybody else who wants to unsubscribe: [furious scream of frustration] How do I get off of this mailing list?! I've been trying to get off of it for months. Help me! That is ridiculously easy :-). Each mail explains it in the headers: List-Unsubscribe: https://lists.sourceforge.net/lists/listinfo/freedos-user mailto:[EMAIL PROTECTED] In other words, write a mail with the subject unsubscribe to the address [EMAIL PROTECTED] to unsubscribe yourself. Completely automated self-service system. You can also surf to lists.sourceforge.net/lists/listinfo/freedos-user. To unsubscribe from another list, for example freedos-kernel, use the same method: Write to [EMAIL PROTECTED] with the subject unsubscribe. Contents of the mail are irrelevant. By the way, why do you want to unsubscribe? :-) Eric - 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/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] regarding COFF parser
Hi Reddy, http://www.delorie.com/djgpp/doc/coff/ provides lots of COFF info, but I think there are several file formats which are all called COFF. As DJGPP is open source, you can also read COFF file format aware source code in the sources of the compiler, linker / binutils, C library... For the MS variant of COFF, check their MSDN/WHDC info. Eric I am interested in knowing the COFF structural details (details on header, sections and symbols structures). ... Also please let me know if i can get the COFF parser code in the net. - 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/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Comparison of FreeDOS 2036 to the Tom kernel
Hi Bart, here my reply to your reply to my list :-) Few part 2 reactions first: - what was the reason for 21.3301 modifying DL again? - why is 2f.1228 seek disabled? - do you want to explain the something else in nls.c? Reactions to this first part: Any volunteers for SYS.TXT / CONFIG.TXT / INTFNS.TXT updates? Todo items: check if sys.txt is up to date, add to the IF example and mention that FCBS setting is basically irrelevant because FreeDOS simulates FCBS (both config.txt). Check which int 2f DOS kernel functions are not yet implemented and add a list of them to intfns.txt; Fix the drive vs driver typo. Plus there is that secondard typo in fatfs.c ;-). Any volunteers for the int 21.5d01 ... 5d05 implementation? Various close all handles with property X functions, so this should be a reasonably tame task. Bart, what was the dosfns.c spc=rg[0] and padding can be with spaces and 0 bytes purpose again? And what was the JPP story about deltree in fatfs.c, do you remember the background? I think the fatdir.c i=3 change from if volid is set but dir is not to if, ignoring rdonly and archive, only volid is set was to make Zeliard findfirst happy. You said it was only in the copy on my homepage but not in cvs... Did you already throw in the other changes from my homepage, with some useful cvs logs, or did you wait for me to do that? I will try to update the cvs a bit in the next time, but may take a while. So of course it would be nice if somebody could help out with the .txt file updates in the meantime :-). Thanks! Eric - 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/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Tom's kernel changes vs. CVS
Hi Bart, Tom, some extra comment for 2. initoem.c: + if (ramsize == peek(0, RAMSIZE)) if (ramsize * 64 == ebdaseg ramsize 640 peek(0, RAMSIZE) == ramsize) the extra double check looks strange to me, why check twice? Something strange with short-circuit boolean evaluation? ... I got the recommendation do not move EBDA unless it starts at the segment where low DOS RAM ends according to 40[13], as another location could mean that something else fiddled with the location / memory already. Of course that does not answer the question why ramsize == peek(0, RAMSIZE) is checked for twice. Eric PS: Bart, could you make a list which things you merged in from Tom's kernel and which you did not? I would like to compare it to my own list... Thanks :-). PPS: Did you also check in the changes from the kernel on my homepage? If so, I hope you grabbed some of the changelog and put it into the cvs logs. Good cvs logs are always very useful. If you did not check in my changes yet, remind me to do myself ;-). - 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/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] FcbParseName bugfix, dos_rename (was: re: Online Bible and Freedos?)
Hi Frank,
you wrote that the Online Bible for DOS, which one
can download at http://www.onlinebible.net/dosolb.html
does not work in FreeDOS.
After some messing with dosemu and the built-in debugger
and interrupt trace functions of it, I figured out that
your problem is in DOS INT 21 function 29, FcbParseFname.
The difference between MS DOS and FreeDOS is in what
happens when you use a filename with a directory spec
as input. For example foo.txt and x:foo.txt are
both handled okay, but for x:\moo\foo.txt, FreeDOS
returned \moo\foo as the file name, while it seems
to be supposed to return in that case! A patch to
fix this in FreeDOS is as shown below. I also sent
you a modified binary off-list / by direct email.
Please try the updated kernel :-)
Eric
PS: Question to the experts, dos_rename now uses
alloc_find_free to support cross-directory rename
(good), but that has 2 problems: When you rename
a directory, the .. of it is not updated (bad)
and renaming anything consumes a directory entry
(bad). Both problems have been reported as bugs.
Can anybody write a better fatfs.c dos_rename? It
could alloc only if different dir, else rename
in-place and if renamed item is dir, update ...
Thanks a lot.
diff -u fcbfns.org fcbfns.c
--- fcbfns.org 2004-07-25 10:04:54.0 +0200
+++ fcbfns.c2007-05-09 01:22:52.0 +0200
@@ -149,6 +149,14 @@
return FP_OFF(lpFileName);
}
+ /* MS DOS returns all-spaces filename and ext in FCB if pathspec found */
+ if (*lpFileName == '\\')
+ {
+/* file name and ext are left unset or blanked, see PARSE_BLNK_* above */
+*wTestMode = PARSE_RET_NOWILD;
+return FP_OFF(lpFileName);
+ }
+
/* Now to format the file name into the string */
lpFileName =
GetNameField(lpFileName, (BYTE FAR *) lpFcb-fcb_fname, FNAME_SIZE,
-
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/
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
