SpeakUp Open Watcom Session 1 - May 14, 2005

Note:
     <MichalN> = Michal Necasek
     <eCSNL> = Roderick Klein

SpeakUp started at 15:01:47 EDT

<eCSNL> OK welcome to this SpeakUp....
<eCSNL> Well welcome everybody to this second SpeakUp new style.
<eCSNL> I have heard from severeal people that there was interest in a speak with Michal on Open Watcom. It took some time to send the emails out the door.
<MichalN> But they got here really fast!
<eCSNL> I hate long speeches so I will just push the microphone over to Michal. Give a short introduction Michal and then this speakup can start.
* eCSNL pushes the microphone 15000 miles to Michal
<MichalN> My name is Michal Necasek, among other things I'm the official maintainer of the Open Watcom project. This mostly means I get to do stuff no one else wants to do.
<MichalN> It's just about 6,000 miles BTW.
<MichalN> Since I did not prepare any sort of speech, you guys had better ask me some questions now.
<MichalN> Ask me anything you want, preferably related to Open Watcom.
<MichalN> Though I will also answer questions about weather if required.
<MikeG> Will there be a 1.4 GA for OS/2 ?
<RedBill> hallo
<Cinc> Maintaining the compiler means the whole suite windows, OS/2 whatever?
<MichalN> Yes, maintaining the compiler means the whole thing, all platforms.
<MichalN> As for version 1.4 for OS/2, I don't know if there will be any.
<RedBill> what I would like to know if there are some key issues that are being worked on currently
<MichalN> The C++ compiler is slowly but surely getting a lot better.
<RedBill> I ask because I don't follow in the newsgroup
<MichalN> You'd really have to follow the Perforce change list to see what exactly is happening.
<SimpsonTP> hi
<Orac> Why I aren't you sure whether there will be 1.4 version ? It is an excellent compiler with a lot of users I guess.
<MichalN> Lots of users maybe, but about zero helpers on the OS/2 side.
<RedBill> I have been a long time user of Watcom C/C++ from version 10.0 on but I have only used it for C programs
<MichalN> My problem is lack of motivation. I'm using 1.4 already, so I don't need an installer.
<SimpsonTP> MichalN: and how do you picture help from the OS/2 site ?
<MichalN> I started using 10.0 too, then switched mostly to VisualAge, and then got back with Open Watcom.
<MichalN> Have someone actually help me with testing, installer etc.
<Cinc> Why did you switch?
<MichalN> It's lots of terribly BORING work.
<MichalN> Why? Big part was because Watcom didn't support just OS/2. I was doing some DOS stuff, and VAC++ is no good for that.
<SimpsonTP> MichalN: do you have a infrastructure for that?
<RedBill> Michal, how many support CDs have been ordered? :)
<MichalN> Errr, I have no idea about the CDs! I'm not directly involved with that, I'd have to ask at work :)
<RedBill> I remember to have ordered it in 2003 when OW 1.0 became available
<MichalN> What do you mean by infrastructure?
<MikeG> Is there a way to list issues that need to be worked on for the OS/2 version. From the hard stuff down to small stuff that non-programmers can help with?
<MichalN> I don't know about "non-programmers" - I don't think they'd have any interest in compilers.
<MichalN> But there's definitely work for people who are no compiler experts.
<SimpsonTP> MichalN: you want testers, and you want people to help you with a installer, how do you communicate that ?
<MikeG> Well that's kind of what I meant... nono-compiler experts.
<MichalN> I ask in public. Several people have responded, none came through.
<SimpsonTP> MichalN: did you contact netlabs for support ?
<MichalN> No, I didn't.
<MichalN> Hello Steven!
<SimpsonTP> MichalN: special reason for it ?
<StevenL> Hi there.
<MichalN> Special reason for what?
<StevenL> I was working away in wdw and Roderick called to tell me I was late.
<StevenL> It's nice to have a personal secretary.
<MichalN> Not too late.
* eCSNL knows Steven was interested in the SpeakUp.
<StevenL> :-)
<MichalN> The project I personally am working on right now, but has nothing to do with OS/2, is porting the Watcom codegen to MIPS.
<MichalN> I'm trying to learn about MIPS and the codegen. So far I've learned an awful lot in a short period of time.
<Doodle> MichalN: Are there any non-Scitech people working on the OpenWatcom code? Do you know if any other companies are using OW for commercial products?
<MichalN> I may also try to get the PowerPC codegen into shape.
<MichalN> Yes, most OW contributors are not at SciTech.
<Orac> For what platform are you targeting MIPS ?
<MikeG> Well, I remember the installer post. I understood that you do not want to use a separate installer for OS/2. However, WarpIn scripts could be put together for the install.
<MichalN> As for other companies using OW commerically, we have no really good way to tell. There are some, but I only know if they ask about problems.
<MichalN> If someone is going to create a WarpIn installer, great. I personally am not going to do that because the old Watcom installer can do OS/2, DOS, Windows and probably Unix with a single install script.
<MichalN> I'm targetting Linux on MIPS. Or if you're asking about hardware, I have some MIPS dev boards and a PS2 with Linux.
<MikeG> Ok, I have done that for ODIN so that would be easy.
<MichalN> Only the PS2 seems screwy, I think someone patched the PS2 Linux kernel a bit too much. It doesn't seem quite compatible with other MIPS systems.
<MichalN> A compiler is a lot more complex than you might think.
<jep> You say that there are many OS/2 users but no helpers, what help would you need and how could you introduce the "helpers" into OW for OS/2-eCS?
<MichalN> Help is needed on two fronts. One is compiler/tools maintenance. Things like debugger, GUI library, C/C++ runtime etc.
<MichalN> This obviously requires a very skilled programmer.
<MichalN> I can do debuggers and runtimes, but I suck at anything GUI related.
<MichalN> The other front is general maintenance/testing.
<MichalN> Even just having someone who builds the whole thing regularly and reports any problems would be helpful.
<RedBill> Michal, how large is the test suite to check the compiler?
<SimpsonTP> MichalN: with reasone I ment, if there were specifig reasons not to ask netlabs for help
<jep> What do you use to build it for OS/2-eCS?
<MichalN> Hmm... let me put it this way. It takes over an hour to run the C++ compiler test suite on a 3GHz machine.
<MichalN> I don't understand the question what I use to build it.
<MichalN> Open Watcom is built with Open Watcom, if that's what you're asking.
<MichalN> It's possible to build big chunks of the codebase with GCC on Linux, but on OS/2 there appears to be no reason for that.
<MichalN> I also thought of getting thigs building with VisualAge, but gave up. VAC++ is just not up to it, because it doesn't support certain language features.
<RedBill> Michal, you mean VAC++ 4?
<MichalN> No, I mean VAC++ 3.08. I don't even have VAC++ 4.
<MichalN> The problem wasn't C++, the problem was C.
<MichalN> IIRC the biggest issues were anonymous structs/unions and non-int-sized bitfields.
<RedBill> well, someone should supply Michal with a VAC++ 4 compiler then :)
<MichalN> I'm sure I can get it, I just don't need it :)
<SimpsonTP> RedBill: what is the use of that ?
<RedBill> SimpsonTP, it's always useful to compile the same sources with different compilers
<MichalN> Yeah, except when one of them is too crappy :P
<RedBill> to see where they succeed and where they fail
<SimpsonTP> RedBill: I don't see any advantage to build openwatcom with anything else but watcom if that works
<MikeG> MichalN: What version of OW is the ow_daily.tar.bz2 on the ftp site?
<StevenL> This idea doesn't make quite as much sense when you are talking about compiling a cross-platform compiler.
<RedBill> my dream is having Mozilla compiled by OW
<MichalN> The daily tarball is a snapshot of the current source tree as it exists in Perforce. It calls itself 1.4 beta.
<StevenL> RedBill, that's a ways off.
<MichalN> But until 1.4 is released, no one knows what exactly will be in 1.4.
<SimpsonTP> RedBill: why is it a dream ? what advantage does it give you ?
<MichalN> I don't know Steven - someone would have to identify the shortcomings of the C++ compiler. Right now there might not be that many.
<MichalN> It would probably build hell of a lot faster than g++...
<RedBill> SimpsonTP, I don't like GCC. The more compilers can compile Mozilla code the better it is
<StevenL> Mozilla uses quite a number of leading edge C++ fetaures.
* Orac agrees with RedBill.
<StevenL> IAC, the build tool chain includes a lot more than just the compiler.
* jep agree with RedBill
* SimpsonTP feels this types of discussions are the death of OS/2 eComStation
<MichalN> Well, what's "leading edge"? C++98?
<StevenL> I'm not exactly sure. I do know that VAC 3.65 was missing some of the features that the source required.
<StevenL> This is was pushed to switch to gcc.
<RedBill> SimpsonTP, as far as I know there are many compilers for OS/2 who fully support ISO90 C but hardly a C++ compiler
<MichalN> Yes, but VAC++ 3.65 is *really* old. I'm pretty sure OW is a lot better than that.
<MichalN> I don't think 3.56 did namespaces?
<StevenL> I am too, but I'd have to do some research to know the specifics.
<jep> MichalN: What features are you planning/dealing with right now for the next release?
<MichalN> OK, let me find out... I have VAC++ 3.65 here.
<MichalN> Features? Primarily better C++ support. Some improved C99 support, like designated initializers.
<MichalN> Bug fixes, obviously.
<MichalN> Nope, VAC++ 3.65 doesn't do namespaces.
<SimpsonTP> MichalN: and did you describe somewhere what you would like from the public ?
<RedBill> I was almost about to send a request to Comeau about a toolset for OS/2
<MichalN> Yes. And several people did even promise to help, but then nothing happened.
<MichalN> I think Comeau is working on a C++ front end supporting OW.
<MichalN> I don't know that for sure, but Greg Comeau was asking certain questions on OW newsgroups.
<SimpsonTP> MichalN: where did you post that help request ?
<MichalN> I don't know any specific, you'd have to ask Comeau.
<RedBill> Michal, the key is to get money support, too
<MichalN> On the OW newsgroups, and on the eCS mailing list.
<MikeG> .... and is there a way to list exactly what is needed from the OS/2-ECS public (webpage?)
<SimpsonTP> MikeG: MichalN thats why i thought about netlabs
<MichalN> What is needed is everything the "public" is willing to do. That is not a fixed list.
<MikeG> oh... a Netlabs project page
<MichalN> Basically the more people I can get helping me, the better for all OW users.
<Doodle> MichalN: How can you work on SNAP, OW and who knows what else at the same time? Do you assign given days of the week for given projects? :)
<MichalN> I don't know what a Netlabs project page would do, since we already have our own newsgroup and everything.
<RedBill> Michal, do you know what happened to the old crew of Watcom who were engaged in the development of Watcom 11.0 ?
<alex> A list of suggestions would help, though...
<MichalN> No, I don't assign fixed time to anything. I do whatever is needed most.
<alex> If people are left thinking "I just don't know what I can do to help", they generally end up not doing anything.
* jep agree with alex
<MichalN> The old Watcom guys are now working at various companies all over the place. RIM, Broadcomm, QNX, one or two are still at Sybase.
<SimpsonTP> alex: = alex taylor ?
<alex> SimpsonTP, yes
<SimpsonTP> ah ;)
<MichalN> The original Watcom devel team was very small, there were probably fewer than 10 core developers at any single time.
<MichalN> I'm in touch with some of them, and they have helped me in the past.
<MichalN> Alex, what is there to do depends mostly on people's skills and interests.
<MichalN> You have to realize that Open Watcom is over two million lines of source code. Lots of the subprojects are only very loosely related.
<alex> I guess that's why I think a list of generalized suggestions might help... not too specific, but enough to get people in gear.
<SimpsonTP> MichalN: put putting the list somewhere might be of help
<SimpsonTP> MichalN: and again thats why I suggest netlabs
<MichalN> Is there anyone from Netlabs here?
* eCSNL points to SImpson
<SimpsonTP> MichalN: I could count myself for that ;)
<MichalN> Well... do you know how to contact me?
<MichalN> If so, we can work something out I'm sure.
<StevenL> My recommendation for folks that want to get involved is to visit the Watcom contributors newsgroup and start discussing options.
<SimpsonTP> MichalN: I'll temind adrian ;)
<MichalN> Steven is right.
<StevenL> I really don't see a need to fragment an already small group even more.
<MichalN> Oh, and a good place to visit is http://bugzilla.openwatcom.org/ - it contains tons of things to do :)
<StevenL> FWIW, I tried to get the Yahoo C++ for OS/2 group started on some things and for some reason they all seemed to have decided not to get involved.
<MichalN> Who is "they all"?
<RedBill> the only thing I could do is to write test code because I have never worked on compiler software before
<MichalN> You have to realize that a compiler is just a program like any other. There's no magic.
<RedBill> but Michal pointed out that there is already a large base of test code
<MichalN> More test code is always a good thing :)
<MichalN> In fact if there was someone experienced in writing test code, that's be great.
<StevenL> They all is basically the entire memebership, best I could tell.
<MichalN> OIC.
<MikeG> RedBill: volunteering?
<StevenL> I was asked to join the list to provide guidance and answers to questioned that required someone more experienced than the rest.
<RedBill> Michal, my problem is that I may be decent C programmer but I lack the capability of writing decent C++ test code
<MichalN> Actually, nearly all of Open Watcom is written in C. There is relatively little C++.
<StevenL> There's only one way to learn. :-)
<MichalN> Besides the C++ runtime (obviously), only the IDE and source browser are written in C++. All the rest is C.
<MichalN> A lot of that code goes *way* back to the mid-1980s or even earlier.
<StevenL> Another thing to keep in mind is that most C++ code is no more complex than C.
<MichalN> Some of it wasn't even originally written in C, it was WSL - Watcom Systems Language (which I know nothing about).
<MichalN> I don't know about that Steven. C++ is very considerably more complex language than C, and a lot of that complexity is implicitly there as soon as you say 'class'.
<MADodel> Who maintains the WSL code?
<MichalN> There is no WSL code. It was all converted to C almost 20 years ago.
<StevenL> At the compiler level this is true, but at the code level often all it means is that you get to omit the p-> prefix when referencing something.
<RedBill> if I remember correctly, C++ puts much more responsiblity into the compiler than C does
<MichalN> Yes. The C++ compiler is several orders of magnitude more complex than the C compiler.
<MichalN> There is also a good chunk of runtime support which doesn't exist in C.
<StevenL> I'm not saying that C++ can not be more complex that C, but it's just not always all that much more complex.
<MichalN> Things like new/delete, construction and destruction, not to mention exceptions or RTTI.
<MichalN> Depends on the programmer I guess.
<StevenL> And the application.
<MichalN> For our work, we use almost exclusively C. The #1 reason is that it's a lot more portable than C++.
<MichalN> That is, it's a lot easier to write C code that will be accepted by just about any C compiler than it is to do the same for C++.
<RedBill> yes, I agree
<StevenL> This is true.
<RedBill> one example only, Unzip :)
<MichalN> And since we don't always get to choose tools we have to use, we have to try and be fairly minimalistic.
<StevenL> OTOH, I doubt that Mozilla could have been written in C without building a lot of pseudo-C++ library routines.
<StevenL> Once it gets to that point, one might a well just write in C++.
<MichalN> That is probably true. A lot of good C code is sorta similar to C++.
<MichalN> For an app like Moz, sure. For kernel level development like we do, no way.
<MichalN> For us C++ just gets in the way.
<StevenL> My biggest complaint with C++ is that is does not really support private interfaces.
<MichalN> You mean because of header files and the fact that the compiler has to "see" all the declarations?
<StevenL> Keep in mind that most of what I write is C or less, but given a choice I try to pick a language that maps to the job with the least effort.
<MichalN> Sure. Except for some jobs, a more powerful and hence more complex language tends to hinder more than help ;)
<StevenL> There's an art to picking the right one before on fully understands the implications of picking the wrong one.
<MichalN> I think it takes picking the wrong one first before you determine that that wasn't the right thing to do.
<StevenL> :-)
<StevenL> We try not to do that.
<MichalN> Making mistakes is the best way to learn though. If you can make sure the mistakes aren't too expensive.
<RedBill> StevenL, application programming using C is actually not the most prudent thing
<StevenL> Remind me to tell you about the AD 2100 DSP Fortran Compiler someday. :-(
<StevenL> Tell that to all the folks that still do it.
<alex> Depends on the application.
<StevenL> Of course the alternative for most is Visual Basic.
<MikeG> Not to jump in some things that could be done:
<MikeG> 1. WarpIn install for OS/2 - ECS
<MikeG> 2. Have people just try and compile the daily - looking for problems
<MichalN> Exactly, alex.
<RedBill> of course, a small one can use C comfortably
<MichalN> Actually I'd be far happier if people helped me with the Watcom installer instead of WarpIn.
<alex> I use C, but then I don't really know C++. :)
<RedBill> alex, so do I
<StevenL> This is often the real reason for most choices.
<Orac> That is the same for me.
<StevenL> Either that or the app was origianlly in language A and converting would cost way to much.
<MichalN> Some C++ programmers don't know C too well, so they're stuck with C++ :P
<MichalN> Which is why people still use Fortran...
<Mangog> what work needs to be done on the installer?
<StevenL> Michal, would folks willing to do documentation review and updates help you?
<RedBill> Michal, with C its' >you< who has to take care about everything :)
<MichalN> Yes.
<MikeG> Will SciTEch and maybe OpenWatcom be going to Warpstock this year?
<MichalN> RedBill - but that's exactly it. In some cases the control is precisely what's required.
<Orac> I agree with that. For me C++ does too many things behind my back.
<MichalN> MikeG: It's a possibility. Steve will almost certainly go, and I will too with about 50% probability.
<MichalN> Steven: Yes, documentation reviews and updates would help a lot.
<RedBill> I remember when I did Cobol programs. Most was done by the compiler or language constructs
<MichalN> For kernel and driver development, compiler doing things behind people's backs is precisely what they don't want.
<RedBill> correct
<MichalN> The other day I was reading an article about FAA approved aerospace apps.
<MichalN> These have to be provably correct, and have to be hard real time.
<MichalN> They were talking about switching from ADA to Java.
<RedBill> Michal :)
<MichalN> And they said that it's doable, but they have to throw away exceptions, garbage collection, and basically strip down the language to bare minimum.
<MichalN> *Then* it becomes manageable.
<MichalN> A while ago there were some guys trying to get support for C++ code into the Linux kernel. Linus Torvalds basically laughed at them.
<MADodel> barely manageable
<Orac> Into a kernel ? They must be gone bezerk.
<MichalN> I think the problem there was that no new programmers know ADA, so they need to switch to a language they can find programmers for :P
<MichalN> Orac: That'd be my thought too.
<MichalN> It's not that C++ is a bad language, but you pay for the comfort with greatly increased complexity.
<MichalN> I mean, there isn't even a standardized C++ ABI (unless you count platforms with a single compiler vendor).
<MichalN> So alex, how about making some cute new icons and bitmaps for Open Watcom? I know you're good at that :)
<alex> Actually, I'm not an icon designer really.
<alex> I've done a couple, but I don't find it easy...
<alex> There are much more talented guys.
<SimpsonTP> ask eugene
<MichalN> It's not just icon design. A dialog designer would really help.
<MichalN> Someone who is a good PM programmer.
<MichalN> There's this internal library designed for easy portability between Win16, Win32 and PM. The problem is that the PM version is a bit crippled.
<MichalN> Which is why a lot of the dialogs in Open Watcom look so crappy on OS/2.
<SimpsonTP> so that should be looked at ?
<MichalN> If there's someone who know PM dialogs and especially font handling, there's work to be done :)
<SimpsonTP> hmmm
<SimpsonTP> I which I didn't have so much todo already
<alex> I do like dialog & gui design...
<MichalN> The Watcom GUI library is actually very interesting, because it's designed to handle both graphics and text mode programs.
<alex> Just as long as there's little or no actual programming...
* eCSNL just wanted to put he spotlight on Alex
<MichalN> For icon/bitmap/dialog design, there wouldn't be. For fixing the graphics lib, there would be.
* eCSNL knows another source.
<eCSNL> There is Russian developer that does that!
<MichalN> The OW debugger can be built as either GUI or console app, and nearly all the code is the same. This is really helpful if you want to, say, build a Unix console version.
<Orac> I'm not that proficient with font handling. You asked some time ago about zlib perhaps the person who did the zlib port to OS/2 is present ?
<MichalN> I guess not...
<MichalN> I don't know if he ever got anywhere with the zlib stuff.
<SimpsonTP> MichalN: you talked about updating the runtime, isn't the libc runtime usable ?
<MichalN> I highly doubt it. Bits and pieces of it, sure.
* bird don't recall zlib being difficult to port....
<MichalN> Remember that the OW runtime supports 16-bit and 32-bit operating systems, DOS, OS/2, Windows and Unix.
<SimpsonTP> hmmm okay
<MichalN> This wasn't about porting zlib. This was about adding support for "compressed filesystem" to the Watcom installer, for self-extracting executables.
<MichalN> The "problem" with the runtime is the same as with everything else. Some one asks "will you add support for 64-bit files to OW"? I ask, "will you help me with that"? And that's the last I hear from them.
<bird> that sounds very familiar...
<MichalN> lol
<MichalN> Somehow I'm not at all surprised :)
<MichalN> One thing I like about the OW runtime is that it's relatively thin, and designed for static linking.
<MichalN> So a statically linked OW app is smaller than dynamically linked apps produced by certain other tools that shall remain nameless ;)
<MichalN> This helps with load times too, especially on slow machines. If the machine is very slow, the speed difference is quite perceptible.
<MichalN> Come on, don't let me talk to myself!
<Orac> It is that speed difference that keeps me using OpenWatcom.
<MichalN> Yes, the C compiler (and C++ too) is quite fast. It really helps in development.
<MichalN> I spent some time profiling and speeding up version 1.3, and for complex sources it's very noticeably quicker than earlier versions.
<MichalN> For certain pathological cases the compile times went from minutes to seconds.
<MichalN> Did I mention that the OW profiler is actually pretty damn useful tool?
<Orac> It is not only the compile time that is very good also the execution time of the resulting executable.
<Orac> No you haven't :) But the OW profiler is a lifesaver when it comes to performance improvement of one's program.
<SimpsonTP> bird: talking about a familiar sound, did you get to my mail yet ?
<bird> SimpsonTP: not yet. :-)
<jep> Are there someone working the development of the IDE?
<MichalN> One of recent projects we worked on involved a rather slow PowerPC target platform. There was no real profiler for it (embedded Linux, #$@%!).
<SimpsonTP> bird: thats also familiar :)
<MichalN> So we profiled the code on an old Pentium II with OW, and managed to speed up the PowerPC code very significantly.
<MichalN> No, there isn't anyone actively working on the IDE.
<MichalN> The IDE is a bit of an orphan - lots of beginners use it, but almost no expert developers.
<jep> GUI Debugger and the other tools either
<MichalN> So the people who want the IDE aren't good enough to improve it, and the people are good enough don't care.
<jep> Well, that's the reason for using OW besides the filesize, there's an IDE
<MichalN> I don't think there's been any real work one on the debugger GUI, unless you count stuff like XMM register window.
<Orac> The GUI debugger is very good.
<MichalN> But there's definitely work being done on the debugger internals.
<MichalN> I actually use the console debugger, I don't know really why. I think because it doesn't take up the whole screen :)
<RedBill> I have used primarily the character mode debugger
<MichalN> The debugger was switched to a cross platform disassembler, which most people won't notice.
<RedBill> actually, because I was used to old CVP :)
<MichalN> Except perhaps that support has been added for SSE, SSE2, 3DNow! and all that crap.
<MichalN> The Watcom debugger interface was somewhat inspired by CodeView, so the keyboard hotkeys are the same.
<RedBill> yes
<MichalN> Some work has been done to support debugging of GCC programs with WD on Linux. That is far from perfect but to some people already preferable to gdb.
<RedBill> that's interesting
<bird> that doesn't take much imho.
<MichalN> You mean being better than gdb?
<MichalN> I've recently added support for OS/2 (and maybe Windows too?) .sym files, so that the debugger will show symbols for system DLLs if the .sym files are present.
<bird> yea, gdb is a pain to use on complex stuff usually.
<MichalN> The thing with gdb is that it's a really powerful debugger, but the UI just plain sucks.
<MichalN> With WD I'm way more productive because I can examine structures, pointers and memory very easily.
<MichalN> And because WD is a console program, this doesn't require a GUI and can be done over telnet or whatever.
<bird> it's not just that, gdb isn't that stable and it's painful to inspect disassembly and register.
<bird> btw. did you get anywhere on the jit debugging?
<MichalN> The gdb people obviously thought that "everyone has source code" so they made it a real pain in the ass to work on assembly level.
<MichalN> I've done some experiments but nothing I'd call production quality.
<bird> ic
<MichalN> I guess I need to get into a situation where I *need* a JIT debugger :)
<MichalN> Now that I think about it, I just missed an opportunity last week :P
<bird> that's the best inspiration
<MichalN> Someone (Walter Briscoe) screwed up wmake, and it was page faulting only under very specific conditions.
<MichalN> I ended up fixing it via combination of register dumps, debugger and printfs, but it would have been a good use for JIT debugging.
<jep> MichalN: Beginners use OW as you have a useful IDE that even can be installed and produce executables without causing to much headache, how do you want to keep them so they can get more skilled and eventually help you out?
<SimpsonTP> bird: are you thinking about supporting wdb for gcc as well ?
<MichalN> Yes, we don't want to drive the beginners away.
<SimpsonTP> uhm is someone loggin al this ??
<bird> SimpsonTP: shouldn't be all that difficult, just need to linker and/or wd work
<MichalN> Which is why I want for instance a proper installer and only release a tested version. We don't want people to give up because they couldn't install the thing.
<MADodel> hopefully someone is logging
<KenKrchnr> Several are logging
<MichalN> SimpsonTP: There are two ways to get WD working with GCC on OS/2. One, have GCC emit DWARF2 debug information, just like it does on Linux.
<MADodel> Good. I think I have Chatzilla set to autolog the channel
<SimpsonTP> okay
<MichalN> Two, write a HLL Debug Information Processor, aka DIP, for WD.
<SimpsonTP> bird: that way we have a debuger for gcc that is 1) usable and 2) maintainable
<MichalN> I don't know how much work option #1 is. Option #2 is two-three days for a skilled developer, with some bugfixing afterwards.
<SimpsonTP> bird: or am I missing something
<MichalN> SimpsonTP: What are you using for debugging right now?
<bird> I like both options, the latter is probably the most likely one since I still have to do HLL for the mozilla guys.
<MichalN> That's what I was thinking too - it'd by default support debugging of VAC++ apps, if someone wanted to do that.
<SimpsonTP> MichalN: i use vac debugger
<SimpsonTP> MichalN: but thats on a dead end
<MichalN> Which someone might, because although the VAC++ debugger is really good, I think WD is a lot more flexible.
<MichalN> Yeah, I can see that. If you're talking things like SSE support or newer C++ features, that's obviously not gonna happen with ICSDEBUG.
<MichalN> I've recently been using WD for embedded style development where only a debug server runs on the target and downloads the executable over a debug link.
<MichalN> That way I could cross develop from my OS/2 box to a Linux MIPS box without needing to mess with Samba or NFS or anything.
<MichalN> Though WD can also work the other way, where all source code is on the target and the debugger downloads it to the host.
<MichalN> I've been planning to write an article about advanced debugging with WD, but somehow can't get around to it :P
<MichalN> It can do some really cool stuff, like run a routine inside the debuggee, capture its output and show it in a debugger window. The OW compilers use this a lot.
<MichalN> The debug compilers have a bunch of routines that do formatted dumps of various internal data structures, and this way it's easy to examine that in the debugger.
<MichalN> I've used a similar technique with driver development, where I have a debug routine that dumps a bunch of "interesting" registers to a file.
<MichalN> This is really useful especially since the OS/2 (or Linux, for that matter) debug interface won't let me see the MMIO registers directly.
<MikeG> It seems that both the OS/2 GCC people and OW people could gain alot working togther.... or am I wrong?
<MichalN> I don't think you are. It's as always just a question of resources.
<MichalN> I think that OW and GCC are so different that there is a need for both of them.
<MichalN> There are certain things that GCC does much better (or at all) and there are other things that OW does much better (or at all).
<jep> So youcan't make them benefit each other
<SimpsonTP> we are talking about a debugger now
<RedBill> MikeG, it's interesting that those who worked on GCC for OS/2 didn't seem to consider the previous EMX port
<MichalN> If both eg. used the same debugger then both would benefit from any improvements to the debugger.
<bird> RedBill: what?
<RedBill> I may be wrong though
<MichalN> I think you are, RedBill ;)
<RedBill> ok :)
<jep> OK, let's put it this way, can't you merge the project together and take te best from each? Linux->OS/2 porting from gcc and compact fast code from OW for example?
<MichalN> I don't think so.
<bird> no, don't think so.
<RedBill> to get another issue. Does anyone know if it will be possible to create 64-bit subroutines in a 32bit system as OS/2 is now especially with AMD processors?
<bird> no
<MichalN> I never looked into that, but I doubt it.
<bird> or, yes, but you'll have to write a lot of kernel code for doing that.
<MichalN> To be honest, I don't really see the point.
<RedBill> Michal, it would be nice if you could create 64bit calculation routines
<bird> (like all the paging needs to be 64-bit. I did take a look at that some years back)
<MichalN> But what would you calculate?
<bird> 64-bit integers :-)
<RedBill> e.g. :)
<MichalN> Yeah, but who does heavy math with 64-bit *integers*?
<RedBill> Michal, I would :)
<MichalN> For what application? I'm really curious.
<RedBill> Michal, digital signatures e.g.
<MichalN> Is it really *that* much faster than 32-bit code?
<RedBill> I haven't tested that but I can imagine it would
<bird> some of the div/mult stuff is really really slow on 64-bit ints.
<MichalN> Divisions I can imagine, but with multiplications I doubt it.
<eCSNL> Its the same discussion here I'm getting the impression as 16 versus 32 bit device drivers.
<bird> but I think switching between legacy and long mode on a 64-bit amd is very likely more expensive :-)
<eCSNL> Would need to dive in the yahoogroups ddk mailng list archive.
<MichalN> That I can very well imagine - the 64-bit math would be quicker, but expense of switching would kill it.
<bird> :-)
<MichalN> 16-bit drivers are a pain to write, but they're not inherently slower than 32-bit code.
<RedBill> eCSNL, when I ported 16-bit OS/2 code to 32-bit code I noticed some performance increase
<MichalN> Depends on the code. Some code is faster when bitness is increased, other isn't.
<MichalN> Because pointers are bigger, the code tends to be quite a bit bigger. And that slows it down right there.
<MichalN> 32-bit code is a lot faster than 16-bit if it saves you messing with segments.
<RedBill> of course
<MichalN> But I remember hearing that IBM had major trouble getting the 32-bit PM code in OS/2 2.1 as fast as the old 16-bit code.
<RedBill> I remember to have had trouble with 64k stack then :)
<MichalN> Yes. Similarly 32-bit has capacity limitations. If you want to work with a 6GB file, then 32 bits isn't so good.
<MichalN> But if all you need is a web browser or something, I dobut 64 bits gives you much.
<RedBill> yes, that's probably the case
<MichalN> Now AMD64 can help because the architecture has lots more registers, but that's sorta unrelated.
<RedBill> 32 bit is enough for clients, imho
<MichalN> I think so too. There were many applications that didn't need more than 16 bits, and there are vastly more applications that don't need more than 32.
<SimpsonTP> '640k ought to be enough for everone'
<MichalN> And going past 64 bits... maybe few decades from now. Right now I don't see anything that would benefit from 128-bit computing.
<MichalN> Well, it was - in 1981 ;)
<RedBill> I wrote about 2 years ago that the performance increase from 32 bit to 64 bit will be much less than from 16 bit to 32 bit
<MichalN> I totally agree. Everyone was running into problems with 64K limits, but very few people have problems with 4GB limits.
<RedBill> yes
<Orac> I think the major benefit will not be a performance increase but an increase in the range of addressable memory (e.g. in FEM calculations)
<MichalN> The performance improvements on AMD64 are IMO coming from more registers, RIP relative code, and most of all better CPU architecture, which benefits 32bit code also.
<RedBill> otherwise, on x86 we could introduce seg16:32 pointers again ;)
<MichalN> Well, they're there... and OW can use them ;)
<MichalN> It's one of the very few compilers that handle 16:32 code.
<RedBill> I know :)
<MichalN> I have a feeling that MSC386 is about the only other, which is why IBM is still using it to build VDDs.
<RedBill> I don't think Mr Garfinkle will allow us to do that :)
<MichalN> You wouldn't want to give him a heart attack, would you? :)
<RedBill> of course not :)
<MichalN> We had some people from the US Navy trying to use OW for building a custom secure 16:32 OS. I don't know if they got anywhere.
<MichalN> The idea was that with segments, you get way better protection.
<MichalN> You can strictly separate code, data and stack.
<RedBill> yes, you can
<RedBill> a 32 bit code segment is very large
<MikeG> Will you put out a OW 1.3.1 with all the safe fixes - changes from 1.3 release? Is the installer documented?
<MichalN> I doubt it. There have been too many changes since 1.3 and it'd be too much work to selectively go back.
<MichalN> And yes, there is some documentation for the Watcom installer.
<MichalN> Even better, there are working samples in the form of Watcom 11.0, SQL Anywhere and similar stuff :)
<MikeG> So one would have to get Watcom 11.0 for examples?
<MichalN> You wouldn't need the whole thing, just the setup.inf file. Which might be checked into Perforce... let me see.
<MichalN> Yes, it's there.
<MikeG> Ok
<MichalN> The old installer basically just copied files from CD, so you really need them all to see how it works.
<MichalN> The Watcom installer is very good about selecting which host and target platforms you need and installing the right subset of files.
<RedBill> yes, I noticed when I installed Watcom 10.6 on a doze machine
<MichalN> It has some fairly complex internal logic, but the install script is built from human-readable file descriptions.
<MikeG> Well.... I hope you will be willing to answer alot of stupid questions
<MichalN> The only stupid questions are the ones unasked :)
<MichalN> BTW Steven, I don't know if you noticed, but I finally revoked Walter Briscoe's write access this week. He just ticked me off one time too many.
<MichalN> More questions!
<RedBill> of course
<Hawklord> MichalN: What do you use OW for?
<RedBill> about a year ago, somebody told me he didn't use OW for developing DD because he said that OW "wastes" precious stack space like in a switch statement. Have you heard of that before?
<SimpsonTP> just a user question: what is the -c from vac equivalent for OW ?
<StevenL> Annoying is OK. Unwillingness to take reasonable direction is not.
<MichalN> RedBill: Yes I have. This was a guy who used unmodified gcc code and wasn't willing to slightly change it.
<RedBill> Michal, ok :)
<MichalN> Steven - I think many people were wondering what took me so long ;)
<MichalN> SimpsonTP: There isn't any.
<SimpsonTP> MichalN: ohw, it can't create just object files ?
<MichalN> Well, there is, for wcl386. And that's -c. But you can run wcc386 or wpp386 directly.
<MichalN> Sure it can - but the C and C++ compilers can be invoked separately. There is no need to run the compile & link utility.
<MichalN> Hawklord: I use it for work. Most of SNAP driver development is currently done with OW, using stripped down OS/2 installs as a test platform.
<MichalN> Our testboxes are console only, using TSHELL. Development machines are mostly Windows, mine is OS/2.
<bird> by the by, where to download how to install / build on linux?
<MichalN> Nowhere. You ask on the newsgroups ;)
<bird> ok :)
<MichalN> There's nothing to install really. And to build, you get the source, run build.sh, and if nothing is broken right then, it'll build something.
<bird> though so.
<MichalN> All it needs is some version of GCC 3.x. Actually I'm not sure if 3.0 works, I know 3.2, 3.3 and 3.4 does.
<MichalN> My Linux box is still RH8, but I know it works on FC2 and I think FC3 too.
<bird> I'll give it a try then
<MichalN> If you run into problems, just ask :)
<bird> grabbing the daily source ball is safe, or should I try 1.3.0?
<MichalN> The daily tarball is better.
<MichalN> I think there's been a lot of tweaks on the Linux side since 1.3.
<RedBill> Michal, when will you include MD5 sums for downloadable files of OW ? :)
<Hawklord> MichalN: Do you use OW for Windows and Linux SNAP too?
<MichalN> You'd have to ask our web/ftp people :P
<MichalN> Hawklord: Yes, we're using OW for parts of SNAP for Windows.
<MichalN> I think SNAP for NT is built with a combination of VC6 and OW, and the 9x version is built with VC6, OW, VC1.52 and maybe even Borland.
<MichalN> We're not using OW for the Linux utilities, just the drivers.
<Hawklord> Interesting
<MikeG> Would it be easier to just update the IDE with something cross platform like wxWidgets ?
<MichalN> OW doesn't currently support shared libs on Linux, so it's very limited.
<MichalN> My stock answer for that is - are you willing to do it?
<MichalN> If not, then the question is pretty pointless.
<MikeG> Yes I see
<MichalN> What we have now works, but if anyone is willing to spend a lot of effort to do the same thing differently, they're welcome to it.
<MichalN> It's all a question of cost/benefit analysis. Sure, using wxWidgets for the IDE would be "cool", but at the end of the day, what does it really giv you?
<SimpsonTP> I think for linux platform a eclips plugin makes more sense
<MikeG> Yes
<MichalN> Yes, using some other IDE would probably make more sense.
<MichalN> Though I'd probably go for Visual SlickEdit myself ;)
<SimpsonTP> hehe
* bird too
<SimpsonTP> why doesn't that supprise me :)
<bird> I couldn't say...
<MichalN> My problem with IDEs is that they usually can't do the things I need. I just can't imagine how building for instance Open Watcom with an IDE would work.
* RedBill prefers makefiles with cli compilers :)
<MichalN> Build systems for complex multi-platform projects are usually far too complex to be modeled by an IDE.
<MichalN> OW actually uses a combination of makefiles and simple custom build tools.
<RedBill> yes, I know. The OW IDE creates the makefiles
<MichalN> Not for the OW build. That doesn't use the IDE.
<MichalN> The IDE isn't really up to that.
<MichalN> The makefiles need to work on OS/2, Windows and UNIX (and they do).
<MichalN> Many people hate makefiles, but that's just because they don't understand them ;)
<RedBill> lol
<RedBill> well, makefiles are a little hard to understand
<bird> you haven't seen mine then :-)
<MichalN> Not more so than any programming language.
<RedBill> interestingly, Info-Zip invoke make recursively
<MikeG> Michal, I do understand what you are saying. However, alot of users want to concentrate on learning and will never do a large project. The OW IDE helps them...
<MichalN> MikeG: I understand that. I just have zero motivation to work on an IDE that I don't use myself.
<Hawklord> Shouldn't we have a topic?
<MichalN> RedBill: I hate recursive makes and the OW build system almost never uses them. Instead, the directory recursion is driven by a custom tool.
<MichalN> The leaf makefiles in OW look like this (I hope this will come through):
<MichalN> #pmake: build os_os2 cpu_386
<RedBill> Michal, I don't like recursive calls of make either. I have always avoided it
<MichalN> host_os = os2
<MichalN> host_cpu = 386
<MichalN> !include ../mif/master.mif
<MichalN> That's all, just four lines.
<MichalN> If you want to build for 386 Linux, you just say 'linux' instead of 'os2'.
<MichalN> The master.mif is shared by all target platforms, and heavily uses default rules.
<eCSNL> It seems questions about he installer
<MichalN> Right now most projects can be built with either OW or GCC using the same makefiles. It wouldn't be that hard to support other compilers in the build system.
<eCSNL> are better of in the newsgroup that was put up.
<MichalN> For any technical questions about Open Watcom, the newsgroups at openwatcom.org are the best place.
<alex> It's my hope to create OW makefiles for my VAC projects.
<MichalN> Since that's where all the contributors hang out.
<alex> Eventually... esp. once they're open sourced.
<alex> My ideal is that all the major compilers have makefiles, and contributors can just use their preferred compiler.
<MichalN> alex: Shouldn't be too hard - wmake is pretty flexible. It supports two basic types of syntax, the default 'wmake' syntax and MS NMAKE syntax (real similar to IBM NMAKE).
<alex> Yes, it's the tool-specific syntax that's tricky.
<alex> wcc is pretty straightforward, but linking is where I hit the wall.
<MichalN> Of course wmake has special support for OW tools, like using DLL versions of the compiler/linker. That can make builds 10-30% faster.
<MichalN> alex: I recommend using wcl[386] for linking if you're not familiar with wlink.
<alex> I think I figured out the options syntax (finally), but it can't seem to find the PM APIs.
<alex> I couldn't quite figure out what wcl386 was for...
<MichalN> What PM APIs?
<alex> All of them.
<alex> Anything starting with Win...()
<MichalN> wcl386 is just a front end that calls wcc386/wpp386 and wlink for you.
* eCSNL pushes the big red button and the quiz buzzer sounds
<eCSNL> I would like to close these speakup officialy since we are an hour over time. It was supposed to take 2 hours. But I want to stop the logging.
<MichalN> That's all under h\os2 directory.
<alex> I guess it's my old habits...
<alex> I like to explicitly compile first, then explicitly link.
<alex> That's just the way I learned it...
<eCSNL> Everybody can of course continue to discuss things here but there will a second speakup about open watcom (see VOICE news for this).
<MichalN> You can use wcl386 for just linking. But if you want to use wlink directly, the manuals are probably the best place to start.
<MichalN> OK, let's stop logging and I can start saying politically incorrect things off the record :)
<RedBill> ok :)
<eCSNL> The log for the speakup will be posted on www.os2voice.org so the people for
<SimpsonTP> :D
<SimpsonTP> now it gets interesting
<RedBill> log file size 50k
<eCSNL> the session that will be on the 28th of May can read it and can ask questions.
<eCSNL> I also think that some of the questions ask belong in the newsgroups.
<MichalN> alex: were you asking about compiling PM programs or linking?
<MichalN> eCSNL: I could answer everything on the newsgroups ;) But real time communication has some advantages.
<eCSNL> I did not want to suggest it a few minutes ago
<eCSNL> but why not put up an IRC channel for
<eCSNL> open watcom ?
<MichalN> Because I can't promise I'd be there.
<MichalN> So right now is a good opportunity.
<MichalN> Unless this channel needs to be free for some other purpose right now?
<eCSNL> nope.
<alex> MichalN: linking.
<RedBill> alex, was os2386.lib included?
<MichalN> The basic syntax is 'wlink sys os2v2_pm file hello' - this will link a PM program called hello.exe.
*eCSNL* You there ?
<MichalN> If you tell me what the exact error message was, I can take a good guess at what it really meant.
<alex> Actually, this probably isn't the best occasion for detailed tech Q&A on my part, since I don't have OW installed on this PC. :|
<alex> I'm not totally sure how I got onto the topic, actually...
<MichalN> Well, go install it right now! ;)
<eCSNL> Everybody is welcome to continue asking questions here. I think its usefull to do speakups. People talk with each other. The next speakup is onthe 28th of May. Stay tuned on voice news.
<alex> My development drive has
<alex> about 100 MB free. :(
<MichalN> No good for the current OS/2 installer. The new/old one should handle that better.
<eCSNL> I would like to thank Michal for dropping by and all the visitors for giving there idea's and questions. But as host of the speakup I'm off to bed.
<MichalN> Good night ecSNL! I guess it's past midnight for you.
<Mangog> thanks MichalN
<eCSNL> Its 0:15 here...
<RedBill> thank you Michal for being here and answering our questions
<MichalN> Back to makefiles - when we build eg. SNAP for OS/2, we use a bunch of different compilers and tools, two very different installers... we can just run a make program and it spits a complete installer at the end.
<MichalN> I just don't see how an IDE would do that - it'd probably be a lot more work than using makefiles.
<RedBill> interesting
<eCSNL> People from the US and Canada. Stay tuned for the 28th voice speakup since it will also be during the day that you can follow it. Again thank you all for dropping by and more SpeakUps are in the pipeline. Good night.

SpeakUp ended at 18:18:55 EDT