Subj : Re: bcc 5.02 command line v. ide To : borland.public.cpp.borlandcpp From : David Morris Date : Fri Dec 03 2004 08:27 am "Ed Mulroy [TeamB]" wrote in message news:41af39d2$1@newsgroups.borland.com... > Not really. It is the same code base. The wrapper and a > couple of modules giving extra capability are what is > changed. For example: the DLL is launched as a DLL instead > of as a standalone program so accepts commands from the > loading program instead of from a user's command line. Well, years ago I had a problem where I had a DEBUG and RELEASE version of my code. The DEBUG version worked fine, but I had really weird issues with the RELEASE version. I learnt my lesson and tested only with the release version. Now this was while I was still learning 'c' (it may even have been with Turbo C 2.0), and so lost confidence in using the debugger and I never really got in control of it. I found it quicker to insert printf() and getch() to see what was going on, and I still do that today. (This is probably one of those few times when a debugger might help!) > > ... I'll try that with a broken down into an individual > > projects version, and see what I get. ... > > FYI: > For production code I always make an individual project for > each target. I can see why (now), and it is another good reason to move to hand coded make files. ... > If you wanted to drive the serial port yourself in 32 bit Windows > you would have to create a virtual device driver (VxD, Win95/98) > and a kernel mode driver (WinNT/2K/XP) and arrange for them > to both supply the services expected by Windows and replace > the one Windows provides. I already have (this time my own) Windows 32 bit Serial port routines using the Windows API (which works fine). I was actually looking for some 32bit (asm) DPMI code for DOS. I have run out of room in the DOS executable for features that I can still add to the Windows Console (and Service) version of the MonTel Server (The software that reads the serial port from a PABX). To be honest most of my customers want the Windows Service version of the MonTel Server in any case, but I have always found DOS to be much more reliable than windows and obviously less demanding of hardware and I tend to be more confident about recommending it. (Though fewer and fewer customers have the technical skills to maintain a DOS application.) ....DM: > > I'll try that with a broken down into an individual > > projects version, and see what I get. I still ended up with something rather less than useful - the make file pushed its settings into temp files, which means I'll need to edit it so I can read their contents (change to the equivalent of KEEP from NOKEEP in nmake terms). Incidentally, since I may end up using a Microsoft compiler for the Windows code, I am using nmake format make files. That created its own issue for dependencies, and I ended up having to coble together a MAKEDEPEND tool (as per unix), source found on the net, but with some added extras by me. Hopefully, these files use a common sub set of make commands that might also work on other (non Microsoft) platforms. I have target for 'clean' and 'all', and also 'construct' for creating all intermediate folders. FYI, I now know why the code is performing differently, even if I don't know the cause. I was linking the (own) library modules in a different order. When linked in the same order both the IDE and the hand coded make files produce code that performs the same way (that is with or without errors). Despite trawling through the map file but I have not yet found out why, but at least I now have some confidence that I can produce the same output in the hand coded make files. I don't think I would have got so far if I hadn't made these posts. A part from your help, I think it is some times good just to try and describe the problem to someone else (who can understand what you are talking about!). regards DM .