UNIX'er to use Microssoft Visual C++ 6.0
Nan-Shan Chen
compile there my ANSI C codes developed under UNIX,
and make it a GUI-program for Microsoft platforms.
I think I need advice from programmers knowing both
platforms. Please comment and help!
Background: I used to work in a strongly command-line
oriented style: using Vim as editor, calling gcc as
compiler and in the development phase the bounds-checker
by Richard W.M. Jone (Is there a bounds-checker in VC?).
The program simply reads from diskfile or stdin and
outputs to a diskfile or stdout by putting verbose
messages, warnings or debug-info to stderr. That's all.
A Makefile is provide to compile these codes from *.c
to a single executable file with many command-line
options.
1. Can I simply call some "make" to compile, since
my codes are written in standard C? Can I
do this in a DOS-window? Which binaries to call?
Is it possible to work without the IDE and use my
favorate editor?
2. How to "bounds-check" once again these codes?
3. I'd like to keep them in ANSI C (89). Is it possible?
(No time to learn about C++ and too many GUI-things).
4. I'm thinking of 1-to-1 mapping the options (getopt)
and default values of my original program to bottons
in the GUI. What would be the most efficient way of
doing this?
5. Are there information about VC that has been kindly
written for UNIX-users who have never "clicked" in
their lives?
6. Anything else (or links) you could think of that might
help a totally "out-dated" guy? (So was I told :).
Thanks a lot for your help!
Rudi
--
Please remove the string s p a r c 2 0 2 to mail me.
Norm Dresner
"Nan-Shan Chen" <ch...@getsparc202.uni-paderborn.de> wrote in message
news:b4skak$j...@getsparc202.uni-paderborn.de...
> Well, I'm afraid I'll have to look into Visual C++,
> compile there my ANSI C codes developed under UNIX,
> and make it a GUI-program for Microsoft platforms.
>
> I think I need advice from programmers knowing both
> platforms. Please comment and help!
>
> Background: I used to work in a strongly command-line
> oriented style: using Vim as editor, calling gcc as
> compiler and in the development phase the bounds-checker
> by Richard W.M. Jone (Is there a bounds-checker in VC?).
> The program simply reads from diskfile or stdin and
> outputs to a diskfile or stdout by putting verbose
> messages, warnings or debug-info to stderr. That's all.
> A Makefile is provide to compile these codes from *.c
> to a single executable file with many command-line
> options.
>
> 1. Can I simply call some "make" to compile, since
> my codes are written in standard C? Can I
> do this in a DOS-window? Which binaries to call?
> Is it possible to work without the IDE and use my
> favorate editor?
Yes, it's possible. No, I've never done it, though my preferred working
arrangement in Linux and IRIX is nedit + make, I foind that I much prefer
enough features in the IDE's I've used to make it worthwhile to learn them.
It's supposed to be possible to even substitute editors in the Visual Studio
IDE. Again, there's nothing I like enough that's available in a Windows
version to want to bother learning how to do that.
As an alternative, there is a Windows version of gcc that's available too
and a unix-like environment called cygwin. Check them out and you might
feel that you've never left UNIX.
>
> 2. How to "bounds-check" once again these codes?
>
IIRC there are several Electric Fence - like products available. Some even
Freeware or modest-cost Shareware. I've een lucky enough not to have needed
them.
> 3. I'd like to keep them in ANSI C (89). Is it possible?
> (No time to learn about C++ and too many GUI-things).
Well, there was a discussion/argument about this on
comp.os.ms-windows.programmer.win32 recently. Naming your files .C makes
(most of) C++ unavailable. There are a few C++-like things that still are
active, most notably //-comments but the M/S flacks defend this as C99.
Bah!
You'll find that there are some traditional C-library functions that M/S has
implemented in modified-name fuctions to emphasize their "deprecated" nature
in Windows programming. Liberal use of the preprocessor maintains sanity.
Use of the construct #ifdef _MSC_VER ... #endif maintains portability.
I've compiled and run modest sized programs -- several thousand lines of
source code -- this way.
>
> 4. I'm thinking of 1-to-1 mapping the options (getopt)
> and default values of my original program to bottons
> in the GUI. What would be the most efficient way of
> doing this?
I haven't found a native getopt impelementation. You can import source code
from the gcc-library and it'll work; that's what I had to do to maintain
code integrity.
>
> 5. Are there information about VC that has been kindly
> written for UNIX-users who have never "clicked" in
> their lives?
>
Not that I've found.
> 6. Anything else (or links) you could think of that might
> help a totally "out-dated" guy? (So was I told :).
>
You want to create a Console App to avoid all of the Windows S#$T.
> Thanks a lot for your help!
> Rudi
>
>
>
> --
Norm
Nan-Shan Chen
>See answers in-line
Thanks, Norm,
your reply is VERY helpful for me. I'll read
comp.os.ms-windows.programmer.win32 for another
start.
(snip)
>IIRC there are several Electric Fence - like products available. Some even
>Freeware or modest-cost Shareware. I've een lucky enough not to have needed
>them.
So, an electric-fence is not part of the package. I think
that's a very important feature for a development environment.
Not until I tried a bounds-checker have I realized that *most*
of my (floating points and array intensive) codes were in fact
broken. It turned out that I'll never trust such codes again
that have not been bounds-checked ...
(snip)
Dosius
> Well, I'm afraid I'll have to look into Visual C++,
> compile there my ANSI C codes developed under UNIX,
> and make it a GUI-program for Microsoft platforms.
>
> I think I need advice from programmers knowing both
> platforms. Please comment and help!
I really only know DOS. ;)
> Background: I used to work in a strongly command-line
> oriented style: using Vim as editor, calling gcc as
> compiler and in the development phase the bounds-checker
> by Richard W.M. Jone (Is there a bounds-checker in VC?).
> The program simply reads from diskfile or stdin and
> outputs to a diskfile or stdout by putting verbose
> messages, warnings or debug-info to stderr. That's all.
> A Makefile is provide to compile these codes from *.c
> to a single executable file with many command-line
> options.
>
> 1. Can I simply call some "make" to compile, since
> my codes are written in standard C? Can I
> do this in a DOS-window? Which binaries to call?
> Is it possible to work without the IDE and use my
> favorate editor?
>
> 2. How to "bounds-check" once again these codes?
>
> 3. I'd like to keep them in ANSI C (89). Is it possible?
> (No time to learn about C++ and too many GUI-things).
3. Strict ANSI should be possible with *any* sane compiler. If not,
then the compiler is broken.
> 4. I'm thinking of 1-to-1 mapping the options (getopt)
> and default values of my original program to bottons
> in the GUI. What would be the most efficient way of
> doing this?
>
> 5. Are there information about VC that has been kindly
> written for UNIX-users who have never "clicked" in
> their lives?
>
> 6. Anything else (or links) you could think of that might
> help a totally "out-dated" guy? (So was I told :).
>
> Thanks a lot for your help!
> Rudi
6. Yeah - use cygwin or mingw32 instead of Vi$ual ¢, since they are
GCC and use the GNU tools.
-uso.
Norm Dresner
news:9307085f.03031...@posting.google.com...
> ch...@getsparc202.uni-paderborn.de (Nan-Shan Chen) wrote in message
news:<b4skak$j...@getsparc202.uni-paderborn.de>...
> > (No time to learn about C++ and too many GUI-things).
>
> 3. Strict ANSI should be possible with *any* sane compiler. If not,
> then the compiler is broken.
>
If this is your definition of "sane" then you're welcome to it. For me the
usefulness of a tool depends on its design specifications. The entire
Windows community has never been very big on "portability" -- except between
the different versions of Windows. This is not a failing but a conscious
decision on their part to which they've pretty well adhered over the years.
Don't get me wrong -- I think that strict ANSI is very useful for those
times when I need to write portable programs that will run on Windows and
other platforms too. What I usually do there is to start in the other OS
and do the Windows-port last. I also have found that I tend to write pretty
much pure ANSI without any crutches. I've taken several thousand lines of
code from one MS-DOS/ Borland C++ program I wrote and compiled it in
Linux/gcc with perhaps a half-dozen wrappers to get around my inadvertent
use of DOS-only subroutines. The same code was ported to Windows/MS C++v6
with great difficulty because of the lack of major ANSI functions that I had
to write conditional code to work around. But very little of my output
needs to be portable because most of it is very hardware-specific -- it's
not quite embedded systems but close: we're using PC-compatibles for mostly
embedded control tasks and we usually write all of the code, control as well
as post-processing, to run on the single PC involved.
Norm