I thought it would be fun to post what you would have done differently if you had written Windows. Here's some things I would change:

    [*]Set the flags for EAX on exiting a procedure, I mean just an or eax,eax would have been nice
    [*]Preserve ECX instead of EBX to allow for easier counting loops
Posted on 2004-06-15 15:41:22 by donkey
I would have written it to be constantly buggy and exploitable and offer fixes for the problems little by little and when I needed money I would put out a new version that has all those fixes incorporated into the kernel as temporary hacks and put a new GUI on it.
Posted on 2004-06-15 16:07:46 by SpooK
Set the flags for EAX on exiting a procedure, I mean just an or eax,eax would have been nice


Why would you want to do that? 99% of the time it is not required (not by any HLL anyway), and for the 1%, you can just place the or (or whatever else) after the call.

Preserve ECX instead of EBX to allow for easier counting loops


Why not make loops with ebx instead of ecx, or even use a local variable? Besides, the real reason for this convention is because in the old days, bx had special functionality. It was the only 'x' register that could be used with addressing. So it is not a decision of MS, but of Intel (most other OSes work the same way on x86).

I am not sure what I would have done differently. I have used Windows for so long now that I have no desire to change anything. I would rather want other OSes to change and be more like Windows.
Posted on 2004-06-15 16:25:30 by Scali
I don't think that's why they chose to preserve EBX. Usually you won't work with 16-bit addresses in a 32-bit program, so it didn't matter much to them. They simply decided to not preserve the first three registers, and preserve the rest (ESP being treated somewhat specially, of course). The reason we usually use ECX as a loop counter is to save one byte.

I'd use CF for boolean results. They could very well have incorporated this convention into Visual C++, and it would have saved a few bytes here and there. Usually after calling function returning a boolean result you're going to test it, so the 1% figure seems a bit too low to me.

I'd use every available register to return values instead of storing them into an user specified memory address, in most cases, especially when it's obvious that the caller is going to use the result right away, if it's ever going to use it, like with GetFileSize and ReadFile. This could be implemented in a C compiler by declaring the function with a structured return type.
Posted on 2004-06-15 16:52:36 by Sephiroth3
I would have separated kernel and GUI, but left enough hooks in the kernel for GUI, that performance wouldn't have been as utterly lame as linux+XFree86.

I would have modularized things a bit more, and let people have more control of what gets installed and what doesn't. I would let adminstrators control the Windows File Protection completely - turn off, choose which files to protect (including 3rd party ones), etc.

I would have chosen a somewhat different folder structure, and not thrown as much junk in \windows and \windows\system32. I would especially have isolated the legacy subsystem support.

I would have worked towards NT/9x migration right after win95, since 9x is a horrible piece of shit that shouldn't really have existed.

I wouldn't have supported other companies shit code in the kernel (ie, kernel hacks to support versions of eudora depending on internal workings.) - I would have put great effort into breaking 3rd-party software depending on undocumented behaviour.

I would have put great effort into making _stable_ native APIs, and I would have documented those (but still adviced people to use win32, and adviced against depending on undocumented native APIs).

...those are just some. I do think that the NT kernel is very good design, has good performance, and a much better security model than any of the unix junk... too bad that the application programmers have botched up the system as a whole.
Posted on 2004-06-15 16:52:58 by f0dder
Why would you want to do that? 99% of the time it is not required (not by any HLL anyway), and for the 1%, you can just place the or (or whatever else) after the call.


Well, much of the time you check to see if a function was successful by looking for 0 in eax. To do this you OR EAX,EAX/ JZ >.ERROR. Ofcourse if you don't bother checking return values it is not an issue :) Also many more than 1% of the API returns true or false, by setting the flags on exit it makes the check faster. After all, it does not always require that they be explicitly set, they may have been set by some previous operation, the idea is that the returned flags are indicative of the value in EAX, after all every API destroys them anyway.
Posted on 2004-06-15 16:59:49 by donkey
I don't think that's why they chose to preserve EBX. Usually you won't work with 16-bit addresses in a 32-bit program, so it didn't matter much to them.


Newsflash: Windows existed before 32 bit x86 were commonplace.

The reason we usually use ECX as a loop counter is to save one byte.


Would this be by use of the loop or jecxz instructions?
I'd rather use an extra byte than waste 5 or more clks for every iteration because of legacy instructions.
Posted on 2004-06-15 16:59:59 by Scali
Well, 99% of the time you check to see if a function was successful by looking for 0 in eax. To do this you OR EAX,EAX/ JZ >.ERROR


I beg to differ that 99% of the functions you call are even capable of failing at all. At any rate, what does it matter if the or is before or after the return? Especially if you use .IF, the size of the sourcecode will be equal whether you do .IF zero? or .IF eax == 0

by setting the flags on exit it makes the check faster. After all, it does not always require that they be explicitly set, they may have been set by some previous operation, the idea is that the returned flags are indicative of the value in EAX, after all every API destroys them anyway.


That may have been nice in the DOS-age, but Windows was designed to be portable, and to work nicely with HLLs, so these things would not fit in the Windows design-philosophy very well.
I suppose the abandoning of such features was driven by forward movement.
Posted on 2004-06-15 17:06:08 by Scali
The thing with the "or eax, eax" stuff is that it would require adding special code to their compiler, that only assembly programmers would use - or, in case they released that compiler to the public, would make it incompatible with other 32bit compilers (though, of course, yet a calling convention would be constructed.)

How much would you gain by this anyway? In terms of speed, in terms of reduced code size. I would have focused on important things, not "neat" optimizations that wouldn't have much effect.
Posted on 2004-06-15 17:08:24 by f0dder

If i had written Windows ....


I would give up programming becouse im not suited for it :P


but seriously

fodder
I would have modularized things a bit more, and let people have more control of what gets installed and what doesn't. I would let adminstrators control the Windows File Protection completely - turn off, choose which files to protect (including 3rd party ones), etc.


this one realy lacks in windows, especialy when you are also linux user.
Posted on 2004-06-15 17:09:13 by AceEmbler
I would have separated kernel and GUI, but left enough hooks in the kernel for GUI, that performance wouldn't have been as utterly lame as linux+XFree86.


Isn't that exactly what MS has already done?

I would have worked towards NT/9x migration right after win95, since 9x is a horrible piece of shit that shouldn't really have existed.


Newsflash: 9x WAS the NT migration. It just took way longer than planned because people are overly conservative and stupid.
Posted on 2004-06-15 17:09:43 by Scali

Isn't that exactly what MS has already done?

Not yet - although if you hack around enough, you can boot to a "native state" without win32, it still requires video mode though. And it's certainly not anything that's supported.


Newsflash: 9x WAS the NT migration. It just took way longer than planned because people are overly conservative and stupid.

Microsoft needed a bunch of 32bit applications to convince people to move to 95. That happened, and then they should have forced everybody to go NT by simply not releasing any more 9x versions. Not like there was anybody who could have done anything about it...
Posted on 2004-06-15 17:13:44 by f0dder
Man, I didn't want to get into any arguments about this, it was just an "it would be nice if" kind of thread.

BTW I don't use MASM and GoAsm has no .IF statement or equivalent, you cmp and jxx that's all.

It would not break any HLLs to have the flags set to the value in EAX, that is a red herring argument, and I am not talking about explicitly setting the flags each time, just assuring that they would be indicative. At anyrate this already looks like it is heading for a flame war, should have known better than to post here again.
Posted on 2004-06-15 17:16:13 by donkey
Not yet - although if you hack around enough, you can boot to a "native state" without win32, it still requires video mode though. And it's certainly not anything that's supported.


I don't see the relation between kernel/GUI integration and the fact that an OS cannot boot without a kernel.
If I hardcode startkde in init on *nix, it would still have the same kernel/GUI integration, but it could no longer boot without a GUI.
See what I mean?

Microsoft needed a bunch of 32bit applications to convince people to move to 95. That happened, and then they should have forced everybody to go NT by simply not releasing any more 9x versions. Not like there was anybody who could have done anything about it...


Perhaps you don't really get the idea of "The customer is always right" :)
If the customer wants a new 9x, he shall get a new 9x (perhaps they figured that they would either stick it out with 95 or buy 98, but never buy NT).
Another factor could be that a lot of software was written badly, and did not run on NT properly (eg old DOS software or buggy Windows apps (hello VxD hax0rz? :))).
Games may have been a large factor. Even though NT4 supported DirectX, not many games worked on it. It took until Win2k to get DirectX-on-NT and game programmers in sync.
But I recall at the time that Win98 wasn't really planned. Win2k was supposed to be the 'final' Windows platform... I think an indication of that could be that the only non-server version is entitled "Professional". Perhaps they already planned a Win2k "Home", but instead Windows ME was released (why is it not called '2000' aswell?).
WinXP finally fixed it at last, anyway, so it is just a bad memory now.
Posted on 2004-06-15 17:27:58 by Scali
It would not break any HLLs to have the flags set to the value in EAX, that is a red herring argument


Nobody said it would break HLLs. HLLs just won't be able to use this feature, so it is of little use to most programmers anyway.
It would break portability though, since flags are CPU-specific. And above all, Windows is a portable OS. With which I merely want to say: you may want this feature, but MS would not.
Let's just say that the people that work at MS have plenty of knowledge and experience, and their decisions are based on decent arguments. They don't really care about what some little asm programmers might want, and they shouldn't anyway, it's not their target audience. They have to aim at their target audience, and I think the success of MS through the years comes from the fact that they do this better than most people dare to admit.
Posted on 2004-06-15 17:31:58 by Scali

Perhaps you don't really get the idea of "The customer is always right"

As if microsoft always plays by this rule :p

Yes, software was written badly, with direct port I/O etc, which shouldn't have been allowed, even on 9x. That software should simply have been forced to break, and software vendors release new versions. Microsoft could have helped companies rewrite VxDs before there were too many of them.

Microsoft chickened out and did win98, shame on them, more legacy crap apps. And why isn't Me called 2000? Because it's still a stinking piece of 9x shit ;)
Posted on 2004-06-15 17:33:47 by f0dder
As if microsoft always plays by this rule :p


Yes, I am of the opinion that they do. They listen to what the majority of customers want, and deliver that, I think. It's the only way I can explain why they have managed to keep a monopoly of ~95% for all these years, regardless of all these claims that it would be buggy, bloated, slow, overpriced etc. If there wasn't a decent foundation for the MS monopoly, I think it would have fallen apart overnight, with all the alternatives that have been offered (Mac, OS/2, BeOS, linux, etc).

And why isn't Me called 2000? Because it's still a stinking piece of 9x shit


Well it is not called Windows 99 either, or something... The ME name doesn't relate to either product line.
What I meant was that nothing would have stopped them from calling it 2000 Home or such. I think the reason is that the 2000 Home name was reserved for another product, which was not released until 2 years later, but then called XP Home.
Posted on 2004-06-15 17:41:38 by Scali
The calling convention used in Win16 APIs is irrelevant. In fact, BX is not preserved in Win16, and it is for exactly the same reason you suggested for preserving it ^_^. Also the order of stack parameters is reversed.

Usually, the time taken by an API call far outweighs the few nanoseconds taken by a loop or jecxz instruction. I prefer making my programs as small as possible so an user won't have to spend ages downloading it or copying it from the diskette or CD-ROM and having to buy new, larger hard disks all the time. Regarding the flag issue, I think it would have been benificial to incorporate it for functions that return boolean results. There would be ways to make things portable with the invention of the right language or language extensions. The statement that HLLs wouldn't be able to make use of it is quite a bold one.
Posted on 2004-06-15 18:55:09 by Sephiroth3
The calling convention used in Win16 APIs is irrelevant. In fact, BX is not preserved in Win16, and it is for exactly the same reason you suggested for preserving it ^_^


Whatever, bx had a special function in 16 bit. And that is why it is still saved today, regardless of whether the PASCAL calling convention was the most popular or not.

I prefer making my programs as small as possible so an user won't have to spend ages downloading it or copying it from the diskette or CD-ROM and having to buy new, larger hard disks all the time.


Common misconception: The size of a program is mostly driven by the size of its data, not its code. Proof? Simple, take a program of say 1 mb. Disassemble it and count all loops. Let's stay on the generous side and say there are 10000 (that is quite a lot for a single program!). You say a loop with ecx will be 1 byte smaller. So you have just gained 10 kb on a program of 1 mb? That is not going to make any difference for speed of downloading or copying. QED.

There would be ways to make things portable with the invention of the right language or language extensions. The statement that HLLs wouldn't be able to make use of it is quite a bold one.


You prove yourself wrong here. You say the languages need extensions. Apparently these extensions are necessary because HLLs indeed are not able to make use of it. And that is the trap right there: you will require compilers for HLLs that have these extensions to make use of the features. This breaks portability ofcourse. And how big is the chance that anyone other than MS will implement the extensions in their compilers?
Also, you seem like a naive programmer who has only ever seen x86 up close. x86 has flags that may or may not exist on other CPUs, and vice versa. It would come down to having to create a pseudo-flags register in memory somewhere, and having to emulate certain flags on certain CPUs. Not exactly what you want, because it is both slower and generates more code.
Posted on 2004-06-16 02:07:56 by Scali
firstly maybe make the GUI and the Kernel act independant so when you want to move the app window the window doesn't have drawing problembs when entering a heavy msg loop etc etc.

I would like to allow there to be a build in coding platform with a JIT debugger plus have all the libaries etc have comments linked to them to act as documentation ie compiled dll's etc have special resources geared at programmers. Also make it possible to customise nearly every aspect of the os.

Another would be that there is an user that is the system and will not allow any form of login and it won't allow anybody to view things that belong to it... use to protect developed software by having ani-reverse engineering tactics built in... maby a little bit awaire. Each program will have something similar to a GUID to allow the coder to preform debugging on it but not allow others... and the GUID will have diffrent levels as to acommedate OPENSOURCE.
Installing software will be compiling the software, so it is 100% configured for your system... so you would obviously only need 1 copy of the package to run it on diffrent arcutectures and runtime dependantcies - but hopefully keeping it as easy as MSI to install. {sorry linux, mabe a bit sloppy there and rpm's don't really solve the problem}

Oh btw, f0dder - the thing about dumping things in Windows and System... well i sortof agree but in linux there is no uniform install path so you you tend to spend time "#su root" then "#updatedb" and finally "locate what-ever" to see if or more where it is again....

The users will only see their own files and their own common files, they will not in anyway be able to see the system files and the system's actions. {Namespace structure somethin akin to linux, yet Desktop still top of the Namespace ie no drive letters}. Or even better ... each application will have its own namespace and so users with access to the application will be able to see and use and interact with it.{ok once again something akin with linux}

Also swap space will be in a seperate partition and will be treated as restricted... and only used as a last resort.

mabe have the gui act in gl mode... give some real special effects and make it more interactive with the user.

Mabe i should just try get back to windows... seems like i have spent some time on linux...
Posted on 2004-06-16 04:34:01 by Black iCE