Re: [Freedos-devel] ideas about FreeDOS resident calculator

2007-04-11 Thread Aitor Santamaría
I support this idea too, and for the operators, let me suggest using C-style ones, given the big amount of C-compatible languages, not only C/C++ but also Java, ecma-script and derivatives, etc. I am not saying to support them all: - there's no sense for =, +=, -=, etc, unless you implement some i

Re: [Freedos-devel] ideas about FreeDOS resident calculator

2007-04-11 Thread Ladislav Lacina
Yes, exactly. We need only few functions: * check whether is driver present * compute matematical expression (*) set precision for floating point numbers (*) some extra function for operations like arithmetical mean - Take S

Re: [Freedos-devel] ideas about FreeDOS resident calculator

2007-04-11 Thread tom ehlert
Hi, well, honestly, I think there's absolutely no use for an API for FDRC. make the CalcResultFromString portion of FDRC a separate source, linkable to every program that likes to have a calculator. Mit freundlichen Grüßen / Kind regards, Tom Ehlert +49-241-79886 -

Re: [Freedos-devel] ideas about FreeDOS resident calculator

2007-04-11 Thread Eric Auer
Hi, well, honestly, I think the most "in style" way to have an API for FDRC would be to have a way to send strings like "4+sqrt(2)" to the calculator and receive a string with the result. Maybe with some extra functions like "round(2, 4+sqrt(2))" which would return "5.41" and "hex(42)" (returns "

Re: [Freedos-devel] ideas about FreeDOS resident calculator

2007-04-11 Thread Ladislav Lacina
ns.FPU registers work as stacks so no confusion whether read or not read can't occur. - Original Message - From: "Tony G" <[EMAIL PROTECTED]> To: Sent: Tuesday, April 10, 2007 10:37 PM Subject: Re: [Freedos-devel] ideas about FreeDOS resident calculator > I

Re: [Freedos-devel] ideas about FreeDOS resident calculator

2007-04-10 Thread Tony G
; Sent: Tuesday, April 10, 2007 1:16 PM Subject: Re: [Freedos-devel] ideas about FreeDOS resident calculator > Ladislav Lacina wrote: > >>FDRC is nice and comfortable. But you could go further. Now is the TSR >>module called by hotkey. What about making a alternate interface

Re: [Freedos-devel] ideas about FreeDOS resident calculator

2007-04-10 Thread Ladislav Lacina
> in memory). Which functions should be available via INT 2f except > these? Maybe conversions from/to another number representation systems. 255dec = FFh = b - Take Surveys. Earn Cash. Influence the Future of IT Jo

Re: [Freedos-devel] ideas about FreeDOS resident calculator

2007-04-10 Thread Oleg O. Chukaev
Ladislav Lacina wrote: >FDRC is nice and comfortable. But you could go further. Now is the TSR >module called by hotkey. What about making a alternate interface through >some interrupt? Now FDRC serves to users but if you would make some API >let's say on 2Fh DOS multiplex it could serve to progr

Re: [Freedos-devel] ideas about FreeDOS resident calculator

2007-04-07 Thread Tony
part of the FDRC published under the ... license. - Original Message - From: Ladislav Lacina To: freedos-devel@lists.sourceforge.net Sent: Saturday, April 07, 2007 7:38 AM Subject: [Freedos-devel] ideas about FreeDOS resident calculator FDRC is nice and comfortable. But

Re: [Freedos-devel] ideas about FreeDOS resident calculator

2007-04-07 Thread Johnson Lam
On Sat, 7 Apr 2007 13:38:57 +0200, you wrote: >This all is needed because Blo?ek works in VESA graphics mode so the dialog >window of FDRC can't be displayed. I wonder nowadays display card still have support of VESA or not. UNIVBE refuse to work long ago, and other free VESA drivers stopped al

[Freedos-devel] ideas about FreeDOS resident calculator

2007-04-07 Thread Ladislav Lacina
FDRC is nice and comfortable. But you could go further. Now is the TSR module called by hotkey. What about making a alternate interface through some interrupt? Now FDRC serves to users but if you would make some API let's say on 2Fh DOS multiplex it could serve to programmers also. I would like