Re: Questions about Windows by a (L|U)nix user
- From: "Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx>
- Date: Wed, 4 Jan 2012 11:20:16 +0100
On 4 Jan 2012 00:32:06 GMT, Jens Thoms Toerring wrote:
please don't take this as a rant or an attempt to start a
flameware - I'm merely curious and would like to get some
answers to questions I haven't been able to find. And I'm
posting it here since I haven't found any more suitable
place - please accept my appologies if it's off-topic here
(in that case I would be grateful for a pointer to a more
appropriate newsgroup).
Background: I'm a long-time Unix/Linux user and now am in the
situation were I have to write a program that works on Windows
as well (and on MacOS). And, to be honest, it was rather a night-
mare for me to get things to work on Windows;-)
Some things are simpler under Windows some are under Linux. [Talking about
modern time versions, of course. It would be unfair to compare Windows XP
with Unix SysV]
A good deal is
for sure due to my ignorance of Windows and the ways it works.
That depends on which part of API you are talking about: GUI, I/O, tasking
API etc. In some aspects Windows is more "modern" than Linux, because it
borrowed some ideas from VMS. In others it is worse. [Both Windows and
Linux are abomination, actually.]
But there are some things I couldn't find any good explabation
for, and that's what I would like to ask about here:
a) There's a lot of talk about the difficulties of porting pro-
grams from 32 to 64 bit Windows versions. Is that really that
much of an issue?
It is, but depends on the programming language in question and the extent
of 32-bit API usage.
I found maybe two issues where I had made a stupid assumption
that led to trouble but that's about all I ever did see of
32/64 bit issues, so I'm puzzled what the background might
be.
They changed the API, because due to its pointer-length specific design, it
was impossible to extend it.
b) When, as I just read, Microsoft announces to end the lifeline
of a product like XP there's lots of talk of people saying
that they use applications that were written for XP and that
it would take a huge amount of work to get them to run on e.g.
Windows 7. Can someone shed some light on why this is such a
problem?
Many old programs stop working or working improperly under Windows 7
64-bit, even in so-called compatibility modes.
I'm used to writing programs that still compile on
the newest Linux version after 15 years with at most minimal
changes and beside also work on other kinds of Unix. What's the
big difference in the Windows world that makes switching to the
successor version of the same OS such a big deal?
No difference. Old Linux programs do not work without compatibility
libraries, some do not work at all. I am talking about binary ones, of
course. Recompiling from scratch could also be an issue depending on which
libraries are in use.
c) When one compiles a program or a DLL with Visual Studio it
seems to make quite a difference if one uses the 2008 or 2010
version and that all libraries need to be created with the
exact same version.
Well, if you mean C++, then it is the run-time libraries (of C++, possibly,
MFC et al) linked to. It is no different from Linux, if you linked
components of a program to different versions of glibc, you would have
troubles as well.
Why aren't binary packages distributed in all usual
versions and why can't the system then pick the correct one
all by itself?
It can, and does. VC++ has a redistributable package of DLLs which can be
installed. You cannot mix different versions in one application, at least,
you cannot do it easily, but applications using different versions can
coexist.
d) Under Windows there seem to be several "runtime libraries",
and all components of a program (i.e. the program itself
and the DLLs it's linked again) must somehow fit together
also in this respect (as far as I was told). I'm not only
puzzled what this having different "runtine libraries" is
all about (and why it is necessary) but also how one is
supposed to figure out what had been used in the different
DLLs.
That is exactly same as under Linux, unless I misunderstood the question.
e) When trying to compile my program I found that Visual Stusio
doesn't seem to be enough - some functionality seems to re-
side in what's called a "Microsoft SDKs" (of which there are
again several versions. Can someone explain what these are all
about and why are there several versions and how one figures
out which version to use for a program (I got the impression
that v6.0A needs to be used with Visual Studio 2008 and v7.0A
with VS 2010 but that is just a result of "it seems to work
now" but not something I understand - and then, why is there
a 6.0A and 7.0A version while there also seems to be a 5.0
(without the 'A') version)?
Hmm, are you using a "full" edition of VC++, there are some limited
"Express" editions? Normally, if you have a "full" one, it is no problem to
compile and link the program. Problems arise when running it on another
computer with another version of Windows or locale.
f) Under Unix I am used to programs and libraries getting installed
in some small number of places, typically either under /usr (for
stuff that comes with the OS) and /usr/local (for stuff that one
installs beside) and maybe a few other, more exotic places like
/opt.
And also /bin, /sbin, /usr/bin, /usr/sbin etc (:-))
On Windows I haven't been able to find a similar convention,
stuff seems to get installed all over the place and then requires
all kinds of PATH etc. environment variables to be set manually.
Is this impression correct or do I have missed the big picture?
If orrect is there some explanation why things aren't done in a
more systematical way?
Because the OS does not enforce any policy, neither Linux does. It is done
per convention, not per law...
Usually programs are installed in subdirectories of "Program files," which
can be named differently (sic!) depending on the OS language [an absolutely
idiotic idea]. There is a registry key for that somewhere, which I don't
remember. There are Windows, Windows/System32, Windows/SysWOW64
directories, which could serve as equivalents to Linux
/usr/bin+/usr/lib[64].
g) I have got the impression that Visual Studio seems to be rather
slow - the whole of my program takes more than 10 minutes to com-
pile and link while on similar (or less well equiped, both memory-
and CPU-wise) Linux machine gcc takes about 1.5 to 2.5 minutes.
Not really. The real issues are the code generated (2005 and 2008 are badly
broken without service packs) and the C++ standard.
BTW, if you prefer gcc, then you could take a look at MinGW:
http://www.mingw.org/
I am using both GCC (gnat front-end) and VC++ under Windows, I even used
mixed GCC/VC++ applications.
What could be the reasons and what might help to speed things
up a bit?
I don't have this impression, though I am used to compile huge Windows
projects under both. You could turn the precompiled headers on. But beware
they are quite broken.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
.
- References:
- Questions about Windows by a (L|U)nix user
- From: Jens Thoms Toerring
- Questions about Windows by a (L|U)nix user
- Prev by Date: Re: Questions about Windows by a (L|U)nix user
- Next by Date: Web Design Company Florida
- Previous by thread: Re: Questions about Windows by a (L|U)nix user
- Next by thread: Re: Questions about Windows by a (L|U)nix user
- Index(es):
Relevant Pages
|
