DOS ain't dead - CHM reader in DOS

Laaca

Czech republic,
21.03.2009, 08:57

CHM reader in DOS (Announce)

In development versions of Freepascal 2.2.4 is now included for CHM file format in IDE.
Just run IDE (FP.EXE), go into Help -> Files -> ...and select some .CHM file you want to view.

Note that CHM support is limited because CHM files are in the fact compressed HTML files. So the viewer is limited by its HTML rendering capabilities. But for many cases it works well.

---
DOS-u-akbar!

DOS386

22.03.2009, 05:42

@ Laaca

CHM reader in DOS

Post reply

> CHM reader in DOS
> In development versions of Freepascal 2.2.4 is now included for CHM file

Interesting ... maybe I'll test ... of course having this available without the full 30 MiB bloat would be even better ;-)

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

marcov 23.03.2009, 17:22 @ DOS386	CHM reader in DOS Post reply
	> > CHM reader in DOS > > In development versions of Freepascal 2.2.4 is now included for CHM > file > > Interesting ... maybe I'll test ... of course having this available > without the full 30 MiB bloat would be even better I can't wait to see what you come up with. I hope it is as small as your last "cool" TSR. Otherwise it is bloat apparantly.

DOS386

31.03.2009, 03:47

@ marcov

CHM reader in DOS

Post reply

> as small as your last "cool" TSR. Otherwise it is bloat apparantly.

Fortunately there is UPX :clap:

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

marcov

23.03.2009, 17:21

@ Laaca

CHM reader in DOS

Post reply

> In development versions of Freepascal 2.2.4 is now included for CHM file
> format in IDE.
> Just run IDE (FP.EXE), go into Help -> Files -> ...and select some .CHM
> file you want to view.
>
> Note that CHM support is limited because CHM files are in the fact
> compressed HTML files. So the viewer is limited by its HTML rendering
> capabilities. But for many cases it works well.

Note that I still have problem when loading a very large (6MB , all text) CHM.

It then crashes in loading the index.

Laaca

Czech republic,
23.03.2009, 18:43

@ marcov

CHM reader in DOS

Post reply

> Note that I still have problem when loading a very large (6MB , all text)
> CHM.
>
> It then crashes in loading the index.

Strange. One would say that if you can load small (let's say 10KB file) you can a big one too. There shouldn't be any principial difference.

Or it does use some gradual allocation like f.e. TCollection dynamic arrays do?

---
DOS-u-akbar!

marcov

23.03.2009, 21:30

@ Laaca

CHM reader in DOS

Post reply

> > Note that I still have problem when loading a very large (6MB , all
> text)
> > CHM.
> >
> > It then crashes in loading the index.
>
> Strange. One would say that if you can load small (let's say 10KB file)
> you can a big one too. There shouldn't be any principial difference.

If I knew I would fix it. I suspect a problem in the tabel formatting routine, something like a var that is not reinitialized. However the problem drifts, and the exception is hard to trace back to the corruption that caused it.

> Or it does use some gradual allocation like f.e. TCollection dynamic
> arrays do?

It does. Actually the exception is IN TCollection, but it is hard to see what goes wrong. It is like 2000 entries into the table for the letter T or so.

marcov 26.03.2009, 17:51 @ marcov	CHM reader in DOS Post reply
	> If I knew I would fix it. I suspect a problem in the tabel formatting > routine, something like a var that is not reinitialized. However the > problem drifts, and the exception is hard to trace back to the corruption > that caused it. (I should have mentioned that it does this too in 64-bit mode, where it can allocate +/- 6GB, so it is not memory fragmentation or the like)

Rugxulo Usono, 01.04.2009, 13:27 @ marcov	CHM reader in DOS Post reply
	> (I should have mentioned that it does this too in 64-bit mode, where it > can allocate +/- 6GB, so it is not memory fragmentation or the like) Do you routinely use that much RAM (besides for maybe extra caching)?? Don't forget that we used to have HDs smaller than that!!!

marcov

01.04.2009, 23:39

@ Rugxulo

CHM reader in DOS

Post reply

> > (I should have mentioned that it does this too in 64-bit mode, where it
> > can allocate +/- 6GB, so it is not memory fragmentation or the like)
>
> Do you routinely use that much RAM (besides for maybe extra caching)??
> :-|

Not currently. I had clusters of memory databases in a previous job though (several machines, 3GB each, and then a machine that would combine the subqueries from the data machines). At that time 64-bit was too difficult though, and big DIMMs were too expensive. Nowadays you would simply chuck 16GB in a Eur 499 64-bit machine and be done with it.

We had the luck that while we had to do queries in any direction (hence the memdatabase), there was a division in regions that was always used. So we splitted the dataset over such geographic divisions over several machines, and for statistics over all regions simply added up the numbers for the subqueries of the little machines. A lot of collegues had predicted doom and told us to use a "real" database, but this was lightning fast, and actually not that much work.

Currently my apps are typically 400-700MBish Some are bigger, but 1100MB working size is about max. If it is bigger, it is due to leaks. But some of them have 100MByte/s (2 GBit lines, though not entirely full) of image throughput, the queues of memory buffers for the cameras, and the image-queue that must be written to disk alone eat a lot.

> Don't forget that we used to have HDs smaller than that!!!

So? I have had 10MB HDs, but that never stopped me from using more than 10MB of ram either.

In one of my apps I have pictures of 4096x7000x8bpp which are 28MB each. I couldn't even fit that on such HD. (which actually wasn't my first. My first was 40MB, but later I got 10MB discs in a second machine. It was cheap because it was MFM and nobody wanted it anymore)

Rugxulo

Usono,
02.04.2009, 00:16

@ marcov

CHM reader in DOS

Post reply

> > > (I should have mentioned that it does this too in 64-bit mode, where
> it
> > > can allocate +/- 6GB, so it is not memory fragmentation or the like)
> >
> > Do you routinely use that much RAM (besides for maybe extra caching)??
> > :-|
>
> Not currently. I had clusters of memory databases in a previous job though
> (several machines, 3GB each, and then a machine that would combine the
> subqueries from the data machines). At that time 64-bit was too difficult
> though, and big DIMMs were too expensive. Nowadays you would simply chuck
> 16GB in a Eur 499 64-bit machine and be done with it.

I'm not saying it isn't possible to use tons and tons of memory, just that most (and I do mean most) people really really don't need to use ridiculous amounts. Sure, I could run several OSes at once in separate VMs and use 16 GB (if I had that much), but I don't really need (or want) to do that.

> Currently my apps are typically 400-700MBish Some are bigger, but 1100MB
> working size is about max. If it is bigger, it is due to leaks. But some
> of them have 100MByte/s (2 GBit lines, though not entirely full) of image
> throughput, the queues of memory buffers for the cameras, and the
> image-queue that must be written to disk alone eat a lot.

A lot of RAM usage is just caching for extra speed. As processors get faster, you'd think that would go down, but for some reason, every x86 cpu has "gotchas" where "you can't do this and this, such and such must be aligned, and blah blah is slow unless you pair it with this and that". (It must be super hard to design an easy-to-program-for processor that is also fast.)

> > Don't forget that we used to have HDs smaller than that!!!
>
> So? I have had 10MB HDs, but that never stopped me from using more than
> 10MB of ram either.
>
> In one of my apps I have pictures of 4096x7000x8bpp which are 28MB each.

I almost expect you to say, "Widescreen monitors are cheap, and with HD becoming common as well as Blu-Ray, it makes no sense to scale down below 1024x768. Even 8bpp is a waste of the spectral bandwidth. This is not 1988 anymore."

> I couldn't even fit that on such HD. (which actually wasn't my first. My
> first was 40MB, but later I got 10MB discs in a second machine. It was
> cheap because it was MFM and nobody wanted it anymore)

Obviously you shouldn't stick to 10 MB of RAM. The whole point is that > 1 GB is enough to fit an entire OS in (and a semi-modern one, too!). So, in short, don't forget what a luxury it is and how much can fit in it. When you start believing the hype that "10 GB of RAM is nothing", then you really are doing something wrong (note that I'm mainly talking about code size, not data, since data can expand through GBs indefinitely while code won't usually surpass a few MB, if even).

marcov

02.04.2009, 10:35

@ Rugxulo

CHM reader in DOS

Post reply

> A lot of RAM usage is just caching for extra speed.

Well, everything above 12k in a machine with virtual memory. (one page stack, one page code, one page data)

> As processors get faster, you'd think that would go down, but for some > reason, every x86 cpu
> has "gotchas" where "you can't do this and this, such and such must be
> aligned, and blah blah is slow unless you pair it with this and that". (It
> must be super hard to design an easy-to-program-for processor that is also
> fast.)

In my case, the biggest limit is writing to disk. I have to rate limit the amount of that that goes to disk, since in an ordinary system, the HD/Windows can't store it. (100MByte/s is the theoretical max, but you can't keep that up sustained). Some customers that really wanted all images bought storage arrays. That helped.

> > In one of my apps I have pictures of 4096x7000x8bpp which are 28MB each.

> I almost expect you to say, "Widescreen monitors are cheap,

Wouldn't know. Never bought one. I'm sitting here behind my main (CRT) monitor. Would love a flat one, the money is there, but even top monitors can't match my current resolution (2048*1536) on this ole CRT.

I don't get the widescreen hype at all, except the marketing bit that for the same diameter, a widescreen screen has less pixels. IOW a 42cm diameter 4x3 has more pixels afaik than a 42cm widescreen one. (and 16x9 is worse than 16x10)

The number of times that I watch fullscreen video on my computer monitor is a couple of times a year, while I work behind it every day.

> Even 8bpp is a waste of the spectral bandwidth. This is not 1988
> anymore."

????

> > I couldn't even fit that on such HD. (which actually wasn't my first.
> My
> > first was 40MB, but later I got 10MB discs in a second machine. It was
> > cheap because it was MFM and nobody wanted it anymore)
>
> Obviously you shouldn't stick to 10 MB of RAM. The whole point is that > 1
> GB is enough to fit an entire OS in (and a semi-modern one, too!).

Well, that limit is not hard, and shifts with time. There have been people making the same argument for 4kb, 64kb, 640kb, 16MB, 64MB, 512MB etc.

I'd put the number on 2GB. Unless you use Vista, then go to the next switch.

Without VMs or specially memory hungry programs, I have enough with 2GB. 1GB is simply to little if you use GNU tools, since I saw GNU LD use 1.6GB to use a 6MB app. It is quite inefficient.

> GBs indefinitely while code
> won't usually surpass a few MB, if even).

My main app where I spend every working hour on, is +/- 1.5-2MB. (made with Delphi 2006)

The app where I spend every free hour on (FPC) is about 2MB. (the main compiler binary. It is significantly bigger under 64-bit though)

Rugxulo

Usono,
02.04.2009, 21:19

@ marcov

big RAM / 64-bit / etc.

Post reply

> In my case, the biggest limit is writing to disk. I have to rate limit the
> amount of that that goes to disk, since in an ordinary system, the
> HD/Windows can't store it. (100MByte/s is the theoretical max, but you
> can't keep that up sustained). Some customers that really wanted all
> images bought storage arrays. That helped.

SSDs are too expensive but supposedly very quiet, low power, and fast (except for sequential reads?). Do you have any yet? You seem to keep abreast of that kind of stuff. (I may have asked you this already in another thread, but I forget honestly. But it sure sounds familiar.)

> The number of times that I watch fullscreen video on my computer monitor
> is a couple of times a year, while I work behind it every day.

I do agree that DVD playback is mostly a useless gimmick (esp. for low-power laptops). Even moreso Blu-Ray. And not much other reason for widescreen that I can think of (for "normal" users like myself).

> > Obviously you shouldn't stick to 10 MB of RAM. The whole point is that >
> 1 GB is enough to fit an entire OS in (and a semi-modern one, too!).
>
> Well, that limit is not hard, and shifts with time. There have been people
> making the same argument for 4kb, 64kb, 640kb, 16MB, 64MB, 512MB etc.

I don't think anybody ever said 4k was enough for anything! ;-)

As for the other numbers, blame seems to lie with either Intel or MS. (I actually read today, although highly doubt, that it was IBM's fault for 640k although MS had to push hard else IBM wanted 512k !!)

> I'd put the number on 2GB. Unless you use Vista, then go to the next
> switch.

I'm on Vista with 1 GB, which seems to work fine, but I'm used to low RAM DOS software, plus my (integrated / shared) video card sucks (and I disabled desktop composition), so I guess the latter doesn't waste much RAM (thankfully).

> Without VMs or specially memory hungry programs, I have enough with 2GB.
> 1GB is simply to little if you use GNU tools, since I saw GNU LD use 1.6GB
> to use a 6MB app. It is quite inefficient.

I guess you mean building something big like FPC. Obviously for my wimpy attempts at using GCC/DJGPP, it's never gotten that high (mostly because the OS won't allow it, heh). I still say you should try building the "Gold" (ELF) linker sometime or get one of the other FPC devs to send it to you (or tell you how it works for them, etc).

> > GBs indefinitely while code
> > won't usually surpass a few MB, if even).
>
> My main app where I spend every working hour on, is +/- 1.5-2MB. (made
> with Delphi 2006)
>
> The app where I spend every free hour on (FPC) is about 2MB. (the main
> compiler binary. It is significantly bigger under 64-bit though)

I still feel AMD64 is still a toy for (almost all) people. I'm not saying it isn't useful in the right hands, but it will take time.

P.S. Screwing around with CDlinux CE 0.9.2 (live CD) right now, doesn't seem any faster (or slower) with DOSEMU (not included by default). And of course DOSBox is still (fairly) dog slow and WINE seems to only somewhat work for DOS stuff (no surprise there). Heck, they even had to roll back the included WINE version due to instabilities. But it all overall seems to work nicely for the very basics. BTW, still haven't heard if you were able to build DOSEMU for FreeBSD yet (no pressure). ;-)

marcov

04.04.2009, 15:13

@ Rugxulo

big RAM / 64-bit / etc.

Post reply

> > In my case, the biggest limit is writing to disk. I have to rate limit
> the
> > amount of that that goes to disk, since in an ordinary system, the
> > HD/Windows can't store it. (100MByte/s is the theoretical max, but you
> > can't keep that up sustained). Some customers that really wanted all
> > images bought storage arrays. That helped.
>
> SSDs are too expensive but supposedly very quiet, low power, and fast
> (except for sequential reads?).

Well, there are several levels here. Sufficient to say that the recent "consumer" SSD are not what you want except for netbooks.

The "real" ones are very expensive Eur 800-1000+.

For the work situation I mentioned above, SSD is too expensive, for that price you also have drive arrays. Moreover, specially for the ones where we have performance bottlenecks (IOW save a lot), we need room.

I did look into buying a SSD for my private entertainment. Disk is a major bottleneck in FPC building (not that it is annoying, but just for fun), and in general any compiling. However the consumer devices didn't top harddisks, and the enterprise ones are to expensive. Better wait some years.

> > is a couple of times a year, while I work behind it every day.
>
> I do agree that DVD playback is mostly a useless gimmick (esp. for
> low-power laptops). Even moreso Blu-Ray. And not much other reason for
> widescreen that I can think of (for "normal" users like myself).

Well, the monitor part annoys me more than an unused BR engine on the videocard. Why? It is fun to be able to play them, but it is a rare circumstance, and I don't want to mutilate somehting I look at every day for the doubtful benefits of having "no stripes" that one time I watch video.

> > Well, that limit is not hard, and shifts with time. There have been
> people
> > making the same argument for 4kb, 64kb, 640kb, 16MB, 64MB, 512MB etc.
>
> I don't think anybody ever said 4k was enough for anything! ;-)

Yes they did, when the C=64 came out.

> As for the other numbers, blame seems to lie with either Intel or MS. (I
> actually read today, although highly doubt, that it was IBM's fault for
> 640k although MS had to push hard else IBM wanted 512k !!)

Not really. Mac have similar limitations. The 640k barrier was actually ok and visionary for quite a while. The problem is more that most people that hit it, got into PCs rather late in that cycle (1980-1994, the dos golden age)

> > I'd put the number on 2GB. Unless you use Vista, then go to the next
> > switch.
>
> I'm on Vista with 1 GB, which seems to work fine, but I'm used to low RAM
> DOS software, plus my (integrated / shared) video card sucks (and I
> disabled desktop composition), so I guess the latter doesn't waste much
> RAM (thankfully).

Brave :-)

> > Without VMs or specially memory hungry programs, I have enough with
> 2GB.
> > 1GB is simply to little if you use GNU tools, since I saw GNU LD use
> 1.6GB
> > to use a 6MB app. It is quite inefficient.
>
> I guess you mean building something big like FPC. Obviously for my wimpy
> attempts at using GCC/DJGPP, it's never gotten that high (mostly because
> the OS won't allow it, heh).

It is if you try to get the binaries as small as possible.

> I still say you should try building the
> "Gold" (ELF) linker sometime or get one of the other FPC devs to send it
> to you (or tell you how it works for them, etc).

They see Ian Lance Taylor's msgs on comp.compilers, just like I do.

> > The app where I spend every free hour on (FPC) is about 2MB. (the main
> > compiler binary. It is significantly bigger under 64-bit though)
>
> I still feel AMD64 is still a toy for (almost all) people. I'm not saying
> it isn't useful in the right hands, but it will take time.

I took the plunge in february. Put in a new HD, and decided to reinstall Linux instead of moving it (the old one was upgraded twice already). I installed the 64-bit version as the "main" linux (still have 32-bit in a VM)

> BTW, still haven't heard if you were
> able to build DOSEMU for FreeBSD yet (no pressure). ;-)

Hmm. I have to boot freebsd anyway this weekend. Will see if I can do anything.

Rugxulo

Usono,
04.04.2009, 17:21
(edited by Rugxulo, 04.04.2009, 18:01)

@ marcov

big RAM / 64-bit / etc.

Post reply

> Well, there are several levels here. Sufficient to say that the recent
> "consumer" SSD are not what you want except for netbooks.
>
> The "real" ones are very expensive Eur 800-1000+.

I hear Intel's are the best, currently.

> Better wait some years.

Unlikely. Maybe six months to a year, maybe more. But it's definitely hit mainstream and is heading towards us. Then again, so is x86-64 (and I don't know what to do about that for DOS: I suppose dual mode .EXEs, DOSBox, DOSEMU, QEMU).

> Well, the monitor part annoys me more than an unused BR engine on the
> videocard. Why? It is fun to be able to play them, but it is a rare
> circumstance, and I don't want to mutilate somehting I look at every day
> for the doubtful benefits of having "no stripes" that one time I watch
> video.

Most people have standalone players anyways (well, DVD, not necessarily Blu-Ray although those have finally come down in price cheaper than the PS3). Did I mention that I'm so dumb that I accidentally rented a BD video a few months back despite having no BD player? (Had to go back and exchange it, doh!) :-D In my defense, the packaging looks very very similar (and I just wasn't expecting that to be an issue, I'm so "behind the times", lol).

> > > Well, that limit is not hard, and shifts with time. There have been
> > people
> > > making the same argument for 4kb, 64kb, 640kb, 16MB, 64MB, 512MB etc.
> >
> > I don't think anybody ever said 4k was enough for anything! ;-)
>
> Yes they did, when the C=64 came out.

I thought the C64 had 64k? (Okay, too lazy to look it up, I never used one, but still ...) Even the VIC-20 had more than its claimed 2k, I think.

> > As for the other numbers, blame seems to lie with either Intel or MS.
> (I
> > actually read today, although highly doubt, that it was IBM's fault for
> > 640k although MS had to push hard else IBM wanted 512k !!)
>
> Not really. Mac have similar limitations. The 640k barrier was actually ok
> and visionary for quite a while. The problem is more that most people that
> hit it, got into PCs rather late in that cycle (1980-1994, the dos golden
> age)

The original IBM PC supposedly came with anywhere from 16k to 64k. And Gordon Letwin (of MS fame) blames Compaq (exclusive 386 rights initially) and IBM (already promised 286 support) for delaying OS/2 32-bit for way too long. MS wanted to skip the 286 and jump to the 386, but IBM refused. So they got started way late. Also, they thought beating the 640k limit would make OS/2 1.x sell like hotcakes, but DOS extenders took that market away. Plus, Win 3.0 was a hit, and IBM politics kicked them out for refusing to make OS/2 exclusively. (See here for the actual post, I'm just weakly paraphrasing.)

> > > I'd put the number on 2GB. Unless you use Vista, then go to the next
> > > switch.
> >
> > I'm on Vista with 1 GB, which seems to work fine, but I'm used to low
> RAM
> > DOS software, plus my (integrated / shared) video card sucks (and I
> > disabled desktop composition), so I guess the latter doesn't waste much
> > RAM (thankfully).
>
> Brave :-)

The video card only uses 64 MB of shared memory. The Windows Experience Index (or whatever dumb name they call it) rates it lowest of all the pieces, so that's my score (2.4 or so, not very good). Actually it used to be a little bit higher, so I blame some OS or driver upgrade (go figure).

Processor: 4.6
Memory: 4.5
Graphics: 3.1
Gaming graphics: 2.4
Primary hard disk: 4.9

(And BTW, they've already changed/increased the scale in Windows 7, so basically it almost doesn't even make sense!!)

"New hardware detected (huh??) Your Windows Experience Index needs to be refreshed (oh joy)." :-|

EDIT: Graphics is now 3.0. Hooray. :rotfl:

EDIT #2: Disabled antivirus real-time scan, swapped power config to High Performance, closed all apps, and it changed to: 4.6, 4.5, 3.2, 2.4, 4.9 (and even tried again with "desktop composition" enabled, no difference ... note that this is DX10, not 10.1).

EDIT #3: Confused about some things, here's what it says:

NVIDIA GeForce Go 6100
Approx. Total Memory: 281 MB
Current Display Mode: 1280x800 (32bit) (60Hz)
DirectX Version: DirectX 10
DxDiag 6.00.6001.18000 32-bit Unicode Copyright (c) 1998-2006 Microsoft Corporation. All rights reserved.

The 281 is dubious since I think BIOS allows me to select a different max. amount of "shared" memory (min. 64 MB, I thought). It says DX 10 (aka, 10.0, I assume) despite the 6.00.6001.18000 (which Wikipedia says is 10.1). The 2006 copyright would indicate 10.0, but I dunno. I'm pretty sure my XP machine will say 9.0c or something like that (so I assume it would explicitly say 10.1 if my card supported it, which I don't think all cards do, even if they were approved for 10.0).

Anyways, for normal everyday use I disable desktop composition (which disables Flip3d, boo freakin' hoo) just because UAC took at least 5 secs. to recover (fully blank screen!) each time it was invoked. That was just stupid, esp. since I didn't need it. (Silly Sidebar widget says I have 53% RAM used right now. It doesn't typically go too high for me, but I'm not really hardcore in that way. VMs are typically the greediest.)

> > > Without VMs or specially memory hungry programs, I have enough with
> > 2GB.
> > > 1GB is simply to little if you use GNU tools, since I saw GNU LD use
> > 1.6GB
> > > to use a 6MB app. It is quite inefficient.
> >
> > I guess you mean building something big like FPC. Obviously for my
> wimpy
> > attempts at using GCC/DJGPP, it's never gotten that high (mostly
> because
> > the OS won't allow it, heh).
>
> It is if you try to get the binaries as small as possible.

Not for GCC. -Os for them is even faster / lighter than -O2 (although -O1 is recommended for best speed / RAM usage if you need at least some optimizations). Besides, don't forget BinUtils 2.17+ have --reduce-memory-overheads (for slower but less RAM used methods previously utilized).

> > I still say you should try building the
> > "Gold" (ELF) linker sometime or get one of the other FPC devs to send
> it
> > to you (or tell you how it works for them, etc).
>
> They see Ian Lance Taylor's msgs on comp.compilers, just like I do.

But have they tried it? And if not, why not? :-)

> > BTW, still haven't heard if you were
> > able to build DOSEMU for FreeBSD yet (no pressure). ;-)
>
> Hmm. I have to boot freebsd anyway this weekend. Will see if I can do
> anything.

I didn't mean you have to, just curious if somebody knew if it would build there or not. (The DOSEMU docs were very inconclusive. I guess somebody must've tried previously but not recently.)

P.S. Tran's Timeless demo (DOS, w/ .ASM srcs) runs perfect in DOSEMU, and the Win32 SDL port runs perfect in WINE. (But I didn't have GCC, so I couldn't test the GNU/Linux port, go figure).

DOS386

05.04.2009, 04:27

@ Rugxulo

big problem ??? RAM / 64-bit / etc.

Post reply

> Unlikely. Maybe six months to a year, maybe more. But it's definitely hit
> mainstream and is heading towards us. Then again, so is x86-64 (and I
> don't know what to do about that for DOS

IIRC DOS does work on xxx86-64 :clap: ... or oven better, don't throw away your "old" Pentium4-xxx32 :-P

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

marcov

06.04.2009, 10:04

@ DOS386

big problem ??? RAM / 64-bit / etc.

Post reply

> IIRC DOS does work on xxx86-64 :clap:

How so? Once booted into 64-bit mode, afaik real mode is out of the question, since prefix 66 and 67 then refer to 32-bit mode instead of 16.

If you mean on a x86_64 capable machine, except for the very rare EFI ones (that have no BIOS), it will probably work (and I in fact I booted freedos based motherboard CDs under them).

Of course it is yet a newer generation, and probably some backwards compat was killed.

> ... or oven better, don't throw away your "old" Pentium4-xxx32 :-P

I never had one.

DOS386

07.04.2009, 04:32

@ marcov

big problem ??? RAM / 64-bit / etc.

Post reply

> > IIRC DOS does work on xxx86-64 :clap:
> How so?

See below.

> Once booted into 64-bit mode, afaik real mode is out of the question

So simply don't enable the 64-bit long mode ;-)

> If you mean on a x86_64 capable machine, except for the very rare EFI ones
> (that have no BIOS)

Silly but might be possible to "fix"

> in fact I booted freedos based motherboard CDs under them

Self-answer :-)

> > ... or oven better, don't throw away your "old" Pentium4-xxx32 :-P
> I never had one.

Joined FP project very recently, and never had less than 64-bit ? :confused:

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

marcov 07.04.2009, 13:24 @ DOS386	big problem ??? RAM / 64-bit / etc. Post reply
	> > > ... or oven better, don't throw away your "old" Pentium4-xxx32 > > I never had one. > > Joined FP project very recently, Recently? 1998. > and never had less than 64-bit ? > Sure, just never had a Pentium-4.

Rugxulo Usono, 07.04.2009, 13:42 @ marcov	big problem ??? RAM / 64-bit / etc. Post reply
	> ? and never had less than 64-bit ? > > > > Sure, just never had a Pentium-4. I've got one, want me to test any specific benchmarks for you? Or you can turn on a noisy space heater and run a PIII running Vista next to it for the same effect. (I keed I keed, it's not that bad.)

marcov

06.04.2009, 09:53

@ Rugxulo

big RAM / 64-bit / etc.

Post reply

> > Better wait some years.
>
> Unlikely. Maybe six months to a year, maybe more. But it's definitely hit
> mainstream and is heading towards us. Then again, so is x86-64 (and I
> don't know what to do about that for DOS: I suppose dual mode .EXEs,
> DOSBox, DOSEMU, QEMU).

I don't know. E.g. the intel ones haven't become that much cheaper. Sure, there are now cheaper knockoffs, but the benchmarks show they don't hold up to an off-the-shelf HD.

> Most people have standalone players anyways

Indeed, and the BR thing is a matter of time I guess.

> I thought the C64 had 64k? (Okay, too lazy to look it up, I never used
> one, but still ...) Even the VIC-20 had more than its claimed 2k, I
> think.

I'm also to lazy to lookup. vic-20, C16 or PET. They were the "older" users of the computer club.

> > hit it, got into PCs rather late in that cycle (1980-1994, the dos golden
> > age)
>
> The original IBM PC supposedly came with anywhere from 16k to 64k. And
> Gordon Letwin (of MS fame) blames Compaq (exclusive 386 rights initially)
> and IBM (already promised 286 support) for delaying OS/2 32-bit for way

(snip, OS/2 vs WIndows)

I don't agree entirely with this. Some stuff is true (IBM's rigidity and attempts at control), but the main problem I think is that it happened at a time where every so an so many months, the number of computer users doubled, and that made the market very fluid.

> Anyways, for normal everyday use I disable desktop composition (which
> disables Flip3d, boo freakin' hoo) just because UAC took at least 5
> secs. to recover (fully blank screen!) each time it was invoked. That was
> just stupid, esp. since I didn't need it. (Silly Sidebar widget says I
> have 53% RAM used right now. It doesn't typically go too high for me, but
> I'm not really hardcore in that way. VMs are typically the greediest.)

I downgraded to XP with this (work) one. (core 1 laptop, 1GB of which 320MB is taken by the video card. Always!)

But that in retrospect was because of certain problems we had with instability that in the end turned out to be a bios problem (which only occured when the amount of memory was expanded). Vista probably used the higher memory more intensively than XP.

The memory corruption would also corrupt windows installs over time, making the issue even harder to detect. After close to an year(!), the vendor came with a bios update, and the laptop was suddenly stable.

> > It is if you try to get the binaries as small as possible.
>
> Not for GCC. -Os for them is even faster / lighter than -O2 (although -O1
> is recommended for best speed / RAM usage if you need at least some
> optimizations). Besides, don't forget BinUtils 2.17+ have
> --reduce-memory-overheads (for slower but less RAM used methods previously
> utilized).

GCC doesn't support smartlinking that way.

> But have they tried it? And if not, why not? :-)

No. Time, interest.

> > Hmm. I have to boot freebsd anyway this weekend. Will see if I can do
> > anything.
>
> I didn't mean you have to, just curious if somebody knew if it
> would build there or not.

It's an install for experimentation, no problem. Just didn't get around to it.

Rugxulo

Usono,
07.04.2009, 00:43

@ marcov

big RAM / 64-bit / etc.

Post reply

> > Most people have standalone players anyways
>
> Indeed, and the BR thing is a matter of time I guess.

So far (as least in the U.S.) they still make everything for both standard DVD and Blu-Ray (at least according to all the tv ads for movies that I see).

> (snip, OS/2 vs WIndows)
>
> I don't agree entirely with this. Some stuff is true (IBM's rigidity and
> attempts at control), but the main problem I think is that it happened at
> a time where every so an so many months, the number of computer users
> doubled, and that made the market very fluid.

As opposed to now where everything is a big fracas due to too many competing technologies?

> > Anyways, for normal everyday use I disable desktop composition (which
> > disables Flip3d, boo freakin' hoo) just because UAC took at least
> > 5 secs. to recover (fully blank screen!) each time it was invoked.
> > That was just stupid, esp. since I didn't need it. (Silly Sidebar
> > widget says I have 53% RAM used right now. It doesn't typically
> > go too high for me, but I'm not really hardcore in that way. VMs
> > are typically the greediest.)
>
> I downgraded to XP with this (work) one. (core 1 laptop, 1GB of which
> 320MB is taken by the video card. Always!)

Hopefully you got a free downgrade (heh, dumb marketing bastards, we should all have that right)! Yikes about the video card although I've heard similar stories. Oh well. At least it looks pretty. ;-) (Couldn't you swap another card in there? Or is it blacklisted by your BIOS?)

> But that in retrospect was because of certain problems we had with
> instability that in the end turned out to be a bios problem (which only
> occured when the amount of memory was expanded). Vista probably used the
> higher memory more intensively than XP.
>
> The memory corruption would also corrupt windows installs over time,
> making the issue even harder to detect. After close to an year(!), the
> vendor came with a bios update, and the laptop was suddenly stable.

The latest BIOS update on mine changed the fan algorithm dramatically, so it makes a much quieter (but more static) sound than before (which was more of a rev up / rev down thing).

> > But have they tried it? And if not, why not? :-)
>
> No. Time, interest.

Uh, it's predicted to be 5 x faster. You can't afford not to try it!!

> > > Hmm. I have to boot freebsd anyway this weekend. Will see if I can do
> > > anything.
> >
> > I didn't mean you have to, just curious if somebody knew if it
> > would build there or not.
>
> It's an install for experimentation, no problem. Just didn't get around to
> it.

(Where's sol when you need him. He should be testing too!) ;-)