Re: [Freedos-kernel] Re: 32RTM Bug Found, copyleft message

2004-08-13 Thread Luchezar Georgiev
Hallo Eric,
Even 2035z would still mean a sufficiently small CX value and 32RTM 
would work.
If CX is nonzero, 32RTM will *not* work. And CX *is* zero in *all* DOS 
version I've tested (MS-DOS, PC-DOS, ROM-DOS and DR-DOS). Michael, Tom and 
Alain are right. There's nothing else we could do but clear CX. What's 
more important after all - that FreeCOM shows 1.1.35 instead of 0.0.35, or 
that 32RTM works? I think that the answer is obvious for everybody.

Yes we DO want to mention the license! MENTION. Not display the whole 
18k file, obviously.
That's exactly what I meant with my proposal (it fits on 2 lines despite 
the wraparound that my mail client will probably do):

FreeDOS kernel build 2035a-UNSTABLE  Copyleft 1985-2004 Pasquale J. 
Villani and
The FreeDOS Project. NO WARRANTY. Licensed under the GNU General Public 
License

This increases the size in RAM by ZERO bytes and the size on disk by 
some really small number of bytes - and our kernel is very small on disk 
already anyway. So leave the banner message as is, thank you.
The current message does more than simply MENTIONING the GPL. That's why I 
think it's too long. Just MENTIONING the GPL is enough - most people 
nowadays already know it. It's not like it was back in 1991!

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


[Freedos-kernel] Re: 32RTM Bug Found, no good fix

2004-08-13 Thread Eric Auer

Hi, indeed an interesting problem... 32RTM fails to initialize CX
(number of words to copy from stack) before a DPMI call, and instead,
the CX of int 21.30 (get version) is used. So we need a version other
than 1.1.35 (major, minor, seq):

> -  lr.CH = REVISION_MAJOR;   /* JPP */
> -  lr.CL = REVISION_MINOR;
> +  lr.CX = 0; /* serial number must be 0 or buggy 32RTM thrashes 
> stack! */

I would vote for lr.CH = 0 lr.CL = *letter*
(BL is the seq number: 35, and BH is the OEM id: 0xfd)
in that scenario, ver /r would display instead of "1.1.35" (classic 2035)
"0.0.35" (2035 stable) and "0.1.35" (2035a), and so on. And we would finally
have a way to distinguish a/b/c versions without having to use "display
kernel version string" (YES it is accessible by an API and YES it is in RAM
and YES that is a good thing to have).
Even 2035z would still mean a sufficiently small CX value and 32RTM would work.

PS Lucho:
> Please don't put the licensing conditions into the kernel! We strive for 
> small size, don't we?
Yes we DO want to mention the license! MENTION. Not display the whole 18k
file, obviously. This increases the size in RAM by ZERO bytes and the size
on disk by some really small number of bytes - and our kernel is very small
on disk already anyway. So leave the banner message as is, thank you.

Eric



---
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] exeflat (2035a) start segment must be variable

2004-08-13 Thread Alain
Hi Arkady,
good to have you back :)
Please send me your email address for direct contact. I sent you a 
message that was probably lost :(

Alain

---
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

2004-08-13 Thread tom ehlert
Hello Luchezar,

>> There you have it folks.  A dumb bug in a Borland product that by purest
>> happenstance fails under FreeDOS and not MS-DOS.  I don't have any idea
>> how to gracefully fix the problem other than to have FreeDOS change its
>> serial number.  And it shouldn't have to do that.

Another one who whishes to congratulate Michael for finding this bug,
and thanks.


> --- 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! */


and that's a patch I can peer review, understand it's implications,
and merged into my boring rock solid (as stone) kernel branch ;)

tom




---
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] Initial copyleft / licensing message

2004-08-13 Thread Luchezar Georgiev
FreeDOS kernel build 2035a-WHATEVER. Copyright...
This kernel comes with ABSOLUTELY NO WARRANTY and you are welcome to
redistribute it under certain conditions; press F1 for details.
I'd prefer this:
FreeDOS kernel build 2035a-UNSTABLE  Copyleft 1995-2004 Pasquale J. 
Villani and
the FreeDOS Project. NO WARRANTY. Licensed under the GNU General Public 
License

Nice idea and very easy to implement. :) I think, this is even _should_ 
be implemented, as startup screen should be cleaned.
Please don't put the licensing conditions into the kernel! We strive for 
small size, don't we?

Besides, that GNOMOVISION example is in the 12 year olg GPL2 only. The 
Alfero license, which is said to be the example for the future (mythical?) 
GPL3, doesn't have this example.

If you ask me, the smaller startup message the better, and no license 
games at DOS bootstrap!

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


[Freedos-kernel] Mala direta por e-mail - As melhores listas de email

2004-08-13 Thread Erica Silveira
Mala direta por e-mail. Cadastros selecionados. As melhores listas 
de e-mails selecionados por estados, atividades e profissões.
Listas atualizadas para mala direta via e-mail marketing. Visite

http://www.promonet.mx.gs

Cadastros altamente selecionados para divulgação de produtos por
email marketing. Listas de e-mails e programas grátis para divulgação
via correio eletrônico. Mala direta por e-mail. Visite agora:

http://www.promonet.mx.gs


---
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] Versions and builds, conservatism

2004-08-13 Thread Arkady V.Belousov
Hi!

8-Авг-2004 11:39 [EMAIL PROTECTED] (Bart Oldeman) wrote to
[EMAIL PROTECTED]:

BO> FreeDOS could, say, show the full message if you press a certain F key(as
BO> it waits for F5/F8 anyway), like this
BO> FreeDOS kernel build 2035a-WHATEVER. Copyright...
BO> This kernel comes with ABSOLUTELY NO WARRANTY and you are welcome to
BO> redistribute it under certain conditions; press F1 for details.

 Nice idea and very easy to implement. :) I think, this is even _should_
be implemented, as startup screen should be cleaned.




---
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] HiNTOS

2004-08-13 Thread Arkady V.Belousov
Hi!

11-Авг-2004 14:22 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to
[EMAIL PROTECTED]:

LG> RAR 3.30 (its DOS version fails
LG> to modify existing archives but its Windows console version can do it).

 Do you report this to Eugeny? I may do this myself, if you explain me,
how to reproduce this bug.




---
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] Versions and builds, conservatism

2004-08-13 Thread Arkady V.Belousov
Hi!

7-Авг-2004 17:22 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to
[EMAIL PROTECTED]:

LG> Arkady, please respond if you read this. How are you?

 Fine, thank you.




---
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

2004-08-13 Thread Luchezar Georgiev
Thank you very much, Michael, for your discovery of the 32RTM bug!
There you have it folks.  A dumb bug in a Borland product that by purest 
happenstance fails under FreeDOS and not MS-DOS.  I don't have any idea 
how to gracefully fix the problem other than to have FreeDOS change its 
serial number.  And it shouldn't have to do that.
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 ;-)

I guess 32RTM now stands for "32 times Read The Manual!" ;-)
Do you see now what I meant when I wrote that MS-DOS has a better "bug 
compatibility"? ;-)

Regards,
Lucho
--- 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)
   {
---
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


[Freedos-kernel] PATCH: nls.c

2004-08-13 Thread Eduardo Casino
Hi All,

This patch differentiates the calls to NLSFUNC's MUX-14-01 and
MUX-14-03. Fixes implementation of int 21-38-XX/DX= (SET COUNTRY
CODE) and int 21-66-02 (SET GLOBAL CODE PAGE TABLE) and is needed for
the upcoming NLSFUNC (together with this previous patch by Steffen,
which is already in UNSTABLE:
http://sourceforge.net/mailarchive/message.php?msg_id=8804587 )

Eduardo.



diff -uNrp ke2035.orig/kernel/nls.c ke2035/kernel/nls.c
-- ke2035.orig/kernel/nls.c 2004-07-26 14:06:47.0 +0200
+++ ke2035/kernel/nls.c 2004-07-26 14:11:13.0 +0200
@@ -109,7 +109,7 @@ STATIC COUNT muxGo(int subfct, UWORD bp,
/*
  * Call NLSFUNC to load the NLS package
  */
-COUNT muxLoadPkg(UWORD cp, UWORD cntry)
+COUNT muxLoadPkg(int subfct, UWORD cp, UWORD cntry)
{
   UWORD id; /* on stack, call_nls in int2f.asm takes care of this
  * if DS != SS */
@@ -131,7 +131,7 @@ COUNT muxLoadPkg(UWORD cp, UWORD cntry)
   /* OK, the correct NLSFUNC is available --> load pkg */
   /* If cp == -1 on entry, NLSFUNC updates cp to the codepage loaded
  into memory. The system must then change to this one later */
-  return muxGo(NLSFUNC_LOAD_PKG, 0, cp, cntry, 0, 0, 0);
+  return muxGo(subfct, 0, cp, cntry, 0, 0, 0);
}

STATIC int muxBufGo(int subfct, int bp, UWORD cp, UWORD cntry,
@@ -367,15 +367,30 @@ STATIC COUNT nlsSetPackage(struct nlsPac
}
STATIC COUNT DosSetPackage(UWORD cp, UWORD cntry)
{
+  /* Right now, we do not have codepage change support in kernel, so
push
+ it through the mux in any case. */
+
+  return muxLoadPkg(NLSFUNC_LOAD_PKG2, cp, cntry);
+}
+
+STATIC COUNT nlsLoadPackage(struct nlsPackage FAR * nls)
+{
+
+  nlsInfo.actPkg = nls;
+
+  return SUCCESS;
+}
+STATIC COUNT DosLoadPackage(UWORD cp, UWORD cntry)
+{
   struct nlsPackage FAR *nls;   /* NLS package to use to return the
info from */

   /* nls := NLS package of cntry/codepage */
   if ((nls = searchPackage(cp, cntry)) != NULL)
 /* OK the NLS pkg is loaded --> activate it */
-return nlsSetPackage(nls);
+return nlsLoadPackage(nls);

   /* not loaded --> invoke NLSFUNC to load it */
-  return muxLoadPkg(cp, cntry);
+  return muxLoadPkg(NLSFUNC_LOAD_PKG, cp, cntry);
}

STATIC void nlsUpMem(struct nlsPackage FAR * nls, VOID FAR * str, int
len)
@@ -556,7 +572,7 @@ COUNT DosGetCountryInformation(UWORD cnt
#ifndef DosSetCountry
COUNT DosSetCountry(UWORD cntry)
{
-  return DosSetPackage(NLS_DEFAULT, cntry);
+  return DosLoadPackage(NLS_DEFAULT, cntry);
}
#endif

@@ -628,6 +644,7 @@ UWORD ASMCFUNC syscall_MUX14(DIRECT_IREG
   /* Does not pass buffer length */
   return nlsGetData(nls, CL, MK_FP(ES, DI), 512);
 case NLSFUNC_LOAD_PKG:
+  return nlsLoadPackage(nls);
 case NLSFUNC_LOAD_PKG2:
   return nlsSetPackage(nls);
 case NLSFUNC_YESNO:




---
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


[Freedos-kernel] 32RTM Bug Found, no good fix

2004-08-13 Thread Michael Devore
[Sorry, this is going to be long. I can't describe the problem properly 
otherwise.  I'm cc'ing to devel since the problem isn't really in the 
kernel and affects all Borland 32RTM users.]

The 32RTM problem where 32RTM executing under FreeDOS without the -X option 
generates an exception is a Borland bug.  And the bug only shows up with 
FreeDOS because MS-DOS does something slightly different, although the 
FreeDOS method is perfectly valid.

The problem occurs in this code segment in 32RTM:
 push bp
 sub sp,32h
 mov bp,sp
 mov word ptr [bp+1ch],3400h
 mov word ptr [bp+20h], 3202h
 mov word ptr [bp+30h],0
 mov word ptr [bp+2eh],0
 mov ax,300h
 mov bx,21h
 mov di,bp
 push ss
 pop es
 int 31h
Briefly put: when the int 31h (DPMI interrupt) occurs, 32RTM generates an 
exception under FreeDOS.  Basically what is happening in this code segment 
is that 32RTM sets up a stack frame to hold a real mode call structure 
pointed to by ES:DI for calling INT 21h through the INT 31h DPMI 
interface.  It sets the AX value to 3400h, for get InDOS function.  The 
3202h value is the flags register.  And the 0 in the other two stack frame 
values indicates that the DPMI server should use its own internal 
stack.  Everything other real mode register is don't care.  The ax,300h 
simply is the DPMI function for simulate real mode interrupt, here to call 
INT 21h function 34h.  Okay, hope that's clear.

People who use DPMI functions might notice one small omission here.  No CX 
register value is set.  Well, CX is an important register for the 300h 
function, it is the number of words to copy from protected mode to real 
mode stack when the interrupt is issued.

So I looked further back in the 32RTM code to see where CX register is 
getting set and falling through to this routine.  Amazingly enough, the CX 
value used is the one that is returned from an earlier real mode INT 21h 
function 30h get DOS version call.  The return value of CX from that 
function is the lower 16-bits of the "user serial number", whatever the 
heck that is.  Unfortunately, FreeDOS returns a serial number of 101h in 
CX.  MS-DOS appears to return a value of 0.  By a fluke, MS-DOS is 
returning a CX value which allows the above DPMI call to function without 
problems.

So what happens with the FreeDOS 101h value in CX?  It copies 514 bytes of 
crap to the real mode stack during the INT 31h.  That blows the DOS stack 
right there, and if it doesn't, it sure blows the internal DPMI 
stack.  Hard to say what important internal data gets shot down with the copy.

How do I know this is the problem?  I tested it two different ways:
First, I in the debugger I dynamically patched the:
 mov word ptr [bp+30h],0
 mov word ptr [bp+2eh],0
instructions in the code fragment to:
 xor cx,cx
 mov [bp+30],cx
 mov [bp+2eh],cx
with NOP padding. 32RTM happily went resident without exception, since no 
bytes were copied to and from the real mode stack.

Second test: while in the debugger, after the 30h get DOS function call in 
32RTM, I changed CX return value from 101h to 0.  Once again, 32RTM went 
resident without problems.

There you have it folks.  A dumb bug in a Borland product that by purest 
happenstance fails under FreeDOS and not MS-DOS.  I don't have any idea how 
to gracefully fix the problem other than to have FreeDOS change its serial 
number.  And it shouldn't have to do that.


---
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