Re: [Freedos-kernel] 32RTM Bug Found, no good fix
On Fri, 13 Aug 2004, Luchezar Georgiev wrote:
> Sure. But since it's easier to make the kernel return a serial mumber of 0
> as MS-DOS does than to patch each and every copy of 32RTM.EXE, I changed
> our function 30h to return 0 in CX. I tested this change and now 32RTM
> works without -X as Michael wrote indeed! So I uploaded a new unstable
> kernel binary at http://linux.tu-varna.acad.bg/~lig/freedos/kernel/ along
> with a comulative patch (CVSPATCH.TXT) for the unstable branch consisting
> of the Eduardo's NLS patch and the following patch. Thus, regrettably
> we're back to version 0.0.35 now (as reported by the FreeCOM's VER /R ;-)
whatever, now we have 2035, 2.0.35, 1.1.35, and 0.0.35 all as version
numbers ;) Just have to send Ralf Brown another email as my previous
mod to interrupt.f will be obsolete.
Anyway most references other than RBIL tell that the serial number isn't
used as such.
www.htl-steyr.ac.at/~morg/ pcinfo/hardware/interrupts/inte2zlc.htm
tells us that
" - the OEM serial number is a rarity, though some older OEM DOS
versions implemented this feature".
Most likely 32RTM wouldn't run on those older OEM DOS versions either
then.
> --- cvs/kernel/kernel/inthndlr.c 2004-07-25 20:12:50.0 +0200
> +++ src/kernel/kernel/inthndlr.c 2004-08-13 12:05:56.0 +0200
> @@ -698,10 +698,8 @@
> case 0x30:
> lr.AL = os_setver_major;
> lr.AH = os_setver_minor;
> - lr.BH = OEM_ID;
> - lr.CH = REVISION_MAJOR; /* JPP */
> - lr.CL = REVISION_MINOR;
> - lr.BL = REVISION_SEQ;
> + lr.BX = (OEM_ID << 8) | REVISION_SEQ;
> + lr.CX = 0; /* serial number must be 0 or buggy 32RTM thrashes
> stack! */
>
> if (ReturnAnyDosVersionExpected)
> {
>
This patch won't apply without manual tweaks Lucho, please fix your
email client. Lines were wrapped and indentation also messed up (hard
tabs?). There's also a pointless "optimization", that the compiler can do
for us as well.
So here's my version:
--- inthndlr.c 25 Jul 2004 08:04:54 - 1.89
+++ inthndlr.c 15 Aug 2004 08:15:32 -
@@ -704,9 +704,9 @@
lr.AL = os_setver_major;
lr.AH = os_setver_minor;
lr.BH = OEM_ID;
- lr.CH = REVISION_MAJOR; /* JPP */
- lr.CL = REVISION_MINOR;
lr.BL = REVISION_SEQ;
+ lr.CX = 0; /* do not set this to a serial number!
+32RTM won't like non-zero values */
if (ReturnAnyDosVersionExpected)
{
Bart
---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] 32RTM Bug Found, no good fix
Hallo Bart, whatever, now we have 2035, 2.0.35, 1.1.35, and 0.0.35 all as version numbers ;) ...and 2035, 2035a (why not rename them to STABLE?) and 2035a-UNSTABLE releases ;) Just have to send Ralf Brown another email as my previous mod to interrupt.f will be obsolete. ...in the hope that the probability of releasing the next version of the RBIL is greater than the probability of releasing the next version of the GPL (and neither of them is zero ;-) Anyway most references other than RBIL tell that the serial number isn't used as such. True. Moreover, the IBM PC-DOS 7 technical reference update (http://www.redbooks.ibm.com/redbooks/pdfs/gg244459.pdf) says: = start quote = 30H — Get DOS Version Number Purpose Returns the DOS version number. Examples PUSHCX ; CX destroyed in call PUSHBX MOV AH,30H ; Function Call – Get PC DOS 7 ; Version INT 21H ; Issue request to DOS MOV MajorVersion,AL ; Save Version MOV MinorVersion,AH MOV DOS_Running_From,BH ; POP BX POP CX - MajorVersionDB ?; X of X.YY MinorVersionDB ?; YY of X.YY DOS_Running_FromDB ?; 0 = DOS not running in ROM DOS_Running_FromDB ?; 8 = DOS running in ROM Comments On entry, AH contains 30H. On return, CX is set to 0. AL contains the major version number. AH contains the minor version number. BH contains 8 or 0 for DOS running or not running in ROM. If AL returns a major version number of 0, you can assume that the DOS version is pre-DOS 2.00. Use function call 33H AL=6 (Get or Set System Value) to get the true version number. = end quote = Not that it says "On return, CX is set to 0". So, the RBIL is just one of the references - not to be absolutised. www.htl-steyr.ac.at/~morg/ pcinfo/hardware/interrupts/inte2zlc.htm That URL doesn't work. The correct URL (without the extra space) is: www.htl-steyr.ac.at/~morg/pcinfo/hardware/interrupts/inte2zlc.htm tells us that " - the OEM serial number is a rarity, though some older OEM DOS versions implemented this feature". Most likely 32RTM wouldn't run on those older OEM DOS versions either then. Yes. This patch won't apply without manual tweaks Lucho, please fix your email client. I can't fix Opera - it's closed source ;-) Lines were wrapped and indentation also messed up (hard tabs?). Sorry. From now on, I'll enclose my eventual patches as plain text attachments. They'll work then. There's also a pointless "optimization", that the compiler can do for us as well. Will Watcom (the only compiler you recognise) do this? Borland won't, I'm sure. So my optimisation is NOT pointless. By the way, Bart, as an OpenWatcom contributor, would you please post news here and on fd-devel when version 1.3 is officially released? Thanks. Regards, Lucho --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] 32RTM Bug Found, no good fix
On Sun, 15 Aug 2004, Luchezar Georgiev wrote: > Hallo Bart, > > > There's also a pointless "optimization", that the compiler can do for us > > as well. > > Will Watcom (the only compiler you recognise) do this? Of course, I'm not going to state this without checking. > Borland won't, I'm sure. So my optimisation is NOT pointless. We'll make a deal. If Borland fixes their bug in 32RTM as part of open sourcing their old 16bit targetting compiler (even lower than the chance that RBIL will be updated) I'll go for it ;) I do recognize other compilers but... http://marc.theaimsgroup.com/?l=freedos-kernel&m=106373357329924&w=2 " re: BC optimizations: BC isn't a target for freedos optimizations; there's one and only one target to optimize for : WATCOM. so BC specific optimization is a waste of time (ours and yours) tom " This just being tom's opinion but I still agree -- I even agree more than I did a couple months ago, that's why I rejected my own idea of using "_seg *" pointers. I played for a while again with Turbo C++ back then but in the end decided that the difference was just too big. Bart --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Compilers (the eternal topic :)
Hallo Bart, We'll make a deal. If Borland fixes their bug in 32RTM as part of open sourcing their old 16bit targetting compiler (even lower than the chance that RBIL will be updated) I'll go for it ;) And this means - never, and you know it! ;-) I do recognize other compilers but... Glad to hear that! ;-) BC isn't a target for freedos optimizations; there's one and only one target to optimize for : WATCOM. so BC specific optimization is a waste of time (ours and yours) True, but my optimisation isn't BC-specific. It's beneficial for all compilers but Watcom! ;-) Besides, you know that Borland C++ 4.0 produces the smallest possible packed kernel binary file. Sometimes kernel file size is what matters (for floppy and ROM disks) and sometimes - the resident size in RAM (where Watcom is the king), if the DOS is in low RAM or if there is no cache. Depends. This is not to say that I like Borland. They added 3DNow! to their inline assembler in C++Builder 6, but NOT in their TASM, which makes me extremely angry at them! But on the other hand, Datalight still use Borland as their one and only compiler for ROM-DOS. If it was so bad, would they use it? This just being tom's opinion but I still agree -- I even agree more than I did a couple months ago, that's why I rejected my own idea of using "_seg *" pointers. I played for a while again with Turbo C++ back then but in the end decided that the difference was just too big. I agree that this was a right decision. Bart, some programmers claim that the only true Watcom is 10.6-, and 11.0+ is NO LONGER WATCOM as it was RUINED by Sybase. I have compared the code generated by both, and the difference is not so big, plus the code by 11.0+ is more optimal. What you can say on these Watcom version differences? Regards, Lucho --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] More kernel bugs and incompatibilities
At 11:35 PM 8/11/2004 +1200, Bart Oldeman wrote: > And with that, I'm at the end of the list for finding FreeDOS > incompatibilities unrelated to kernel, shell, and stand-alone FD utilities > again. There's one FD incompatibility that's been there for some time: OpenWatcom wd /tr=rsi and wd /tr=cw appear to run just fine when you debug a program but a crash occurs (black screen, reset only way out, or invalid opcode) when you exit the debugger. This doesn't happen with MSDOS. I'm taking the coward's way out here. This happens even without EMM386 or HIMEM, so it about has to be an incompatibility in the kernel. Which gets me off the hook and re-clears my personal checklist. I could try and debug it anyway, but again plead ignorance of detailed kernel workings. A kernel developer would be the best victim..errr...person to track this incompatibility down. I did notice that DOSEMU also has, or had, a problem with child 4Ch termination under WD and that would be my best guess for a starting place on what's going on with WD and FreeDOS. --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
