linux/windows development scenario

[John Eric Hanson]

My company is considering a development path in which we develop code on 32
bit Windows machines to run remotely on 64 bit Linux machines.

What could go wrong?

 

[Ruediger Knoerig]

My company is considering a development path in which we develop code on
32 bit Windows machines to run remotely on 64 bit Linux machines.

What could go wrong?

If you use a good X terminal for windows - not much.

 

[Phlip]

My company is considering a development path in which we develop code on 32
bit Windows machines to run remotely on 64 bit Linux machines.

What could go wrong?

I'd go Cygwin -> X terminals -> Ruby -> Tk

Why C++?

If the answer is speed, I'd write C++-style Ruby, and then profile to see
which modules are the bottlenecks. Then I'd re-write them to use lazy or
early evaluation, extra data stashes, different algorithms, etc.

Then, after exhausting a search for different algorithms, I'd convert the
fastest ones from Ruby into C++ objects bound to Ruby.

But if you don't need speed, you don't need any of that.

 

[Alf P. Steinbach]

My company is considering a development path in which we develop code on 32
bit Windows machines to run remotely on 64 bit Linux machines.

What could go wrong?

Everything, but mostly you will always break the deadlines and deliver an
inferior product. Best advice is to fire the management. But, difficult.

Btw., you're way off-topic in comp.lang.c++.

This answer crossposted to comp.programming with follow-up to comp.programming.

 

[John Eric Hanson]

The code is already written in C++ and is run in both Windows and Linux.
Speed is important.

Going forward we are considering continuing development in Windows, but
running on remote, 64 bit Linux machines. The program when run in
'production mode' (on large datasets) may exceed the 1 to 2MB of RAM
available on the development machines as well so complete testing need to be
done remotely. We don't expect any issues from scaling up though as data
subsets are analogous to the whole.

We do have a large number of 32 bit NT, XP and Linux machines that will
continue to be running lower priority code, both existing and new, so the
scenario is one in which there may be possible drawbacks in migrating the
development platform to 64 bit as well. I'm simply trying to evaluate which
scenario is likely to be more problematic: Windows development in a 32 bit
environment for deployment on 64 bit Linux system or Windows development in
a 64 bit environment for deployment on both 32 and 64 bit, Windows and Linux
environments.

Thanks again,

Eric

 

[Chris Mantoulidis]

My company is considering a development path in which we develop code on 32
bit Windows machines to run remotely on 64 bit Linux machines.

What could go wrong?

I don't know what could go wrong but there may be some slight bugs;
they can as well not be

BTW: Why do you want to have a 64bit Linux? What's wrong with the good
ol'32bit?

 

[Ian]

My company is considering a development path in which we develop code on 32
bit Windows machines to run remotely on 64 bit Linux machines.

What could go wrong?

A windows virus

Why not just develop on Linux?

Ian

 

[John Eric Hanson]

"John Eric Hanson" <[email protected]> wrote in message

I don't know what could go wrong but there may be some slight bugs;
they can as well not be

BTW: Why do you want to have a 64bit Linux? What's wrong with the good
ol'32bit?

The general consensus among us is that we'd experience performance gains in
both operations on doubles and in having more RAM easily accessible. We
will verify this in practice first, but the short of it is we are expecting
some performance gains with the 64 bit chips.

Our current concern is in ameliorating any possible issues that might be
involved in the development environment. Particularly as they involve the
platform and tools we currently use (Visual C++ on XP machines).

 

[Chris Mantoulidis]

The general consensus among us is that we'd experience performance gains in

both operations on doubles and in having more RAM easily accessible. We
will verify this in practice first, but the short of it is we are expecting
some performance gains with the 64 bit chips.

Yeah there will be some extra performance...

Our current concern is in ameliorating any possible issues that might be
involved in the development environment. Particularly as they involve the
platform and tools we currently use (Visual C++ on XP machines).

Let me get this straight. From what you've said till now, you are
writting C++ on 32 bit Windows that you want to run under 64bit Linux?
If you want to make a program just for Linux, then MAKE it in Linux as
well. But if you want to use that code for Win32 and Linux 32bit as
well and Linux 64 bit, here's a suggestion:

Make the program in Windows, compile it and you got your Win32 program
Copy the code to Linux (32bit) make the appropriate changes (e.g. some
API calls) and compile it and you got your Linux 32bit code.
For a 64bit code, you'd want a 64bit compiler. I don't know if there
are any, so you better search. If you find one do what you did
earlier.

However, the 64bit code MAY have some bugs if you run it on a 32bit
PC. So I suggest you don't do that. 32bit code runs fine on 64bit PCs.

It's your call though

BTW: This is kind of off topic in comp.lang.c++ . You'd be better off
in some other newsgroup (e.g. linux newsgroup or w/e else)

cmad

 

[Bob Hairgrove]

For a 64bit code, you'd want a 64bit compiler. I don't know if there
are any, so you better search. If you find one do what you did
earlier.

The Intel compiler, AFAIK, can generate either 32 bit or 64 bit code.
Also, there are Windows and Linux versions of this compiler, so I
think it would be a logical choice.

I'm assuming that the program will need to run on 64-bit Intel
machines ...