Hm, when you guys has tried it with the ^M inside and you don't has tools to handle it, you has problems. Well, first \n in unix is not the right way to handle ascii text. The real way to handle ascii text is broken in unix - and hacked in windows. :) First, 0x0a and 0x0d are named "line feed" and "carriage return" (hope i spelled right). They are command from the good old mechanical typewriter times. As commands, they invoke electric typewriters at the end of a line to "go one line up" and "move the carriage back". Notice, that this is not the same - for tables for example you don't want move the carriage - you just go one line down and one back - so, this is not as stupid as you think. These are 2 (!) actions - different actions. In unix, the one command is skipped - but that means NOT that "hello world"+ox0d+0x0a is not a valid acii string! Is it - and its by unix and his tools to handle it. Unix don't can do it most times. Well, thats one reason why i tell unix as "not more or less limited as windows or other OS". The bad point is that most unix user THINK they have the god given tools (sorry bob :-) . There are more bad points, where unix really sucks when it tries to do other things then the standard ones - cvs is totally crappy in working with windows ascii files or binaries. Notice, that in the real big world (banks and other big data handling companies) most count cvs as "not useful for professional use". Please, this is not a flame mail - iam really tired about this threads. Is just, that IF we use cross platform source, we should be able from source & tools to face the specifics. Well, and you don't want a doc file which tells the users: "because the limited powers of unix you must remove all 0x0d and all // C++ command lines that this platform can use his overaged development tools." (Sorry, i can't resist to write this :) Btw, under windows, every slightly good shareware tool (text editor or compiler) can handle all this stuff. The point is, that i DON'T SEE in windows any difference in editor or VC between a windows or unix file - they handled 100% in the right way. You can even mix unix and windows text- it will shown right. Ok, we should set for the source there some rules. In all ways, this above is pur trivial. To the source - remember i hacked the flat mode in 4 hours. And some is ripped from dx client. For other system you don't have to compile it - you have to implement it. This is the stage the source go to alpha - is even pur work source yet. So don't expect a non warning/error compiling in the first steps. I will update the source in the next days. Michael > Hi guys, > njh and I tried to compile the sdl client, after a good 30 > mins of fixing silly errors njh has gotten impatient and given > up. I once again state that IF you want this code to be the > STANDARD and maintained by everyone it is going to need to be > really cleaned out. > > There are missing pointers and assumptions made (talk to njh > about specifics: njh (at) hawthorn.csse.monash.edu.au). That to > my understanding should simply not compile. How are why it does > on windows is a mystery to me, but the reality is it cannot be > compiled on my machine. I believe this is the flat supported > version and as thus is very flaky. Please don't use // comments > as they seem to cause problems with some compilers. Please don't > use ^M new lines \n is the standard. > > I am sure the isoclient is a much nicer piece of code in the long > run, but right now it simply cannot be read. I implore people > like Mark to take alook and try to clean it up. I am very > interested to know who has compiled it, and under what OS or > distribution of linux. > > This message is not intended to be an attack on Mich's coding > skills (as they are certainly far better than mine for starters > ;), but in the interested of moving to a smaller support base > setup I would like to make this point. Please take this as > constructive criticism and work with me to get crossfire's SDL > client up and running for everyone. > > Yours peacefully > dnh > _______________________________________________ > crossfire-devel mailing list > crossfire-devel at lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel