[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[linrad] Re: Windows graphics again
H Leif,
Why is it possible under Linux only ?
Hmmm, what I ment is that an averagely skilled radio amateur can
make changes to the Linrad source code, tyme "make linrad.exe"
and get something that will work on the Windows machine.
OK, I get you. I would agree building code on UNIX is very easy - far less hassle than on Windoze. The
'configure' scripts work pretty well. They are much easier than hacking Makefiles.
Of coures anyone with adequate computing skils can do whatever
it takes to install the source files, a suitable C compiler
and nasm for MS Windows and then set up a makefile.
Sure.
Of course I must agree that "possible under Linux" might be
a serious overstatement but I think you will find that this
will be so from a practical point of view.
I am glad to hear that. I have herd is said some have installed Linux for Linrad, which can only be a
good thing. I should add I do not run Linux much. I use it at work on my PC, but at home I use
Solaris. (Most people would no doubt do it the other way around - Solaris at work, Linux at home!)
From my experience with atlc, there are perhaps 100 users, but I
suspect only a few percent of them modify the code.
A consider a few percent quite sucessful.
Presumably the reasons
for personalizing atlc are rather small as compared to Linrad.
Yes, I think that is true.
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.
Hmmm, I am opening the text files like this: fopen("foo","w") or
fopen("foo","r"). I have not noticed any problems other than
the usual one that Windows uses return and line-feed while
Linux only uses one of them.
I've certainly seen problems. It may have been writing binary
files, I can't recall. But I think it is
safer to put the "t" or "b". The software I wrote for
transmission lines was not working properly on
DOS and was found to be the lack of the "t" (or was it "b" ??)
option. Adding it got it working
properly on both platforms.
Maybe it is because I use some version of gcc under mingw32.
I know that under DOS a single occurance of ctl Z is interpreted
as end of file so a binary file is never read further than to
the first occurance of 26 if it is opened as a text file.
Seems like the default is binary under gcc:-)
UNIX does not distinguish binary from text files, which is why the "t" or "b" is ignored. I just
looked at the man page on fopen and it says the "b" is strictly for compatability with ANSI C and has
no effect on any POSIX operating system. It suggests adding the "b" if you do IO of binary files on
non-UNIX operating systems. I'm not sure if my problems were on binary or text files, but I have seen
them. But ATLC writes bitmaps, which are binary files, so perhaps that is what causes the problem.
2) If it compiles on Windoze and your favorite Linux (Redhat or
whatever) don't assume it will compile
on all Linux/UNIX systems.
OK. Actually it compiles under Linux only.
I'm confused. You have Windows binaries, but it only compiles under Linux.
Perhaps you use Cygwin?
No, I have one computer with Debian Linux. On this machine I have
svgalib, nasm and mingw32. Just by typing make "linrad.exe" this
computer produces linrad.exe.
OK. I've not used that.
Does that mean only Redhat?
Oooh No!! It means every (reasonable) Linux distribution that is
not much older than RedHat 6.1.
OK. I have seen a comment from someone that they are happy if their code compiles on Redhat and do not
worry about anything else. That seems a bit much to me if you are going to distribute the code as
open-source.
I occasionally verify that the code
still runs on an old Pentium computer with very little memory on which
it is not so easy to install a modern Linux distribution.
That is sensible. I wrote a script for doing this in atlc. The script logs into a
remote host by passwordless (public-key/private-key) ssh, runs the configure script, builds the
software, runs the self tests and sends back the results (passes and failures). I assume that is not
too easy to do with Linrad, as you need to be at the machine to test it.
But new algorithms are more likely to appear if more people can
compile it, which means making it more
portable. I tried compiling it under Solaris on SPARC and soon
realised it was very Linux dependant. I
gave up at that point. I apprecaite the number of SPARC users for
ham software must be quite low, but
if the code only compiles on Redhat, you are seriously
restricting the user base.
Surely true, but that is not the case. I have tested several of each of
RedHat, Mandrake, Suse, Fedora, Debian and Slackware. There have been
several bugs in various distributions and I have made the changes
required to make Linrad compile under all of them. There have also been
quite a lot of errors in the sound systems over the years and therefore
the soundcard init routine is quite a bit more complicated than would be
needed on a modern distribution.
OK, things are clear now.
The message I tried to convey is that it is extremely easy for a newcomer
with practically no programming experiences to change the Linrad code.
Certainly it is not easy to change the actual processing in a meaningful
way, but sending commands to a tranmitter over the serial port or showing
some more information on the screen is very easy. Easiest, write a line
at the top of the screen "THIS COPY OF LINRAD HAS BEEN HACKED BY XXXXX".
If I were a 14 years old newcomer I might have started at something
like that to give to my friends;-) Showing time, date, parameter values
or any other global data is also very easy....
I'd mis-interpreted what you were saying. Sorry about that. It's probably not helped by the fact I
don't actually run the code. I looked at using some of it for a professional application, but never did.
--
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