Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

NASM version 2.09 available | A86 and kernels (Announce)

posted by Rugxulo Homepage, Usono, 08.09.2010, 06:49

> > But yeah, it hasn't been developed since 2000, so it only supports SSE1
>
> That really doesn't bother me.
Nor me, but it just means he hasn't kept it up. Granted, I personally can't help but wonder if we've "jumped the shark" on x86, adding so many things (SSSE3, SSE4.1, XOP, AVX) in addition to obvious things like FPU, MMX, SSE2, AMD64. You're right when you say A86 is dated. It's still good for lots of uses, though I don't personally use it much anymore.

> > > (Actually, we don't even know whether A86 really is self-compiling.)
> >
> > A86 is (allegedly) self-compiling, if you believe the author.
>
> That's what I said. Although I don't really doubt that it is
> self-compiling: unless we have the source, we can't know for sure.
TMA (abandoned) mimics A86 somewhat, but I don't know offhand (without trying, and I'm on the wrong computer) whether it builds with A86. Also, Octasm was originally written in A86 but now (only) assembles itself.

> > Well, it's still a derivative.
>
> The kernel still is. But what if I get to a point where I've rewritten
> everything? Could I release it as my work? Would anyone even care to check
> the code? Probably not. (Don't misconstrue this. I don't want to steal any
> of Mike's code. Rewriting everything just really is a possibility.)
Yes, obviously I didn't mean to imply legalities. Yes, I personally think you could do whatever if you rewrite it. But I'm no lawyer (and despise legalese).

> > The next Y2K problem.
>
> Oh you. I wasn't aiming for that, 38 just is a nice number.
A lot can happen in 28 years! Looking at the past ten years, we would've never guessed computers would change so much.

> > it's pretty much "dead" legally, IMHO.
>
> Like about 95% of DOS software, only for that we don't get the source at
> all. So it was pretty nice of them to give us even "semi-free" source code,
> don't you think?
Yes, of course, I just hate that it has a license which apparently "sucks", but nobody is around to change it or even discuss it officially.

> They're Linux zealots. They can't accept that there might be cases were
> accepting binaries instead of recompiling everything might be better, even
> if these binaries are just for a deprecated, foreign architecture no one
> supports.
It's such a bullcrap pretext. They have binary blobs, yet somehow FreeDOS is tainted?? Humbug. 99% of Linux distros aren't even FSF-labeled "free".

> Solution: Change people. Or use a workaround, for example, provide a
> free-free-free compiler for them. (Extend gcc? Use some existing DOS
> compiler with GPL or a really free license?)
Some of the kernel devs probably knows more here than me what would need to be done. I don't honestly even remember what memory model the kernel uses. In theory, we could probably easily convert it from (non-portable) C to (non-portable) assembly for NASM, I guess. WDIS is our friend. ;-)

BCC/Dev86 is a pain to compile, so that doesn't help either. And it's pretty much the only GPL 16-bit C compiler that I know of.

> > And no, VFAT isn't in FreeDOS proper,
> > so that can't be a good reason against it.)
>
> VFAT is in Linux, so what?
No, I think they removed it after the TomTom incident. Last I heard, they only write the LFN, not the SFN now, but I haven't tested. (Such a dumb patent, esp. since it was for FAT, which MS hates and deprecates anyways.)

> Seems somewhat extreme. As pedant, I believe a one-pass compiler wouldn't
> be better than a multi-pass one. Maybe bad OW configuration (use "-os" or
> so to optimize for size)? There might also be more/better run-time checks
> in OW.
I didn't mean it was "better", just smaller, and obviously I couldn't remember if that was before or after UPXing (apparently only after).

> > It has something to do with size, I never looked to closely. Yes, I
> know,
> > it shouldn't be an issue, but it is. Blame the lame-o C compilers.
>
> There's at least one PUSH imm opcode in one of the (NASM) source files.

Still?? I think they fixed that. What file / version are you looking at? But again, there are very few 8086 users still. I think Mike Chambers runs DR-DOS, and I told him to try a newer FreeDOS, and it might've worked. Perhaps SYS from 2038 fixed it, I don't remember.

> Given that LOADFIX is absolutely useless on true 8086 and 80186 processors
> (they only address 1024 KiB of memory, there's no HMA or A20) you selected
> a bad example ;-)
Well, the point was that they couldn't share a single shell between 100% of all users. Even if 8086 users can't use it, others can (though I never need it, honestly, and originally LOADFIX for FreeDOS was a separate util anyways, so it's no dealbreaker).

> As I said, the FreeCOM version I examined (0.84-pre XMS_Swap, 2005-07-20)
> really does have 8086-incompatible code. (Only seen it in an XMS call
> function though, and XMS doesn't exist on true 8086 machines, does it?
> Still bad enough.)
They had both XMS and KSSF/VSPAWN variants, obviously preferring the former.

Oops, forgot that SourceForge still only has 0.82pl3. (God, they are so desparate for more volunteers or really stubborn, I dunno)! 0.84 had "too much added" without review, says Eric, including an obscure bug/hang, and even Blair never updated it "yet again" like he originally claimed (swapping, oh well).

> > I haven't rebuild FreeCOM lately.
>
> Either way, fixing the broken 8086 compatibility should be a very easy
> task.
I'm not even sure it builds with OpenWatcom, I forget. I know I had some minor trouble with SUPPL, so I just used a prebuilt lib for that. It's not that complicated, but it could surely be much much easier. (Centroid's DJGPP/386 shell is less compatible to MS-DOS but a thousand times easier to build. But again there was a stupid flaw where mkdir pulls in ctime unnecessarily, bloating it by several useless kb. I never properly patched that for DJGPP two years ago, and they didn't seem to care anyways. Oh well. Too much to do! I guess I'm too useless and spastic and ambitious, sorry guys.)

> > I dunno, everything's just
> > so disorganized, too much to do, not enough volunteers, etc.
>
> I fondly regard Robert's mail asking about how FreeDOS 1.1 tasks are
> organized. And Pat's very inexplicit answer... "assessing what needs to be
> done in order to scope out the effort". Heheheheheh.
Four years (last Friday) since 1.0 release. Not a big deal, DOS ain't high priority. But yeah, we could use a bit better organization and a few volunteers. ;-) I still say we should (also) focus on DOS emulation, which is "teh futurez!"

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22649 Postings in 2111 Threads, 402 registered users, 901 users online (1 registered, 900 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum