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] Re: Freedos-kernel digest, Vol 1 #409 - 1 msg
Charles Doty wrote: Is there a specific reason to compile out the check and not simply use the config option to disable the 2 second f5/f8 check? I missed that config option. Is it in config.b? No, perhaps I should have been more clear. It is a settable configuration option via sys config skipconfigseconds=# where # (see kconfig.h) represents: 0 : not possible to skip config.sys (no check), and no delay = 0 : only possible if already pressed before, no delay or message 0 : wait that many seconds for F5/F8 to be pressed Additionally ensure BootHarddiskSeconds (another sys config option) is the default of 0 (or a negative value) so when not booting from a hard drive it just continues the boot without waiting/prompting the user. A positive value here will cause a delay, with a default action of booting from the hard drive instead of the floppy or whatever (useful if you tend to leave a bootable floppy or CD in the drive but usually want it actually boot). Jeremy --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: Freedos-kernel digest, Vol 1 #409 - 1 msg
Is there a specific reason to compile out the check and not simply use the config option to disable the 2 second f5/f8 check? I missed that config option. Is it in config.b? --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: Freedos-kernel digest, Vol 1 #404 - 2 msgs
[EMAIL PROTECTED] escribió: Send Freedos-kernel mailing list submissions to freedos-kernel@lists.sourceforge.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/freedos-kernel or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than Re: Contents of Freedos-kernel digest... Today's Topics: 1. Re: please change the default freecom and increasethe kernel version (Robert Riebisch) --__--__-- Message: 1 Date: Fri, 27 Jan 2006 11:32:12 +0100 From: Robert Riebisch [EMAIL PROTECTED] Organization: BTTR Software To: freedos-kernel@lists.sourceforge.net Subject: Re: [Freedos-kernel] please change the default freecom and increasethe kernel version Reply-To: freedos-kernel@lists.sourceforge.net Alain wrote: Would averyone agree to include it? I agree. ;-) Robert Riebisch I agree but the newest compile with -DWITHFAT32 -DWIN31SUPPORT :D:D --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] re: please change the default freecom and increase the kernel version
Hi Bernd, kernel 2034, 2035 released by Bart kernel 2035A released by Jeremy kernel 2035B by Jeremy (2035A + stable features backported from 2035W) kernel 2035W by Jeremy, experimental/development line The core problem is that 2035w is not a version. It is the label for the daily compile kernels and has been for a year or more... There is some int 21 function to grab the version STRING, but VER does not use that function. And it would not really help either, as normal mortals cannot do cvs checkout [version defined by date in terms of day month year] nor can they compile the kernel. So they can only eat the kernel of the day or refuse to do so and be stuck with 2035b. When they find a bug, they can only compare today with 2035b, they cannot test in-between versions. FreeCOM 0.82, 0.82patchlevel 1, 0.82pl2, 0.82pl3 by Steffen Kaiser flavour 1: XMS-swapping, 8086+ flavour 2: KSSF-swapping, 8086+ FreeCOM 0.84prerelease (CVS) by Jeremy flavour 1: XMS-swapping, 8086+, no LH, no ALIAS flavour 2: XMS-swapping, 80186+, full-featured flavour 3: KSSF-swapping, 8086+, full-featured, no binary available. What I'm afraid of is 80186+/80386+ binaries which somehow end up being transferred to older machines (8086). Then it might not work (kernel for example). That's why 8086-kernel and 8086-FreeCOM are provided by default. Only (major!) drawback to that is no LH functionality in FreeCOM. Bernd, you can count 8086 users in parts per mio in 2006. Please do make the 186+ XMS Swap full featured FreeCOM the default. Otherwise 999 of 1000 users will complain about the crappy FreeCOM which cannot even LH, which has ALIAS broken, and so on. Note that you did not upload a diskette edition of the current beta anyway, to the three still existing 8086 users on the world cannot install the beta anyway. They will use ODIN or will use a bootdisk from fdos.org, possibly manually replacing the FreeCOM on it by the 8086 one if needed. Eric --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] re: Can FreeDOS be installed on embedded system based on 80186/80188?
Hi, the short answer is: YES. You can run FreeDOS on 8086. is it possible that freeDOS work on an embedded system without BIOS? The answer for that is longer. Searching for embed on http://fd-doc.sourceforge.net/faq/cgi-bin/search.cgi will point you to: http://fd-doc.sourceforge.net/faq/cgi-bin/viewfaq.cgi?faq=./incoming/277 which explains which BIOS services you have to provide for a minimal FreeDOS install (in other words, services which are needed by the kernel itself - depending on which DOS programs you want to run, you may need additional BIOS parts loaded). Note that running FreeDOS on a pre-286 will use a lot of RAM. Normally, FreeDOS will move most of the kernel to HMA (right after the first 1 MB) and the FreeCOM shell will use XMS for swapping, so it only uses a small amount of DOS memory. As your 80186 has no HMA and no XMS, both the kernel and the FreeCOM command.com shell will have to use DOS memory for everthing, so I think only 400-500 kilobytes of DOS RAM will be free. On a 286 system, it is easy to have more than 600 kilobytes free with FreeDOS. On a 386 with EMM386 or another UMB driver loaded, you can even use dosdata=umb / loadhigh / devicehigh to get more than 620 kilobytes of the 640 kilobytes of DOS RAM free. Of course you will also be unable to do some 386-specific things, including: emm386, caching, dosfsck, booting from LBA FAT32 drives, himem (but you can use fdxms instead of himem if you have at least a 286 or newer processor). If EDIT or KEYB fail on your 80186, try EDIT 0.7d and MKEYB, which should work even on 8086. Or use no keyboard driver at all (if you use US keyboard layout). Let us know if you find other programs which do not work on 80186 processors. To get started, download the kernel and shell or a minimal boot disk from http://fdos.org/kernel/ - you should probably not use the big ISO distros (beta9sr2: 12 MB, Blair's full ISO: 120 MB). But you can use the ODIN one diskette distro with many preinstalled programs. Eric PS: Feel free to add corrections / ideas to the FAQ entry about 80186. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] re: Can FreeDOS be installed on embedded system based on 80186/80188?
Hi! 16-Дек-2005 13:50 [EMAIL PROTECTED] (Eric Auer) wrote to freedos-kernel@lists.sourceforge.net: EA EDIT 0.7d and MKEYB, which should work even on 8086. Or use no MKEYB uses INT15 service, which not present on XT. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: [Freedos-cvs] freecom/lib cd_dir.c,1.4,1.5 critrchk.c,1.1,1.2 err61.c,1.4,1.5 mk_rddir.c,1.2,1.3 optsb.c,1.3,1.4 where.c,1.5,1.6
Hi!
I wrote:
+++ mk_rddir.c10 Dec 2005 10:09:43 - 1.3
+int lfn_mrc_dir(const char *path, int mode)
+{
+ struct REGPACK r;
+ int mrc_f[6] = { 0x713A, 0x7139, 0x713B, 0x3A, 0x39, 0x3B };
------
BTW, bug! Function number should come in AH, not AL! So:
+ r.r_ax = mrc_f[mode + (checkDriveSupportsLFN(getdisk() + 'A') ? 0 :
3)];
if (checkDriveSupportsLFN(getdisk() + 'A'))
mode += 0x7100;
r.r_ax = mode;
Possible solution with my edition:
if (...)
mode += 0x7100;
else
mode = 8; /* shift low byte to high byte */
r.r_ax = mode;
Or:
if (...)
mode = (mode 8) + 0x7100;
r.r_ax = mode;
[...]
#define chdir(x) lfn_mrc_dir(x,0x3B00)
--^^
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] freecom/lib cd_dir.c,1.4,1.5 critrchk.c,1.1,1.2 err61.c,1.4,1.5 mk_rddir.c,1.2,1.3 optsb.c,1.3,1.4 where.c,1.5,1.6
Arkady V.Belousov wrote: ... BTW, bug! Function number should come in AH, not AL! So: ... I will try to fix in the morning, thanks. Jeremy --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: [Freedos-cvs] freecom/cmd dir.c,1.25,1.26 if.c,1.8,1.9 set.c,1.6,1.7
Hi!
10-Дек-2005 10:09 [EMAIL PROTECTED] (Kenneth Davis) wrote to
[EMAIL PROTECTED]:
+++ dir.c 10 Dec 2005 10:09:43 - 1.26
+#ifdef FEATURE_LONG_FILENAMES
void printLFNname(char *shortName, char *ext)
{
char pathbuffer[128];
+ char longname[270];
+ /* reconstruct the path+filename */
pathlen = strrchr(path,'\\') - path;
sprintf(pathbuffer,%*.*s\\%s%c%s
In memory of defensive programming:
- strrchr() may return NULL (I think, in many cases most standard functions
should be replaced by own versions with more safe characteristics);
- pathbufer shorter than longname.
+ /* LFN get canonical LFN */
r.r_ds = FP_SEG(pathbuffer);
+ r.r_si = FP_OFF(pathbuffer);
+ printf( %.30s , strrchr(longname, '\\')[1]);
--^---^^^
This is same as strrchr() + 1.
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: Freedos-kernel digest, Vol 1 #391 - 1 msg
[EMAIL PROTECTED] escribió: Send Freedos-kernel mailing list submissions to freedos-kernel@lists.sourceforge.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/freedos-kernel or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than Re: Contents of Freedos-kernel digest... Today's Topics: 1. comments changing (Arkady V.Belousov) --__--__-- Message: 1 To: freedos-kernel@lists.sourceforge.net From: Arkady V.Belousov [EMAIL PROTECTED] Date: Tue, 6 Dec 2005 20:45:29 +0300 (MSK) Subject: [Freedos-kernel] comments changing Reply-To: freedos-kernel@lists.sourceforge.net Hi! I think, before changing comments in current dev snapshot, should be released some intermediate release (say, 2036). --__--__-- ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel End of Freedos-kernel Digest Yeahh but with the with the windows 3.1 support enanbled , the latest beta sr2 does not have kernel compiled with -DWIN31SUPPORT to enable de windows 3.1 with debugging. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/sys sys.c,1.41.2.20,1.41.2.21 fdkrncfg.c,1.11.2.2,1.11.2.3
Arkady V.Belousov wrote: Hi! 30-Ноя-2005 21:59 [EMAIL PROTECTED] (Kenneth Davis) wrote to [EMAIL PROTECTED]: +++ sys.c 30 Nov 2005 21:59:18 - 1.41.2.21 -extern int VA_CDECL printf(const char * fmt, ...); -extern int VA_CDECL sprintf(char * buff, const char * fmt, ...); +extern int VA_CDECL printf(const char FAR * fmt, ...); +extern int VA_CDECL sprintf(char FAR * buff, const char FAR * fmt, ...); +++ fdkrncfg.c30 Nov 2005 21:59:18 - 1.11.2.3 -extern int VA_CDECL printf(const char * fmt, ...); -extern int VA_CDECL sprintf(char * buff, const char * fmt, ...); +extern int VA_CDECL printf(const char FAR * fmt, ...); +extern int VA_CDECL sprintf(char FAR * buff, const char FAR * fmt, ...); Isn't better to move prototypes to something like prf.h? -- Yes, and this is planned as they are repeated way too many times and a pain to keep in sync. :-) Jeremy --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: [Freedos-cvs] kernel/sys sys.c,1.41.2.20,1.41.2.21 fdkrncfg.c,1.11.2.2,1.11.2.3
Hi! 30-Ноя-2005 21:59 [EMAIL PROTECTED] (Kenneth Davis) wrote to [EMAIL PROTECTED]: +++ sys.c 30 Nov 2005 21:59:18 - 1.41.2.21 -extern int VA_CDECL printf(const char * fmt, ...); -extern int VA_CDECL sprintf(char * buff, const char * fmt, ...); +extern int VA_CDECL printf(const char FAR * fmt, ...); +extern int VA_CDECL sprintf(char FAR * buff, const char FAR * fmt, ...); +++ fdkrncfg.c30 Nov 2005 21:59:18 - 1.11.2.3 -extern int VA_CDECL printf(const char * fmt, ...); -extern int VA_CDECL sprintf(char * buff, const char * fmt, ...); +extern int VA_CDECL printf(const char FAR * fmt, ...); +extern int VA_CDECL sprintf(char FAR * buff, const char FAR * fmt, ...); Isn't better to move prototypes to something like prf.h? -- -- Best regards! Sincerely yours, Хемуль Советикус. Утомлённый чаем любитель сладкого, в девичестве Бильбо Ленивчатый. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: [Freedos-cvs] kernel/kernel init-mod.h,1.56.2.4,1.56.2.5 prf.c,1.31.2.3,1.31.2.4 proto.h,1.75.2.7,1.75.2.8
Hi! 20-Ноя-2005 16:39 [EMAIL PROTECTED] (Kenneth Davis) wrote to [EMAIL PROTECTED]: +++ prf.c 20 Nov 2005 16:39:14 - 1.31.2.4 @@ -123,17 +123,17 @@ +STATIC void do_printf(const char FAR *, va_list); +VOID VA_CDECL printf(const char FAR * fmt, ...); ^^ [...] -VOID VA_CDECL printf(const char *fmt, ...) +VOID VA_CDECL printf(CONST BYTE FAR *fmt, ...) ^^ Why? -VOID VA_CDECL sprintf(char * buff, const char * fmt, ...) +VOID VA_CDECL sprintf(char FAR * buff, CONST BYTE FAR * fmt, ...) -STATIC void do_printf(CONST BYTE * fmt, va_list arg) +STATIC void do_printf(CONST BYTE FAR * fmt, va_list arg) +++ init-mod.h20 Nov 2005 16:39:14 - 1.56.2.5 +VOID VA_CDECL init_sprintf(char FAR * buff, const char FAR * fmt, ...); +++ proto.h 20 Nov 2005 16:39:14 - 1.75.2.8 +VOID VA_CDECL printf(const char FAR* fmt, ...); +VOID VA_CDECL sprintf(char FAR * buff, const char FAR* fmt, ...); --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628alloc_id=16845op=click ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: [Freedos-cvs] kernel/kernel intwrap.asm,NONE,1.1.2.1
Hi! 20-Ноя-2005 16:57 [EMAIL PROTECTED] (Kenneth Davis) wrote to [EMAIL PROTECTED]: --- NEW FILE: intwrap.asm --- reloc_call_int13_handler: cli ; disable other interrupts for now INT instruction already disables IFlag. stc ; force error unless BIOS clears ?! This is issue of caller to set or reset CFlag. push dx ; store BIOS drive # for error handling usage push ds ; get segment of kernel DATA mov ds, [cs:_DGROUP_] pushf ; simulate int call so returns back here (flags+cs:ip on stack) call far [ds:_UserInt13] Bug!!! Here DS register is garbaged, whereas it used by some functions (for example, INT13/42). pop ds ; restore ds jc int13err ; test if error, if not return to caller int13iret: inc sp ; clean up stack inc sp sti ; ensure int's are renabled retf 2 ; return to caller leaving flags asis I don't think that this is right way, because caller may disable interrupts for own purposes, whereas here interrupts enabled. int13wrap: %IF XCPU 186 push ax ; preserve registers, setup stack frame push bp mov bp, sp mov ax, 13h; want to push 0x13 onto stack xchg ax, [bp+2] ; so restore pushed ax value and put 0x13 on stack pop bp ; clean up stack frame (leaving just 0x13 pushed on stack) pushbp pushbp mov bp,sp mov word [bp+2],13h pop bp --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628alloc_id=16845op=click ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel intwrap.asm,NONE,1.1.2.1
Arkady V.Belousov wrote: Hi! 20-Ноя-2005 16:57 [EMAIL PROTECTED] (Kenneth Davis) wrote to [EMAIL PROTECTED]: --- NEW FILE: intwrap.asm --- reloc_call_int13_handler: cli ; disable other interrupts for now INT instruction already disables IFlag. stc ; force error unless BIOS clears ?! This is issue of caller to set or reset CFlag. push dx ; store BIOS drive # for error handling usage push ds ; get segment of kernel DATA mov ds, [cs:_DGROUP_] pushf ; simulate int call so returns back here (flags+cs:ip on stack) call far [ds:_UserInt13] Bug!!! Here DS register is garbaged, whereas it used by some functions (for example, INT13/42). good catch, I rewrote this section several times until I finally tracked down my problem was my usual init-time variables don't match run-time variables [address wise, though the compiler thinks they do, so the UserInt13 initialized wasn't the one used] unless special care is taken. Earlier versions had a different path for ah 17h versus ah 17h, which I need to re-add (as the error values returned do not make sense for most functions ah 17h, but even if not returned, still within same error code group for those less; that or just change it to check on int13/16h ) pop ds ; restore ds jc int13err ; test if error, if not return to caller int13iret: inc sp ; clean up stack inc sp sti ; ensure int's are renabled retf 2 ; return to caller leaving flags asis I don't think that this is right way, because caller may disable interrupts for own purposes, whereas here interrupts enabled. I'm not sure what is correct here, but I suppose it should simply leave the flag as the user had it (I think I added this after reading a note somewhere in RBIL about a bug in earlier BIOSes that failed to do this). int13wrap: %IF XCPU 186 push ax ; preserve registers, setup stack frame push bp mov bp, sp mov ax, 13h; want to push 0x13 onto stack xchg ax, [bp+2] ; so restore pushed ax value and put 0x13 on stack pop bp ; clean up stack frame (leaving just 0x13 pushed on stack) pushbp pushbp mov bp,sp mov word [bp+2],13h pop bp I like it, cleaner and removes the easy to overlook restoration of ax Thanks for reviewing these patches, Jeremy --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28alloc_id845op=click ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: [Freedos-cvs] kernel/kernel intwrap.asm,1.1.2.1,1.1.2.2 kernel.asm,1.54.2.6,1.54.2.7
Hi! 20-Ноя-2005 19:03 [EMAIL PROTECTED] (Kenneth Davis) wrote to [EMAIL PROTECTED]: +++ intwrap.asm 20 Nov 2005 19:03:17 - 1.1.2.2 -sti ; ensure int's are renabled retf 2 ; return to caller leaving flags asis Another potential bug: if caller will not STI somewhere after INT13, then it will work in CLI state (because its IFlag is CLIed by INT instruction). --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628alloc_id=16845op=click ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel intwrap.asm,NONE,1.1.2.1
Hi! 20-Ноя-2005 13:50 [EMAIL PROTECTED] (Kenneth J. Davis) wrote to freedos-kernel@lists.sourceforge.net: int13iret: inc sp ; clean up stack inc sp sti ; ensure int's are renabled retf 2 ; return to caller leaving flags asis I don't think that this is right way, because caller may disable interrupts for own purposes, whereas here interrupts enabled. KJD I'm not sure what is correct here, I suggest, only returned ZF/CF should be copied to existing value on stack. For example: int13iret: pushax lahf pushbp mov bp,sp and byte [bp+10],not 0C1h ; 10=bp+ax+...+cs:ip and ah,0C1h ; remain only SF/ZF/CF flags or byte [bp+10],ah ; pass to caller SF/ZF/CF from INT13 pop bp pop ax add sp,2 iret KJD but I suppose it should simply leave KJD the flag as the user had it (I think I added this after reading a note KJD somewhere in RBIL about a bug in earlier BIOSes that failed to do this). --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628alloc_id=16845op=click ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: [Freedos-cvs] kernel/kernel dosfns.c,1.70.2.4,1.70.2.5 entry.asm,1.27.2.3,1.27.2.4 fatfs.c,1.70.2.5,1.70.2.6 int2f.asm,1.34.2.3,1.34.2.4 inthndlr.c,1.87.2.18,1.87.2.19 kernel.asm,
Hi! 6-Ноя-2005 19:50 [EMAIL PROTECTED] (Kenneth Davis) wrote to [EMAIL PROTECTED]: +++ inthndlr.c6 Nov 2005 19:50:34 - 1.87.2.19 - r.DX = 0xA2AB; /* on succes DS:AX set to A2AB:B97Ch */ + r.DX = 0xA2AB; /* on succes DX:AX set to A2AB:B97Ch */ @@ -1839,29 +1859,89 @@ */ r.DX = 0xA2AB; /* on succes DS:AX set to A2AB:B97Ch */ --^^ DX +++ entry.asm 6 Nov 2005 19:50:34 - 1.27.2.4 +mov dx,[cs:_DGROUP_] +mov ds,dx mov ds,[cs:_DGROUP_] +cmp word [_OemHook21], -1 +je no_oemhndlr +cmp word [_OemHook21+2], -1 +je no_oemhndlr This is if (FP_OFF (OemHook21) != -1 FP_SEG (OemHook21) != -1), which is not equal to if (OemHook21 != -1) _and_ prevents OemHook21 point to HMA. I suggest, check only for offset is enough. (And in this case you may restore DS right before JE.) +pop dx +pop ds +jmp far [ds:_OemHook21] ; invoke OEM handler (no return) Looks like bug: if before ds=cs:_DGROUP_ DS doesn't contains segment of _OemHook21, then it willn't contain it after POP DS (and JMP then tries to get jump address from wrong point). Else, if DS contains segment of _OemHook21 before this code, then why MOV DS above? --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel dosfns.c,1.70.2.4,1.70.2.5 entry.asm,1.27.2.3,1.27.2.4 fatfs.c,1.70.2.5,1.70.2.6 int2f.asm,1.34.2.3,1.34.2.4 inthndlr.c,1.87.2.18,1.87.2.19 kernel.
Arkady V.Belousov wrote: ... +cmp word [_OemHook21], -1 +je no_oemhndlr +cmp word [_OemHook21+2], -1 +je no_oemhndlr This is if (FP_OFF (OemHook21) != -1 FP_SEG (OemHook21) != -1), which is not equal to if (OemHook21 != -1) _and_ prevents OemHook21 point to HMA. I suggest, check only for offset is enough. (And in this case you may restore DS right before JE.) sounds like a reasonble solution as I doubt anyone really would set this to : for a valid pointer. +pop dx +pop ds +jmp far [ds:_OemHook21] ; invoke OEM handler (no return) Looks like bug: if before ds=cs:_DGROUP_ DS doesn't contains segment of _OemHook21, then it willn't contain it after POP DS (and JMP then tries to get jump address from wrong point). Else, if DS contains segment of _OemHook21 before this code, then why MOV DS above? ... I agree there is a bug here, I originally coded this differently (copied address to a variable in code segment which I believe a comments still has remnants of) and then simplified it at some point (which introduced the bug). I have a fix locally (just need to compile and test). Jeremy --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel dosfns.c,1.70.2.4,1.70.2.5 entry.asm,1.27.2.3,1.27.2.4 fatfs.c,1.70.2.5,1.70.2.6 int2f.asm,1.34.2.3,1.34.2.4 inthndlr.c,1.87.2.18,1.87.2.1
Hi! 6-Ноя-2005 17:44 [EMAIL PROTECTED] (Kenneth J. Davis) wrote to freedos-kernel@lists.sourceforge.net: +jmp far [ds:_OemHook21] ; invoke OEM handler (no return) Looks like bug: if before ds=cs:_DGROUP_ DS doesn't contains segment of _OemHook21, then it willn't contain it after POP DS (and JMP then tries to get jump address from wrong point). Else, if DS contains segment of _OemHook21 before this code, then why MOV DS above? KJD I agree there is a bug here, I originally coded this differently (copied KJD address to a variable in code segment which I believe a comments still KJD has remnants of) pushax ; place for push ax ; far address pushbp movbp,sp ; pointer to above place pushds mov ds,[cs:_DGROUP_] lds ax,[_OemHook21] mov [bp+6],ds pop ds cmp ax,-1 ; FP_OFF(OemHook21) != -1 ? xchg[bp+4],ax pop bp je ... retf ...:add sp,4 KJD and then simplified it at some point (which introduced KJD the bug). I have a fix locally (just need to compile and test). --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: reload partition table and reassign drive letters
Hi Jeremy, Date: Tue, 18 Oct 2005 08:24:41 -0400 From: Kenneth J. Davis [EMAIL PROTECTED] To: freedos-kernel@lists.sourceforge.net Subject: Re: [Freedos-kernel] reload partition table and reassign drive letters Reply-To: freedos-kernel@lists.sourceforge.net I've considered this in the past, but the consensus seems to be that it is best just to reboot. It is possible to assuming no TSRs are loaded that would be confused by such action, but if done in the kernel it would involve leaving normally init time (hence transient so does not normally occupy the precious low memory) code in. If you really really really need to do this, then for a controlled setup only (no TSRs or ones you know, and I do mean know, will not be confused by such action -- note FreeCom may be confused by such action) If FreeCom can handle drive letters coming and going due to network drives being connected/disconnected, how would fixed disks coming and going make a difference? I would have thought that FreeCom wouldn't pay much attention to what type of drive it was looking at. Clueless and hoping to learn something interesting :) David --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: reload partition table and reassign drive letters
The main issue with FreeCom would be the location of its resources changing. As long as the comspec env variable still pointed to the same (or an identical) copy of the strings, it would probably be ok, but honestly I don't know if FreeCom closes/opens or keeps open the file with its resources. There may or may not be other issues. Jeremy --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: reload partition table and reassign drive letters
Hello Kenneth, The main issue with FreeCom would be the location of its resources changing. under normal circumstances, FreeCom-xmsswap will have it's resources loaded at startup and touch them never again. Tom --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] re: Re: reload partition table and reassign drive letters
Hi, yes, FreeCOM can handle changing drive letters. The PROBLEM is that harddisk letters are handled by a kernel driver which can only do one hole-free range of drive letters. So if you could enable a new partition on the fly, all subsequent drive letters would move. HOWEVER, you are free to write a RAMDISK style driver which MOUNTS an arbitrary FAT partition: You only have to provide sector read/write and calculate the right (read: offset by partition start position) sector numbers, and the kernel will do the rest. Such a driver can even be loaded from the prompt with devload... Eric --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] re: Re: reload partition table and reassign drive letters
Eric Auer schreef: Hi, yes, FreeCOM can handle changing drive letters. The PROBLEM is that harddisk letters are handled by a kernel driver which can only do one hole-free range of drive letters. So if you could enable a new partition on the fly, all subsequent drive letters would move. HOWEVER, you are free to write a RAMDISK style driver which MOUNTS an arbitrary FAT partition: You only have to provide sector read/write and calculate the right (read: offset by partition start position) sector numbers, and the kernel will do the rest. Such a driver can even be loaded from the prompt with devload... except it cannot re-assign already used driveletters I guess. Same as Jason Hood's disk mounting tools cannot use B:, the kernel already claims it as alternative for A:. There's no if B: refers to same drive as A:, then allow another disk mounting tool to install itself as B: (hm, nice idea. No idea if possible). Kernel can access the partition table, thus also count/determine how many FAT partitions are present. 1st FAT partition will be C:. So a certain range must be free [4 partitions: C..F ]. If C..F are still available, dismount + remount. I like this remount idea, it proves how much we consider the existing limits of DOS, even while writing replacement components that optionally may behave smarter/better as long as it doesn't hurt compatibility. Quarterdeck's quickboot was such an idea, and Eric implemented something like it in FDAPM (is there a single known case of hotboot works though?). Quickboot ment skip BIOS part of boot process upon warm reboot. DOS disk partitioning tools only insist on rebooting because the kernel only recognizes harddisk partitions upon initialisation of the kernel, not at runtime. If the FreeDOS kernel would allow rescanning somehow, FreeDOS Fdisk could be made to not reboot if user decides so. I realize the investment/profit ratio is very bad, which would mean this option would not be implemented any time soon, and would probably be a patch contributed by an 'external' developer instead of regular people working on the kernel. @echo off echo FAT partition on harddisk required, as drive C: if exist c:\nul goto skipfdsk fdisk rem let the used DOS kernel re-initialise driveletters assigned to disk partitions. Don't touch A,B, and driveletters installed by drivers. Fdisk /rescanharddisks if not exist c:\nul fdisk /reboot goto skipfdsk :skipfdsk a driver for mount/initialisation also sounds nice. Eric Bernd --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] re: reload partition table and reassign drive letters
Hi Bernd, I did not invent quickboot, fdapm hotboot just calls int 19 (load boot sector and run it). To make that work in real life, you would have to have all interrupt vectors DOS free at the moment, or at least some int 19 handler would have to be hooked by everything which hooks boot-relavant interrupt vectors. Most DOS components do not do that, maybe Quarterdeck quickboot has a sys driver which backups / restores values from early during boot to make int 19 work. Second point, reassign drive letters: You CAN steal drive letters from existing drivers, then fiddle with the drive table and so on, but I very much doubt that that would be useful. In the case of mounting a freshly made partition, it would be easier to ADD a drive letter in unused drive letter space with the described ramdisk style driver instead of modifying existing drive letters. Do not make things more complicated than they need to be. Eric --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] re: reload partition table and reassign drive letters
firstly, I never said FreeCom couldn't handle drive letter changes, I said if one did something, then they need to make sure it can; in particular the way it loads strings; although from my experience not being able to load its strings usually just results in FreeCom issuing useless messages (eg try to do dir get a bunch string #XX instead). I stand by my take the code from the kernel and make it an external program if you really want it. Its not overly difficult, just make sure all files are closed first, change the internal structures (hence the kernel version check), and as far as the kernel is concerned nothing happened, but now you may have different drive letters. Of course you would want to be sure to handle the case of LASTDRIVE too small and various details like that. And really if you wanted to be clever, maintain the needed information about open files and TSRs won't even notice the change, even if the file is now on a different drive (C:-D:) The point is, in a known boot state this could all work fine, but in a random user's setup, some program out there is going to get confused and cause data loss (some undelete, raw disk accessing, ... utility) and given the effort involved for such tool versus the man power we have, the best idea is just plan for a reboot. This has the advantage of almost always working, requires no kernel specific knowledge (so same boot disk can easy be changed to use FD/MS/PC/DR/EDR/ROM/??? DOS) and is not too difficult; for floppies simply require it to be writable and store the current state (this is what was done at my old job for repartiting/restoring/upgrading the PCs [of course they were all IBM machines so it was easy to detect the proper machine for driver/BIOS issues]) and for CDs there are methods. As for the int19h issue, MS DOS actually hooks several (I think this is one) and assuming it eventually gets called by whoever hooks it after, does several things to aid in rebooting; restoring a couple of the int vectors and if himem was loaded it clears the vdisk entry so it will reload on next boot (unlike with FD where you get the driver already loaded error). So to summarize, yes DOS could reload partition tables and reassign drive letters, to a certain extent some drivers such as CD or network drivers do this, current kernels do not do a complete scan and reassign drive letters though, doing so would require work from developers we don't have and if made into a resident DOS call would waste conventional memory for most people. Jeremy --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] re: Re: reload partition table and reassign drive letters
Hi! 20-Окт-2005 00:42 [EMAIL PROTECTED] (Bernd Blaauw) wrote to freedos-kernel@lists.sourceforge.net: style driver which MOUNTS an arbitrary FAT partition: You only BB except it cannot re-assign already used driveletters I guess. Same as There exists utilities, which swaps drive letters (for example, SSWAP.EXE from Stacker). So, this is possible to handle drive mappings with help of external utilities on the fly. Though, I suggest, this may be dangerous, if some other utility (like disk cache) links itself to drive letters. BB If C..F are still available, dismount + remount. --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] re: reload partition table and reassign drive letters
Hi, Very very nice discussion, I am enjoying this a lot, thanks! Kenneth J. Davis escribió: various details like that. And really if you wanted to be clever, maintain the needed information about open files and TSRs won't even notice the change, even if the file is now on a different drive (C:-D:) The point is, in a known boot state this could all work fine, but in a random user's setup, some program out there is going to get confused and cause data loss (some undelete, raw disk accessing, ... utility) and given the effort involved for such tool versus the man power we have, the best idea is just plan for a reboot. This has the In my opinion, there's no need to worry about external UNDELETE (ours could be adapted) or other raw disk accessing utilities. First of all, theoretically because proper DOS apps should not be using BIOS/Hardware (I know many do), but secondly because after all, none of them were actually working with Microsoft's DBLSPACE/DRVSPACE: if they can do it, we can do too. Just announcements here and there NOT to use partition mounting/unmounting with such tools. As for the int19h issue, MS DOS actually hooks several (I think this is Well, vectors 20h-39h are actually assigned to OS/DOS by the PC Architecture standard, right? So to summarize, yes DOS could reload partition tables and reassign drive letters, to a certain extent some drivers such as CD or network drivers do this, current kernels do not do a complete scan and reassign drive letters though, doing so would require work from developers we don't have and if made into a resident DOS call would waste conventional memory for most people. Well, we certainly have other priorities now, but not a reason not to add it to the post-1.0 list, for the next (forthcomming!) revision... Aitor --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] re: reload partition table and reassign drive letters
Hi, Jeremy is right, FreeDOS boots in seconds, so it is best to just reboot. Dynamic drive letter assignment is not what DOS programs are used to cope with. HOWEVER, useful aspects of re-read partitions would be: - you can scan a PCMCIA disk after initializing the disk controller - you can rescan a normal harddisk after loading an improved version of our UDMA2 driver, to gain access to the full disk even if the BIOS can only access the first 32, 64 or 128 Gigabytes. - possibly other things :-). About you first partition, then reboot, then restore a diskimage, then reboot, then edit the config, then reboot to Windows in your WinXP net installer system: You could avoid one or two steps by using a tool which can copy the image to raw space / which reads the partition table itself. I think this is quite normal for disk image tools: You do not copy the image to a drive letter, you copy it to a partition. So DOS'es drive letter system is not involved. A second reboot might be saved by using a DOS version of the mtools (known from Linux) to copy files to unmounted filesystems, e.g. to the restored partition before it even has a drive letter. By the way, WinXP should better use NTFS instead of FAT anyway. There are tools like ntfs4dos to copy files to NTFS. Eric --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: device=f:\foo.sys fails
Hi Bart, Date: Sun, 11 Sep 2005 18:12:26 +1200 (NZST) From: Bart Oldeman [EMAIL PROTECTED] [...] here's a patch which fixes a problem where drives E: aren't properly initialized with a full CDS entry until after all device drivers are loaded. RBIL actually says about lastdrive: 21hBYTEnumber of available drive letters; also size of current directory structure array. For DOS 4.0-6.0: largest of 5, installed block devices, and CONFIG.SYS LASTDRIVE= For DOS 7.x (Windows9X), set to 32 if no LASTDRIVE= or LASTDRIVEHIGH=, else set to larger of installed block devices and LASTDRIVE(HIGH)= we always use the 4.0-6.0 method. Technically the FAT32-enabled kernel should emulate the DOS 7.x behaviour, and the other one 5.0 behaviour. But perhaps 7.x behaviour is desirable at all times? So if we're not initialising drives E: until all the drivers are loaded, what are we doing once they are all loaded - initializing the ones that are used but making the memory for the others available? Could we not just initialize 26 but still make the memory for the unused ones E: available after the drivers are loaded? If we're not making the memory available, of course, it sounds like there is not much point in setting LASTDRIVE to anything but 26 :) Please excuse my cluelessness, I guess I could read the source but I figure you can answer my questions pretty quickly! Thanks in advance, David --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: device=f:\foo.sys fails
Hi! 20-Сен-2005 21:52 [EMAIL PROTECTED] (David O'Shea) wrote to freedos-kernel@lists.sourceforge.net: DO Could we not just initialize 26 but still make the memory for the DO unused ones E: available after the drivers are loaded? It is. --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: re:about boot sector
Yeah , I have known .Thanks Jeremyd
[Freedos-kernel] re: Kernel debugging
Hi, I think you can indeed introduce a compile time option like the DOSEMU one (which makes put_console send output to int e6 function 13) to get output to Bochs / QEmu specific interfaces. On the other hand, you can just use DOSEMU :-). I really recommend to use Bochs and the built-in debugger of Bochs for kernel debugging. Make sure you have a local copy of the kernel sources and of Ralf Brown's Interrupt List around, then you should really be able to understand things happening in the kernel very well after a while. Eric --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] re: DEVLOAD / ramdisk troubles - or kernel problems?
Hi Florian, What is ... supposed to be? Aitor Florian Xaver escribió: Hi! Another idea: Why not including ... ? I am using 4DOS very often, and am happy with it. I mostly don't need more points :-) Bye, Flo --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] re: DEVLOAD / ramdisk troubles - or kernel problems?
Hi! Another idea: Why not including ... ? I am using 4DOS very often, and am happy with it. I mostly don't need more points :-) Bye, Flo Eric, I have uploaded a test kernel [stable branch] for you to try. http://www.fdos.org/kernel/test/kernel.eric.sys It implements the two items you suggest, a check check for \,., and .. before checking all device headers, and the device header is checked to make sure it is a character device before testing its name. --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] re: DEVLOAD / ramdisk troubles - or kernel problems?
Hi, as the KERNEL.dbgdev from fdos.org/kernel works for me in
DOSEmu, I could do some DEVLOAD CD .. problem debugging:
Unfortunately the debug output is very verbose and multi-line, so
I replaced media_check: no change by MC:ok and replaced
get_near_f_node and got near fnode by getfnode and got: below:
D:\TEMPcd ..
MC:ok getfnode: fnp is 0108:0CE0 got: fnp-f_count=1 MC:ok
truename(..)
CDS entry: #3 @C430:0108 (2) 'D:\TEMP'
[At this point you get CHDIR failed from FreeCOM after DEVLOADing
the Deskwork RAMDISK or another RAMDISK... Does not happen with
DEVICE= loaded RAMDISKs or drivers which can be loaded from prompt
without devload, nor does it happen with usbaspi or aspidisk devload!]
SUBSTing from: D:\TEMP
MC:ok getfnode: fnp is 0108:0CE0 got: fnp-f_count=1 MC:ok
Absolute logical path: D:\
Physical path: D:\
MC:ok getfnode: fnp is 0108:0CE0 got: fnp-f_count=1 MC:ok
MC:ok getfnode: fnp is 0108:0CE0 got: fnp-f_count=1 MC:ok
D:\
Given the code flow in COUNT truename(...) and the (missing) debug
messages before the failure, I think that
struct dhdr FAR *IsDevice(const char FAR * fname)
has a problem here. But why does that only happen with DEVLOAD?
Other candidates are drNrToLetter() and DosGetCuDir()...
But IsDevice looks like the one: It walks the device chain
starting from nul_dev to check if (the part before the dot of)
the provided filename matches the name of any device.
In the first place, file names like ., .. or \ should
always return is not a device name at once without even
walking the device chain.
Second, device chain entries ONLY have names for CHAR devices,
so the is the name the same as the name of the device? part
should be SKIPPED for BLOCK devices.
The problem happens in real DOS, in DOSEmu for diskimage drives,
and even in DOSEmu for lredir drives, and it looks like the
kernel is to blame here...
I hope there are still some readers on the kernel list and we
can move the further discussion to that list. A fix should be
quite straightforward: 1. . .. \ are all no device names and
2. dhp-dh_attr should be tested for ATTR_CHAR before comparing
the IsDevice input to dhp-dh_name.
struct dhdr { struct dhdr FAR *dh_next; UWORD dh_attr;
VOID(*dh_strategy) (void); VOID(*dh_interrupt) (void); UBYTE dh_name[8]; };
By the way, init_device drops devices which either take no memory
(endaddr same as device header location) or are 0 drive block devices.
Eric
---
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] re: DEVLOAD / ramdisk troubles - or kernel problems?
Eric Auer wrote:
...
struct dhdr FAR *IsDevice(const char FAR * fname)
has a problem here. But why does that only happen with DEVLOAD?
...
I hope there are still some readers on the kernel list and we
can move the further discussion to that list. A fix should be
quite straightforward: 1. . .. \ are all no device names and
2. dhp-dh_attr should be tested for ATTR_CHAR before comparing
the IsDevice input to dhp-dh_name.
struct dhdr { struct dhdr FAR *dh_next; UWORD dh_attr;
VOID(*dh_strategy) (void); VOID(*dh_interrupt) (void); UBYTE dh_name[8]; };
Eric, I have uploaded a test kernel [stable branch] for you to try.
http://www.fdos.org/kernel/test/kernel.eric.sys
It implements the two items you suggest, a check check for \,., and ..
before checking all device headers, and the device header is checked to
make sure it is a character device before testing its name.
Unfortunately I don't get the error you are experiencing with devload
and xmsdisk, it works fine for me without the fix so I can't verify it
will fix your problem (my guess is my computer's memory has 0s or values
that don't trigger the problem). I also fixed a bug in that function
where device names shorter than 8 characters could return as not a
device (on these i==FNAME_SIZE+1 due to inner for loop).
As soon as you test and get back to me, I will either change or commit.
By the way, init_device drops devices which either take no memory
(endaddr same as device header location) or are 0 drive block devices.
yes, this is correct.
Eric
Thanks for the detailed analysis,
Jeremy
---
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] re: DEVLOAD / ramdisk troubles - or kernel problems?
Hi Jeremy, that was quick... quite straightforward: 1. . .. \ are all no device names and 2. dhp-dh_attr should be tested for ATTR_CHAR before comparing the IsDevice input to dhp-dh_name. Eric, I have uploaded a test kernel [stable branch] for you to try. http://www.fdos.org/kernel/test/kernel.eric.sys Unfortunately this only fixes HALF of the problem: Actual / diskimage drives now allow CD .. again even if a block device driver which has the whole dh_name field filled with 00s (including the number-of-units value in the first byte, which ONLY happens for the deskwork.de dwdos RAMDISK and the OLD 3.13 DEVLOAD - both the new DEVLOAD and the DOS kernel (if you use DEVICE= instead of DEVLOAD) fill in number-of-units from the driver init call response). HOWEVER, if you DEVLOAD-old load the Deskwork ramdisk (so you have a block device with all-zero dh_name in the device chain), DOSEmu lredir drives (in my case: C: drive) appear completely empty. I can flip that problem by manually changing dh_name[0] of the Deskwork ramdisk between 00 (caused by devload problem) and 01 (correct). So your kernel is still not immune to the problem entirely - it still somehow uses names of block device drivers even though those names are optional and not even related to file name processing at all. Unfortunately I don't get the error you are experiencing with devload and xmsdisk, it works fine for me without the fix... XMSDSK has some name in dh_name[1..7] and also fills in dh_name[0] even if the kernel (here: old devload version) fails to do that for it. I also fixed a bug in that function where device names shorter than 8 characters could return as not a device (on these i==FNAME_SIZE+1 due to inner for loop). Are you sure that there was a bug? Maybe you even introduced one ;-). The comparison is meant to check if all chars beyond the end of the checked name are either 00 or space in the device header. If so, the device name is matching the checked name. So all 8 bytes of dh_name are checked before you know that it is a match. I think you got the bypass search if name is empty (. .. or root) right but have an error in skip name check if block device - you can check that by using old devload and deskwork ramdisk. Or just use DEBUG to zero out the dh_name bytes (including the [0] one) in the device header of your loaded XMSDSK. If you have no DOSEmu, you should disable the skip if .. part of your patch to make problems with skip if block device visible even on real / local drives. Eric --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] re: DEVLOAD / ramdisk troubles - or kernel problems?
Eric Auer wrote: ... So your kernel is still not immune to the problem entirely - it still somehow uses names of block device drivers even though those names are optional and not even related to file name processing at all. I will have to check and see if there are other references in the kernel then, as the IsDevice proc should not be the issue any longer (it checks the device header for character bit, and if not set continues to next header in chain bypassing any block devices). ... I also fixed a bug in that function where device names shorter than 8 characters could return as not a device (on these i==FNAME_SIZE+1 due to inner for loop). Are you sure that there was a bug? Maybe you even introduced one ;-). you are correct, not a bug, just a mistake on my part, already undone ... Eric Jeremy --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Analysis: Support for sector sizes != 512 bytes
Hi, tom ehlert escribió: Hello Eric, While we are at it, I would suggest a new category not planned at all unless you tell us why it is useful or alternatively send us patches for the list: http://fdos.org/ripcord/fdos_1_0/official/post.htm Bad idea: I unsupport this. If you don't want to patch them, don't do it, but don't close doors. Aitor --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: Analysis: Support for sector sizes != 512 bytes
Hi Arkady, AFAIK, CD-ROM sector is 2352 bytes. That would be the raw (cdda) sector size. For data (iso9660...) CD-ROM, the useable sector size is 2048 bytes, rest is CRC/ECC overhead. Eric, I suggest, non-standard sector size is not the hottest issue (and, probably, will never be actual in future). My point was that it would be easier than I had thought to support at least smaller-than-default sector sizes. Ramdisk/Romdisk could be happy about that (although the smallest sector size which still fits a minimal BPB, 64 bytes, would mean up to 1/33th of all space used already by each FAT in FAT16 case). Minimal in this context means: 3 bytes jump + 8 bytes OEM string + full FAT12/FAT16 BPB (including label, serno, FAT type string) + finally the 2 byte magic 55 aa value. So no FAT32 in the 64 byte / sector case. The more so, does anyone contains resources (devices), where non-standard sectors support may be YES, big question! Which FAT devices use non-standard sector size, apart from ramdisk/romdisk? For example memory cards, DiskOnModule, Flash, optical storage (e.g. DVD-RAM maybe?), maybe ZIP or LS120 or similar? TESTED? Whereas for non-standard devices you anyway should install their own device driver, which may easily emulate 512-bytes sectors. While the ElTorito driver can use sector sizes of 512, 1024 and 2048 bytes (depending on what is provided by the BIOS) I would really need more info about other devices. A driver CAN emulate 512 byte sectors, but WILL it do? After all, not all drivers are open source. I hope somebody can tell me whether there are storage devices which use nonstandard sector size and which could be used for DOS as soon as it supports that. After all, there ought to be a reason why other DOSes have support for it... While we are at it, I would suggest a new category not planned at all unless you tell us why it is useful or alternatively send us patches for the list: http://fdos.org/ripcord/fdos_1_0/official/post.htm Candidates are: drivparm / driver sys / 3rd floppy support (kernel, sys...), himem cpuclock and eisa options, graphics lcd option (for old CGA 640x200 handhelds with widescreen display), emm386 Weitek FPU MMIO support... Let me know if I forgot something. Eric PS: Eg. FASTOPEN can, imho, be useful, as scanning large directories causes big load for CPU and BUFFERS / cache which can be reduced by a specialized FASTOPEN directory entry cache. But thats just my 2 cents. --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393alloc_id=16281op=click ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Analysis: Support for sector sizes != 512 bytes
Hello Eric, While we are at it, I would suggest a new category not planned at all unless you tell us why it is useful or alternatively send us patches for the list: http://fdos.org/ripcord/fdos_1_0/official/post.htm Candidates are: drivparm / driver sys / 3rd floppy support (kernel, sys...), himem cpuclock and eisa options, graphics lcd option (for old CGA 640x200 handhelds with widescreen display), emm386 Weitek FPU MMIO support... Let me know if I forgot something. add sectorsize != 512 PS: Eg. FASTOPEN can, imho, be useful, as scanning large directories causes big load for CPU and BUFFERS / cache which can be reduced by a specialized FASTOPEN directory entry cache. But thats just my 2 cents. send us patches tom --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393alloc_id=16281op=click ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: DELTREE gets error 5 for directories since 2035a
Hi, Lucho pointed out that DELTREE got error 5 because it had code which does if OEM ID is 0FDh and CX is 0 or -1, then explicitly exclude the DIR attribute when resetting file attribs in preparation of deletion. This code is triggered by 2035a as it sets CX to 0, which is needed by 32RTM DOS extender. The -1 value marked VERY old DOS-C / FreeDOS kernels which needed the special DELTREE behaviour to avoid directories becoming files (oops)... The solution is two-part: The http://fdos.org/kernel/ page has kernels which ignore dir attribute access when you change file attributes (although it is common and okay to just respond with error 5, as 2035a does), and I have a patched version of DELTREE (which also is a bit smaller, less than 3 kB UPXed) which works with kernel 2035a. No reply from Raster about it yet, strange... http://www.coli.uni-sb.de/~eric/deltree-1.02f.zip (temporary location) Eric --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: DELTREE gets error 5 for directories since 2035a
Oops ... should have checked that more closely before posting. Eric is not the maintainer, of course. I've moved Eric's 1.02f into a subdir on ibiblio, and I'll try to reach Raster to see if this can become an official release of 1.02f. -jh Jim Hall wrote: Eric, I've mirrored your DELTREE 1.02f at ibiblio: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/deltree/ I'll also update the LSM database. Feel free to make an announcement on the FreeDOS.org page, if you want it announced there. -jh Eric Auer wrote: Hi, Lucho pointed out that DELTREE got error 5 because it had code which does if OEM ID is 0FDh and CX is 0 or -1, then explicitly exclude the DIR attribute when resetting file attribs in preparation of deletion. This code is triggered by 2035a as it sets CX to 0, which is needed by 32RTM DOS extender. The -1 value marked VERY old DOS-C / FreeDOS kernels which needed the special DELTREE behaviour to avoid directories becoming files (oops)... The solution is two-part: The http://fdos.org/kernel/ page has kernels which ignore dir attribute access when you change file attributes (although it is common and okay to just respond with error 5, as 2035a does), and I have a patched version of DELTREE (which also is a bit smaller, less than 3 kB UPXed) which works with kernel 2035a. No reply from Raster about it yet, strange... http://www.coli.uni-sb.de/~eric/deltree-1.02f.zip (temporary location) Eric -- I'm sorry my president's an idiot. I didn't vote for him. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: [Freedos-cvs] kernel/kernel fatfs.c,1.71,1.72 inthndlr.c,1.93,1.94 proto.h,1.77,1.78
Hi!
6--2005 16:58 [EMAIL PROTECTED] (Kenneth Davis) wrote to
[EMAIL PROTECTED]:
merge from dev kernel, Jason Hood's patch for extended DPBs and Set Extended
Error function
+++ inthndlr.c6 Mar 2005 16:58:31 - 1.94
@@ -1215,6 +1226,20 @@
+ /* Set Extended Error */
+case 0x0a:
+ {
+lregs er;
+fmemcpy(er, FP_DS_DX, sizeof(er));
+CritErrCode= er.AX;
+CritErrDev = MK_FP(er.ES, er.DI);
+CritErrLocus = er.CH;
+CritErrClass = er.BH;
+CritErrAction = er.BL;
+CLEAR_CARRY_FLAG();
+break;
+ }
Hm. Why to use stack and fmemcpy()? Isn't better to access directly:
__O\_/_\_/O__
case 0x0a:
#define er (* MK_PTR (lregs, lr.DS, lr.DX))
CritErrCode= er.AX;
CritErrDev = MK_FP(er.ES, er.DI);
CritErrLocus = er.CH;
CritErrClass = er.BH;
CritErrAction = er.BL;
#undef er
CLEAR_CARRY_FLAG();
break;
_
O/~\ /~\O
Or, if if by some reason doesn't wish to copy MK_PTR definition into stable
edition (why not?), _in given case_ you may do:
#define er (* (lregs FAR*) MK_FP (lr.DS, lr.DX))
/* --^^^ Don't forget */
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95alloc_id396op=click
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: [Freedos-cvs] kernel/kernel initdisk.c,1.34,1.35
!
6--2005 16:12 [EMAIL PROTECTED] (Kenneth Davis) wrote to
[EMAIL PROTECTED]:
insure bpb_huge is initialized (zeroed) [merge from dev kernel]
+++ initdisk.c6 Mar 2005 16:12:34 - 1.35
@@ -603,12 +603,15 @@
+ if (pEntry-NumSect = 0x)
+ {
pddt-ddt_defbpb.bpb_nsize = (UWORD) (pEntry-NumSect);
if (hiword (pEntry-NumSect) == 0)
{
pddt-ddt_defbpb.bpb_nsize = loword (pEntry-NumSect);
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95alloc_id396op=click
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: Re: [Freedos-cvs] kernel/kernel initdisk.c,1.34,1.35
I assume you are pointing out the use of hiword loword versus what I used
I did this for two reasons, the 1st is that those macros are not in the
stable kernel's portab.h, so using them would just make a kernel that did not
compile. Yes I could easily add them, but that wasn't the point of the commits,
they were to fix specific issues whose changes I am reasonably sure have no
negative
side effects. (Please note, my dev kernel is somewhat different from the
one in cvs as I have switched it to remove all fnodes, but haven't yet worked
out
enough kinks that I'm willing to commit it, so I'm not inclined to merge more
from it than necessary at the moment.)
Testing directly against 0x as a boundary condition is clearer and more
succinct
(to me) than testing if (0x (unsigned)((pEntry-NumSect) 16u)) equals
0,
hence my selection of it over the use of hiword. The use of loword is
technically
safer and more accurate, but again the macro isn't available in stable yet, and
unless
someone changes UWORD to be smaller or signed, in which case, this is the least
of
their issues, the resulting value should still be the same (based on the if) .
Please explain why you feel hiword is better and I will reconsider.
(and please do, if you have a reason other than style or if the general
consensus is that using hiword is clearer, then I will make the change)
Thank you for reviewing the changes,
Jeremy
-- Original Message -
Subject: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel initdisk.c,1.34,135
Date: Mon, 7 Mar 2005 01:12:40 +0300 (MSK)
From: Arkady V.Belousov [EMAIL PROTECTED]
To: freedos-devel@lists.sourceforge.net,
freedos-kernel@lists.sourceforge.net
óÁÌÑÍ!
6-íÁÒ-2005 16:12 [EMAIL PROTECTED] (Kenneth Davis) wrote to
[EMAIL PROTECTED]:
insure bpb_huge is initialized (zeroed) [merge from dev kernel]
+++ initdisk.c6 Mar 2005 16:12:34 - 1.35
@@ -603,12 +603,15 @@
+ if (pEntry-NumSect = 0x)
+ {
pddt-ddt_defbpb.bpb_nsize = (UWORD) (pEntry-NumSect);
if (hiword (pEntry-NumSect) == 0)
{
pddt-ddt_defbpb.bpb_nsize = loword (pEntry-NumSect);
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95alloc_id396op=click
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: [Freedos-cvs] kernel/kernel initdisk.c,1.33.2.4,1.33.2.5
Hi!
2--2005 07:47 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to
[EMAIL PROTECTED]:
LG Suppress spurious warning on 1022 cylinder LBA partition and optimise a bit
Details, please.
LG +++ initdisk.c 2 Feb 2005 07:47:34 - 1.33.2.5
LG - /* Valid entry:
LG - entry == chs || // partition entry equal to computed values
LG - (chs-Cylinder 1023 // or LBA partition
LG - (entry-Cylinder == 1023 ||
To support 1022, here you may replace ==1023 by =1022.
LG - entry-Cylinder == (0x3FF chs-Cylinder)))
LG - */
LG - return !((pEntry_chs-Cylinder == chs-Cylinder
LG -pEntry_chs-Head == chs-Head
LG -pEntry_chs-Sector == chs-Sector)||
LG - chs-Cylinder 1023u
LG - (pEntry_chs-Cylinder == 1023 ||
LG -pEntry_chs-Cylinder == (0x3ff chs-Cylinder)));
LG + if (pEntry_chs-Cylinder != (chs-Cylinder 0x3FF)
LG + || pEntry_chs-Head != chs-Head
LG + || pEntry_chs-Sector != chs-Sector)
Non-equal replacement. But see below (*).
LG +STATIC void warning_suspect(char *partitionName, struct CHS *chs,
LG + struct CHS *pEntry_chs)
STATIC void warning_suspect(CStr partitionName, const struct CHS *chs,
---^
struct CHS *pEntry_chs)
LG +if (pEntry-FileSystem == 0
LG + || partitionsToIgnore (1 i)
LG + || IsExtPartition(pEntry-FileSystem)
LG + || scan_type == SCAN_PRIMARYBOOT !pEntry-Bootable
LG + || !IsFATPartition(pEntry-FileSystem))
LGcontinue;
Last condition (!IsFATPartition()) includes also IsExtPartition() and
==0 checks, thus, IsExtPartition() and ==0 checks may be removed:
if (partitionsToIgnore (1 i)
|| scan_type == SCAN_PRIMARYBOOT !pEntry-Bootable
|| !IsFATPartition(pEntry-FileSystem))
continue;
LG /* some FDISK's enter for partitions
LG -8 GB cyl = 1023, other (cyl1023)
LG +8 GB cyl = 1022 or 1023, other (cyl1023)
Bart earlier explains this and gives link to URL with details, but
decised to remain only ==1023 check.
LG */
LG -if (is_suspect(chs, pEntry-Begin))
LG +if (!IsLBAPartition(pEntry-FileSystem))
LG {
LG - print_warning_suspect(partitionName, pEntry-FileSystem, chs,
LG -pEntry-Begin);
LG + warning_suspect(partitionName, chs, pEntry-Begin);
LG + warning_suspect(partitionName, end, pEntry-End);
LG }
Non-equal replacement: here checked only non-LBA partitions ((*) this
explains condition simplification in warning_suspect()), LBA partitions
doesn't checked at all (neither 1023, nor 1022), even if they completely
inside 1023 cylinder. If this replacement valid, it should be commented.
LG +if (pEntry-NumSect == 0)
LG {
LG + printf(Not using %s with 0 sectors\n, partitionName);
LG + continue;
LG }
This check should be moved above, before LBA_to_CHS() calls.
Well, my edition for this function (note: partitionStart replaced by
startSector):
__O\_/_\_/O__
for (i = 0; i 4; i++, pEntry++)
{
if (partitionsToIgnore (1 i)
|| scan_type == SCAN_PRIMARYBOOT !pEntry-Bootable
|| !IsFATPartition(pEntry-FileSystem))
continue;
sprintf(partitionName, partition %s:%d (ID %02x),
---^
extendedPartNo ? Ext : Pri,
extendedPartNo ? extendedPartNo : i + 1,
pEntry-FileSystem);
/* sanity checks, that partition structure is OK */
if (pEntry-NumSect == 0)
{
printf(Not using %s with 0 sectors\n, partitionName);
continue;
}
startSector += pEntry-RelSect;
LBA_to_CHS(chs, startSector, driveParam);
LBA_to_CHS(end, startSector + pEntry-NumSect - 1, driveParam);
^^^
/* For LBA partitions above 1023 cylinder only NumSect field is used:
into 10-bit field for cylinder in partition entry usually placed
low 10-bit of real value or some fake value (like 1022 or 1023).
Thus, we skip CHS validness check for LBA partitions, even if
they completely lie below 1024 cylinder.
*/
if (!IsLBAPartition(pEntry-FileSystem))
{
warning_suspect(partitionName, chs, pEntry-Begin);
warning_suspect(partitionName, end, pEntry-End);
}
if (chs.Cylinder 1023 || end.Cylinder 1023)
{
[...]
DosDefinePartition(driveParam, startSector, pEntry, extendedPartNo, i);
--^^^
_
O/~\ /~\O
---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create
[Freedos-kernel] Re: [Freedos-cvs] kernel/kernel initdisk.c,1.33.2.3,1.33.2.4 inthndlr.c,1.87.2.16,1.87.2.17
Hi! 30--2005 19:32 [EMAIL PROTECTED] (Kenneth Davis) wrote to [EMAIL PROTECTED]: KD +++ initdisk.c 30 Jan 2005 19:32:08 - 1.33.2.4 KD + if (pEntry-NumSect = 0x) if (hiword (pEntry-NumSect) == 0) /* 16-bit value? */ KD +pddt-ddt_defbpb.bpb_nsize = loword (pEntry-NumSect); --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: [Freedos-cvs] kernel defaults.bat,1.1.2.7,1.1.2.8
Hi! 30--2005 19:32 [EMAIL PROTECTED] (Kenneth Davis) wrote to [EMAIL PROTECTED]: some of Arkady's suggestions (simplify logic), add comments +++ defaults.bat 30 Jan 2005 19:32:08 - 1.1.2.8 +if %COMPILER%-%OS% == WATCOM-Windows_NT set BINPATH=%BASE%\binnt +if %COMPILER%%LIB% == MSC set LIB=%MSC_BASE%\lib Into second line I recommend also add the separator (for example, dash, but not space), as in first line. :) --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: [Freedos-cvs] kernel/kernel dosfns.c,1.70.2.2,1.70.2.3 dyninit.c,1.8.2.2,1.8.2.3 fatdir.c,1.47.2.2,1.47.2.3 fatfs.c,1.70.2.4,1.70.2.5 globals.h,1.45.2.2,1.45.2.3 inithma.c,1.28.2.1,1.28.2.2 irqstack.asm,1.6,1.6.2.1 main.c,1.81.2.9,1.81.2.10 prf.c,1.31.2.2,1.31.2.3
Hi! 29--2005 20:33 [EMAIL PROTECTED] (Kenneth Davis) wrote to [EMAIL PROTECTED]: KD new debug macros, simplify selective debug output KD --- NEW FILE: debug.h --- KD #ifdef DEBUG KD #define DebugPrintf(x) printf x +#define DEBUG_NEED_PRINTF KD #else KD #define DebugPrintf(x) KD #endif [...] KD #ifdef DEBUGCFG KD #define CfgDbgPrintf(x) printf x +#define DEBUG_NEED_PRINTF KD #else KD #define CfgDbgPrintf(x) KD #endif [...] KD /* just to be sure printf is declared */ KD #if defined(DEBUG) || defined(DEBUGIRQ) || defined(DEBUGCFG) || \ KD defined(DEBUGDOSFNS) || defined(CHDIR_DEBUG) || defined(FIND_DEBUG) || \ KD defined(DEBUGFATDIR) || defined(DEBUGFATFS) KD #ifndef DEBUG_NEED_PRINTF KD #define DEBUG_NEED_PRINTF KD void printf(const char *, ...); KD #endif KD #endif Remove these lines. About declaration see below: KD just comments and additional debug messages, updated history (little KD +++ fatdir.c29 Jan 2005 20:33:10 - 1.47.2.3 KD #include portab.h KD #include globals.h KD +#include debug.h Note: proto.h (called in globals.h) already tries to declare printf(), if defined DEBUG. And you also try to declare printf() in debug.h. I think, debug.h (without declaring printf()) should be included before (or inside) globals.h, and proto.h should checl DEBUG_NEED_PRINTF instead DEBUG. KD +++ fatfs.c 29 Jan 2005 20:33:11 - 1.70.2.5 KD +FatFSDbgPrintf((dos_open: splitpath(\%s\, \%11s\) failed.\n, KD @@ -330,7 +339,7 @@ KD #ifdef DEBUG ^ DEBUGFATFS? KD @@ -1817,18 +1830,18 @@ KD + DebugPrintf((get_near_f_node: fnp is %p\n, fnp)); KDif (fnp-f_count (++fnp)-f_count) KD panic(more than two near fnodes requested at the same time!\n); KDfnp-f_count++; KD + DebugPrintf((got near fnode, fnp-f_count=%i\n, fnp-f_count)); Also FatFSDbgPrintf()? BTW, I think, better to _not_ abbriviate Debug as Dbg (ie., above should be FatFSDebugPrintf()), because easier to search only DebugPrintf, not both DebugPrintf and DbgPrintf. --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel task.c,1.44.2.4,1.44.2.5
Arkady V.Belousov wrote: Hi! 17--2005 18:34 [EMAIL PROTECTED] (Kenneth Davis) wrote to [EMAIL PROTECTED]: tc debug build fix +++ task.c17 Jan 2005 18:34:10 - 1.44.2.5 -#if DEBUG +#ifdef DEBUG __O\_/_\_/O__ #if TST # error 1 #endif _ O/~\ /~\O __O\_/_\_/O__ bcc -c -DTST tst.cpp Borland C++ Version 3.1 Copyright (c) 1992 Borland International Error t.cpp 1: Expression syntax Fatal t.cpp 2: Error directive: 1 *** 2 errors in Compile *** _ O/~\ /~\O Fix: #if TST+0 ---^^ PS: I don't understand, what the trouble was with debugging? Old code was includes conditional part when DEBUG is defined, new code includes code only when DEBUG is defined AND not zero. Ie. -DDEBUG now not enough to include those conditional part. I'm confused. How does #ifdef DEBUG (the new code) require DEBUG to be defined and not zero? The issue here is that when I converted an #if 1 to be debug only code I forgot to change the #if to #ifdef. On a tangential [only slightly related] note, for debug code I want in the source but almost never compiled (something that helped track down a specific issue, but generally not needed for a debug build), should I used #ifdef DDEBUG ... #endif or simply #if 0 ... #endif or #ifdef ?? suggestions ?? ... #endif Thanks, Jeremy --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel task.c,1.44.2.4,1.44.2.5
Hi! 19--2005 15:06 [EMAIL PROTECTED] (Kenneth J. Davis) wrote to freedos-kernel@lists.sourceforge.net: +++ task.c17 Jan 2005 18:34:10 - 1.44.2.5 -#if DEBUG +#ifdef DEBUG Fix: #if TST+0 ---^^ KJD I'm confused. KJD How does #ifdef DEBUG (the new code) Oops... :( Sorry, I'm dubiously blind man - I visually entangle/miss + and - characters in your update. :( KJD On a tangential [only slightly related] note, for debug code I want in KJD the source but KJD almost never compiled (something that helped track down a specific KJD issue, but generally not needed for a debug build), should I used KJD #ifdef DDEBUG ... #endif KJD or simply KJD #if 0 ... #endif KJD or KJD #ifdef ?? suggestions ?? ... #endif I think, for (most) specific-purposed debug fragments, better to use general-purpose #if 0 - usually, when you debug some fragment, you not need to see other cross-kernel debug messages. The more so, I don't think that you need to devise name for conditional compilation guard - debugging of specific fragments is rare thing, and in this case you may manually (temporarily!) edit source (0 - 1), instead manually editing your config.bat (but don't forget to re_build_ the kernel after/if you restore original source file with older date). After all, I think, DEBUG name is useful for places, where is perofmed output of general-purpose and user-friendly information. And such places should be small amount, else profit of debugging output (which can't be redirected to separate device with permanent memory!) will be losted in big amount of garbage. --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: [Freedos-cvs] kernel/kernel task.c,1.44.2.4,1.44.2.5
Hi! 17--2005 18:34 [EMAIL PROTECTED] (Kenneth Davis) wrote to [EMAIL PROTECTED]: tc debug build fix +++ task.c17 Jan 2005 18:34:10 - 1.44.2.5 -#if DEBUG +#ifdef DEBUG __O\_/_\_/O__ #if TST # error 1 #endif _ O/~\ /~\O __O\_/_\_/O__ bcc -c -DTST tst.cpp Borland C++ Version 3.1 Copyright (c) 1992 Borland International Error t.cpp 1: Expression syntax Fatal t.cpp 2: Error directive: 1 *** 2 errors in Compile *** _ O/~\ /~\O Fix: #if TST+0 ---^^ PS: I don't understand, what the trouble was with debugging? Old code was includes conditional part when DEBUG is defined, new code includes code only when DEBUG is defined AND not zero. Ie. -DDEBUG now not enough to include those conditional part. --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Re: [Freedos-cvs] kernel/kernel
Hi! 6--2005 23:47 [EMAIL PROTECTED] (Peter Fedorow) wrote to freedos-kernel@lists.sourceforge.net: OmmitIfOptimizeSize break (); Very hard to justify such macros, then you may as well use a comment, the potentially nasty fallthrough would still be there in the embedded case. PF A macro will allow all such cases to be turned on and off at once. This There is no noticeable gain (in resulting code size) and no enhancement of source, so such places better to optimize at all and just comment tricky places (for example, where reused `break' from following `case' branch). PF A more accurate name for the macro would probably be PF OmmitIfOptimizeSizeExtreme, but I think that might be getting PF rediculously long. Perhaps someone has a better name for it? Again: better to not bother with _such_ ways, just optimize. And comment tricky places. IMHO if you really want to save space for embedded stuff you should selectively remove features (e.g. FAT12 or FAT32, LBA, FCB stuff, whatever). Those in the business hopefully make money of their embedded stuff, and they are free to make such modifications; they should not prey to the kernel developers to do it. PF Are embedded developers welcome to send in clean patches to selectively PF remove those items? To remove - no. To send patches, which _adds_ possibility of conditional compilation (with removing some unneeded parts) - yes. --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: [Freedos-cvs] kernel/kernel dsk.c,1.44.2.2,1.44.2.3 initdisk.c,1.33.2.1,1.33.2.2
Hi!
9--2005 11:25 [EMAIL PROTECTED] (Kenneth Davis) wrote to
[EMAIL PROTECTED]:
fix bug 1789 and add some extra debug prints
+++ initdisk.c9 Jan 2005 11:25:44 - 1.33.2.2
if (pEntry-NumSect 0x)
+ {
+pddt-ddt_defbpb.bpb_nsize = 0;
pddt-ddt_defbpb.bpb_huge = pEntry-NumSect;
+ }
else
+ {
pddt-ddt_defbpb.bpb_nsize = (UWORD) (pEntry-NumSect);
+pddt-ddt_defbpb.bpb_huge = 0;
+ }
Small optimization :) and readability change:
pddt-ddt_defbpb.bpb_nsize = 0;
pddt-ddt_defbpb.bpb_huge = pEntry-NumSect;
if (hiword (pEntry-NumSect) == 0)
{
pddt-ddt_defbpb.bpb_nsize = loword (pEntry-NumSect);
pddt-ddt_defbpb.bpb_huge = 0;
}
Last assignment (bpb_huge = 0) also may be optimized (because hiword is
already zero), but this (3-5 bytes reducing) hurts readability.
---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel entry.asm,1.27.2.1,1.27.2.2
Hello Alain, Tuesday, January 11, 2005, 1:24:48 PM, you wrote: Arkady V.Belousov escreveu: Hi! 4--2005 19:05 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to [EMAIL PROTECTED]: Fix divide error message text +++ entry.asm 4 Jan 2005 19:05:08 - 1.27.2.2 -; print a message 'Interrupt divide by zero' +; print a message 'Interrupt divide error' This is not fix, this is change - though division by zero interrupt INT0 hapens not only in case of real division by zero, but this (Divide by Zero) is a standard name. On the other side, Interrupt divide error I read as error in dividing the interrupt, so, if you wish to give more meaningful name, there should be something like Interrupt: division error. I agree :) I disagree :( tom --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel entry.asm,1.27.2.1,1.27.2.2
Hi Tom, Arkady V.Belousov escreveu: Hi! 4--2005 19:05 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to [EMAIL PROTECTED]: Fix divide error message text +++ entry.asm 4 Jan 2005 19:05:08 - 1.27.2.2 -; print a message 'Interrupt divide by zero' +; print a message 'Interrupt divide error' This is not fix, this is change - though division by zero interrupt INT0 hapens not only in case of real division by zero, but this (Divide by Zero) is a standard name. On the other side, Interrupt divide error I read as error in dividing the interrupt, so, if you wish to give more meaningful name, there should be something like Interrupt: division error. AlainI agree :) Tom I disagree :( I don't understand why, for curiosity sake only: interrupt divide error in english is ambigouous and can be interpreted in two ways. Anyway, I vote for the exact MS-DOS message for compatibility. Alain --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel build.bat,1.14.2.6,1.14.2.7 buildall.bat,1.6.2.2,1.6.2.3 config.b,1.12.2.3,1.12.2.4 defaults.bat,1.1.2.5,1.1.2.6
Arkady V.Belousov wrote: Hi! 31--2004 21:37 [EMAIL PROTECTED] (Kenneth Davis) wrote to [EMAIL PROTECTED]: use NT OW binaries on NT, add access to more options from build cmd line +++ defaults.bat 31 Dec 2004 21:37:51 - 1.1.2.6 +set BINPATH=%BASE%\bin +if %COMPILER% == TC set BINPATH=%BASE% +if %COMPILER% == WATCOM set BINPATH=%BASE%\binw +if %COMPILER% == WATCOM if %OS% == Windows_NT set BINPATH=%BASE%\binnt + +echo Path to compiler programs (binaries) is %BINPATH% if not %BINPATH% == goto skip_binpath ^^ set binpath=%BASE%\bin if %COMPILER% == TC set BINPATH=%BASE% if %COMPILER% == WATCOM set BINPATH=%BASE%\binw if %COMPILER%%OS% == WATCOMWindows_NT set BINPATH=%BASE%\binnt -^^ ok echo Path to compiler programs (binaries) is %BINPATH% :skip_binpath +:- MSC searches libraries only through LIB variable. +if %COMPILER% == MSC set LIB=%MSC_BASE%\lib if %COMPILER%%LIB% == MSC set LIB=%MSC_BASE%\lib -^ I like +set XCPU_EX= +++ build.bat 31 Dec 2004 21:37:51 - 1.14.2.7 +echo :--- This ECHO shows line with quotes. and? its just there so I don't have to keep opening the batch file to see what its arguments are, they should be balanced though, making a bounding box (at least for me it does) if %1 == 386 set XCPU=386 +if %1 == x86 goto setCPU This option doesn't shown in help screen. its not really a useful option, that was me testing to see if setting the compiler to 386 made a difference (since I rarely test on anything less than a 486), but all OW's settings produced identical code (though its possible the setting somehow didn't propagate, for the curious, it basically sets XCPU=386 and later adds the %1 as a compiler switch (eg -4 instead of -3). cd ..\sys call %MAKE% all if errorlevel 1 goto abort-cd +if NOT %XUPX% == %XUPX% ..\bin\sys.com Isn't better to place XUPX call inside sys\makefile, like in kernel\makefile? yes, I would prefer it in the Makefile, but I do not know how to do in way that works with all our make.exe programs to only perform the upx if %XUPX% is set. If you (or someone) has a suggested patch, please send it to the list (or me at my fdos address). I'll see about updating this shortly. Thanks, Jeremy --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: [Freedos-cvs] kernel/kernel main.c,1.81.2.7,1.81.2.8
Hi! 9--2005 20:36 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to [EMAIL PROTECTED]: Possible bugfix for Grub +++ main.c9 Jan 2005 20:36:21 - 1.81.2.8 + init_PSPSet(DOS_PSP); set_DTA(MK_FP(DOS_PSP, 0x80)); PSPInit(); - init_PSPSet(DOS_PSP); No, this shouldn't fix/change anything, because only PSPinit() initializes PSP area, other calls (set_DTA() and init_PSPSet()) just sets DOS variables (through INT21 calls), which points to PSP. --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: [Freedos-cvs] kernel/kernel entry.asm,1.27.2.1,1.27.2.2
Hi! 4--2005 19:05 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to [EMAIL PROTECTED]: Fix divide error message text +++ entry.asm 4 Jan 2005 19:05:08 - 1.27.2.2 -; print a message 'Interrupt divide by zero' +; print a message 'Interrupt divide error' This is not fix, this is change - though division by zero interrupt INT0 hapens not only in case of real division by zero, but this (Divide by Zero) is a standard name. On the other side, Interrupt divide error I read as error in dividing the interrupt, so, if you wish to give more meaningful name, there should be something like Interrupt: division error. --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: [Freedos-cvs] kernel build.bat,1.14.2.6,1.14.2.7 buildall.bat,1.6.2.2,1.6.2.3 config.b,1.12.2.3,1.12.2.4 defaults.bat,1.1.2.5,1.1.2.6
Hi! 31--2004 21:37 [EMAIL PROTECTED] (Kenneth Davis) wrote to [EMAIL PROTECTED]: use NT OW binaries on NT, add access to more options from build cmd line +++ defaults.bat 31 Dec 2004 21:37:51 - 1.1.2.6 +set BINPATH=%BASE%\bin +if %COMPILER% == TC set BINPATH=%BASE% +if %COMPILER% == WATCOM set BINPATH=%BASE%\binw +if %COMPILER% == WATCOM if %OS% == Windows_NT set BINPATH=%BASE%\binnt + +echo Path to compiler programs (binaries) is %BINPATH% if not %BINPATH% == goto skip_binpath ^^ set binpath=%BASE%\bin if %COMPILER% == TC set BINPATH=%BASE% if %COMPILER% == WATCOM set BINPATH=%BASE%\binw if %COMPILER%%OS% == WATCOMWindows_NT set BINPATH=%BASE%\binnt -^^ echo Path to compiler programs (binaries) is %BINPATH% :skip_binpath +:- MSC searches libraries only through LIB variable. +if %COMPILER% == MSC set LIB=%MSC_BASE%\lib if %COMPILER%%LIB% == MSC set LIB=%MSC_BASE%\lib -^ +set XCPU_EX= +++ build.bat 31 Dec 2004 21:37:51 - 1.14.2.7 +echo :--- This ECHO shows line with quotes. if %1 == 386 set XCPU=386 +if %1 == x86 goto setCPU This option doesn't shown in help screen. cd ..\sys call %MAKE% all if errorlevel 1 goto abort-cd +if NOT %XUPX% == %XUPX% ..\bin\sys.com Isn't better to place XUPX call inside sys\makefile, like in kernel\makefile? --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Re: [Freedos-cvs] kernel/kernel inthndlr.c,1.87.2.12,1.87.2.13
Hi! 5--2005 22:59 [EMAIL PROTECTED] (tom ehlert) wrote to Eric Auer freedos-kernel@lists.sourceforge.net: te and while I agree completely with what he wrote, IMO he slightly te missed the point (and you -eric- miss it completely) The whole point is that if you remove the break; completely, then somebody who later reads or changes the code might be mislead into thinking that the code SHOULD fall through ... Eric correctly repeat my point, as I try to express it. (Of course, there may be raised other issues about shared programming effort, but I begun thread with only specific reason of readability, which was affected by patch.) --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Re: [Freedos-cvs] kernel/kernel inthndlr.c,1.87.2.12,1.87.2.13
Hi Tom, the whole point is that in a shared programming effort (as the freedos kernel still should be) it's a waste of resources to change ANYTHING without a certain payback. Lucho's payback is clear. He compiles with Borland C and compresses the result, so that the *compressed* kernel fits in 40K. Not the uncompressed usage matters but the compressed; as far as I understood, he has exactly 40K left on his ROM for kernel.sys. Anyway, for those not watching freedos-cvs, he removed the breaks and put in some other optimizations now. in this case, removing 'break;' may have saved 5 bytes in the early 90ties, but is irrelevant (or even contraproductive) with optimizing compilers, and leads only to such irrelevant 'why was this changed' threads. For Turbo: 6 bytes (2x jmp near). With Watcom and the #pragma aux return_user aborts (so the compiler knows it can use jmp and not call) no difference at all. Bart --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel inthndlr.c,1.87.2.12,1.87.2.13
That's really bad practice. The reason that it's there is so if, by reason of a bug or hardware failure of any sort, return_user() does really return, you will have bug that will be a nightmare to find. For the savings of less than 10 bytes, it's not worth the risk. Pat Arkady V.Belousov wrote: ! 31--2004 12:46 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to [EMAIL PROTECTED]: +++ inthndlr.c31 Dec 2004 12:46:21 - 1.87.2.13 @@ -752,7 +752,6 @@ return_user(); - break; @@ -1025,7 +1027,6 @@ return_user(); - break; I think, for readability purposes (to make understanding by new developers easier) `break' should be remained as comment. Something like: /* return_user() never returns, so break not need */ --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel inthndlr.c,1.87.2.12,1.87.2.13
Hi! 5--2005 08:30 [EMAIL PROTECTED] (Pat Villani) wrote to freedos-kernel@lists.sourceforge.net: +++ inthndlr.c31 Dec 2004 12:46:21 - 1.87.2.13 return_user(); - break; I think, for readability purposes (to make understanding by new developers easier) `break' should be remained as comment. Something like: /* return_user() never returns, so break not need */ PV That's really bad practice. The reason that it's there is so if, by PV reason of a bug or hardware failure of any sort, return_user() does PV really return, you will have bug that will be a nightmare to find. No, I say not this (that `break' should be present): I say, that new kernel developer may not know (yet) that return_user() never returns, so [s]he may wonder, why there is no `break' and why this is not a bug. So, commenting this trick may ease the understanding of this code. PV For the savings of less than 10 bytes, it's not worth the risk. BTW, `break' here really (may) save some bytes, because tails merging. --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel inthndlr.c,1.87.2.12,1.87.2.13
Hi Arkady, The - in the diff says that the break is removed entirely. Did you actually mean this, given your reply? I think you do save 2 or 3 bytes per break, depending on the compiler. However, I can relate to you an amusing experience. At one time, I did some consulting for Bell Labs. A few years after I left, ATT had a major network failure in the northeast US. A friend who was still with ATT told me that the failure was the result of a hardware problem that took the code into an untested branch of code. It was a function call inside a case that should have never returned and had no break at the end. The code fell into the next case and the system fell like a set dominoes. I'm not maintaining the kernel, so just my $0.02 -- which is worth less in Euros ;-) Pat Arkady V.Belousov wrote: Hi! 5--2005 08:30 [EMAIL PROTECTED] (Pat Villani) wrote to freedos-kernel@lists.sourceforge.net: +++ inthndlr.c31 Dec 2004 12:46:21 - 1.87.2.13 return_user(); - break; I think, for readability purposes (to make understanding by new developers easier) `break' should be remained as comment. Something like: /* return_user() never returns, so break not need */ PV That's really bad practice. The reason that it's there is so if, by PV reason of a bug or hardware failure of any sort, return_user() does PV really return, you will have bug that will be a nightmare to find. No, I say not this (that `break' should be present): I say, that new kernel developer may not know (yet) that return_user() never returns, so [s]he may wonder, why there is no `break' and why this is not a bug. So, commenting this trick may ease the understanding of this code. PV For the savings of less than 10 bytes, it's not worth the risk. BTW, `break' here really (may) save some bytes, because tails merging. --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel inthndlr.c,1.87.2.12,1.87.2.13
Hi! 5--2005 09:19 [EMAIL PROTECTED] (Pat Villani) wrote to freedos-kernel@lists.sourceforge.net: PV The - in the diff says that the break is removed entirely. Did you PV actually mean this, given your reply? Yes. Break is removed, but later some new developer may wonder, why there are no `break'?. So, I suggest, better to remain `break' in place, or replace it by consequent comment (like there is commented other `break' missings - see /* fall through */ comments). Of course, advanced developer later spends his time and teaches itself, that return_user() is never returns, but before this he will be in trouble. PV I think you do save 2 or 3 bytes per break, depending on the compiler. `Break' is a jump, so removing `break' may reduce code, but if there are similar tails above removed `break's, then you (may) lost in size, because those tail now can't be joined (at least, if you can't instruct compiler, that last function call never returns). PV However, I can relate to you an amusing experience. At one time, I did PV some consulting for Bell Labs. A few years after I left, ATT had a PV major network failure in the northeast US. A friend who was still with PV ATT told me that the failure was the result of a hardware problem that PV took the code into an untested branch of code. It was a function call PV inside a case that should have never returned and had no break at the PV end. The code fell into the next case and the system fell like a set PV dominoes. :) We can't protect from such hardware failures (when executed random pieces of code). :( PV I'm not maintaining the kernel, so just my $0.02 -- which is worth less PV in Euros ;-) --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Re: [Freedos-cvs] kernel/kernel inthndlr.c,1.87.2.12,1.87.2.13
Eric Auer schreef: PS: Which kernels contain the DOSLFN compatibility patch (improved xBPB/DPB initialization and set extended error code implemented), only the development kernels at www.fdos.org/kernel, I think. Jeremy has been active lately. Only thing missing by default is that IF a compressor is used, SYS should also be compressed by it (UPX, Apack). did somebody contact GRUB people about 0.0.35 vs. 1.0.35 version ID, why exactly? I cannot connect to GRUB4DOS site. to work with DOS=HIGH (I seem to remember that recompiling with either Toms or my KITTEN version or recompiling ZLIB or both was what Bob did to fix the bug... maybe there are OTHER programs with CATS affected? Which programs still use CATS instead of KITTEN? Symptom was a CRASH when using HTMLHELP several times on SOME systems if DOS=HIGH...) ...? FreeDOS textmode installer still uses CATS. I could really use a smaller installer.. The texmode installer is quite old, and I cannot obtain the exact version of it (3.7.x), and newer versions should also exists (3.9, 4.0) somewhere in Jeremy's archives. And did Arkady re-add the seemingly but not actually unneeded BPB/... initialization at boot time which he had removed at some point? why 'not unneeded' ? Bernd --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Re: [Freedos-cvs] kernel/kernel inthndlr.c,1.87.2.12,1.87.2.13
Hello Eric, Hi guys, interesting anecdote from Pat, but: yes, it was interesting to see Pat watching this list at all. and while I agree completely with what he wrote, IMO he slightly missed the point (and you -eric- miss it completely) The whole point is that if you remove the break; completely, then somebody who later reads or changes the code might be mislead into thinking that the code SHOULD fall through ... the whole point is that in a shared programming effort (as the freedos kernel still should be) it's a waste of resources to change ANYTHING without a certain payback. in this case, removing 'break;' may have saved 5 bytes in the early 90ties, but is irrelevant (or even contraproductive) with optimizing compilers, and leads only to such irrelevant 'why was this changed' threads. even if this WOULD save 3,5, or even 10 byte: it's completly irrelevant. the kernel has more then enough space in HMA, = 40 buffers ARE enough, and fighting lengthy email threads to free possibly another 512 byte (with exactly zero performance increase) is simply a waste of developers time, ethernet and my barins bandwidth. Besides that, this byte fiddeling attitude is the IMO the reason for the developement kernels name - 'unstable'. tom after the return_user, or that it would be OKAY to fall through - in both cases, he will either not UNDERSTAND the code properly or will even add BUGS by erroneously adding the possibility of returning to the caller to return_user(). So: OKAY, remove break; if you want, BUT add a comment instead of the break;, to let people know that return_user() never returns. You should even add such a comment to return_user() itself actually. By the way, you probably save even more bytes - and a bit of stack space - by using an evil GOTO for the return_user(), unless it already is an inlined macro or similar already anyway. OLD: break; BAD: (nothing) BETTER: /* return_user never returns, no break needed */ EVIL: use goto instead of call for return_user ;-). Eric PS: Which kernels contain the DOSLFN compatibility patch (improved xBPB/DPB initialization and set extended error code implemented), did somebody contact GRUB people about 0.0.35 vs. 1.0.35 version ID, does anybody remember why FreeCOM has if XMS swap version, then disable LOADFIX in #if, and why old CATS of HTMLHELP required LOADFIX to work with DOS=HIGH (I seem to remember that recompiling with either Toms or my KITTEN version or recompiling ZLIB or both was what Bob did to fix the bug... maybe there are OTHER programs with CATS affected? Which programs still use CATS instead of KITTEN? Symptom was a CRASH when using HTMLHELP several times on SOME systems if DOS=HIGH...) ...? And did Arkady re-add the seemingly but not actually unneeded BPB/... initialization at boot time which he had removed at some point? --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel -- Kind regards, Tom Ehlert mailto:[EMAIL PROTECTED] +49-241-79886 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: [Freedos-cvs] kernel/kernel inthndlr.c,1.87.2.12,1.87.2.13
! 31--2004 12:46 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to [EMAIL PROTECTED]: +++ inthndlr.c31 Dec 2004 12:46:21 - 1.87.2.13 @@ -752,7 +752,6 @@ return_user(); - break; @@ -1025,7 +1027,6 @@ return_user(); - break; I think, for readability purposes (to make understanding by new developers easier) `break' should be remained as comment. Something like: /* return_user() never returns, so break not need */ --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel config.c,1.89.2.10,1.89.2.11 inthndlr.c,1.87.2.10,1.87.2.11
Hi!
30--2004 00:35 Arkady V.Belousov wrote to
freedos-kernel@lists.sourceforge.net:
Remove hack in Int 21h AH=38h, revert bad change in _CmdInstall
+++ inthndlr.c29 Dec 2004 19:27:31 - 1.87.2.11
- rc = DosGetCountryInformation(cntry, FP_DS_DX);
- if (rc = SUCCESS)
- {
-/* HACK FIXME */
^
Note: keyword here not hack, but fixme. Code below should return
correct current code in AX and BX instead built-in 1...
-if (cntry == (UWORD) - 1)
- cntry = 1;
-/* END OF HACK */
-lr.AX = lr.BX = cntry;
- }
+ rc = DosGetCountryInformation(lr.BX ? lr.BX : NLS_DEFAULT,
FP_DS_DX);
}
...but:
AVB Bug: INT 21/38 should return country code in AX and BX when CF=0, even
AVB if initially there was AL=0 or AL=-1. New code returns wrong value when
AVB AL=0 or -1 - in this case there will _not_ returned requred country code.
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel build.bat,1.14.2.5,1.14.2.6 defaults.bat,1.1.2.4,1.1.2.5
Hi! 23--2004 02:04 Arkady V.Belousov wrote to freedos-kernel@lists.sourceforge.net: AVB Ok. First, call presence/missing doesn't affect calls throug AVB makefile, call affects execution only througb batch files. Second, you AVB may just remove check on Close window on program exit option. ...this allows to see (last) screen output without inserting pauses at the end. BTW, why you run compilation through additional icons? AVB Third, you may redirect output of (almost) all messages into external file. AVB modifying original batch files. NDOS itself allows to redirect output of AVB batch files. ...Unfortunately, command.com doesn't allows to redirect output of batch files, but... AVB Under command.com, you may do so: AVB %comspec% /c build %1 %2 %3 %4 compile.msg --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: [Freedos-cvs] kernel build.bat,1.14.2.5,1.14.2.6 defaults.bat,1.1.2.4,1.1.2.5
Hi! 19--2004 19:33 [EMAIL PROTECTED] (Kenneth Davis) wrote to [EMAIL PROTECTED]: KD +++ defaults.bat19 Dec 2004 19:33:26 - 1.1.2.5 KD -if %COMPILER% == WATCOM set LINK=..\utils\wlinker /nologo KD +if %COMPILER% == WATCOM set LINK=call ..\utils\wlinker /nologo Why? KD +++ build.bat 19 Dec 2004 19:33:26 - 1.14.2.6 KD -defaults.bat clearset KD +call defaults.bat clearset Why? What wrong with calls without call (from makefile in first case and at the end of batch file in second)? --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: feasibility question about embedded FreeDOS in my hobby project
On Tue, 30 Nov 2004 13:34:26 +0100 (MET), Eric Auer [EMAIL PROTECTED] wrote: Hi, you are not the first one who is planning FreeDOS ports for embedded x86: http://fd-doc.sourceforge.net/faq/cgi-bin/viewfaq.cgi?faq=incoming/277 This FAQ entry contains a detailled description of the needed BIOS services for the kernel. You can remove some of them by modifying the kernel a bit. You should not try to remove all - it is easier to keep them in the BIOS, even if this means that you have to improve your BIOS first. If you want to use non-BIOS disks, you will have to load a driver which offers simple sector read / write. You can load the kernel into RAM and start it, but then, you need at least a very tiny and simple disk (could be a disk image in ROM, as in ROMOS) with already active drivers to provide files like config sys. In config sys, you can load the abovementioned driver (if the disk is partitioned, it would have to process the MBR itself - but the KERNEL can do all the FAT processing for you) to gain access to more disks. I am a little bit confused here. Is non-BIOS disk an HD that the BIOS doesn't know of (through manual setting, or auto-detection)? If so, Do I need to provide a different driver for each different disk that I attach to my controller? If not so, it would be the best answer to my question below. I did some reading and I found that a BIOS might not be difficult if I know the parameters of the HD that I am going to interface with. I want my BIOS to be small, but I also want every HD that attaches to my controller to work without manual setting. I have no idea how auto-detection is done at this point. What is the best way to solve the problem (small BIOS supports every HD)? I want the small BIOS to provide both CHS and LHA services. Well, as long as I know the HD parameters... Thanks vax, 9000 Eric --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: feasibility question about embedded FreeDOS in my hobby project
Hi, you are not the first one who is planning FreeDOS ports for embedded x86: http://fd-doc.sourceforge.net/faq/cgi-bin/viewfaq.cgi?faq=incoming/277 This FAQ entry contains a detailled description of the needed BIOS services for the kernel. You can remove some of them by modifying the kernel a bit. You should not try to remove all - it is easier to keep them in the BIOS, even if this means that you have to improve your BIOS first. If you want to use non-BIOS disks, you will have to load a driver which offers simple sector read / write. You can load the kernel into RAM and start it, but then, you need at least a very tiny and simple disk (could be a disk image in ROM, as in ROMOS) with already active drivers to provide files like config sys. In config sys, you can load the abovementioned driver (if the disk is partitioned, it would have to process the MBR itself - but the KERNEL can do all the FAT processing for you) to gain access to more disks. Summary of required services: Int 0x11 / 0x12 (trivial) provide system information Int 0x14 / 0x17 are used to init and access COM and LPT ports, but only if system information told that such ports exist. Int 0x19 can be used to reboot, but is not really needed. Some values at 0x40:?? have to be present for FreeDOS. For DISK access, functions 0, 1, 2, 3 and 8 should be present of int 0x13 (more if you prefer LBA access instead of CHS). Read MEMDISK of SYSLINUX sourcecodes for an example. For KEYBOARD access, int 0x16 functions 0, 1, 2 are needed, for modern keyboards also 0x10, 0x11, 0x12. For SCREEN access, int 0x10 functions like 0x0e (TTY) are used, but you should add a few more like 2, 9 and some status functions / cursor movement. For CLOCK access, int 0x1a is needed, and 0x40:0x6c has to do the usual timer tick - many DOS programs expect that. The int 0x1e contents should tell about the geometry of your (possibly simulated) floppy. Eric --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: feasibility question about embedded FreeDOS in my hobby project
On Tue, 30 Nov 2004 13:34:26 +0100 (MET), Eric Auer [EMAIL PROTECTED] wrote: Hi, you are not the first one who is planning FreeDOS ports for embedded x86: http://fd-doc.sourceforge.net/faq/cgi-bin/viewfaq.cgi?faq=incoming/277 This FAQ entry contains a detailled description of the needed BIOS services for the kernel. You can remove some of them by modifying the kernel a bit. You should not try to remove all - it is easier to keep them in the BIOS, even if this means that you have to improve your BIOS first. If you want to use non-BIOS disks, you will have to load a driver which offers simple sector read / write. You can load the kernel into RAM and start it, but then, you need at least a very tiny and simple disk (could be a disk image in ROM, as in ROMOS) with already active drivers to provide files like config sys. In config sys, you can load the abovementioned driver (if the disk is partitioned, it would have to process the MBR itself - but the KERNEL can do all the FAT processing for you) to gain access to more disks. Summary of required services: Int 0x11 / 0x12 (trivial) provide system information Int 0x14 / 0x17 are used to init and access COM and LPT ports, but only if system information told that such ports exist. Int 0x19 can be used to reboot, but is not really needed. Some values at 0x40:?? have to be present for FreeDOS. For DISK access, functions 0, 1, 2, 3 and 8 should be present of int 0x13 (more if you prefer LBA access instead of CHS). Read MEMDISK of SYSLINUX sourcecodes for an example. For KEYBOARD access, int 0x16 functions 0, 1, 2 are needed, for modern keyboards also 0x10, 0x11, 0x12. For SCREEN access, int 0x10 functions like 0x0e (TTY) are used, but you should add a few more like 2, 9 and some status functions / cursor movement. For CLOCK access, int 0x1a is needed, and 0x40:0x6c has to do the usual timer tick - many DOS programs expect that. The int 0x1e contents should tell about the geometry of your (possibly simulated) floppy. Thank you very much. Your answer is very helpful. It seems it is quite feasible. My system will only run one program. I planed to ROMmize the program, but since it will use an HD to store data, I now plan to place the program in the HD too. Seems I only need to implement int 0x11/0x12 and 0x13. Thank you again. vax, 9000 Eric --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/utils exeflat.c,1.9.2.3,1.9.2.4
On Thu, 18 Nov 2004, Arkady V.Belousov wrote: Of course, qsort() if very fast algo (except some specific cases, when it is O(N^2)), but why to do _any_ extra action, when unnecessary? :) Especially, I suggest, (most) linkers do own sorting anyway? I think even bubble sort would be fast enough here. It's just that qsort is convenient because it is provided by the RTL. Hm. I think for simplicity and safety, exeflat should itself move relocation table from executable's header inside executable itself, so that it may be reused by MoveKernel(). This allows to eliminate manual table at kernel.asm:__HMARelocationTableStart. (Yes, I know __HMARelocationTableStart is not plain relocation table, but jump/code table, with jmps and calls to EnableA20. But table from header may be copied (after fixing) into secondary table. This allows to make code, which is more relocatable and may make cross-segments calls and accesses. This also solves issues with standard library routines, which may be used both from non-relocatable low code and from relocatable code.) This is not so easy. Firstly a secondary table would need extra space in low memory. There used to be entries to strcpy et al in the table but I removed them later because that part of the table that was useless after init was still resident. Secondly it would be quite a bit of effort for very little gain. Also think about it: we don't know in advance how big the table will be, it's hard to insert something of arbitrary size in kernel.sys. And then, where's the simplicity? PS: Bart, some time ago you decrease kernel by reordering object files. May you explain what was changed and how you find this? Just reordered by placing more or less similar files close together (asm close to asm, c close to c); that decreased entropy so compression improved. Bart --- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/utils exeflat.c,1.9.2.3,1.9.2.4
Hi! 20--2004 18:54 [EMAIL PROTECTED] (Bart Oldeman) wrote to [EMAIL PROTECTED]: Hm. I think for simplicity and safety, exeflat should itself move relocation table from executable's header inside executable itself, so that it may be reused by MoveKernel(). This allows to eliminate manual table at kernel.asm:__HMARelocationTableStart. (Yes, I know __HMARelocationTableStart is not plain relocation table, but jump/code table, with jmps and calls to EnableA20. But table from header may be copied (after fixing) into secondary table. This allows to make code, which is more relocatable and may make cross-segments calls and accesses. This also solves issues with standard library routines, which may be used both from non-relocatable low code and from relocatable code.) BO This is not so easy. Firstly a secondary table would need extra space in BO low memory. ...unless it will be placed into transient/initial portion, which discarded from memory after startup. BO There used to be entries to strcpy et al in the table but I Yes, and then now may be reduced code duplication in asmsupt.asm (which generated both for transient and resident portion). BO removed them later because that part of the table that was useless after BO init was still resident. If you relocation table (RT) will be placed into discardable portion, then it will not still resident, And see the difference: RT is not entry points table, but table with references to places, which need correction, if they refers to relocated code. BO Secondly it would be quite a bit of effort for very little gain. 1. This gives safety (not need to worry about references from initialization part to relocatable resident part; of course, reference from resident portion to transient portion shold be worried). 2. This allows to reduce code (no duplication of same functions, like strcpy). BO Also think about it: we don't know in advance how big BO the table will be, it's hard to insert something of arbitrary size in BO kernel.sys. Of course, I think about this. But, because this table (should be) placed into transient portion, why not _allocate_ oversized table (say, 100-200 items)? Especially, because unused entries will be zero, they will be very well packed by UPX? I see there only one issue: how to reliably find in exeflat, where those place (for RT) resides in executable. BO And then, where's the simplicity? Of course, initial efforts to implement are not very easy, but gain is noticeable. For example, with such relocation you will never encounter troubles, like was issued with RTL-multiplcation functions from OW. The more so, now they may be moved from low/nonrelocatable part (in kernel.asm) into resident part! (Do you remember, how I was try to move Borland's RTL functions into resident part and forget about relocations?) PS: Bart, some time ago you decrease kernel by reordering object files. May you explain what was changed and how you find this? BO Just reordered by placing more or less similar files close together (asm BO close to asm, c close to c); that decreased entropy so compression BO improved. Only compression? I remeber something about reduced executable size, but without words about compression. --- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/utils exeflat.c,1.9.2.3,1.9.2.4
On Sat, 20 Nov 2004, Arkady V.Belousov wrote: Yes, and then now may be reduced code duplication in asmsupt.asm (which generated both for transient and resident portion). only for Borland C. For Watcom they are not duplicated (only one CS: there). And anyway it's only a small amount of code. Of course, initial efforts to implement are not very easy, but gain is noticeable. For example, with such relocation you will never encounter troubles, like was issued with RTL-multiplcation functions from OW. That was a different problem. Watcom generated NEAR calls to these functions. Relocation wouldn't help. This point is moot now with one CS, and anyway I like our own versions better :) The more so, now they may be moved from low/nonrelocatable part (in kernel.asm) into resident part! (Do you remember, how I was try to move Borland's RTL functions into resident part and forget about relocations?) Yes you could move these into the resident part if you do runtime patching. But is it worth the effort for a secondary compiler? I will not stop you trying to do this, but I see it as a waste of time myself (other than an exercise in patching). PS: Bart, some time ago you decrease kernel by reordering object files. May you explain what was changed and how you find this? BO Just reordered by placing more or less similar files close together (asm BO close to asm, c close to c); that decreased entropy so compression BO improved. Only compression? I remeber something about reduced executable size, but without words about compression. No it was only compression, how else can reordering save space? The trick to reduce uncompressed executable size was only obtained using a different default calling convention via #pragma. Bart --- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/utils exeflat.c,1.9.2.3,1.9.2.4
On Thu, 18 Nov 2004, Arkady V.Belousov wrote:
Small optimization: because BC doesn't knows, that exit() doesn't
returns, better to insert explicit return 0; after exit() or return error
code through return (remaining error handling for main()). For BC, this
allows to join common tails.
I don't think optimizing exeflat.exe's size is very important though ;)
LG + qsort(reloc, header.exRelocItems, sizeof(reloc[0]), compReloc);
Why to spend extra time for sorting relocations?
I think it's easier to read the output that way. Tom's idea.
Does qsort() really take a long time for you in exeflat? I find that hard
to believe, for just ~70 relocations.
LG +for (j = 0; j silentcount; j++)
LG + if (segment == silentSegments[j])
LG + {
LG +silentdone++;
LG +goto dontPrint;
LG + }
Never understand this option. (Though, don't try to study its meaning
deeper). The more so, me always annoying tons of some information about some
relocations, which garbaes output after exeflat.
use a larger backscroll buffer. Anyway, seriously:
The -S0x10 -S0x8B is outdated. 0x10 corresponds to segment 0x70 (device
drivers etc) and 0x8B to the DOS data segment at 0xEB. However over the
years some things were made smaller and the DOS data segment seems to be
at 0xCF or 0xD0 depending on compilation options now.
-S0x10 -S0x6F -S0x70
will catch relocations from these segments. The idea to silence these is
that these relocations are harmless because these segments don't move.
Relocations to other segments may be bugs. With the above options you
should get something like
relocation at 0x:0x0021 -01d6 (far jmp to init code in kernel.asm)
relocation at 0x01d6:0x9f2d -0f2f (seg init_tos in kernel.asm)
relocation at 0x01d6:0xa19c - (LowKernelConfig, main.c)
relocation at 0x01d6:0xc21c -01d6 (MoveKernel, FP_SEG(_HMATextEnd, inithma.c)
I checked them and these relocations are all fine. But if a fifth shows up
unexpectedly we may have a bug.
---
UPXOPT seems indeed unnecessary now.
Bart
---
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/utils exeflat.c,1.9.2.3,1.9.2.4
Hi! 18--2004 21:21 [EMAIL PROTECTED] (Bart Oldeman) wrote to [EMAIL PROTECTED]: Small optimization: because BC doesn't knows, that exit() doesn't BO I don't think optimizing exeflat.exe's size is very important though ;) Sure. :) But why not make more optimal code from scratch in any case, without thinking will this code often used? LG + qsort(reloc, header.exRelocItems, sizeof(reloc[0]), compReloc); Why to spend extra time for sorting relocations? BO I think it's easier to read the output that way. Tom's idea. BO Does qsort() really take a long time for you in exeflat? I find that hard BO to believe, for just ~70 relocations. Of course, qsort() if very fast algo (except some specific cases, when it is O(N^2)), but why to do _any_ extra action, when unnecessary? :) Especially, I suggest, (most) linkers do own sorting anyway? Ok, ok, above questions are not critical and mostly rhetorical. LG +for (j = 0; j silentcount; j++) Never understand this option. (Though, don't try to study its meaning deeper). The more so, me always annoying tons of some information about some relocations, which garbaes output after exeflat. BO use a larger backscroll buffer. Anyway, seriously: BO The -S0x10 -S0x8B is outdated. 0x10 corresponds to segment 0x70 (device BO drivers etc) and 0x8B to the DOS data segment at 0xEB. However over the BO years some things were made smaller and the DOS data segment seems to be BO at 0xCF or 0xD0 depending on compilation options now. ...and different kernel branches. :) BO -S0x10 -S0x6F -S0x70 BO will catch relocations from these segments. The idea to silence these is BO that these relocations are harmless because these segments don't move. BO Relocations to other segments may be bugs. With the above options you Ok, I see. Thank you for exaplanation. BO should get something like BO relocation at 0x:0x0021 -01d6 (far jmp to init code in kernel.asm) BO relocation at 0x01d6:0x9f2d -0f2f (seg init_tos in kernel.asm) BO relocation at 0x01d6:0xa19c - (LowKernelConfig, main.c) BO relocation at 0x01d6:0xc21c -01d6 (MoveKernel, FP_SEG(_HMATextEnd, inithma.c) BO I checked them and these relocations are all fine. But if a fifth shows up BO unexpectedly we may have a bug. Hm. I think for simplicity and safety, exeflat should itself move relocation table from executable's header inside executable itself, so that it may be reused by MoveKernel(). This allows to eliminate manual table at kernel.asm:__HMARelocationTableStart. (Yes, I know __HMARelocationTableStart is not plain relocation table, but jump/code table, with jmps and calls to EnableA20. But table from header may be copied (after fixing) into secondary table. This allows to make code, which is more relocatable and may make cross-segments calls and accesses. This also solves issues with standard library routines, which may be used both from non-relocatable low code and from relocatable code.) BO --- BO UPXOPT seems indeed unnecessary now. Sure. :) PS: Bart, some time ago you decrease kernel by reordering object files. May you explain what was changed and how you find this? --- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/utils exeflat.c,1.9.2.3,1.9.2.4
Hello Arkady, Small optimization: because BC doesn't knows, that exit() doesn't BO I don't think optimizing exeflat.exe's size is very important though ;) Sure. :) But why not make more optimal code from scratch in any case, without thinking will this code often used? And why not leave *existing* code as is - without wasting mental and ethernet bandwidth on it ? LG + qsort(reloc, header.exRelocItems, sizeof(reloc[0]), compReloc); Why to spend extra time for sorting relocations? BO I think it's easier to read the output that way. Tom's idea. BO Does qsort() really take a long time for you in exeflat? I find that hard BO to believe, for just ~70 relocations. Of course, qsort() if very fast algo (except some specific cases, when it is O(N^2)), but why to do _any_ extra action, when unnecessary? :) it's not unnecessary - else I wouldn't have written it. Especially, I suggest, (most) linkers do own sorting anyway? I call people who 'suggest' somethintg that is plain wrong (and they could have seen that themself) idiots. Ok, ok, above questions are not critical and mostly rhetorical. but give some insight. Hm. I think for simplicity and safety, exeflat should itself move relocation table from executable's header inside executable itself, so that it may be reused by MoveKernel(). This allows to eliminate manual table at kernel.asm:__HMARelocationTableStart. (Yes, I know __HMARelocationTableStart is not plain relocation table, but jump/code table, with jmps and calls to EnableA20. But table from header may be copied (after fixing) into secondary table. This allows to make code, which is more relocatable and may make cross-segments calls and accesses. This also solves issues with standard library routines, which may be used both from non-relocatable low code and from relocatable code.) if you can write down a simpler and saver method to do that - fine. else - see my bandwidth comment... tom --- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/utils exeflat.c,1.9.2.3,1.9.2.4
Hi! 18--2004 11:24 [EMAIL PROTECTED] (tom ehlert) wrote to Arkady V.Belousov [EMAIL PROTECTED]: te And why not leave *existing* code as is - without wasting mental and te ethernet bandwidth on it ? This is not (yet) existing, this is _new_ code. Especially, I suggest, (most) linkers do own sorting anyway? te I call people who 'suggest' somethintg that is plain wrong (and they could te have seen that themself) idiots. Sometime I study executables, and seen tables was sorted. (Probably, this was caused by applied exepackers, I not remember such details, but they _was_ sorted). --- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: [Freedos-cvs] kernel/utils exeflat.c,1.9.2.4,1.9.2.5
Hi! 18--2004 11:20 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to [EMAIL PROTECTED]: LG (Arkady) Remove -U option as Bart's new EXFLAT now uses XUPX variable directly LG +++ exeflat.c 18 Nov 2004 11:20:04 - 1.9.2.5 LG + upx = getenv(XUPX); LG + compress_sys_file = exeflat((int)upx, argv[1], argv[2], argv[3], LGsilentSegments, silentcount); LG + if (upx == NULL) I think, exeflat (upx != NULL,... should be better - at least, in sense of readability. Also, into config.b should be added comment about usage of XUPX in exeflat.c. --- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: [Freedos-cvs] kernel/kernel makefile,1.19.2.4,1.19.2.5
Hi! 18--2004 11:20 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to [EMAIL PROTECTED]: LG +++ makefile18 Nov 2004 11:20:03 - 1.19.2.5 LG + ..\utils\exeflat kernel.exe $*.sys $(LOADSEG) -S0x10 -S0x8B -^^ As explained by Bart, this value should be changed to reflect real (current) position of FD data segment. --- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: [Freedos-cvs] kernel build.bat,1.14.2.4,1.14.2.5 buildall.bat,1.6.2.1,1.6.2.2 clean.bat,1.10.2.1,1.10.2.2 clobber.bat,1.11.2.1,1.11.2.2 config.b,1.12.2.2,1.12.2.3 defaults.bat,1.1.2.3,1.1.2.4 filelist,1.9.2.5,1.9.2.6 makefile,1.2,1.2.2.1
Hi! 18--2004 11:16 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to [EMAIL PROTECTED]: LG Modified Files: LG Tag: UNSTABLE LG build.bat buildall.bat clean.bat clobber.bat config.b LG defaults.bat filelist makefile LG Log Message: LG sg This letter looks like bug somewhere (because garbage after Log). --- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: [Freedos-cvs] kernel/hdr portab.h,1.31.2.3,1.31.2.4
Hi! 18--2004 11:20 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to [EMAIL PROTECTED]: LG Suppress TC++ 1.01 warnings (BC++ 3/4/5 not affected!) and MSC LIB prompt LG +++ portab.h18 Nov 2004 11:20:03 - 1.31.2.4 LG @@ -66,6 +66,14 @@ LG +#if __TURBOC__ 0x400 /* targeted to TC++ 1.0 which is 0x297 (3.1 is 0x410) */ LG +#pragma warn -pia /* possibly incorrect assignment */ LG +#pragma warn -sus /* suspicious pointer conversion */ LG +/* LG + * NOTE: The above enable TC++ to build the kernel, but it's not recommended LG + * for development. Use [Open]Watcom (the best!) or newer Borland compilers! LG + */ LG +#endif May I ask which places cause warnings, which are turned off here (I don't have TCPP1 to check this)? May be better to fix (for example, by adding castings) those places instead turning off warnings at all? --- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: [Freedos-cvs] kernel/sys sys.c,1.41.2.7,1.41.2.8
Hi! 17--2004 18:01 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to [EMAIL PROTECTED]: LG Bart enhanced EXEFLAT for smaller packed binary; now calls UPX itself LG +++ sys.c 17 Nov 2004 18:01:53 - 1.41.2.8 LG -#define MSDOS MSDOS.SYS LG +#define MS_DOS MSDOS.SYS LG - if (altkern == MS_OEMKERN) dosfn = MSDOS; LG + if (altkern == MS_OEMKERN) dosfn = MS_DOS; Hm. How this relates to exeflat/UPX and which rationale for patch? Subject of taste? --- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: [Freedos-cvs] kernel/kernel makefile,1.19.2.3,1.19.2.4
Hi! 17--2004 18:01 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to [EMAIL PROTECTED]: LG Bart enhanced EXEFLAT for smaller packed binary; now calls UPX itself LG +++ makefile17 Nov 2004 18:01:53 - 1.19.2.4 LG - $(XUPX) kernel.exe Don't forget, that XUPX variable also defined in generic.mak (if it not defined in config.bat). Also, if exeflat relies on XUPX variable itself, what to pass extra option -U to it? Just check if XUPX variable is present or not and remove all messinf with XUPX and UPXOPT in generic.mak. --- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: [Freedos-cvs] kernel/utils exeflat.c,1.9.2.3,1.9.2.4
Hi!
17--2004 18:01 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to
[EMAIL PROTECTED]:
LG +++ exeflat.c 17 Nov 2004 18:01:54 - 1.9.2.4
LG +int exeflat(int UPX, const char *srcfile, const char *dstfile,
LG +const char *start, short *silentSegments, short silentcount)
LG {
LGif (fread(header, sizeof(header), 1, src) != 1)
LG{
LG -printf(Error reading header from %s\n, argv[1]);
LG +printf(Error reading header from %s\n, srcfile);
LG fclose(src);
LG -return 1;
LG +exit(1);
LG}
Small optimization: because BC doesn't knows, that exit() doesn't
returns, better to insert explicit return 0; after exit() or return error
code through return (remaining error handling for main()). For BC, this
allows to join common tails.
LG + qsort(reloc, header.exRelocItems, sizeof(reloc[0]), compReloc);
Why to spend extra time for sorting relocations?
LG +for (j = 0; j silentcount; j++)
LG + if (segment == silentSegments[j])
LG + {
LG +silentdone++;
LG +goto dontPrint;
LG + }
Never understand this option. (Though, don't try to study its meaning
deeper). The more so, me always annoying tons of some information about some
relocations, which garbaes output after exeflat.
---
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: CF and HOT SWAP
Hi, you do NOT have to write code to handle FAT filesystem. You only have to EITHER convince the BIOS to access your CF disk OR write some (relatively simple) code which can read and write single sectors on the CF disk by accessing the IDE controller directly. The REST will be done by the FreeDOS kernel for you, and here is how: Look at the source code of a RAMDISK like TDSK. As you can see, there is not much more than write a sector, read a sector, tell if disk changed and give boot sector information to DOS. Implement that as a block device driver (just use TDSK source code and replace the copy to/from XMS code by your direct IDE access code) and you have a complete CF disk driver for DOS :-). Bonus problem: If you have partitions on your CF disk, then you should try by accessing only the first FAT partition. Just read the partition table on the CF, store the offset of the first FAT partition, and add that offset to the sector number of each read or write request from DOS. In other words, tell DOS that your driver is a generic driver for a single drive letter consisting of sectors. DOS kernel does not have to know more details, and it does not have to know about partition details. Eric --- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: Fwd: FreeDOS kernel disk routines
Hi! te My computer BIOS INT 13 is able to access up to 4096 cylinders te in a hard disk. te by using bits 6 -7 of DH in INT 13 requests as bits 10-11 of cylinder te number. I remember having a 386 (NeAT mainboard) which had this kind of BIOS feature. It means you can have 4k cylinders but only 16 (in theory 64, but at least my BIOS only allowed 16) heads. As Tom points out, this is incompatible to modern style disk access, so you will only be able to use the first 1024 cylinders with FreeDOS. There are other INT 13 extensions which allow you to use cylinder numbers of up to 65535. Those come in two flavors: One is a call which tells add CX to cylinder number for next disk access (int 13.ef, supported by Ontrack Drive Rocket, SWBIOS and Disk Manager, and the other just adds a constant value of 1024 to the cylinder number (int 13.ee). SWBIOS is a TSR by OnTrack. For all three special more cylinder things, I can tell you that they are very outdated. Please install something more fancy (e.g. newer OnTrack or EzDrive driver, which you put into the MasterBootRecord) which provides a modern LBA (all sectors on disk are just accessed by linear number, not by a position in terms of cylinders, heads and sectors) interface. I even wrote something like that myself for that 386 (must have been AMI or AWARD BIOS). It mapped access to the second harddisk to access to the first harddisk, after adding 1024 to the cylinder number. Very ugly but allowed me to use all of my 850 MB disk for a while (until something went really wrong and the simulated 2nd harddisk contents got screwed). Yet another reason why you should use LBA: With LBA, you can have up to 255 (+/- 1, depending on OS) heads, so with a smart LBA driver in place, even CHS based access, using translation to LBA positions, can squeeze 8 GB of disk space into the first 1024 cylinders! Much better than having 16 heads and some incompatible (even to standard partition table format) cheat to allow 4096 cylinders (to reach 2 GB instead of 500 MB). Eric --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: Your X-Comment-To: tom ehlert te@drivesnapshot.de
Hi! 7--2004 01:02 [EMAIL PROTECTED] (Jose Antonio Senna) wrote to Arkady V.Belousov [EMAIL PROTECTED]: JAS I am unable to post,but read user and devel lists. Just subscribe. :) JAS Here are some further explanations: te by using bits 6 -7 of DH in INT 13 requests as bits 10-11 of cylinder avb If so, then this is non-standard and this completely prohibits LBA avb (with up to 256/255 heads). [...] te This BIOS variant is documented in Brown and Kyle interrupts list. avb Ralf Brown not documents such API deviation (or I miss something?). JAS It does,not in DOS API,but under low-level disk I/O heading,at Of course, I also mean INT13. JAS least in the list version which copy I have. A mail to this list JAS by Bart Oldeman a few hours ago confirms it is documented. Yes, I was see this letter. Ok, there was such deviation te However,FreeDOS hooks INT 13 and,in doing so,rolls over any cylinder te number modulo 1024, that is,if I make a request to access cylinder 1024,it te does not report any error,but I get cylinder 0, and so on. avb FreeDOS _doesn't_ hooks INT 13. See main.c:setup_int_vectors() for list avb of hooked vectors. JAS I thought I did,for the vector in the Interrupt Vector Table clearly JAS points into DOS area. Ok, let clarify this. Unfortunately, neither my nor Bart's MEM shows interrupt vectors relation, so procedure slightly more complex: 1. Run my MEMA (prefered) with option(s) /DAT (without quotes) or run Bart's MEM with options /F/D/U (without quotes) and show me result. 2. In DEBUG execute d 0:0l100 ans show me results. Then get results into file (which you may insert into letter) you may use redirection. For example, make file (and call it, say, DBG.CMD) with next content: __O\_/_\_/O__ d 0:0l100 q _ O/~\ /~\O and run next commands: MEMA/DATRESULT1 DEBUGDBG.CMDRESULT2 Now you get results in files, which you may send us. JAS Maybe I did miss something, and there is some JAS installed device driver, instead, that hooks INT 13. --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88alloc_id065op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: [Freedos-user] Unable to format harddisk partition after reboot
Hi! 13--2004 11:25 [EMAIL PROTECTED] (Christof Meerwald) wrote to [EMAIL PROTECTED]: CM I am unable to format a harddisk partition after a reboot (the problem CM occurrs in a Linux dosemu box and on real hardware), here is the version CM information of the FreeDOS kernel: CM FreeDOS kernel version 1.1.35w (Build 2035w-UNSTABLE, Sep 27 2004) A:\format c: /u /q CM Critical error encountered while using DOS disk driver CM DOS driver error (hex): 01 CMDescription: unknown unit for driver CM It seems that FreeDOS hasn't initialized some disk parameter block, CM because if I access the harddisk before trying to format it (i.e. dir CM c:), the format works: CM Does anyone have an idea? Yes. In last patches Lucho removes main.c:InitializeAllBPBs(), which does what you explain (initialize BPBs for utilities, which access disk directly). Probably, issue is in this removed function. Unfortunately, at given moment I don't have latest CVS kernel to try to return this function and see what happen. Kenneth, Lucho? May be someone of you? PS: Bart, tom: who was wrote comment for InitializeAllBPBs()? Can you explain, how to reproduce direct access through DE? _Probably_, there should be loaded empty environment and DE runned for browsing physical drive? --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: question about the kernel with
Hi Jeffrey, I think I can explain your symptoms... Your bootable CD probably contains a boot floppy image. The BIOS uses this image to simulate an extra floppy drive. You can check the contents of the A: and B: drives to verify this. To avoid the effect, create a bootable CD with help of ISOLINUX (which does not need a virtual floppy) boot loader / boot menu, and load the virtual floppy image, with help of MEMDISK, only for the DOS menu entry, not for the boot from harddisk menu entry. Hit any key within 10 seconds to continue booot from Floppy Hit 'H' orwait 10 seconds to boot from Harddisk After booting into Windows, I can see there are two floppy drives... Eric PS: Check the FreeDOS ISO image as an example of the MEMDISK method. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: question about the kernel with
Hi Jeffrey, actually the kernel tries to finish CD harddisk emulation before booting from HD (main.c, EmulatedDriveStatus) unfortunately this doesn't seem to work (in your case, with your CD burning software,...) tom --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: [Freedos-cvs] kernel/kernel nls_hc.asm,1.4.2.2,1.4.2.3
Hi! 23--2004 13:08 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to [EMAIL PROTECTED]: LG Divide hard-coded UCASE and FUCASE tables LG +++ nls_hc.asm 23 Sep 2004 13:08:23 - 1.4.2.3 Note: nls_hc.asm is inherited from nls\049-850.hc. Thus, as I understand, should be also updated all files in nls\ directory. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
