Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #1202 > unrolled thread

Questions about Windows by a (L|U)nix user

Back to article view | Back to comp.programming

Contents

  Questions about Windows by a (L|U)nix user jt@toerring.de (Jens Thoms Toerring) - 2012-01-04 00:32 +0000
    Re: Questions about Windows by a (L|U)nix user "io_x" <a@b.c.invalid> - 2012-01-04 06:40 +0100
      Re: Questions about Windows by a (L|U)nix user "io_x" <a@b.c.invalid> - 2012-01-04 06:48 +0100
      Re: Questions about Windows by a (L|U)nix user blp@cs.stanford.edu (Ben Pfaff) - 2012-01-03 21:41 -0800
    Re: Questions about Windows by a (L|U)nix user Patricia Shanahan <pats@acm.org> - 2012-01-03 21:48 -0800
      Re: Questions about Windows by a (L|U)nix user jt@toerring.de (Jens Thoms Toerring) - 2012-01-04 09:09 +0000
    Re: Questions about Windows by a (L|U)nix user Robert Wessel <robertwessel2@yahoo.com> - 2012-01-04 03:27 -0600
      Re: Questions about Windows by a (L|U)nix user jt@toerring.de (Jens Thoms Toerring) - 2012-01-04 10:05 +0000
    Re: Questions about Windows by a (L|U)nix user "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-01-04 11:20 +0100
    Re: Questions about Windows by a (L|U)nix user "BartC" <bc@freeuk.com> - 2012-01-04 11:44 +0000
      Re: Questions about Windows by a (L|U)nix user Robert Wessel <robertwessel2@yahoo.com> - 2012-01-04 05:57 -0600

#1202 — Questions about Windows by a (L|U)nix user

Hi,

   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;-) A good deal is
for sure due to my ignorance of Windows and the ways it works.
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? I'm curious since I never had any serious
   issues with programs I wrote under Unix to get them to com-
   pile and work under 32 and 64 bit systems, including several
   drivers. And e.g. in a program of mine of more than 200K lines
   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.

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? 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?

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. This I found quite problematic since some
   component DLLs I had to use were binary packages only and it
   often wasn't even clear what had been used for creating them.
   In the end it took more than two weeks to find a combination
   that finally seemed to work (some combinations seemed to work
   at first but then crashed sometimes in completely mysterious
   ways). Why aren't binary packages distributed in all usual
   versions and why can't the system then pick the correct one
   all by itself?

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.

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)?

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. 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?

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.
   I am aware that "similar machines" is a bit loose a concept but
   the difference is that large that it seems to be significant.
   What could be the reasons and what might help to speed things
   up a bit?

Of course, I don't expect complete answer to all of my questions
- they might be too long for a newgroup. But already getting just
some pointers to places were I can read a bit more about the back-
grounds would be rather nice - I have done a lot of google'ing but
mostly drawn blanks.
                                Regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

[toc] | [next] | [standalone]

#1203

"Jens Thoms Toerring" <jt@toerring.de> ha scritto nel messaggio 
news:9mhl06FiraU1@mid.uni-berlin.de...
> Hi,

for me windows api are ok

[toc] | [prev] | [next] | [standalone]

#1204

"io_x" <a@b.c.invalid> ha scritto nel messaggio 
news:4f03e56b$0$1385$4fafbaef@reader1.news.tin.it...
>
> "Jens Thoms Toerring" <jt@toerring.de> ha scritto nel messaggio 
> news:9mhl06FiraU1@mid.uni-berlin.de...
>> Hi,
>
> for me windows api are ok

but i use only windows OS api
and study them with Win32.hlp file
and if question i went to
comp.os.ms-windows.programmer.win32
no problem for me
no problem in my .dll
no problem interface OS api dlls exe
but with some trick
Have good 2012

[toc] | [prev] | [next] | [standalone]

#1205

"io_x" <a@b.c.invalid> writes:

> "Jens Thoms Toerring" <jt@toerring.de> ha scritto nel messaggio 
> news:9mhl06FiraU1@mid.uni-berlin.de...
>> Hi,
>
> for me windows api are ok

You're the guy who posts code like this:

    // macro for types
    #define  u64  uint64_t
    #define  u32  uint32_t
    #define  u16  uint16_t
    #define  u8    uint8_t
    #define  uns  unsigned
    #define  dbl    double

    // macro for function
    #define  P  printf

    // macro for keyWords
    #define G  goto
    #define R  return
    #define W  while
    #define F  for 

I don't think anyone should take your advice on anything C-related.
-- 
"[Modern] war is waged by each ruling group against its own subjects,
 and the object of the war is not to make or prevent conquests of territory,
 but to keep the structure of society intact."
--George Orwell, _1984_

[toc] | [prev] | [next] | [standalone]

#1206

On 1/3/2012 4:32 PM, Jens Thoms Toerring wrote:
...
> 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;-) A good deal is
> for sure due to my ignorance of Windows and the ways it works.
> But there are some things I couldn't find any good explabation
> for, and that's what I would like to ask about here:
...

Whether it is a practical solution depends on the nature of the
application and how much code already exists, but have you considered Java?

I've run the same jar on 32-bit Windows, 64-bit Windows, and Linux
without recompiling, let alone making any source changes.

Patricia

[toc] | [prev] | [next] | [standalone]

#1207

Patricia Shanahan <pats@acm.org> wrote:
> On 1/3/2012 4:32 PM, Jens Thoms Toerring wrote:
> ...
> > 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;-) A good deal is
> > for sure due to my ignorance of Windows and the ways it works.
> > But there are some things I couldn't find any good explabation
> > for, and that's what I would like to ask about here:
> ...

> Whether it is a practical solution depends on the nature of the
> application and how much code already exists, but have you considered Java?

> I've run the same jar on 32-bit Windows, 64-bit Windows, and Linux
> without recompiling, let alone making any source changes.

Sorry, but in my case that's not possible - the choice of
language wasn't mine and I now have to get it to work.
Moreover, part of the project is a DLL with bindings for
Python and I guess this could become a bit difficult with
a pure Java solution without any C/C++. And even if I would
be able to switch to Java I still would be interested in
answers to the questions (or getting told that some or all
of them are misunderstandings or based on rumours), just
out of mere curiosity;-)
                           Best regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

[toc] | [prev] | [next] | [standalone]

#1208

On 4 Jan 2012 00:32:06 GMT, jt@toerring.de (Jens Thoms Toerring)
wrote:

>Hi,
>
>   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;-) A good deal is
>for sure due to my ignorance of Windows and the ways it works.
>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 useful resource when porting from *nix is:

http://technet.microsoft.com/en-us/library/bb496505.aspx

But as you mention, a large part of the problem is familiarity - a lot
of *nix developers come to Windows and insist on doing things the *nix
way, which usually ends poorly, or at least involves considerable
pain.

OTOH, Windows developers migrating to *nix also spend a lot of time
wondering what the *nix designer were smoking.

The environments are different, and you have to adapt - just things as
fundamental as the distribution of source vs. binary impact a lot of
things.  It's far from uncommon to compile an application on
installation on *nix, which eliminates most issues with conflicting
versions of shared binaries, whereas most Windows systems don't even
have a C compiler installed.  In general you can share considerable
source code between *nix and Windows, but don't try too hard to share
the meta stuff.


>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? I'm curious since I never had any serious
>   issues with programs I wrote under Unix to get them to com-
>   pile and work under 32 and 64 bit systems, including several
>   drivers. And e.g. in a program of mine of more than 200K lines
>   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.


Probably the majority of the problem is that the Windows world has
usually involved far less porting of code, thus allowing far more
platform assumptions to sneak into the code.  Some API changes have
also occurred on the major transitions (16 bit real mode to 16 bit
protected mode to Win32 to Win64), while there have been relatively
few on the last, those do need to be dealt with.

Many of the issues would be avoided had people consistently used the
"STRICT" versions of libraries, and things like that, but all to often
they didn't, and you end up with hundreds of cases of assuming a
pointer can fit in a (32 bit) ULONG.  Frankly that's just sloppiness,
but the more consistent environment makes it easy to get away with
that.

But a Win32 app built with STRICT, and with /Wp64, is usually pretty
easy to port to Win64 (of course lazy programmers will then complain
about having to all the types and whatnot just right - poor babies).
That's usually the recommended approach anyway (get the 32 bit app to
compile and run like that, then port 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? 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?


It's exaggerated.  Most applications do work going forwards, even many
that are more than a bit ill behaved.  There are always exceptions,
but I can think of only a handful of minor (at least to fix) issues
that have occurred for us over the years.  Which is not to say that an
"old" application will not have integration issues with the more
modern environment.  And many people are running packages from vendors
that have not updated their code, or their running back version which
the vendor will not support on the newer platform.

A few significant areas are a problem, like IE6 compatibility (IE6 was
notorious for non-standard HTML extensions and behaviors). There is an
astonishing amount of code out there depending on that, and there are
people who can't even install the latest XP service packs since that
would require upgrading to something newer than IE6, and you have
either in-house applications that nobody is willing to upgrade, or a
third party is unwilling to upgrade (and there's an astonishing bit of
that).  Of course those won't port to anything else either.

And then there's stupid stuff - I can't tell you how many installation
programs I've seen that check the OS version in such a way to prevent
installation on newer versions on Windows.  Usually that's just a
mistake (if the application needs a minimum of XP to run, you get
people checking for the major version being 5 - that's not only
incorrect - Win2K was 5.0, XP is 5.1, but prevents you from running on
Vista and Win7 for no good reason).  That's so pervasive a problem
that Windows even provides a way to fake the reported version to a
program.

As an example of things working across versions, I have half a dozen
versions of Visual Studio installed on my machine - they all work
fine.


>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. This I found quite problematic since some
>   component DLLs I had to use were binary packages only and it
>   often wasn't even clear what had been used for creating them.
>   In the end it took more than two weeks to find a combination
>   that finally seemed to work (some combinations seemed to work
>   at first but then crashed sometimes in completely mysterious
>   ways). Why aren't binary packages distributed in all usual
>   versions and why can't the system then pick the correct one
>   all by itself?
>
>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.


Side-by-side assemblies go a long way towards eliminating "DLL Hell".
But usually third party DLLs should reasonably independent of other
parts of the runtime being used, or should be clear about the versions
they require.  It usually not a problem, for example, that your
program needs the version X CRT, and the DLL requires version Y,
because most of the time the usual interfaces don't expose the CRT
directly.  In cases where it does, it's a problem, and the third party
vendor should be dealing with it.  Again, they often don't do it very
well.


>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)?


There's usually a fair bit of forwards and backwards compatibility in
the SDKs.  7.1, for example, is for VS05, VS08 and VS10.  The SDK is
really related to an OS release, and is what defines the APIs and
whatnot for the version of the OS - v7.0 was the first to support the
new stuff in Win7, for example.  So if you were targeting Win7 back
before VS10 was released (which shipped with SDK 7.0, IIRC), you could
download SDK 7.0 and compile for Win7, with VS05 or VS08.  The SDKs
also support backwards compatibility by disabling new features (so you
can still target XP using SDK 7.1).

There's a standard version of the SDK that comes with a release of VS,
usually you'd use that, or upgrade to a newer version as needed.


>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. 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?


Most applications should install under "\Program Files".  If they need
manual setting of the PATH and/or environment variables, the
installation program needs work.

Application packaging and installation is a totally different beast
under Windows than *nix.  Basically forget *everything* you know on
one platform when going to the other.  And especially on Windows,
where users don't (can't) usually do much tweaking of the
installation, it's important to get it right (and the available tools
are extensive).


>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.
>   I am aware that "similar machines" is a bit loose a concept but
>   the difference is that large that it seems to be significant.
>   What could be the reasons and what might help to speed things
>   up a bit?


As a compiler, MSVC tends to be faster than GCC.  Standard Windows
application include some very large headers (windows.h in current
versions includes a couple of megabytes of source by default, and can
include more if you ask for it), which slows things down.  Precompiled
headers help, but I'm personally not fond of them.


>Of course, I don't expect complete answer to all of my questions
>- they might be too long for a newgroup. But already getting just
>some pointers to places were I can read a bit more about the back-
>grounds would be rather nice - I have done a lot of google'ing but
>mostly drawn blanks.

[toc] | [prev] | [next] | [standalone]

#1209

Robert Wessel <robertwessel2@yahoo.com> wrote:
> On 4 Jan 2012 00:32:06 GMT, jt@toerring.de (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;-) A good deal is
> >for sure due to my ignorance of Windows and the ways it works.
> >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 useful resource when porting from *nix is:

> http://technet.microsoft.com/en-us/library/bb496505.aspx

> But as you mention, a large part of the problem is familiarity - a lot
> of *nix developers come to Windows and insist on doing things the *nix
> way, which usually ends poorly, or at least involves considerable
> pain.

<lots of good advice snipped>

Thank you very much for all your explanations, it's a very
big help! It will take some time to absorb all you've pointed
out and also some more reading and experimentation, so I'll
not start asking further questions just now;-)

                          Best regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

[toc] | [prev] | [next] | [standalone]

#1210

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

[toc] | [prev] | [next] | [standalone]

#1212

"Jens Thoms Toerring" <jt@toerring.de> wrote in message
news:9mhl06FiraU1@mid.uni-berlin.de...

> 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? I'm curious since I never had any serious

32-bit programs seem to work just as well under 64-bit Windows without any
recompilation. That would have to be the case otherwise hardly anything
would have worked under 64-bits.

However many 16-bit programs that worked under 32-bit Windows, which you
didn't even realise were 16-bit, don't seem to run under 64-bits.

That includes some MS applications! But I also have 16-bit applications of
mine where I've lost some of the sources. (And recently I've even had to
advise someone to buy hardware with a 32-bit OS in order to run them. If
anyone knows of a workaround, I'd be grateful!)

But if you're talking about actually creating 64-bit versions of your 
programs, then yes it does seem to be a minefield.

-- 
Barct 

[toc] | [prev] | [next] | [standalone]

#1213

On Wed, 4 Jan 2012 11:44:06 -0000, "BartC" <bc@freeuk.com> wrote:

>"Jens Thoms Toerring" <jt@toerring.de> wrote in message
>news:9mhl06FiraU1@mid.uni-berlin.de...
>
>> 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? I'm curious since I never had any serious
>
>32-bit programs seem to work just as well under 64-bit Windows without any
>recompilation. That would have to be the case otherwise hardly anything
>would have worked under 64-bits.
>
>However many 16-bit programs that worked under 32-bit Windows, which you
>didn't even realise were 16-bit, don't seem to run under 64-bits.
>
>That includes some MS applications! But I also have 16-bit applications of
>mine where I've lost some of the sources. (And recently I've even had to
>advise someone to buy hardware with a 32-bit OS in order to run them. If
>anyone knows of a workaround, I'd be grateful!)


Well, 16 bit apps are completely unsupported by Windows in 64 bit
mode.  The subsystem simply doesn't exist.  That includes 64 bit
version of XP, Vista and Win7, and the corresponding server versions.

Win7 in 32 bit mode, *does* support Win16, although I've seen some
quirks.

Win7, in both 32 and 64 bit versions, supports "XP Mode" (you may need
the "pro") version, which uses MS's Virtual Machine technology to run
a somewhat stripped version of XP in a virtual machine - and almost
anything that ran on XP will run there.

If they're 16 bit DOS programs, something like DOSBox can often run
them.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming

csiph-web