Re: [Freedos-devel] FreeDOS package issues
Hi Jim, Jerome Shidel wrote: > 4) CDP, This is not open source software. It is Freeware without > sources. Should this be removed. Is there an decent open source > alternative? On Wed, Feb 15, 2023 at 4:10 PM E. Auer wrote: What does CDP do? Can you mention some features of that? As Robert already mentioned in this thread: "CDP is a non-TSR CD player." Well, you can tell a CD drive to play track X using my minimalist cdrom2ui, but I think that would be sort of an INdecent open source alternative because it is too minimal :-D On the other hand, a QuickBasic solution sounds like something needing FreeBASIC in QB mode, or something which compiles into a large binary? That is probably too non-minimal? Regards, Eric ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS package issues
Hi Jerome, 1) CPIDOS, this is basically just a package of codepage font files. Those files have been assembled in some fashion into the CPX files and distributed as such. However, there is no utility or information present in the package to create such CPX files. We should probably do something to remedy that. Check the sources of MODE for more info. I think the method is to rename the CPI to COM (or SYS? I think it was COM) and tell UPX to compress that "executable". If you want the 8086 compatibility, do not forget to use the appropriate UPX flag. I recommend that you test the CPX files generated, in case I forgot something relevant. 4) CDP, This is not open source software. It is Freeware without sources. Should this be removed. Is there an decent open source alternative? What does CDP do? Can you mention some features of that? Eric ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] UEFI, virtual BIOS and virtual hardware - was: Google Summer of Code?
Hi Bret, thanks for the great summary! For awhile, the UEFI manufacturers provided a CSM (Compatibility Support Module) as the "translation layer" so you didn't need a VM. But they've even stopped doing that nowadays. So, we'll either need to come up with a "generic CSM" that doesn't need a VM but still provides the needed level of hardware support both now and in the future, or we'll need to do some kind of "thin VM" as Jerome is suggesting. I think the second option has a better chance of long-term viability even though I would prefer the first. My impression based on earlier discussions and/or BTTR forum threads would be that there are "open source BIOS" initiatives which could be a starting point for a large point of a "generic CSM" (BIOS module to load on UEFI systems before booting DOS, with some magic glue needed) at least for actually more aspects of the BIOS than normal DOS and DOS apps will require :-) I can imagine that the dosemu2 people also have interesting expert thoughts about that and those magic glue problems involved. Depending on how thin the glue and VM layer will be, you will be able to run fewer or more DOS apps with it. You can run some DOS apps in CTTY serial consoles if they only use int 21 for user I/O. There are support modes for simple DOS apps in some boot managers which only implement a few most popular bits of the DOS API to run apps directly from the boot manager without an actual DOS. So why not use for example real mode DOS apps without sound, with whatever is left in terms of hardware text mode or maybe VGA as an already entertaining intermediate milestone and keep more VGA, VESA, PC speaker, mouse, protected mode apps etc. pp. for later? The "easy" solution will still be running a DOS-friendly VM inside Linux or other host OS. But not the exciting solution regarding technological challenge and "abstraction thinness". People have written hypervisors to hide malware. Porting an open BIOS and some VM ingredients into a CSM and an open source "VMware ESXi" competitor which runs DOS better than the commercial product does? In other words, a Xen for DOS? To stay in the Xen terminology, would one want a paravirtualized DOS for that? Or would one put some light weight "BIOS setup" type menu into dom0 and run DOS only as client? Wikipedia mentions Alpine Linux offering a rather small Linux dom0. https://en.wikipedia.org/wiki/Proxmox_Virtual_Environment and KVM may also be an interesting combination to look at? Checking for others in https://en.wikipedia.org/wiki/Comparison_of_platform_virtualization_software my impression is that those Hypervisors which run on bare metal somehow tend to be either Linux specific or commercial and proprietary things? Regards, Eric ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Linking asm with C
hi! if you are using a protected mode model,
it may be impossible to call int 10 directly
and you may have to use dpmi for that.
all compilers for DOS offer ways to call BIOS
and other interrupts directly from C, which
is a lot more foolproof than using ASM here.
the next problem is whether you should use
RET here, that may be something C does for
you and it may be something more complex
than just calling RET, e.g. also preparing
and clearing up the stack before and after
the ASM part. you can try without the RET.
C compilers have various opinions about
whether and which registers you are allowed
to change, but int ax=0x0013 probably is
safe, changing only AX, as far as I remember.
Note that you write mov al,0x13, which
means you do NOT specify what AH should
be. this is a BAD idea. AH could be any
arbitrary value at that moment, so you
could be triggering any VGA BIOS int 10
thing instead of the one you intended.
Finally, your clear screen confuses the
graphics RAM segment 0xa000 with absolute
address 0xa and relative offsets of
0 to 0xfa00 within that. It will depend
A LOT on which compiler and memory model
you use what the PROPER way to do this
will be for you. I can only tell that
the style you use right know is NOT okay
and will just overwrite data and crash.
Regards, Eric
I can’t for the love of god figure out why this is throwing the divide
by zero interrupt.
void setMCGA() {
_asm {
mov al, 0x13
int 0x10
ret
}
}
void setText() {
_asm {
mov al, 0x03
int 0x10
ret
}
}
void clearScreen(char color) {
int i;
for (i = 0xa000; i < 0xfa00; i++) {
char* byte = i;
*byte = color;
}
}
int main(int argc, char** argv) {
setMCGA();
clearScreen(255);
getchar();
setText();
return 0;
}
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Upcoming 1.3-RC5
Hi Jerome, Here is the NEW general logic used by the installer in NORMAL mode. if the MBR for the target hard disk DOES NOT CONTAIN any boot code in the MBR, then ASSUME YES and overwrite it. if the MBR for the target hard disk has ANY KIND of boot code in the MBR, then PROMPT USER to overwrite it. I assume by "it" you mean the boot code? How about the partition table? As far as the boot code is concerned, the new logics sound nice :-) I’m thinking of also adding Or, if there is ONLY a single DOS partition on the drive, then ASSUME YES. You mean if there IS boot code and a partition, you want to overwrite the boot code and/or partition table nevertheless? Why that? And why not ask the user, possibly with a prompt telling them that they are "only" going to overwrite a single FAT partition, just to be sure? A single prompt definitely is not too much to prevent data loss or "bootability loss". Imagine the scenario where there is only 1 FAT partition and you keep the partition (which I recommend) but overwrite the MBR boot code without asking. The boot code may have contained something specific to the hardware, such as a LBA helper for old BIOSes and replacing it may render the system unbootable. The case where no boot code at all can be found in the MBR is much lower risk :-) You could backup the previous MBR contents and provide a way to restore either boot code or partition table or both, for example in the form of a readme file explaining how to use FDISK or DEBUG and a backup file created by the installer before modifying MBRs. Of course if there is a security prompt, this will be needed much less often, but having a backup file would not hurt either way :-) FDISK has command line calls for some of this, as far as I remember. Thanks! Regards, Eric PS: Do not forget to update and promote UHDD instead of UIDE :-) ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] FreeDOS kernel DMA boundary handling versus I/O speed configurability request
Hi Jeremy, a last minute request for the new kernel release: In context of the patch for significant I/O speed improvements by only splitting transfers around DMA boundaries for drives where that actually is needed, based on the int 13.48 flags, please add a config sys option to override the int 13.48 answer into either "always avoid DMA boundaries" or "always assume DMA boundaries are no problem" for all fixed disks (0x80 and up). Background: MS DOS, predating the int 13.4x extensions, probably defaults to never avoiding DMA boundaries for fixed disks and always avoiding them for floppy. So the config sys flag can give us MS DOS speed and behavior even when using BIOSes which fail to properly report their ability to transparently handle any DMA boundary issues. We would needlessly lose I/O speed otherwise. The other option, always avoiding DMA boundaries, would allow the user to switch back to old FreeDOS behaviour, for example for benchmark comparisons or for cases where the BIOS claims to be DMA boundary safe, but actually messes up handling there. Thanks :-) As said, the ability to either avoid or not avoid DMA boundaries would make a big difference for I/O speed. I think it was Tom who proposed the patch which made us int 13.48 aware :-) Regards, Eric PS: I think it is NOT necessary to have similar options for individual drive numbers, because any mismatch between the reported and actual abilities will usually affect all disks of the same BIOS and having 2+ broken disk BIOSes is uncommon. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.3-RC5
Hi! Do we wait for a new KERNEL and FREECOM release? Jeremy was almost ready with those quite a while ago, It would be nice if RC5 had those. But, I don’t know how far off those are. Very nearby, I would say. If we don’t include updates for those in RC5, I don’t feel it would be wise to update them for 1.3-FINAL. I would rather delay the release of the next release candidate than say "if the next kernel update takes too long, we could simply sell the next distro with a 5 year old kernel". That would be a big disappointment regarding what you get by using the new update. So, dear distro experts: Please awaken Jeremy to officially publish the new KERNEL and FREECOM versions and find somebody (sorry, I am away from my build system) to update the FDISK partitioning wizard as well. Also, while waiting for those, please make sure to use the newest UHDD, UDVD2, DEBUG, XMGR and, if you like, HIMEMSX with patched giga-sized RDISK from Mercury's download page. Sad that we still have no news of AHCICD, regarding licensing, from the author's survivors. I also strongly recommend to make the "no XMS" boot option and similar 8086 friendly boot editions use KSSF freecom, as the XMS swap version would take away too much app memory. Thanks! PS: FreeDOS.org says new Bochs, Links and other updates are here :-) ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] TDSK related issues.
Hi Rugxulo, thanks, noticed kernel 2040 is listed on Ibiblio now as well. http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/kernel/2040/ would you be able and willing to copy the kernel's changelog as it's in CVS/SVN right now, to above directory? DOS386 and/or Christian Masloch ... http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/kernel/history.txt Thank you, that is more search engine friendly than having to browse the www CVS/SVN page on sourceforge. However, you still need to use a search engine to find the history.txt, maybe we could have a link on a more prominent place on freedos.org or on the wiki :-) Eric -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] UPX and XFDISK (was: EXE2BIN)
Hi, Here it is (w/ srcs and one-byte diff): https://sites.google.com/site/rugxulo/XFDISK.ZIP?attredirects=0d=1 Nice size for a patch ;-) As for UPX terms, I could try LZMA and Ultra Brute settings indeed, but wonder what effect (decompression possible at all? loading times? memory uses? does resulting binary work?) they have on ancient machines. I think XFDISK, even at the best of times, only works on 286s on up. But I used --ultra-brute --lzma --8086 anyways I got the impression that lzma and ultra-brute are very slow to create and that lzma will use more CPU and RAM even when unpacking... So I would probably settle with something more humble, something like upx --8086 --best *.com which should still be quite decent in size reduction in particular when compressing typical relatively small DOS apps like we do. Eric PS: The above is based on intuition, not research. -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] UPX and XFDISK
Hi! There was a question about the which of the algorithms (LZMA, NRV, UCL) is safe for GPL software. A quick review of the UPX web site did not give me a clear answer on which one was used when I specified -9 --8086 for options. Does anybody know off the top of their heads? I personally would say they are all safe, but because NRV is closed source, it would be bad for Debian evangelists to use that. To have the toolchain itself open source, you have to use UPX-UCL. Each UPX tool only supports either NRV or UCL as far as I remember and the default download on the UPX homepage is NRV, but Rugxulo et al do deliberately use UPX versions compiled with UCL style which is only a bit less effective than NRV. As said, UCL is open source, as is the LZMA compression which is rather new, included in all newer UPX binaries (both UCL and NRV style ones) sometimes (in particular for larger apps) more effective in compressing and always much slower in compressing. LZMA is also likely to be slower in uncompressing (i.e. when you run compressed apps) and likely to use more RAM for both compressing and uncompressing. So far my F.U.D. about LZMA ;-) Eric -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
