[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[linrad] Re: Windows graphics again

Agreed - although a cynic might say that by porting to Windoze, you are slowing the drift towards linux. I've heard it said many installed Linux to use Linrad, but now they do not have too.
Perhaps having the latest version on Linux, and less development on Windows will force the hand of a few more. 


I want to ask you a question, just curious. I just want to know whether
you continue doing your Windows developing from Mingw under Linux. Just
to confirm that the setup works and can be used to develop Windows apps.
I am writting a simple C program under Linux that writes antenna NEC
input files for yagis entering element dimensions. I have done it for
personal work, but could be useful for others( I am a horrible
programmer). It could be a good idea to compile it for windows as well.
Just for my local amateur radio friends that are lazy to install Linux! ;-)



I'll give you some of my experience writing command line driven programs for Windows and UNIX.

atlc  - http://atlc.sourceforge.net
that I wrote has been run on many computer systems, including the usual mix of PC and UNIX hardware, Windows, but also a Sony Playstation 2 and a Cray X-MP 64-bit supercomuter where sizeof(short)=8. That was a real pig for binary files. 

1) If you write text files, use fp=fopen("foo","rt") or fopen("foo","wt").

UNIX silently ignores the "t" for text or "b" for binary, but for Windows it is important.
2) If it compiles on Windoze and your favorite Linux (Redhat or whatever) don't assume it will compile on all Linux/UNIX systems.
3) If you write binary files and use short, int or long, then pay attention to the fact that some hardware (x86 for example) is little endian, whereas other UNIX hardware (such Sun's SPARC processor) use big endian.
To get around an issue on the Cray with sizeof(short)=8, I had to resort to writing data a byte at a time, but this is probably a bit OTT, and better to just ignore very old hardware. (The Cray runs at 33 MHz, to give you some idea of its age).
4) Don't assume a system is 32-bit. A lot of UNIX hardware has been 64-bit for a long time. (over a decade, and of course PCs are starting to be 64-bit now). 

5) Test the software on a range of hardware, but include 4 catagoies

i) Little endian 32-bit
ii) Little endian 64-bit
iii) Big Endian 32-bit
iv) Big Endian 64-bit.
If you host the program on Sourceforge, they have a "compile farm" you can use for this purpose. Compaq/HP did have (still have??) a "testdrive" system so you can test programs on that. The nice thing about that is there is some seriously fast hardware on that.
6) Don't only use gcc. Lots of people use other compilers, usually because they are faster. I've seen too many programs that work with gcc, but fail to work with 'cc' from Sun, IBM, SGI or HP.
7) Testing code on different platforms often finds bugs that do not appear their ugly heads on one system. I found a multi-threaded application will work 95% of the time on IBM's AIX, but 100% of the time on Solaris, Linux, HP-UX, Windows, tru-64 and others. It was a real bug in my code, and was not a bug in AIX, despite the fact it only showed up under AIX. 


--
Dr. David Kirkby PhD CEng MIEE,
Senior Research Fellow,
Department of Medical Physics,
Mallet Place Engineering Building,
Gower St,
University College London,
London WC1E 6BT.


#############################################################
This message is sent to you because you are subscribed to
 the mailing list <linrad@xxxxxxxxxxxxxxxxxxxxx>.
To unsubscribe, E-mail to: <linrad-off@xxxxxxxxxxxxxxxxxxxxx>
To switch to the DIGEST mode, E-mail to <linrad-digest@xxxxxxxxxxxxxxxxxxxxx>
To switch to the INDEX mode, E-mail to <linrad-index@xxxxxxxxxxxxxxxxxxxxx>
Send administrative queries to  <linrad-request@xxxxxxxxxxxxxxxxxxxxx>
LINRADDARNIL
o