By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
444,246 Members | 1,451 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 444,246 IT Pros & Developers. It's quick & easy.

linux/windows development scenario

P: n/a
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?
Jul 22 '05 #1
Share this Question
Share on Google+
9 Replies


P: n/a
John Eric Hanson wrote:
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.
Jul 22 '05 #2

P: n/a
John Eric Hanson wrote:
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.

--
Phlip
http://www.xpsd.org/cgi-bin/wiki?Tes...UserInterfaces
Jul 22 '05 #3

P: n/a
On Fri, 13 Feb 2004 16:01:34 GMT, "John Eric Hanson" <er**@newyorklogic.com> wrote:
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.

Jul 22 '05 #4

P: n/a
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
"Phlip" <ph*******@yahoo.com> wrote in message
news:6F******************@newssvr16.news.prodigy.c om...
John Eric Hanson wrote:
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.

--
Phlip
http://www.xpsd.org/cgi-bin/wiki?Tes...UserInterfaces

Jul 22 '05 #5

P: n/a
"John Eric Hanson" <er**@newyorklogic.com> wrote in message news:<yx*******************@twister.nyroc.rr.com>. ..
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?
Jul 22 '05 #6

P: n/a
Ian
John Eric Hanson wrote:
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

Jul 22 '05 #7

P: n/a

"Chris Mantoulidis" <cm****@yahoo.com> wrote in message
news:a8**************************@posting.google.c om...
"John Eric Hanson" <er**@newyorklogic.com> wrote in message

news:<yx*******************@twister.nyroc.rr.com>. ..
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?


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).
Jul 22 '05 #8

P: n/a
> 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
Jul 22 '05 #9

P: n/a
On 13 Feb 2004 22:52:58 -0800, cm****@yahoo.com (Chris Mantoulidis)
wrote:
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 ...
--
Bob Hairgrove
No**********@Home.com
Jul 22 '05 #10

This discussion thread is closed

Replies have been disabled for this discussion.