On 4/11/2012 9:17 PM, Rugxulo wrote:
> It's not insane at all. In fact, some people *like* static binaries.
> :-) And they are sure a billion times smaller than silly GLIBC. I'm
> not saying GLIBC doesn't have advantages, but I think OW is perfectly
> acceptable for Linux. However, no shared lib su
Hi,
On Wed, Apr 11, 2012 at 7:30 PM, Michael B. Brutman
wrote:
> On 4/11/2012 1:25 PM, Rugxulo wrote:
>>
>> On Sat, Apr 7, 2012 at 7:12 PM, Michael B. Brutman
>> wrote:
>>> For hard-core application programming where you need to use a few BIOS
>>> and DOS interrupts I like to use C and C++ (car
On 4/11/2012 2:34 PM, Alex wrote:
> Sorry but I still don't find the above comments very reassuring, with
> regard to the future usability of (Free)DOS on new hardware. The fact
> that we will be able to run DOS in emulators/virtual machines, because
> we can no longer boot it, is no reason at all
On 4/11/2012 1:38 PM, John Wesley Cooper wrote:
> On 4/11/2012 6:14 AM, Michael B. Brutman wrote:
>> As an end user, your fears are probably foolish. Emulation and
>> virtualization work fine
>> for anybody playing with DOS at the application level.
> Application-level? But doesn't DOS more or l
On 4/11/2012 1:25 PM, Rugxulo wrote:
> Hi,
>
> On Sat, Apr 7, 2012 at 7:12 PM, Michael B. Brutman
> wrote:
>> For hard-core application programming where you need to use a few BIOS
>> and DOS interrupts I like to use C and C++ (carefully). C gives you a
>> tremendous amount of control and flexib
On Wed, Apr 11, 2012 at 5:51 PM, BretJ wrote:
>
>> Some DOS *apps* cared and choked on it, so I wrote Korn shell alias
>> wrappers to reset the option delimiter char to / before running them, and
>> set it back to - when they exited.
>
> Like I said, this is why it won't work in the _general_ case
> Some DOS *apps* cared and choked on it, so I wrote Korn shell alias
wrappers to reset the option
> delimiter char to / before running them, and set it back to - when they
> exited.
Like I said, this is why it won't work in the _general_ case. There are
situations and programs where it can work
On Wed, Apr 11, 2012 at 5:02 PM, Alex wrote:
> On Wed, Apr 11, 2012 at 10:54 PM, dmccunney wrote:
>> *That* purpose has been unnecessary for decades. Running in a VM or
>> emulator still lets you *run* DOS and legacy DOS apps, which is all
>> you are likely to really *need* to do.
>
> I beg to
On Wed, Apr 11, 2012 at 3:31 PM, Bret Johnson wrote:
>> But no, it would almost never use '/' because that is the Directory
>> Separator (or whatever you want to call it). Also, '\' is the quote
>> character for the shell, hence "My\ File\ Name.txt". Also, I think
>> *nix (or at least Linux) can u
On Wed, Apr 11, 2012 at 10:54 PM, dmccunney wrote:
> On Wed, Apr 11, 2012 at 3:34 PM, Alex wrote:
>> Sorry but I still don't find the above comments very reassuring, with
>> regard to the future usability of (Free)DOS on new hardware. The fact
>> that we will be able to run DOS in emulators/virtu
On Wed, Apr 11, 2012 at 3:34 PM, Alex wrote:
> Sorry but I still don't find the above comments very reassuring, with
> regard to the future usability of (Free)DOS on new hardware. The fact
> that we will be able to run DOS in emulators/virtual machines, because
> we can no longer boot it, is no re
Some time ago I was in contact with this company.
The system-on-chip includes sound, net and video chipsets on the same
ceramic capsule where the processor is. A very nice idea, this system
needs very energy to work.
They offer systems with WinXP and a ligth Linux distro. Is an x86
compatible
2012/4/11, Bret Johnson :
> That was basically my point. *nix has conventions/standards that it uses,
> and so does DOS, and they are not the same. Trying to make one "look like"
> the other, especially with so much history and "freedom" allowed by DOS,
> just won't work.
I would to remind here
Hi people!
My DOS box is an old Pentium II 450 Mhz, which has ISA and PCI slots. The
problem is that this machine is sooo big and heavy. In the other hand, my
appartment is getting smaller every year. :)
I was looking in the Internet and I found this SoC Vortex86 (
http://www.vortex86dx.com/), wh
On Wed, 2012-04-11 at 02:11 -0700, Jack wrote:
> Intel has its guns aimed against SATA, as well, in favor of AHCI
AHCI is a standardised programming method that can be used on different
chipsets that adhere to the AHCI standard.
SATA is the bus where data is transferred to/from disks.
--
Tacti
There is another thread about the future of DOS
The fear is that we'll reach soon the point of no more new equipments
will be able to boot a "real" DOS on native mode.
At this point the options are to use emulators or to port DOS to new
processors (new x86 based or totally different processor fa
Op 11-4-2012 21:33, Jack schreef:
> Send me a private E-Mail, and if XMGR can be modified so Syslinux and
> Isolinux do NOT "confuse" it, I will make such modifications in XMGR!
I'll try to figure out what's going on, however have much doubt that I'd
be skilled enough to actually find a root cau
Sorry but I still don't find the above comments very reassuring, with
regard to the future usability of (Free)DOS on new hardware. The fact
that we will be able to run DOS in emulators/virtual machines, because
we can no longer boot it, is no reason at all for being reassured. In
fact, such a state
> But no, it would almost never use '/' because that is the Directory
> Separator (or whatever you want to call it). Also, '\' is the quote
> character for the shell, hence "My\ File\ Name.txt". Also, I think
> *nix (or at least Linux) can use any character for filenames except
> NUL, i.e. "..." is
>>> ... With my own testing I found JEMMEX more compatible than XMGR
>>> or HIMEMX + JEMM386 in various cases, but on other systems it is
>>> different, as Mike mentioned ...
>>
>> To WHAT "incompatibilities" are you referring??
>
> The A20 stuff that Syslinux/Isolinux (and MEMDISK) mess around wit
On Tue, Apr 10, 2012 at 10:37 AM, Alex wrote:
> This topic is not about DOS vs other operating systems, or the fact
> that users tend to gradually abandon DOS. It's about the survivability
> of DOS vis-a-vis hardware.
> The starting point for my reasoning is: what will happen with the
> future d
2012/4/11, Bret Johnson :
>> My personal vote would be for bringing a little more order, I mean:
>> to suppress recognizing such input as option, if slash is directly
>> after some string of characters - in such case path recognition
>> should be assumed.
>
> Problem with that is that I've seen pr
Op 11-4-2012 21:10, Jack schreef:
>> ... With my own testing I found JEMMEX more compatible than XMGR or
>> HIMEMX + JEMM386 in various cases, but on other systems it's different,
>> as Mike mentioned ...
>
> To WHAT "incompatibilities" are you referring??
The A20 stuff that Syslinux/Isolinux (and
Hi,
On Wed, Apr 11, 2012 at 2:00 PM, Bret Johnson wrote:
>> My personal vote would be for bringing a little more order, I mean:
>> to suppress recognizing such input as option, if slash is directly
>> after some string of characters - in such case path recognition
>> should be assumed.
>
> Proble
> ... With my own testing I found JEMMEX more compatible than XMGR or
> HIMEMX + JEMM386 in various cases, but on other systems it's different,
> as Mike mentioned ...
To WHAT "incompatibilities" are you referring??
Be advised of the following --
1) JEMMEX/JEMM386 use "old" memory-test schemes,
> My personal vote would be for bringing a little more order, I mean:
> to suppress recognizing such input as option, if slash is directly
> after some string of characters - in such case path recognition
> should be assumed.
Problem with that is that I've seen programs that _require_ the options
i think it's an excellent idea to get the "/" character as a directory
seperator...
( i t s h o u l d b e a n o p t i o n . )
..
eufdp...@yahoo.com
eufdp...@yahoo.com
eufdp...@yahoo.com
eufdp...@yahoo.com
eu
Hi,
On Wed, Apr 11, 2012 at 1:24 PM, Bernd Blaauw wrote:
> Op 11-4-2012 20:02, Rugxulo schreef:
>
> The entire idea of opensource was to be able to modify sources to suit a
> person's needs. Most people, including me, haven't got enough interest
> or experience to be a programmer, but still, a bi
On 4/11/2012 6:14 AM, Michael B. Brutman wrote:
>As an end user, your fears are probably foolish. Emulation and virtualization
>work fine
>for anybody playing with DOS at the application level.
Application-level? But doesn't DOS more or less give an application (nearly)
unfettered access to th
Freedos may provide pressure if it is popular enough to stay with well
known standard interfaces. If AHCI is going to be a well known
interface and it offers some advantage over SATA, Freedos can have a
driver for it and there is no reason to worry. In environments that are
more time sensitive, w
Op 11-4-2012 20:25, Rugxulo schreef:
>> (PS: If we have FreeDOS code that doesn't compile under OW I'd be
>> interested in seeing it. A few #defines can fix a lot of problems. The
>> debugging is the hard part.)
>
> There is a tcc2wat "library" by Blair Campbell on iBiblio, if anyone
> wants to
Hi,
On Sat, Apr 7, 2012 at 7:12 PM, Michael B. Brutman
wrote:
>
> For hard-core application programming where you need to use a few BIOS
> and DOS interrupts I like to use C and C++ (carefully). C gives you a
> tremendous amount of control and flexibility.
>
> Open Watcom is open source and is r
Op 11-4-2012 20:02, Rugxulo schreef:
> Users will always need sources, esp. if they share, but they don't
> necessarily need to unpack them. (Well, anyways, they probably don't
> have all compilers anyways.)
The entire idea of opensource was to be able to modify sources to suit a
person's needs
2012/4/11, Rugxulo :
> Good to know, thanks for the feedback, but ...
>
> a). there is no maintainer for 4DOS
It seems, there's no hope for handling that timer-related issues too soon.
> b). it doesn't compile (easily), and OpenWatcom isn't supported
...it's even worse. O_O
>> 2. Could it be m
2012/4/11, Tom Ehlert :
>> 2. Could it be made to use slash as separator in pathnames, just like
>> 4DOS allows both slash and backslash? Every Linux/BSD user will
>> appreciate that.
> whats supposed to happen on
>
>C:>DATE/T
> /T is probably an option
>
>DATE\T
> probably some program in
Hi,
On Wed, Apr 11, 2012 at 12:19 PM, Zbigniew wrote:
>
> 1. Its "history" records "empty" lines (e.g. when one hits "Enter") -
> I think, there's no need for that. It should record a line only in
> case, when after eliminating blank characters (CR, LF, space...) from
> both ends, its length stil
Hi,
On Wed, Apr 11, 2012 at 11:13 AM, Eric Auer wrote:
>
>>> it seems even on modern hardware unpacking FreeCOM
>>> during install may take VERY long, so we need a fix:
>>
>> This seems to be specific to the old installer (v3.7.8 by Jeremy) I
>> think, as that unpacks entire packages. Sourcecode
Hallo Herr Zbigniew,
am 11. April 2012 um 19:19 schrieben Sie:
> 1. Its "history" records "empty" lines (e.g. when one hits "Enter") -
> I think, there's no need for that. It should record a line only in
> case, when after eliminating blank characters (CR, LF, space...) from
> both ends, its leng
1. Its "history" records "empty" lines (e.g. when one hits "Enter") -
I think, there's no need for that. It should record a line only in
case, when after eliminating blank characters (CR, LF, space...) from
both ends, its length still remains > 0.
2. Could it be made to use slash as separator in p
Hi Bernd,
>> it seems even on modern hardware unpacking FreeCOM
>> during install may take VERY long, so we need a fix:
>
> This seems to be specific to the old installer (v3.7.8 by Jeremy) I
> think, as that unpacks entire packages. Sourcecode modification would be
> required to add a "-x source
>>With a help of Ed (DXForth creator) the problem is recognized; Ed wrote:
>>
>>#v+
>> 4DOS (or something associated with it) is setting PIT timer 0
>> from mode 3 to
>> mode 2 - which in turn is causing MS in DX-Forth to run slow.
>>#v-
> Nice find, didn't really expect that. Any hints in the
On 4/11/2012 5:21 AM, Alex wrote:
> This is exactly the sort of nightmarish scenario I was worrying about!!
> I was hoping that someone would point out how foolish my worries were,
> but now they appear to be not so foolish after all...
>
As an end user, your fears are probably foolish. Emulation
On Wed, Apr 11, 2012 at 10:07 AM, Jim Lemon wrote:
> I have been battling with this for some years, and my colleagues have
> to scavenge for old PCs that will run DOS natively.
This is exactly the sort of nightmarish scenario I was worrying about!!
I was hoping that someone would point out how f
The problems, that I was writing about lately, are caused by 4DOS'
tinkering with Timer 0. Ed (DXForth creator) sent to me a little
utility to check out; it's short Forth listing, but most is assembler:
#v+
\ Check current mode of the 8253/4 PC tick timer
\
\ Compile with DX.EXE - INCLUDE GM.F BY
Ralf,
Apologies for my previous "reply", which was not a reply, only my having
hit Opera's "send" button by error!
>> Cannot answer on all subjects, but re: disk/CD/DVD drivers, I am NOT
>> overly optimistic! Intel/Microsoft want us all to "buy into" AHCI,
>> and they may have started "orderin
On Tue, 10 Apr 2012 22:16:50 -0700, Ralf A. Quint wrote:
> At 01:13 PM 4/10/2012, Jack wrote:
>> Cannot answer on all subjects, but re: disk/CD/DVD drivers, I am NOT
>> overly optimistic! Intel/Microsoft want us all to "buy into" AHCI,
>> and they may have started "ordering" mainboard vendors t
On 04/11/2012 12:37 AM, Alex wrote:
> Hi
>
> This topic is not about DOS vs other operating systems, or the fact
> that users tend to gradually abandon DOS. It's about the survivability
> of DOS vis-a-vis hardware.
> The starting point for my reasoning is: what will happen with the
> future develop
47 matches
Mail list logo
