Further to the discussion about Windows 98, it should be noted that even Microsoft have decided to drop support for the 98 platform. It is not the first program I have seen misbehave on 95/98, and not just segmentation issues either, and yet, these programs run flawlessly on other Windows operating systems that utilise a better memory protection scheme. As someone else has pointed out, it does appear to work fine on some installs of W98/WinMe. This potentially points to a bug in some other DLL or system driver that the GCC tools unfortunately tweak. Since installing anything to win98 can cause system drivers and DLLs to be altered, to find the root cause can at times be black magic. I personally use Win2k at present, but this has as much to do with other commercial software that I need on a day to day basis, and is not supported on a Linux platform. (Win2k has no problems with the tools suit either) If, in fact your windows 98 install has bloated to fill a twenty Gb hard disk drive, the potential problem sources ore so numerous, it is scary!
Even commercial companies have problems with this. Xilinx were caught with Win2k professional when Microsoft Service Pack 3 clashed with one of Xilinx's drivers. The outcome of that was that a reinstall of WIN2k was required! (No other fix, but windoz can be like that!) A team of several hundred programmers might still take a few weeks to find, and then fix, bugs like this. The mere fact that the tools work on any windows platform is a bonus. The tools are in fact so useful, that if they were not supported on a windows platform, I would arrange a Linux partition just to utilise the GCC, GDB etc. (My main machine is normally booted into windows, other machines though, run Linux. If people have issues with this, they can always work out the fixes themselves, and have them posted to the relevant repositories .I am sure the people who while away their lives in the development of the tools would appreciate the support. The fact that the tools have been written up in circuit cellar in no way should affect the way that development has proceeded, and will proceed in the future. It is fairly obvious that the people who do most development on the tools can be counted on one hand. (And I personally thank them for a job that is MORE than well done!) Even tools that seem to be "reliable" on windows 95/98 have always been far superior on NT4 and better windows operating systems. I realise that windows 95/98 do allow some ability to manipulate the I/O and memory space in a more direct fashion, but this facility undoubtably also has something to do with this segmentation failure. The time has come to bite the bullet, get rid of windows 98 (at least for serious development. Re-partition your hard disc subsystem, and multi boot win2k (or XP if you can handle a slow, bloated operating system), and also a Linux partition would be a very good idea. If you are happy to use GCC ports of a compiler for a microcontroller, you should also be happy using its big brother to do development on. Cheers, Harry -----Original Message----- From: mspgcc-users-ad...@lists.sourceforge.net [mailto:mspgcc-users-ad...@lists.sourceforge.net]on Behalf Of David Brown Sent: Wednesday, April 30, 2003 12:16 AM To: mspgcc-users@lists.sourceforge.net Subject: Re: [Mspgcc-users] Re: mspgcc is not a reliable Windows solution > .You are right about the fragility of this development. > A response to the " segmentation error issue " from one of the developers > Dmitry <di...@mail.ru> was and I quote. > "I cant help here, cause I'm not running windows" > Yet In the download web page Dmitry is given credit for the port toWindows > > I understand this is a free platform and that we should expect to get what > we paid for. However this is was promoted in Circuit Cellar in an article > about MPS430 and also at the mikrocontroller web site from which it was > downloaded. The article and the website say it is windows compatible > Some will always shoot or impune the messenger or grasp at any convenient > reason for the lack of results. Some will feel that the reporting of a > defect by a user brings with it the obligation for that user to undertake > fixing it. If this is the philosophy of this development group it will have > a chilling effect on the quality of the end product. Perhaps it already has > since the fact is this doesn't at the moment work reliably across Windows. > The msp430 gcc and gdb ports are perfectly usable on Windows, as long as you use real windows (NT, W2K, and possible XP) rather than toy windows (Win9x, including WinME). As far as I know, the compiler itself is fine under Win9x, but some people have trouble with gdb (and in particular, Insight). For some, it works fine, and for others it is unstable or fails to work at all - that's life with Win9x. It would be nice if Circuit Cellar and mikrokontroller made this a bit clearer, but then almost nobody considers Win9x to be a sensible choice of platform for serious development work. You will not find any modern commercial development software (for embedded development or otherwise) which lists Win9x as "recommended" - indeed, you will find very little modern software, except perhaps games, that recommends Win9x. Although most software will normally run on it, you must be prepared to accept problems and crashes with no apparent justifications - and that applies to simple word processors or web browsers, never mind development tools. Just ask Microsoft technical support how to improve the reliabilty of your Win9x system - the two suggestions will be to format the disk and re-install windows, or to upgrade to XP. Fighting with the inconsistencies and instabilities of Win9x is a waste of time for the msp430 gcc and gdb developers - they have plenty of far more useful work to do on the tools themselves. The tools rely on basic functionality being available in the underlying system - Linux and other unix-type OS's provide such functionality natively, and NT (including W2K and XP) provide most of it, while Win9x cannot provide reliable OS services such as process seperation or multi-tasking. The gdb tools use cygwin to provide the OS services on top of the underlying Windows system - for NT, this is can be done reliably since much of the groundwork is provided by NT. But Win9x is missing so much that by some definitions it cannot be classified as an operating system (after all, even WinME is fundamentally 16-bit single-tasking DOS with a partially 32-bit gui on top). Cygwin has only recently been able to work well on Win9x, and is regularly updated with fixes and improvements on Win9x. This is something that the Cygwin developers are working hard at, and the msp430-gcc developers can and should pretty much ignore Win9x-specific issues. So if you want to try using Win9x for development work, then by all means try, and let others know of your successes or failures. Sometimes there will be small things that can been done to fix problems, or there will be work-arounds. You can help by ensuring that you have the latest version of cygwin first - that can make a big difference. But if you really want to use a computer for work, and want to be able to rely on it, then switch to W2K (or, obviously, Linux, *bsd, etc.). Don't blame the msp430-gcc developers for MS's failures, and don't make the mistake of mixing up problems with individual Win9x systems with a working Windows port of the software. ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
