• C++ Programming for Financial Engineering
    Highly recommended by thousands of MFE students. Covers essential C++ topics with applications to financial engineering. Learn more Join!
    Python for Finance with Intro to Data Science
    Gain practical understanding of Python to read, understand, and write professional Python code for your first day on the job. Learn more Join!
    An Intuition-Based Options Primer for FE
    Ideal for entry level positions interviews and graduate studies, specializing in options trading arbitrage and options valuation models. Learn more Join!

Rumor: Windows 8 Set for September Reveal

When writing a software on different OS, how much you should care about if the software will be compatible with other versions of OS. There are platform specific softwares which can be tun on particular OS. That's what I meant.
I'm sorry but I didn't understand what you just said.
 
I'm sorry but I didn't understand what you just said.

You asked for the explanation of compatibility. I said that in compatibility I meant that you should always take into consideration the platform specific nature of the software you are currently writing. Suppose you are creating a software while running on Win7. You must be careful to make use of the features those are not supported by XP/Win2000/Vista in order to let them also run your software. I had an experience many times when coding on Win7 I don't use some features also take into account .NET version in order to let other platforms make use of it.
 
oh... compatibility between different versions of windows. Good luck with that!!
 
I really liked one of the recent posts. This endless war on OS preference and programming languages. We always fight which is better and the valid answer is always none. Let's use whatever makes us happier and does our job.
 
Still light years ahead of compatibility between different Linux distros.

The discussion was about compatibility in the context of programming interface, and I'd say your statement is wrong in that regard. For Unix systems, POSIX is mature and well-maintained programming API. Also, Unix programmers have choice between number of tools, like GNU autotools or CMake (CMake works to some extent for Windows too) that could help them to detect all sort of platform specifics at project build configuration time. None of this is case for Windows programmers: native Windows programming interface is very clumsy, and APIs change at will (I never understood how it is possible that Windows programmers accept they have to rewrite their applications every couple years: first they had to use Win32 API, then MFC, then ATL/COM, now they have to use .Net - and basically they are told to switch to new programming language for this last change - and who knows what comes next).

That said, I guess that what you had on your mind is compatibility in the context of installing applications, especially regarding dependencies between given application and needed libraries. In this context, you're right - although there exist efforts for standardization in that domain, like FHS, the current situation is far from ideal.
 
BTW, does windows versions have more compatibility problems than Linux versions?
 
That said, I guess that what you had on your mind is compatibility in the context of installing applications, especially regarding dependencies between given application and needed libraries.

Yes, you are right I refered to this problem exactly. However, I woudln't state that everything is clear with programming interfaces in Linux. There are great things (for example, I am big fan of D-bus and it is what COM should actually be) but to say that situation as whole is a way better than in Windows it's a very strong exaggregation:

- There is existing debate in Linux world - "buggy kernel-space vs. buggy user-space - what should be fixed first" - the good thing that Linus is winning so far but there are other examples you can find below.
-There was a situation with "perfomance improvements" by glibc team which led to breaking changes in implementation of memcpy() after 20 years of existence in its previous implementaiton (!).
- There was a situation with glibc team which refused to maintain some functions from standard library or provide reasonable implementation for some architectures (read ARM) - the reasons for Debian to switch from glibc to eglibc.
- There was a situation with tty interface in kernel-2.6 which led to departure of Alan Cox from kernel team. Quite ridiculous situation, I must say. I can't think about departure of COO from Oracle or Microsoft because they disagree with CEO on whether or not they should care about customers applications.
- There is a situation with compatibility between 2 most popular standard C libraries for embedded systems - ucLibc and eglibc - they are not binary compatible, however eglibc is binary compatible with glibc. "POSIX" and "well-maintained API" ?
- There was a situation when glibc team refused to fix security bugs which they thought were impossible to reproduce - you can find more by googling for LD_AUDIT and glibc.
.... and the list goes on.

I never understood how it is possible that Windows programmers accept they have to rewrite their applications every couple years: first they had to use Win32 API, then MFC, then ATL/COM, now they have to use .Net - and basically they are told to switch to new programming language for this last change - and who knows what comes next
All these technologies are still used and supported byMS and what you've stated above is called evolution ;) If you disagree with the idea that developers should get better tools then there is a good reason to blame C++ committee because they "force" you to learn all new things from C++0x.
 
I never understood how it is possible that Windows programmers accept they have to rewrite their applications every couple years: first they had to use Win32 API, then MFC, then ATL/COM, now they have to use .Net - and basically they are told to switch to new programming language for this last change - and who knows what comes next

Very interesting point. By the way, we are told every year to switch to upgraded platforms and the reason almost always stated is the platform agnostic nature of .NET. Here the talk goes about the structure exception handling mechanism which is expected to give a general overview about the preference of .NET over older platforms:

The obvious problem with these older techniques is the tremendous lack of symmetry. Each
approach is more or less tailored to a given technology, a given language, and perhaps even a given
project. To put an end to this madness, the .NET platform provides a standard technique to send and
trap runtime errors: structured exception handling (SEH).
The beauty of this approach is that developers now have a unified approach to error handling,
which is common to all languages targeting the .NET platform. Therefore, the way in which a C#
programmer handles errors is syntactically similar to that of a VB programmer, or a C++ programmer
using C++/CLI.
As an added bonus, the syntax used to throw and catch exceptions across assemblies and machine
boundaries is identical. For example, if you use C# to build a Windows Communication Foundation
(WCF) service, you can throw a SOAP fault to a remote caller, using the same keywords that allow you to
throw an exception between methods in the same application.
Another bonus of .NET exceptions is that rather than receiving a cryptic numerical value that simply
identifies the problem at hand, exceptions are objects that contain a human-readable description of the
problem, as well as a detailed snapshot of the call stack that triggered the exception in the first place.
Furthermore, you are able to give the end user help-link information that points the user to a URL that
provides details about the error, as well as custom programmer-defined data.

The bold phrase is almost everywhere. Imagine the next version even better packaging all those advantages will be saying:

" To put an end to this madness regarding the .NET platform ... .NET++ provides a solution" << for example. And then .NET++ then .NET+=3 ...

And what will only be left from the current .NET version seems to be this:

C++:
for ( int i = 1; i <=10; i++)

{

           Upgrade_To(".NET" + i.ToString());
           Console.WriteLine(".Net upgraded to: {0} \nWaiting for the next decade", i );

}


 
-There was a situation with "perfomance improvements" by glibc team which led to breaking changes in implementation of memcpy() which existed for 20 years (!).

I'll comment on this one only, as it is typical for most of the items you mentioned (except for embedded related stuff - I don't care about these, so I don't know much about it). The situation is rather clear with memcpy(): it was never supposed to allow overlapping between source and destination - for example, check towards the end of B3 section of K&R book and you'll see. So it was perfectly valid by glibc guys not to worry about this when changing implementation. Again, this issue is already thoroughly discussed, any anyone interested could check (start for example from here) and draw own conclusion.

As for this (glibc team vs. Linux kernel guys) and other (like Alan Cox vs. Linus) disagreements: Linux as a platform is huge, so it's perfectly normal that tension arise from time to time. As most of the development is in open, this sort of arguments is publicly visible. It's pity that Alan left, but life goes on - as you can see, the kernel development is not stalled in the meantime. And - it would be rather naive to think that, just because we don't hear about it, the development process in companies like MS or Oracle is all rosy and calm.

Note also that I haven't said in my previous message that POSIX is perfect - it's an old standard, and certainly has own warts (signals related stuff probably being the most ugly one). But - yes, it is mature and well-maintained: it gets extended by new stuff, and these extensions get incorporated with much care about maintaining compatibility, and the "spirit" of the API as a whole.

All these technologies are still used and supported byMS and what you've stated above is called evolution ;) If you disagree with the idea that developers should get better tools you can blame C++ committee because they "force" you to learn all new things from C++0x.

This is completely inappropriate comparison. C++0x is just extending previous C++ standard and this is what is called evolution - existing and new features could be freely mixed. With Windows programming APIs, new API covers most of the functionality of old API, and you're de-facto forced to switch. Old API could be still used, indeed; but for all practical purposes the old API get abandoned and its usage is discouraged - remember for example, when MFC finally get updated with ribbon interface support, of that silly prohibition of using it in applications that "directly compete with Office applications"?
 
BTW as I heard, we shouldn't expect new windows this year...The discussion went towards the comparison of different OSs and left the question unanswered. Any precise info about it?
 
As for this (glibc team vs. Linux kernel guys) and other (like Alan Cox vs. Linus) disagreements: Linux as a platform is huge, so it's perfectly normal that tension arise from time to time. As most of the development is in open, this sort of arguments is publicly visible.

Yes, agree here. I just didn't want it to look like good vs. bad but rahter one way vs. another way. You can have a very good support from one part the community and in different situation you can be treated like a retard by another part.

With Windows programming APIs, new API covers most of the functionality of old API, and you're de-facto forced to switch.

However, I can't agree with that - well, to be precise, I don't quite understand what do you mean by new API covering most of the functionality of old API. If it's about .NET vs WIN API then it's not entirely true because Win API is also updated. If it's about managed vs native application than you can see new features that were added to the C++ developers from MS - for example, you can find quite a good example here (it's about concurrency runtime).
 
However, I can't agree with that - well, to be precise, I don't quite understand what do you mean by new API covering most of the functionality of old API.

I was mostly having MFC vs. .Net API on my mind as an example, as both cover most of the functionality needed to write desktop applications: like building GUI, and then maybe connecting to database, communicate over the network, or doing some 2D graphics - I'd say all of this functionality get completely overhauled by each new Windows programming API.
 
I'd say all of this functionality get completely overhauled by each new Windows programming API.
How come that Linux platform is not overhauled by QT and WxWidgets and XUL for native developemnt and Swing and SWT for Java and lets not forget about Abobe Flex SDK? I bet they copy each other in terms of core functionaliy however I don't see anything wrong in good understanding of all or at least the good part of them for UI development.
 
How come that Linux platform is not overhauled by QT and WxWidgets and XUL for native developemnt and Swing and SWT for Java and lets not forget about Abobe Flex SDK? I bet they copy each other in terms of core functionaliy however I don't see anything wrong in good understanding of all or at least the good part of them for UI development.

Each of these options is equally valid/usable for Windows as it is for Linux, and each of them came from trying to achieve bigger goal - multi-platform compatibility. For tasks I've mentioned above, and in the context of single platform native APIs (compatibility of which is, if I understood it correctly, in the focus of our discussion): POSIX sockets programming interface, and then Xlib, Motif etc. are APIs that are long stable in Unix world.
 
Each of these options is equally valid/usable for Windows as it is for Linux, and each of them came from trying to achieve bigger goal - multi-platform compatibility.
Yep, agree about this - I thought you were talking about another level of abstraction.

For tasks I've mentioned above, and in the context of single platform native APIs (compatibility of which is, if I understood it correctly, in the focus of our discussion): POSIX sockets programming interface, and then Xlib, Motif etc. are APIs that are long stable in Unix world.

Lets look at XLib as example of well established API in the Linux world - we have XLib and on top of it we have QT, GTK, Motif etc.
Lets look at GDI+ as counterpart of XLib from the Windows world - we have GDI+ and top of it we have MFC, WinApi and WinForms with WPF.

How does it come that the first case is considered as a well-established API and modular architecture with a good level of abstraction
(I don't object this description but agree with it) and at the same time on another side the same situation (with different names though) is considered as "I'd say all of this functionality get completely overhauled by each new Windows programming API." (c) ? Since when GTK is overhauled by QT or vice versa?
 
Lets look at XLib as example of well established API in the Linux world - we have XLib and on top of it we have QT, GTK, Motif etc.
Lets look at GDI+ as counterpart of XLib from the Windows world - we have GDI+ and top of it we have MFC, WinApi and WinForms with WPF.

How does it come that the first case is considered as a well-established API and modular architecture with a good level of abstraction
(I don't object this description but agree with it) and at the same time on another side the same situation (with different names though) is considered as "I'd say all of this functionality get completely overhauled by each new Windows programming API." (c) ? Since when GTK is overhauled by QT or vice versa?

Once again: Qt and Gtk are not relevant for the discussion here - albeit primarily written on Linux, these are multi-platform toolkits. Motif is Unix native toolkit, and it is not replacing Xlib, but complementing it instead - Xlib has no functionality included for creating GUI widgets (Xlib is mostly about dealing with windows, and then basic user interaction and 2D drawing), and Motif is created to support this sort of higher-level functionality.

Let me try to clarify my point through an example: If an app is written 15-20 years ago, say that it was about fetching some stock values over the network and then updating some charts on screen, developers would probably use POSIX sockets interface, Xlib and Motif for implementation on Unix, and Win32 GDI and Windows controls stuff plus Winsocks (if they existed at all back at the time - shall I remind you that MS CEO didn't believed in Internet back at the time, so at the end they just had to rip off BSD TCP/IP implementation in hurry) for implementation on Windows. Fast forward to now, and most of the code in Unix implementation is probably the same (OK - Motif part would be ugly, but Unix people don't care much about GUI anyway), and fellow Unix programmers would certainly have no objection to keeping this old code. Windows application would probably get through two or three rewrites: first in C++ with MFC, then some stuff would be changed to make it work with COM, and finally it would be probably rewritten again in C# to use WinForms etc. I'm not claiming that all of these rewrites would be started by rational reasons - oftentimes it's matter of "being modern" hype, but there are other reasons too. Sometimes, new features are just not accessible through old API (see about ribbon example I've mentioned above), and sometimes MS is indeed creating serious interoperability problems between old and new API. Also, if not doing these rewrites - can you imagine your fellow Windows programmer if you show him your original Win32 code? So if for nothing else, you have to update your application just because every time after couple years there is no one else that would understand your code.
 
Once again: Qt and Gtk are not relevant for the discussion here - albeit primarily written on Linux, these are multi-platform toolkits.
Why ? I don't care whether they are multi-platform or not - it's the same level of abstraction on top of graphics API as MFC or WinForms or WinApi. .NET API is multi-platform now because of Mono. Should we eleminate it from discussion?

Ok. Lets go through your example. I just modified it a bit

Let me try to clarify my point through an example: If an app is written 15-20 years ago, say that it was about fetching some stock values over the network and then updating some charts on screen, developers would probably use POSIX sockets interface, Xlib and Motif for implementation on Unix, and Win32 GDI and Windows controls stuff plus Winsocks (if they existed at all back at the time - shall I remind you that MS CEO didn't believed in Internet back at the time, so at the end they just had to rip off BSD TCP/IP implementation in hurry) for implementation on Windows. Fast forward to now, and most of the code in Windows implementation is probably the same (even WinAPI part for graphics would be OK), and fellow Windows programmers would certainly have no objection to keeping this old code. Unix application would probably get through two or three rewrites: first in C++ with QT or GTK or WxWigets , then some stuff would be changed to make it work with CORBA, and finally it would be probably rewritten again in Java to use Swing etc. I'm not claiming that all of these rewrites would be started by rational reasons - oftentimes it's matter of "being modern" hype, but there are other reasons too. Sometimes, new features are just not accessible through old API (see about ribbon example I've mentioned above), and sometimes kernel team or glibc team are indeed creating serious interoperability problems between old and new API. Also, if not doing these rewrites - can you imagine your fellow Unix programmer if you show him your original Posix code? So if for nothing else, you have to update your application just because every time after couple years there is no one else that would understand your code.

You've made some assumptions about the majority of Windows programmers in the world, so I think it was OK for me to made the same assumptions about Unix programmers - much better now?
 
Why ? I don't care whether they are multi-platform or not - it's the same level of abstraction on top of graphics API as MFC or WinForms or WinApi. .NET API is multi-platform now because of Mono. Should we eleminate it from discussion?

I've mentioned it above: correct me if I'm wrong, but I thought this whole latest exchange of messages started on the topic of comparing native platform programming interfaces: POSIX etc. for Unix vs. Win32 and everything else that was considered as native API for Windows programming. Qt and Gtk are not useful for discussion, because whatever one may say in comparing Qt/Gtk functionality vs. say Linux native APIs, it mostly holds too for comparing Qt/Gtk functionality vs. Windows native APIs.

You've made some assumptions about the majority of Windows programmers in the world, so I think it was OK for me to made the same assumptions about Unix programmers - much better now?

No - because your assumptions are mostly wrong. Especially "fast forward to now, and most of the code in Windows implementation is probably the same" part - how many pure-Win32 application are there in common use on Windows desktops these days?

And here is another example: in the hypothetical situation I've described above, Unix programmer would probably start learning APIs needed for his work from W. Richard Stevens APUE/UNP books, while Windows programmer would probably use Charles Petzold tome "Programming Windows" (excellent book, back at the time). Still even today, Linux programmer use exactly the same books for learning this stuff. What do you think - how relevant is Petzold book these days, how many Windows programmers had it read (and - don't get started about "Programming Windows Forms", the contents in this one is completely different)?
 
Back
Top