OSDev.org

I get most of the dos programs to work in windows and xp
and even most of win95 and win98 programs.........

It's true that Windows .. for that matter dos is not portable across
diffrent achitecture... but for the platform it works .. it works well
and good .... I also know that they have copied desgin of Java (.Net)
etc ... But no man is an island ... Microsoft cant build everything......

The unix and it's variants has its drawbacks .. Can you get a binary
in RedHat 6 to work on RedHat 9.0 seemlessly ...... no .But it is
a brutally powerfull OS and i really like unix ...... It is difficlut
for a non technical person to use unix but that's not the case
with windows .. my old grandmother can even use windows
seemlessly ... But for technical people unix is good for many
reasons and i also admit that windows is not as customisable as
linux ... also for for learning purposes unix is good .... It is
much easier to learn unix system calls than to get used to Win32 API...


But coz of it's userfriendliness , good `user documentation` and
ablity to binary transfer files and run them seamless :- it
scores over linux and its cousins .... Dependencies are frustraing.......
.......especially for newbie ... Even now i run the good ol Slackware
in my PC ----- Slackware is worderfull man....

It's true that Windows .. for that matter dos is not portable across
diffrent achitecture...

actually, it is.. DOS itself was a port of CPM (at the time, the most popular OS in the world), and windows has actually been ported to many architectures -- MS used to sell windows for many different platforms, but there isnt much market for it anymore, so most of those other versions have been discontinued

It is much easier to learn unix system calls than to get used to Win32 API...

that is like saying its much easier to eat fruit than drive a car -- they are unrelated
win32 is not a syscall interface, it is an OS-independent library intended to sit between the application and the OS, to abstract away the OS, so that the same application binary could be used unaltered under any OS, unfortunately, MS is about the only company that doesnt cheat and assume the software is running under windows (in fact most applications assume a specific version of windows which is why there are so many compatibility issues whenever a new version of windows is released)

SandeepMathew wrote:Why do everyone here hate microsoft ....even though they have created
one of the most user friendly os ever known.............

Please don't assume from the fact that there are a lot of people complaining about MS that everyone here doesn't like them. Personally, I have no problem with them. Perhaps a more appropriate comment would be 'most people here dislike Microsoft'.

SandeepMathew wrote:It's true that Windows .. for that matter dos is not portable across diffrent achitecture...

JAAman wrote:windows has actually been ported to many architectures

NT 4 for DEC Alpha, PowerPC, Sparc etc for starters. I suppose x86-64 counts as well.

Brendan wrote:Unfortunately, for Microsoft's OSs the GUI is "hard coded" into the kernel, and can't be changed, improved, replaced, etc (it's just plain bad design to have such a large piece of code hard-coded into the OS

As others have pointed out, the GUI is not actually part of the kernel. I assume the point Brendan was making is that (for the current NT line at least) you cannot choose to install the kernel without the GUI, nor can you change it for another.

inflater wrote:Like MS Windows 1.0 was 1.0, MS Windows 2.0 was 2.0, Win3.1 - 3.1, WinNT 3.51 - 3.51, Win95 - 4.1, Win98 - 4.2 (?), WinME - 4.3 (?), Win2000 - 5.0, WinXP - 5.1... and Vista - 6.0?

I think you're confusing marketing numbers with product versions. Win95 does not sit as an evolutionary bridge between NT 3.51 and 2000 but is rather a member of a different line.

@Colonel Kernel: I agree with you that MS is not doing well for its shareholders. They seem rightly worried by Apple's domination of the portable music player market, as it is most likely that any profits made from that can be diverted back into the Mac hardware/OS divisions and thus further challenge Microsoft's near monopoly in the client computer market.

SandeepMathew wrote:It is much easier to learn unix system calls than to get used to Win32 API...

I suppose that depends on what you are used to. Sometimes, I find win32 easier, as it is at least consistent and pretty well documented. As an example, initially the implementation of threads and TLS was particularly confusing in the linux api as there were a number of different implementations by different groups, and to be truly portable you generally had to support each. With Win32, because its direction is dictated by Microsoft, you can be sure that all versions of Windows, after 95, support TlsAlloc, TlsSetValue etc.
I completely agree with you about Slackware, however. My main reason for installing Linux alongside Windows is customisability and I find Slackware one of the easiest to customise.

So I do have a lot of respect for Microsoft's operating systems (although I'm losing a bit after trying vista). Let's not forget that as a company they are involved in far more than producing operating systems. I do not use MS Office, as I find OpenOffice comparable and free, although it seems to be more than proficient. Visual Studio, with a little help from gcc and binutils, is pretty perfect for os development, and for windows development is easy to use and quick to learn. Microsoft mice have pretty much defined a standard. They are contributors to many standards bodies and support research into new technologies (e.g Singularity). Microsoft, along with the chip manufacturers, have crafted the modern PC world nearly by themselves, and I don't think they have done too bad a job from the average end-user's perspective. I am typing this on a system which allows me to communicate with friends and colleagues, write documents, prepare presentations, edit photos and so on, so let's not knock them too much because of slightly dodgy business practices and errors when we try and do something outside the realm of 'normal' use, as defined by 95% of the computer-using public. If you want to do something slightly unusual, turn to a unix. I certainly do.

Regards,
John.

I don't hate Microsoft, it's just that I don't like working on their system.

I have a copy of Visual C++ .NET 2003, I've used it a bit, but never really wrote anything, because I can't help but thinking that "This program won't work on anything but Windows."

I hate vendor lock in.

PS: I can't really say that I trust Microsoft either, so maybe that contributes to my dislike of their system.

Alboin wrote:I hate vendor lock in.

Bingo. I think just about everybody would agree with that.

Now some people claim that Apple is just as bad as MS when it comes to vendor lock-in... I suppose on some level it's true, in the sense that Apple stuff works better with Apple stuff, just like MS stuff works better with MS stuff. On the other hand, the core of Mac OS X is based on open source code, the UNIX subsystem behaves a lot like BSD and plays nicely with the GNU toolchain, Safari is based on KHTML and is more standards-compliant than IE, the iPhone doesn't support proprietary browser plug-ins like Flash or proprietary video codecs like WMV, the graphics subsystem exposes an OpenGL API, etc. I don't want to side-track this thread into an Apple discussion -- I just want to point out that a vendor can have it both ways (proprietary technology + open standards).

In contrast, MS seems to invent its own standards for everything (DirectX, asf, wma, wmv, ooxml, C#, CLI, and now Silverlight). Not all of them are bad (I actually like C# and the CLI), but most of them serve no purpose other than to further vendor lock-in, and as a consumer, that pisses me off. As a developer it also pisses me off, because I've been in the position many times of having to implement some crappy half-assed poorly-documented standard that MS has rushed out the door just so they can implement it better in their own competing products. The talk about secret handshakes between MS client and server products is totally true -- I've seen it first-hand. The playing field is not level where MS is concerned. IMO the DOJ should have busted them up years ago. Sorry if I sound bitter... it's just that Microsoft technical shenanigans have set much of the technical direction of my career.

Re: Windows history... it's been a busy week and I need to get some sleep, so I'll have to revisit it later.

I agree with the above sentiments about vendor lock-in.

However; if I wrote a very successful OS which was influential enough for hardware/software vendors to come to me when they were designing a new piece of kit/software, I would be thinking along the lines of "how is this new x going to play nicely with my OS?" rather than worrying about "oh - but will people on other OS's be able to use it too?", whether or not I had financial/world domination motives for the above.

Just a thought . Please don't take this to mean that I agree with everything M$ does!

Adam

Alboin wrote:I don't hate Microsoft, it's just that I don't like working on their system.

I have a copy of Visual C++ .NET 2003, I've used it a bit, but never really wrote anything, because I can't help but thinking that "This program won't work on anything but Windows."

I hate vendor lock in.

PS: I can't really say that I trust Microsoft either, so maybe that contributes to my dislike of their system.

Same here. The problem is, you can't explain vendor lock-in in a way that most people understand what you're trying to tell them. We need a form of advertising campaign-like setup with clear examples of the problems, similar vein to "Smoking is bad, it causes this, this is the alternative" which nobody's bothered to set up properly for similar reasons.

Yea,
I agree you can write non portable programs under Windows.....
but's that's true with other oses as well..... do you expect to
run Slackware 3.0 binaries under Slackware 9.0 ....never...!!!!
(other than copying root filesystem and chroot ..ing) ..The
point is with care you can write Portable programs in Windows...
This is just true for any os ..... If you use platform specfic API's
then it will be non portable ... that's it..........But the beauty of
Windows API is that..... with very little modification .. The code i
wrote for a Win16 system could be compiled on a Win32 system
with slight modifications here and there....True..This may not be
equally true for all unix systems........ .Net Patform is
specific to Windows only yet ... This paltform is richer and
more "interoperable than java" ... This is coz u see more langages
targeted to the .Net plaform ... As far as i know only Jython and
Java are the only popular languages the output Java byte code
... but the caveat is that Microsoft had time to see what works good
in Java and what not... ... I do admit that Windows has it's weaknesses ... but it's not entirely bad either.......

SandeepMathew wrote: I do admit that Windows has it's weaknesses ... but it's not entirely bad either.......

/me goes for a reductio ad hitlerum

Saying that Windows has its good sides is like saying the Third Reich has its good sides. It would have brought the world together, finally abolished the Tower of Babel, united us all for a common goal and it would've brought world peace.

/me scores


Now for a more serious reply.

Windows only lives because it supports /ALL/ the legacy there is, even when it means making the exact same function ten times. The Windows API is huge, so huge that you can't hope to duplicate it even if you were paid to do so, not in part due to it being undocumented and bug-riddled (so even if you had the docs you would be screwed). Windows programs are notorious in not allowing the OS to fix bugs but to use / patch them in the user code. Whilst the applications in question run better on the then-target, they run barely, if at all, on another platform.

Unix itself is a very long standing and fairly small API that anybody can implement. There are minute differences and it does evolve a bit, which explains why applications that were good now no longer compile. This is mostly minute work, because of new insights a slightly different approach should be taken.

The main difference in my opinion is that Unix doesn't allow you to abuse bugs and that Windows allows you to do so but tries to limit the non-nice things you can do. The latter is notoriously hopeless.

Another added advantage of Unix-like systems is their conformity with standards, Most implement functions as defined in the ANSI/POSIX/SUS specifications.

While very few of the free ones are "certified" Unix, most do comply with those standards.. as such, it makes porting applications between Unix-like systems fairly easy.

Brynet-Inc wrote:Another added advantage of Unix-like systems is their conformity with standards, Most implement functions as defined in the ANSI/POSIX/SUS specifications.

While very few of the free ones are "certified" Unix, most do comply with those standards.. as such, it makes porting applications between Unix-like systems fairly easy.

...most of the time. I think this is more true for C than C++ code. My current project at work involves developing a rather complex set of components in C++ that must be portable to Linux, Solaris, AIX, HP-UX, and a very old variant of System V UNIX. Guess which one is giving me the most trouble?

About Win32: I disagree with Candy that the Win32 API is poorly documented. There are plenty of other Microsoft APIs that are poorly documented, but I find the documentation for Win32 to be quite good. The problem with Win32 is its size and complexity, like you said.

Colonel Kernel wrote:About Win32: I disagree with Candy that the Win32 API is poorly documented. There are plenty of other Microsoft APIs that are poorly documented, but I find the documentation for Win32 to be quite good. The problem with Win32 is its size and complexity, like you said.

Do you count undocumented actually-not-really-intended-to-be-public functions as part of the API or do you not count them? If you do, which is fairly required for making those things work, you end up with them not being documented.

I'm not sure how large the amount is, this is hearsay. I'm also not sure whether bugs that were removed a few years ago are mentioned now, because from an application developers POV they're not relevant anymore, but if you support an application that relies on it...

Candy wrote:Do you count undocumented actually-not-really-intended-to-be-public functions as part of the API or do you not count them?

They're not counted.

If you do, which is fairly required for making those things work, you end up with them not being documented.

Do you have a specific example? I've never had to use an undocumented function to make a Win32 function work. You might be thinking of APIs beyond Win32, which are legion. Pretty much any API involving COM is suspect, due to Microsoft's tendency to implement undocumented COM interfaces in server products and have client products query for those interfaces (I've seen this happen).

I'm also not sure whether bugs that were removed a few years ago are mentioned now, because from an application developers POV they're not relevant anymore, but if you support an application that relies on it...

That would be nasty... "if (app is QuickTax 1.0) { doSomethingSpecial(); }" I've read about that kind of thing on Raymond Chen's blog, but I've never personally run into it myself... in Win32. In other MS APIs, yes, but not in Win32. I might be a special case though, because nearly all Win32 APIs I use are the kernel32 APIs (I don't do much UI stuff).

http://www.kuro5hin.org/story/2004/2/15/11942/2702

From the leaked NT/2000 source, interesting stuff...

I know perfectly well that windows conforms to POSIX i do know which
version ... but Windows 2000 server is posix compliant... and so r the
future versions..............