I think it's a speed thing. It turns up in faster machines too but not as frequently. The compiler was probably designed for a 486 or even 386, windows yes but not NT. On a 486 under DOS it's fine. It isn't my code that's doing it: it's the compiler or its libraries but is shouldn't be executing anything except itself at that point. The weirdness is that lack of consistency. It might go through, it might fail the moment it starts or anywhere between. A soft bug I'd expect to blow up after a specific time and probably as it's working on a particular source library - which it lists to screen as its going.
My main concern was to check whether it would work (including run the result since it's an intermediate translating system) with NT. If it won't, it won't. I don't want my home stuff under NT anyway!
Truth is, I don't like mysteries and 'General Error' is as bad as 'DOS Error 21' for informativeness.
Thanks. It's not because of old hardware: just the reverse. It is worse on the test machine but it happens on the P3s as well. There may well be bugs in some of the source libraries. I've fixed the ones that actually threw compilation errors. From what you say is sounds like the compiler should be handling this and isn't. It does run in Protected. What puzzles me is the inconsistency but I'm getting a picture that possibly the code isn't fast enough to catch all the interrupts on this machine while on slower ones it does and on faster some of them get just plain lost so fewer get through to throw it out.
I'm hoping to get a Linux fixed anyway and there is one compiler, one Algol68-to-C translator free for that. My original intention was to get stuff working and run it through the A2C to get an idea of the various C (or rather C++) libraries involved in standard work. I find C/C++/Java messy, inconsistant and feeble but they happen to be what's in use. Somehow you don't see that many adverts for Eiffel, Ada, Mod3 or other exotica just like nothing ever stood a chance against Fortran and Cobol however much better.
It doesn't always work fine, just fewer of these weirdies on Pentium 3. I think it's probably incompatibilities with NT but it's strange that there's no consistency as to when it happens or whether it goes through OK. If it won't run on NT then it won't. But I'd love to know what's going on there. On really antique H/W - 486 under DOS it's fine. I expect it is Windows 95/98 compatible but not NT.
Well that clears the confusion about which meaning the interrupt has. Assuming that is that it didn't change after the 286 (Did anyone ever see a 286?). But WTF is 'General Protection Error' asposed ta mean? All I know is that it comes up on faster machines too but not as often and there is no regularity so it does look more like something machine side than software side. It's a mystery but I'm not losing much sleep over it because I'm only using something I know in the hopes of quick&dirty and also putting it through a C++ translator to familiarise with learning that horror.
You could have a point. It's 96M and the problem is NT. With an old DOS box it behaves itself. I've met this random interrupt on faster NTs at work but not as often. That's why I was surprised to find it coming up so much. I think it must be something to do with a slow machine.
I did and it doesn't apply. That's why I posted it here. It doesn't occur at any specific point where I could guess my software is incompatible and there's no drive access going on. Unless it occurs as a 'normal' feature and NT usually handles it out of the way. It isn't even consistent between different user interfaces. What I was looking for was a way to integrate old command line stuff into NT with a reasonable user interface, which Take Command more or less provides (and to find out what it will do as compared to what it's supposed to do). I have got it through since - sometimes - but I guess it's just a case of do it MuckySoft's way or forget it. There are times when sodding about with setting windows up is not worth the effort compared to a quick dirty command line. But I was hoping it needn't be quite as dirty as what's provided!
I'm mostly replying to the one above because I can't find a 'reply' for it. "Hello World".print sounds the hell of a lot like SmallTalk. If you like a language where CASE and ELSE-IF are impossible because a program statement is an object and an object must have finite limitations, where every dimension of array needs a separate definition, then ST for you! Personlly, I suspect *all* these Ultimate Solutions of faddism. There are occasions where 'goto' is useful - even if disguised as 'break' or 'continue' or even 'throw', which is the worst example of unstructured programming I can think of. OK, I have a bias here: my favourite for personal hacking has been Algol-68 for about 15 years. None of that having to remember that C(++) can't tell that one part of a CASE ends when the next begins, no worries about one form for IF that doesn't assign, another if it does, no incomprehensible near-assembler loops or syntactic distinctions between test before/test after. And, if you really want it, yes a Procedure has as much right to be part of a Structure as anything else. Are the complexities of 'black boxing' objects (a sure way to make using them 100 times more difficult as there's no knowing what's going on) really necessary once precompiled libraries can be called or read-only modules inserted? I suspect here a certain amount of gimmickry because C is such a lousy Fortran-inspired mess.
I think it's a speed thing. It turns up in faster machines too but not as frequently. The compiler was probably designed for a 486 or even 386, windows yes but not NT. On a 486 under DOS it's fine. It isn't my code that's doing it: it's the compiler or its libraries but is shouldn't be executing anything except itself at that point. The weirdness is that lack of consistency. It might go through, it might fail the moment it starts or anywhere between. A soft bug I'd expect to blow up after a specific time and probably as it's working on a particular source library - which it lists to screen as its going. My main concern was to check whether it would work (including run the result since it's an intermediate translating system) with NT. If it won't, it won't. I don't want my home stuff under NT anyway! Truth is, I don't like mysteries and 'General Error' is as bad as 'DOS Error 21' for informativeness.
Thanks. It's not because of old hardware: just the reverse. It is worse on the test machine but it happens on the P3s as well. There may well be bugs in some of the source libraries. I've fixed the ones that actually threw compilation errors. From what you say is sounds like the compiler should be handling this and isn't. It does run in Protected. What puzzles me is the inconsistency but I'm getting a picture that possibly the code isn't fast enough to catch all the interrupts on this machine while on slower ones it does and on faster some of them get just plain lost so fewer get through to throw it out. I'm hoping to get a Linux fixed anyway and there is one compiler, one Algol68-to-C translator free for that. My original intention was to get stuff working and run it through the A2C to get an idea of the various C (or rather C++) libraries involved in standard work. I find C/C++/Java messy, inconsistant and feeble but they happen to be what's in use. Somehow you don't see that many adverts for Eiffel, Ada, Mod3 or other exotica just like nothing ever stood a chance against Fortran and Cobol however much better.
It doesn't always work fine, just fewer of these weirdies on Pentium 3. I think it's probably incompatibilities with NT but it's strange that there's no consistency as to when it happens or whether it goes through OK. If it won't run on NT then it won't. But I'd love to know what's going on there. On really antique H/W - 486 under DOS it's fine. I expect it is Windows 95/98 compatible but not NT.
Well that clears the confusion about which meaning the interrupt has. Assuming that is that it didn't change after the 286 (Did anyone ever see a 286?). But WTF is 'General Protection Error' asposed ta mean? All I know is that it comes up on faster machines too but not as often and there is no regularity so it does look more like something machine side than software side. It's a mystery but I'm not losing much sleep over it because I'm only using something I know in the hopes of quick&dirty and also putting it through a C++ translator to familiarise with learning that horror.
You could have a point. It's 96M and the problem is NT. With an old DOS box it behaves itself. I've met this random interrupt on faster NTs at work but not as often. That's why I was surprised to find it coming up so much. I think it must be something to do with a slow machine.
I did and it doesn't apply. That's why I posted it here. It doesn't occur at any specific point where I could guess my software is incompatible and there's no drive access going on. Unless it occurs as a 'normal' feature and NT usually handles it out of the way. It isn't even consistent between different user interfaces. What I was looking for was a way to integrate old command line stuff into NT with a reasonable user interface, which Take Command more or less provides (and to find out what it will do as compared to what it's supposed to do). I have got it through since - sometimes - but I guess it's just a case of do it MuckySoft's way or forget it. There are times when sodding about with setting windows up is not worth the effort compared to a quick dirty command line. But I was hoping it needn't be quite as dirty as what's provided!
I'm mostly replying to the one above because I can't find a 'reply' for it. "Hello World".print sounds the hell of a lot like SmallTalk. If you like a language where CASE and ELSE-IF are impossible because a program statement is an object and an object must have finite limitations, where every dimension of array needs a separate definition, then ST for you! Personlly, I suspect *all* these Ultimate Solutions of faddism. There are occasions where 'goto' is useful - even if disguised as 'break' or 'continue' or even 'throw', which is the worst example of unstructured programming I can think of. OK, I have a bias here: my favourite for personal hacking has been Algol-68 for about 15 years. None of that having to remember that C(++) can't tell that one part of a CASE ends when the next begins, no worries about one form for IF that doesn't assign, another if it does, no incomprehensible near-assembler loops or syntactic distinctions between test before/test after. And, if you really want it, yes a Procedure has as much right to be part of a Structure as anything else. Are the complexities of 'black boxing' objects (a sure way to make using them 100 times more difficult as there's no knowing what's going on) really necessary once precompiled libraries can be called or read-only modules inserted? I suspect here a certain amount of gimmickry because C is such a lousy Fortran-inspired mess.