64 bit Forths out there?

[Cecil Bayona]

I'm looking for a 64 bit Forth for analyzing and doing some x64
assembler learning. The Forth needs the following features;

Written in x64 assembler for Windows or generates 64bit assembler code
for Windows with a "see" word available so I can see what was generated.

I found two 64 bit Forth for Linux forthX64, and sixtyForth which could
be useful but it would be better if they were available for Windows
which they are not.

I have iForth rev 6 which is written in Forth with a Meta-compiler but I
believe it generates x64 assembler code and available for Windows.

Are any others out there available? Especially one written in assembler
for Windows if possible?

Looking at the x64 programming model I'm surprised that so few 64 bit
Forths are available, even if one doesn't need such a big cell the extra
registers and addressing model of x64 assembler is so much better for
creating a fast Forth, all the extra registers would come in handy as
pointer to the user page, pointer to locals, etc that would make a
compiler way more efficient.

Thanks

--
Cecil - k5nwa

[Paul Rubin]

Cecil Bayona <cba...@cbayona.com> writes:
> Looking at the x64 programming model I'm surprised that so few 64 bit
> Forths are available, even if one doesn't need such a big cell

My guess is that most 64 bit cpus have enough address space and cpu
cycles that people usually program them in HLL's rather than assembler
even if it sacrifices some of the hardware capabilities. There's lots
of Forths (you named some) that run fine on 64 bit machines or could
easily be made to do so. They just aren't written in asm, because
relatively few 64 bit programs are.

I use gforth on 64 bit x86 and it works fine, though it's written in C
and doesn't compile to machine code. It does have an x64 disassembler
if you want to use that for something.

[Cecil Bayona]

What I'm really interested is a Forth that generates x64 machine code,
so I can look at the generated code, it could be written in C or
something else that is OK.

I have 64 bit C compilers but they tend to optimize so much that often
the code can't be duplicated in Forth unless a horrendous amount of
optimizing is also done. I setup the Tcc 64 bit C Compiler as a last
resort, it doesn't optimize a lot but I would prefer a Forth compiler
generating simpler code if possible.

It doesn't have to be a great Forth, it's going to be used as a learning
experience not as a practical tool.
--
Cecil - k5nwa

[anon]

In article <p6l7vq$qv0$1...@dont-email.me>, cba...@cbayona.com says...

> It doesn't have to be a great Forth, it's going to be used as a learning
> experience not as a practical tool.

You may not want to hear this (I didnt when I lost jack and had to learn it myself)
but you may be better off starting with 32 bit to aim for initially.

To get an x86_64 running you need to jump through a wide array of
complex hoops. ( someone joked a few weeks ago that I'm designing my own
CPU just because I'm too lazy to learn how to program an intel one - he may be
right.)

I've got as far as running up to 32bit protected mode myself and stopped there
to work on some software and the hardware. I'm not convinced I want to go
further with intel at all in assembler. A nice forth based Intel CPU control
package to fire them up would be a nice project for someone with months to burn
though.

I strongly recomend you get the (intel) docs and have a good read before
getting too involved so you can see just how annoying it is.
(Or fun if thats what floats your boat)
Just choosing a memory design could take quite a while.

You might want to take a look at ben lunts system book as well.
That may save you some time with some of the traps and maps.
(And really tell you how annoying it can be.)

If you're not decided on an assembler I found NASM to be pretty good.
Actually bashing out a forth once you can tame the beast isnt the hard part.

--

john

=========================
http://johntech.co.uk
=========================

[Cecil Bayona]

Thanks for the response.

I started looking for some decent books for x64 assembler and there is
next to nothing that doesn't cost an arm and a leg (I'm on a limited
budget) so I came to the conclusion that since I already own several
nice 32 bit assembler books that I would need to start there and then
pick up the differences later after I feel comfortable with 32 bit
assembler.

As far as the Intel books, I have a copy, several 500 to 600 page books
with no end to the minutia that is why I started looking for a decent
book to skip all the noise and concentrate on the important stuff.

However I though that getting a Forth compiler that generates x64 code
could be useful while I read up on 32bit assembler. I have several 32bit
Forth that generate machine code with facilities "see" to look at the
generated code for small words and see it all working out, that I why I
was hoping for a Forth compiler that generates 64bit assembler code.

I have a computer setup with VisualASM, VisualCode, and Visual Studio
for 32bit and 64 bits along ttc in 32bits and 64bit flavors and several
x64 debuggers to look at the resulting code. Included in there is both
MASM and NASM assemblers. But I prefer to use a Forth compiler as I can
see small words and what it generates as examples.

--
Cecil - k5nwa

[Cecil Bayona]

Problem in paradise, it seems that iForth 64bits crashes under Windows10
64bit so now I stand as having no Forth compiler that generates x64
code. We will try again tomorrow and if doesn't work again I will try
Windows 7 64bit.


--
Cecil - k5nwa

[Anton Ertl]

Paul Rubin <no.e...@nospam.invalid> writes:
>I use gforth on 64 bit x86 and it works fine, though it's written in C
>and doesn't compile to machine code.

It's written mostly in Forth. The engine is written in vmgen and
compiles through C. Dynamic superinstructions (enabled by default)
have been described as compiling to machine code.

>It does have an x64 disassembler
>if you want to use that for something.

You need a somewhat recent snapshot to get the AMD64 disassembler
included with Gforth. Try
<https://www.complang.tuwien.ac.at/forth/gforth/Snapshots/current/gforth64.exe>.
I have read something about some Windows 10 incompatibility, but I
don't know if current snapshots are affected.

In Gforth 0.7 gdb is used for disassembly when present, but I doubt
that it is present in most Windows installations.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2017: http://euro.theforth.net/

[Anton Ertl]

Cecil Bayona <cba...@cbayona.com> writes:
>Written in x64 assembler for Windows or generates 64bit assembler code
>for Windows with a "see" word available so I can see what was generated.

In Gforth SEE shows the native code of primitives and something
approaching the source code for colon definitions. Use SEE-CODE to
see the native code of the dynamic superinstructions (for primitives
that are not relocatable and are therefore not integrated into dynamic
superinstructions, SEE-CODE does not show the native code). You may
want to use gforth-fast, which does not contain code for maintaining a
copy of the instruction pointer in memory.

>Looking at the x64 programming model I'm surprised that so few 64 bit
>Forths are available

There are a number of 64-bit Forths, and have been since at least
1995, but apparently the intersection of Forth, 64 bits, and Windows
is not needed.

[Paul Rubin]

an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> In Gforth 0.7 gdb is used for disassembly when present

Oh interesting, I didn't realize that. I only noticed that SEE shows
assembly code. Point taken regarding the other stuff.

[Paul Rubin]

Cecil Bayona <cba...@cbayona.com> writes:
> What I'm really interested is a Forth that generates x64 machine code,
> so I can look at the generated code, it could be written in C or
> something else that is OK.

Maybe you could look at something like GNU Lightning or Qhasm, or bits
of hand-written x64 asm code like the optimized crypto functions in openssl?

What is the goal of this project? Are there real differences between
32-bit and 64-bit x86 code that are giving you trouble?

[john]

> In article <9974b788-d90e-084b...@cbayona.com>, cba...@cbayona.com says...

>
> On 2/21/2018 8:42 PM, anon wrote:
>
>
> As far as the Intel books, I have a copy, several 500 to 600 page books
> with no end to the minutia that is why I started looking for a decent
> book to skip all the noise and concentrate on the important stuff.
>
> However I though that getting a Forth compiler that generates x64 code
> could be useful while I read up on 32bit assembler. I have several 32bit
> Forth that generate machine code with facilities "see" to look at the
>

Hi Cecil

Sorry - I wasn't clear on the info - The intel docs I was suggesting are
downloadable PDF files - There are a collection of them. They are heavy
reading but it is doable. If you cant find them I can put them online for you.
(I think thats allowed by intel)

There are also intel white papers you may wish to just scan
(Such as the 64 bit integer carry-less multiplication instruction introduced in 2010
- useful for AES calculation and other things.)
The first one you may find instructive might be
253665-sdm-vol-1.pdf - look on yahoo -
This details the basic architecture and operating modes of the x86_ia32 family

What I do is just scan over these PDF's when I'm taking a break to spot
things that may be useful later. If you did decide to learn the PC boot
and configuration procedure I'd suggest many of them are a must-have.
(as would be a book about the complications - hence my Fysos suggestion)

If you plan on skipping the boot process and designing under windows
you will avoid most of the complications but I'm not sure what if anything
you could learn from that. You may as well just do 32bit and leave it there
since you can just copy what is already out there.

Ben Lunts book isn't too expensive (I hear you on price however - I forked
out quite a bit for the Xilinx FPGA design book a while back - and it still stings)
If you hunt around there is a lot available on line. I advise anyone
never to skip on books - it always pays off in the end.

If it helps I hadn't done any Intel assembler for many years - and the book I
used to get back into it is "Programming the 8086/8088 by michael thorne.
It is MASM based but converting some examples to NASM also helped me
get back into the swing.

Thats off my shelves from 1986. - One good thing about the monstrous Intel
beast is that you can do that.... (perhaps the only good point but its there)
So dont imagine you need the latest most expensive books - amazon
sometimes has sales - I bought a couple of books on Z for 1penny each
to refresh myself with that.

You do still need to understand the architecture.though.
I'll leave it to those that have built a "microsoft forth" to advise on doing it
under windows - It isnt something I'd do but I'm glad others have.

For what its worth - my investigations last year revealed that 32bit designs
with wider options as "extensions" is perhaps the most efficient. Its just
an academic based conclusion right now but I think I'm right.

Dont be put off - think of it as writing a program - start simple and build up
and it can work out ok.

[Albert van der Horst]

In article <87tvu9e...@nightsong.com>,

ciforth is available in 64 bits linux and 64 bits windows incarnations.
They both are a single assembler source, where you can pick
the assembler you want.

It has an assembler inside but no disassembler. I didn't feel much need
because of the construction of the assembler, there is no guessing
about what code is generated.
For the 32 bit version there is a separate program ciasdis.
This assembler disassembler, was used to disassemble and reassemble
the first version of colorforth, sufficiently conspicuous that it was
ridiculed by Jeff Fox.
ciasdis has been forked for the Apple.

There is a huge example of assembly programming, because the floating
point is in source form in the library. The 32 bit assembler works
mostly for 64 bit too. All blocks of the fp except two are ?32+.

This illustrate which words are size dependant:
( -fp- FINIT FDEPTH WAIT L>F F@>L F>L ) CF: ?32 \ AvdH B6apr03
( -fp- FINIT FDEPTH WAIT L>F F@>L F>L ) CF: ?64 \ AvdH B6apr03

It is surprising how far you can get with knowledge about some
prefixes, but the write up about what prefixes are needed when is
still missing.
The 32 bit assembler is pretty well documented, even in the base forth.

https://github.com/albertvanderhorst/ciforth
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[Albert van der Horst]

In article <MPG.34f83e887...@news.aioe.org>,

anon <an...@example.com> wrote:
>In article <p6l7vq$qv0$1...@dont-email.me>, cba...@cbayona.com says...
>
>> It doesn't have to be a great Forth, it's going to be used as a learning
>> experience not as a practical tool.
>
>You may not want to hear this (I didnt when I lost jack and had to learn it myself)
>but you may be better off starting with 32 bit to aim for initially.
>
>To get an x86_64 running you need to jump through a wide array of
>complex hoops. ( someone joked a few weeks ago that I'm designing my own
>CPU just because I'm too lazy to learn how to program an intel one - he may be
>right.)

It was a kind of revelation, but once I understood the requirement of
128 bits alignment, there is not much difference between a 32 and 64 bit
Forth on Windows.
My code for e.g. OPEN-FILE is highlevel and the same for 32 and 64 bit.
My solution foregoes the need for local variables, almost mandatory
otherwise.

A a small amount of conditional code is inevitable in the actual calls:

CODE_HEADER({CALL]},{CALLCLOSE})

POP AX
XCHG SP, [PARS+ (CW*(PH_OFFSET)) ] ; Nieuwe stack.

_BITS64_({
MOV CX, [SP+(CW*(0))]
MOV DX, [SP+(CW*(1))]
MOV R8, [SP+(CW*(2))]
MOV R9, [SP+(CW*(3))]
})
CALL AX
XCHG SP, [PARS+ (CW*(PH_OFFSET)) ] ; Nieuwe stack.
_PUSH

The four move's are extra for 64 bits.
The indirect call is very similar. That's about it.

>
>I've got as far as running up to 32bit protected mode myself and stopped there
>to work on some software and the hardware.

I was at first intimidated by DLL's, but the usage in MS-Windows turns
out to be pretty straightforward.

<SNIP>

>If you're not decided on an assembler I found NASM to be pretty good.
>Actually bashing out a forth once you can tame the beast isnt the hard part.

I used NASM too, but fasm is superior in all respects.
nasm uses an external linker, fasm doesn't.
I found the cooperation with the linker the hardest part, and
not reliably reproducible between releases.
fasm builds my 32 and 64 bit linux forth's with a one liner.
I build and test 32 bits MS-windows Forth on linux, thanks to fasm.

https://github.com/albertvanderhorst/ciforth

I just tested all 6 versions (fasm gas nasm ) x ( 32 64) for linux
on my 64 bit linux. I'm sure that my fasm build instructions
work everywhere, about the others I'm not.

>john

Groetjes Albert

[m...@iae.nl]

Why don't you ask for support? If you officially acquired
iForth (any version), it is good for life-long free upgrades.

The latest release has no problems with Windows 10, given
recent hardware.

-marcel

[john]

> In article <p6m8vl$86v$1...@cherry.spenarnc.xs4all.nl>, alb...@cherry.spenarnc.xs4all.nl says...
>
Hi Albert

>
> It was a kind of revelation, but once I understood the requirement of
> 128 bits alignment, there is not much difference between a 32 and 64 bit
> Forth on Windows.

Thats actually nice to hear. I had assumed there would be more complications
doing forth (appart from the obvious extra regs etc)

> My code for e.g. OPEN-FILE is highlevel and the same for 32 and 64 bit.
> My solution foregoes the need for local variables, almost mandatory
> otherwise.
>

Once you have forth running there is no need for low level file stuff
I dont suppose. The temptation to assume assembler is always best
is an easy trap to fall into. I've made that mistake myself.

> A a small amount of conditional code is inevitable in the actual calls:
>
> CODE_HEADER({CALL]},{CALLCLOSE})
>
> POP AX
> XCHG SP, [PARS+ (CW*(PH_OFFSET)) ] ; Nieuwe stack.
>
> _BITS64_({
> MOV CX, [SP+(CW*(0))]
> MOV DX, [SP+(CW*(1))]
> MOV R8, [SP+(CW*(2))]
> MOV R9, [SP+(CW*(3))]
> })
> CALL AX
> XCHG SP, [PARS+ (CW*(PH_OFFSET)) ] ; Nieuwe stack.
> _PUSH
>
> The four move's are extra for 64 bits.
> The indirect call is very similar. That's about it.
>

I'm not experienced enough with modern intel to comment but it looks clean enough.
(Stack swapping is something I've been looking into recently by the way - I'm hoping
to have some on chip facilities for that. - I actually tried to make it my learning project
for the FPGA I'm learning on but I got stuck trying to get the BRAMS to initialise and
had to change tack. in order to progress- )

>
> I was at first intimidated by DLL's, but the usage in MS-Windows turns
> out to be pretty straightforward.
>

I must admit I panicked a bit when I wrote my first DLL but I was using FPC/Lazarus
and it's simple enough with that (it gets a bit more complex if you want to put forms
in the DLL but otherwise no problem) Oddly enough I never wrote one in my Delphi days.
.SO is easy enough too.

I hear what you say about fasm. When I looked around that was my first choice but
at the last minute something forced me to change to nasm. I dont recall what it was now
but I do have a note here that says switch to fasm at a later date. I think I was impressed
with the growing structured features of fasm.

My own interest in a forth for the PC is 2 fold:
1. I want it to prototype some of the more experimental language features I'm developing
for the new processor to see how they perform in reality.(I've done a few things but need to do more
when I can get a decent IDE running)
2. To be called from within the IDE for prototyping the end user programming interface
. (The IDE itself will initially be FPC/Lazarus)
This will involve DLL and other calls to a forth compiler initially.

The idea is to translate the IDE and all development to my new TIL when I get to the point
of actually having one. Making the core stuff work in forth should give me a leg up on building that.
I'm happy to use 32 or 64bit forth for any of that.

[Albert van der Horst]

In article <MPG.34f8d9e3...@news.aioe.org>,

john <jo...@example.com> wrote:
>> In article <p6m8vl$86v$1...@cherry.spenarnc.xs4all.nl>, alb...@cherry.spenarnc.xs4all.nl says...
>>
>Hi Albert

<SNIP>

>>
>> I was at first intimidated by DLL's, but the usage in MS-Windows turns
>> out to be pretty straightforward.
>>
>I must admit I panicked a bit when I wrote my first DLL but I was using FPC/Lazarus
>and it's simple enough with that (it gets a bit more complex if you want to put forms
>in the DLL but otherwise no problem) Oddly enough I never wrote one in my Delphi days.
>.SO is easy enough too.

I'm only talking about using DLL's, such as opening a cdrom tray, popping
up a window or getting at %COMSPEC%.
I'm still intimidated by writing a DLL, especially its file layout.
Maybe a programming environment helps, but still.

>
>--

[Mihail Maksimov]

> Written in x64 assembler for Windows or generates 64bit assembler code

http://fpauk.narod.ru/Win64FasmForth5.zip

cfa_AHEADER 0,"QBRANCH",QBRANCH
db 09h,0c0h ; or %eax,%eax
db 48h,8bh,45h,00h ; mov 0x0(%rbp),%rax

Replaced:

cfa_AHEADER 0,"QBRANCH",QBRANCH
or rax,rax
db 48h,8bh,45h,00h ; mov 0x0(%rbp),%ra

Assembler and disassembler can be taken
from the version for Linux

http://212.237.6.204:8008/Forth/Linux/LinuxSPF64/

[john]

> In article <p6msp7$b1k$1...@cherry.spenarnc.xs4all.nl>, alb...@cherry.spenarnc.xs4all.nl says...

>
>
> I'm only talking about using DLL's, such as opening a cdrom tray, popping
> up a window or getting at %COMSPEC%.
> I'm still intimidated by writing a DLL, especially its file layout.
> Maybe a programming environment helps, but still.
>

> Groetjes Albert

Assuming were on the same page - with fpc/laz its simple enough.
Just pass the path to your DLL by calling the "winows.loadLibrary()" function
This returns a pchar (string) which you identify to confirm the correct dll
then you can call its functions.

To create the DLL just label your first unit as "library "
then create the function used above to return a pchar using stdcall
put a few lines in to define the response string and your done.

When finished with the dll just free it.
As for getting the DLL to do things thats just straight up FPC programming.
I can paste an example of code if you want to see it..
How this would translate into assembler dont know.
As I say - poping windows from inside a DLL does take a little more effort
but I could probably dig out some code from an old Delphi book if it helped.
I dont need windows for my security apps so havnt done DLL windowing it in FPC
for all I know they may have made that easier these days.

Maybe doing it in lazarus could help to work it out for forth. FPC is compiled
after all.(You can look at the assembler code I guess)

[Cecil Bayona]

On 2/22/2018 1:10 AM, Anton Ertl wrote:
> Paul Rubin <no.e...@nospam.invalid> writes:
>> I use gforth on 64 bit x86 and it works fine, though it's written in C
>> and doesn't compile to machine code.
>
> It's written mostly in Forth. The engine is written in vmgen and
> compiles through C. Dynamic superinstructions (enabled by default)
> have been described as compiling to machine code.
>
>> It does have an x64 disassembler
>> if you want to use that for something.
>
> You need a somewhat recent snapshot to get the AMD64 disassembler
> included with Gforth. Try
> <https://www.complang.tuwien.ac.at/forth/gforth/Snapshots/current/gforth64.exe>.
> I have read something about some Windows 10 incompatibility, but I
> don't know if current snapshots are affected.
>
> In Gforth 0.7 gdb is used for disassembly when present, but I doubt
> that it is present in most Windows installations.
>
> - anton
>

Windows 10 is a pain, a lot of times with the major updates it breaks
application, usually installing them will fix the problems.

--
Cecil - k5nwa

[Cecil Bayona]

Just learning x64 assembler but I'm not familiar with 32 bit assembler
so I will start there. If any future project requires assembler I figure
I might as well is x64 specially in creating a Forth the extra register
can be a cause for major efficiency increase.

--
Cecil - k5nwa

[Cecil Bayona]

Tomorrow I will try to find how to access support, the error in Windows
10 is very annoying as is says nothing of use, if one tries to run the
Forth, it sits there for 10 seconds and then a screen pops up saying the
program failed to run, with no reason, I will send in the error logs
they provide some additional information.

--
Cecil - k5nwa

[Cecil Bayona]

I assume the compiler generates subroutine threaded code with
optimizations, I found your site but skimming through it I found no
reference to the output of the compiler. Without a SEE word it will make
it harder, as with my current compilers I can SEE a word and it displays
the code for it, which is what I want to do . iForth has a 64bit
Compiler with SEE and other debug works but right now it will not run
with the latest version of Windows 10.

Looking at this whole project I will need to start with 32bit compilers
which I have several that have SEE so I can see the generated code. My
current 32bit Forths, SwiftForth, MPE VFX, ntf2017 compilers have SEE
and other words to display the generated code.

--
Cecil - k5nwa

[Albert van der Horst]

In article <p6ol5h$rvm$1...@dont-email.me>,

Remember AMD invented the 64 bit Intel compatible architecture.
This is the definitive document:

AMD64 Architecture
Programmer's Manual
Volume 3:
General-Purpose and
System Instructions
Publication No. Revision Date
24594 3.20 May 2013

The number 24594 is important in finding this document back.
24592 is also of interest (Volume 1).

>
>--
>Cecil - k5nwa

[Albert van der Horst]

In article <p6omot$5iv$1...@dont-email.me>,

You assumed wrongly, It is a classical indirect threaded model.
There is a small paragraph in the first page about features.
The compiler is , ("compile,") . It is so small you may
have missed it.

ciasdis is the tool to look at ifyou want to disassemble.

optimisations are experimental.

>--
>Cecil - k5nwa

[Walter Banks]

On 2018-02-23 3:56 AM, Cecil Bayona wrote:

> Windows 10 is a pain, a lot of times with the major updates it breaks
> application, usually installing them will fix the problems.
>

I beg to politely disagree about w10. Every MS windows package we have
ever released starting in the 90's running under early windows releases
to current code will run under w10 just fine. The application excutables
are what I am executing nothing is rebuilt.

This is a record that is hard to equal under any other environment.

w..

[Paul Rubin]

Cecil Bayona <cba...@cbayona.com> writes:
> Just learning x64 assembler but I'm not familiar with 32 bit assembler
> so I will start there.

If you want to see how a real fanatic (I mean that in a good way)
programs x32 assembler, you might look at Michael Abrash's old books on
the subject. Look also at Agner Fog's optimization manuals at
agner.org.

[Cecil Bayona]

"We have ever release" sounds like you work with Microsoft but
unfortunately that is not the experience I noticed here, the worst
offender were the nVidia Drivers, they would often have to be
re-installed after a major upgrade, it got to the point that I would do
it automatically and not wait for problems.

The anti-virus would also break a few times, and a few older
applications also broke, they worked in one release and they would not
work ever again after a new release.

I have 12 desktops in 3 basic hardware arrangements, and 4 laptops, it
was so much work to keep up with them that most are now in the garage
and I only use a few I7 home-built ones, and a few HP desktops with I5
or I7 CPUs and a couple of Q9650 CPUs, they all acted the same way, all
of them have Windows 10 with only one exception a small laptop with
Windows 7 32 bits, and I want to upgrade it someday before free upgrades
is completely shutdown.

Unlike versions of the past you have no choice about installing
upgrades, you can delay them a little but sooner or later they get to be
installed.

--
Cecil - k5nwa

[Alex]

On 23-Feb-18 19:52, Cecil Bayona wrote:
> a small laptop with Windows 7 32 bits, and I want to upgrade it someday
> before free upgrades is completely shutdown

I thought free upgrades ended July 2016?

--
Alex

[Rob Sciuk]

Ah, yes, backwards compatibility in Windows is predicated upon every bit
of code of every OS release from Windows 3.11 on is included in Win10.
That might explain why it is so bloated. And bug-ridden. And susceptible
to viruses, worms and exploits. Used by many, though.

[Walter Banks]

Actually the OS app interface has just remained very stable and upward
compatible. It does require app's to be implemented with developer
discipline and not go around the system calls.

The general comments I have heard at security conferences has been that
Windows is far more secure that most of the common Unix/Linux OS's in
common use and about the same as the various android OS's.

It is a common opinion that windows is bug-ridden but in our experience
that hasn't been backed by our data.

As a stable platform to develop and distribute develop tools windows has
served us well.

w..

[minf...@arcor.de]

You are sure? AFAIK Androids are the most attacked and vulnerable OS.

[Anton Ertl]

Rob Sciuk <r...@controlq.com> writes:
>Ah, yes, backwards compatibility in Windows is predicated upon every bit
>of code of every OS release from Windows 3.11 on is included in Win10.

Not in my experience, and not from what I read. Many installations
still use Windows XP (and many more Windows 7) because the software
they need does not run on anything newer. Like for anything else, in
compatibility, MS is satisfied with getting the vast majority, rather
than getting all. For the rest they rely on network effects (e.g.,
new hardware not supporting old Windows, people sending around MS
Office files that cannot be processed by old MS Office versions etc.).

Not that free software is necessarily better. While Linus Torvalds
makes a point in not breaking the user experience, the rest of the
Linux ecosystem does not generally follow this good practice. Examples:

* I cannot run my old ZMAGIC and QMAGIC binaries on my Debian 8 system,
because Debian does not deliver the AFAIK required binfmt_aout
module.

* The mount tool uses the relatime option by default, breaking
practices that rely on proper atime behaviour.

* The gcc maintainers release new gcc versions that do not compile
existing programs to behave as before, and either they or their
fanboys argue that this behaviour is a virtue.

>That might explain why it is so bloated.

I think this is more due to the development culture inside MS:
<http://blog.zorinaq.com/i-contribute-to-the-windows-kernel-we-are-slower-than-other-oper/>

>And bug-ridden.

As a non-developer (on Windows), I don't experience many bugs. There
are reportedly many bugs in the APIs. As long as most developers
still prefer Windows (thanks to the number of non-developers) over
other platforms, there is no reason for MS to eliminate such bugs. So
that's what you get when commercial considerations meet network
effects.

>And susceptible
>to viruses, worms and exploits.

It seems to me that MS is doing a lot to avoid these problems. But
they collide with the things that make MS Windows popular: The ability
to run old applications, the insecure practices of the users that the
users want to continue practicing, etc. MS tries to deal with that by
requiring user feedback upon doing things that may be insecure, but
most users are not up to making the decisions that this model requires
of them.

Unix/Linux seems to be a little better off thanks to having a division
between root and non-priviledged users from the start, but there are
still quite a number of cases where that degrades to the current
Windows security model.

But are systems that started from a clean slate (like iOS and Android)
really more secure?