Re: [fpc-pascal]About order of units...
In reply to your message of August 30, 2003 > h2pas is only a helper program that does the major part of C header > translation. It uses longint by default as parameter type for > macro's. When you want to have correct macro's you need to create/edit > them manualy. Yep... I know. But it occurs to me that whoever did the conversion didn't check very carefully. - L D Blake ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: Hacking was Re: [fpc-pascal]Lazarus
> > That's so pathetic. What'd the hacker do anyhow ? And how the heck does > > > a hacker break into a *nix box ? (I assume it is...) > > It's easy. At least if you run an old redhat, or run some of the dangerous > > services. > You really need to be deligent and keep up with the security updates and > apply them when a hole comes up. I was busy and lazy and didn't get around > to one of them and that is how they got in. :-\ It happens to the best of them... http://linuxtoday.com/news_story.php3?ltsn=2000-05-05-009-04-PS http://www.internetnews.com/infra/article.php/2248811 __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]About order of units...
On zondag, aug 31, 2003, at 20:40 Europe/Brussels, L D Blake wrote: Ok, I can accept that... but now I'm left to wonder what is causing all those bizarre range checking errors At least some of the range check errors are due to errors in the Windows unit (mingling cardinals=dwords and longints). However, these are not errors that will change the course of your program in any way, as the data passed around doesn't change because of these typings. It's of course possible you have other range errors in your program as well, but that you can't discover them because it bombs out earlier because of the windows unit mess. Have you already tried using -ghl to check for memory errors? Jonas ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]About order of units...
In reply to your message of August 31, 2003 > I simply think you're on > a bad track suspecting that your problems are originated from some bugs > in Windows unit. Ok, I can accept that... but now I'm left to wonder what is causing all those bizarre range checking errors and why my project's screens draw as they do. The most puzzling is how launching a file in a completely different program can cause range checking errors in mine. There is definately something damned weird going on... but where, and why? I gotta confess, if it's not the windows unit, I have absolutely no clue what the problem is... I've been over my own code, checked declarations, disabled and rewritten things and nothing changes the errors I'm getting. Nothing eliminates the errors, nothing prevents the screen from getting scrambled and I'm not going to finalize a project that won't run with overflow, stack, and range checking turned on and I'm certainly not going to finalize one that bombs out when other windows are opened... - L D Blake ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]About order of units...
L D Blake wrote: In reply to your message of August 31, 2003 If you have a look at the implementation, you'll quickly find, that all of the examples you listed in this mail make absolutely _no_ difference. It DOES matter, especially in structures where windows is accessing things as an offset from a pointer. Typing something as a 4 byte variable instead of a 1 or 2 byte one will result in wrong structure sizes causing all kinds of errors inside windows where we can't really trace them down... The same is true of parameters passed in API calls, hand it 4 bytes instead of 1 or 2 and you've just offset the rest of the parameters, causing errors, never mind the potential for passing grossly incorrect data... and I'm pretty sure that's what I've got going on. ... L D Blake No, L.D. Blake, it doesn't matter. Tomas was right. All the things that you showed as having bad parameters are _macros_, not _API calls_. This is why h2pas generated "LongInt" types for theses parameters. And this is also the reason why it doesn't hurt : even if WinAPI docs states that some macro takes Byte as parameter (which is just a specification of the "proper use of the macro", because in actual C code macro's parameters have no assigned type), and in our Windows unit it takes LongInt (and than casts it in the implementation to Byte before doing some bit-shifts) it will not cause any errors. Because this is a macro: it is basically just some utility routine that is written and compiled in FreePascal. It is NOT something that is called from some Windows system DLLs. So even if we have LongInt parameters where WinAPI Help states that these should be Byte - it doesn't hurt, it will not cause any errors. In response to your next letter (that I just received), I can guarantee you that Windows unit IS extensively used and it is tested all the time. It is a base unit for many other units in FPC, some of them multi-platform, some of them Windows-specific. I simply think you're on a bad track suspecting that your problems are originated from some bugs in Windows unit. Regards, -- Michalis Kamburelis <[EMAIL PROTECTED]> http://www.camelot.homedns.org/~michalis/ ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal]runtime error 6
I am getting runtime error 6 with a "while not eof(filename)" statement in a DOS program I am writing. I already successfully used it twice previously in the same program (I actually copied the previous code and altered it for the new filename and altered functionality), but when I have used it with a third file I get this error. The documentation (as far as I can see) doesn't really tell me how to fix this, and I don't fully understand the explanation of the problem anyway (especially since I didn't have any problem with the other 2 files previously). Can anyone shed some light on this for me? thanks, DONALD. E-mail - [EMAIL PROTECTED] BIG DON's Home-page - http://jedi.apana.org.au/~jims_son Pedder Passer Rating - http://jedi.apana.org.au/~jims_son/PPR AusNFL mailing-list - http://jedi.apana.org.au/mailman/listinfo/ausnfl "What I always wanted is to be accepted, not understood" - MAN RAY ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]About order of units...
In reply to your message of August 31, 2003 >>Yep... I know. But it occurs to me that whoever did the conversion didn't >>check very carefully. > When the windows unit was created it was more important to get the compiler > running correct natively under windows. After that nobody took care of > walking the whole windows unit because it is a boring job to do. The > windows unit worked for us and the users didn't report problems so it > stayed that way. The current developpers have other priorities that they > want to do than updating the windows unit. FPC is open source so you are > welcome to supply patches to fix the windows unit. I am still learning here, Peter... I know TP 5 from years ago, I know windows from last month and I haven't even ventured in to OOP yet... I really don't think myself qualified to take on a big job like this, at least not right now. That said... I will be happy to work with, perhaps coordinate, a group of more advanced FP users who DO want to take on the task of improving the unit. I have the time (and hopefully the patience) to go through the source and find all the obvious errors, perhaps even do some minor bug fixing. If a couple of others would like to help with compiling (I can't get this unit to compile to save my soul!) and testing maybe we can get the job done. But then... that's a 5 year old unit that never had any real testing or developement, it might actually be worthwhile to reconstruct the unit from scratch. The new Platform SDK from Microsoft has all the .h files for nt4, 2000, xp, and 2003 in it, including support for transparency, overlays, xp styles, and a bunch of nifty new controls that are in the current versions but are not supported by FP. It might actually make more sense to start over rather than simply patching up an antique. Anyone who'd be willing to take this on can contact me privately as [EMAIL PROTECTED] and we can at least discuss the idea. - L D Blake ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]About order of units...
In reply to your message of August 31, 2003 > If you have a look at the implementation, you'll quickly find, that > all of the examples you listed in this mail make absolutely _no_ > difference. It DOES matter, especially in structures where windows is accessing things as an offset from a pointer. Typing something as a 4 byte variable instead of a 1 or 2 byte one will result in wrong structure sizes causing all kinds of errors inside windows where we can't really trace them down... The same is true of parameters passed in API calls, hand it 4 bytes instead of 1 or 2 and you've just offset the rest of the parameters, causing errors, never mind the potential for passing grossly incorrect data... and I'm pretty sure that's what I've got going on. As I explained earlier... I'm getting re-draw errors. Not only is my project losing it's title bars, it is redrawing window frames in the wrong places and sometimes it redraws the wrong window altogether... Try moving one window and it draws the frame of a different window in the wrong place on the screen. If I turn on range checking I get a 201 error (range check) from my program every time I try to open an HTML file (i.e. the FP docs) in IE... This is especially weird since int's only HTML and only in IE... nothing else. And I get hundreds of Range errors as the program runs (it's mostly api calls at this point). Errors like these from supplied units is a serious impediment to the developement of bug free, reliable software, which is what Pascal is supposed to be all about. It's strength is in it's rigid error checking. - L D Blake ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]About order of units...
From: L D Blake <[EMAIL PROTECTED]>
Organization: Secret society to end secret societies
To: Marco van de Voort <[EMAIL PROTECTED]>
Subject:Re: [fpc-pascal]About order of units...
Send reply to: [EMAIL PROTECTED]
Date sent: Sat, 30 Aug 2003 15:29:48 -0400
> From base.inc ...
>
> { was #define dname(params) def_expr }
> { argument types are unknown }
> function HIBYTE(w : longint) : BYTE;
>
> Should be hibyte(w : word) : byte; according to the SDK.
>
>
> { was #define dname(params) def_expr }
> { argument types are unknown }
> function HIWORD(l : longint) : WORD;
>
> Should be hiword(l : longword) : word;
.
.
If you have a look at the implementation, you'll quickly find, that
all of the examples you listed in this mail make absolutely _no_
difference. For example:
--
function HIBYTE(w : longint) : BYTE;
begin
HIBYTE:=BYTE(((WORD(w)) shr 8) and $FF);
end;
-
The first thing being done with the supplied argument is type casting
to a word. BTW, at least some of these macros could probably be
implemented more efficiently using some pointer arithmetics, but
that's a different story.
Tomas
___
fpc-pascal maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]More strangeness...
From: L D Blake <[EMAIL PROTECTED]> Organization: Secret society to end secret societies To: Peter Vreman <[EMAIL PROTECTED]> Subject:Re: [fpc-pascal]More strangeness... Send reply to: [EMAIL PROTECTED] Date sent: Fri, 29 Aug 2003 19:12:04 -0400 > > And it has been already a longint for 5 years. > > Which pre-dates all of NT4, win2000, XP, 2003 ... Which are true 32 > bit operating systems. . . NT4 is available since around, IIRC. Tomas ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]About order of units...
> h2pas is only a helper program that does the major part of C header > translation. It uses longint by default as parameter type for > macro's. When you want to have correct macro's you need to create/edit > them manualy. Yep... I know. But it occurs to me that whoever did the conversion didn't check very carefully. When the windows unit was created it was more important to get the compiler running correct natively under windows. After that nobody took care of walking the whole windows unit because it is a boring job to do. The windows unit worked for us and the users didn't report problems so it stayed that way. The current developpers have other priorities that they want to do than updating the windows unit. FPC is open source so you are welcome to supply patches to fix the windows unit. Peter ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]About order of units...
In reply to your message of August 31, 2003 > At least some of the range check errors are due to errors in the > Windows unit (mingling cardinals=dwords and longints). However, these > are not errors that will change the course of your program in any way, > as the data passed around doesn't change because of these typings. It's > of course possible you have other range errors in your program as well, > but that you can't discover them because it bombs out earlier because > of the windows unit mess. Exactly... I want to find MY mistakes... but I am being hindered because of the errors occuring elswhere. I'm aware that most of the errors won't affect performance but they do make a mess of my own efforts to perfect my code. > Have you already tried using -ghl to check for memory errors? No not yet... but I will. The program is only 66k (so far) so I doubt I'm having memory problems in a 256meg machine, but you never know. FWIW... I think I've found one of the problems. I'm using a scrollbar as a song position indicator, commenting out the code that enables and disables that particular child window seems to get rid of the screen scattering problem... so I have to look much more closely at the way I'm manipulating it. Of course I still get a gazillion range checking errors which isn't helping me find the other problems and I still get that pesky range error from my proggy whenever I open the FP docs... This is why I was suggesting that maybe we (?) should look into updating the windows unit... get it to match the SDK specs and add in the new controls for 2k, xp and 03 while we're at it. - L D Blake ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal]Problem - ocrt.pp & cp1251
Hello! I use ocrt unit since a couple of moths and I found it very useful. The problem occures when I use nEdit function for string type variable. In the codepage cp1251 (microsoft :-((( ) the symbol with code 255 ($FF) is a cyrillic letter that sounds like "ya". When I press its key, nothing happens, the function rejects the input. I walked by the source and I saw that the symbol #255 is used to mark some internal events. This codepage is used in Bulgaria. I don't know the historical reason why this codepage is chosen in my country, but I have to cope with this. I have no that much time to rewrite that huge function... Any suggestions? TIA! Ivan Petrov ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]About order of units...
From: L D Blake <[EMAIL PROTECTED]> Organization: Secret society to end secret societies To: Michalis Kamburelis <[EMAIL PROTECTED]> Subject:Re: [fpc-pascal]About order of units... Send reply to: [EMAIL PROTECTED] Date sent: Sun, 31 Aug 2003 14:40:33 -0400 > > I simply think you're on > > a bad track suspecting that your problems are originated from some > > bugs in Windows unit. > > Ok, I can accept that... but now I'm left to wonder what is causing > all those bizarre range checking errors and why my project's screens > draw as they do. The most puzzling is how launching a file in a > completely different program can cause range checking errors in mine. I have one idea (although I'm no windows programmer). How do you play sound files - using some kind of your own code, or relying on default Windows handlers (i.e. installed Windows codecs)? If it's the latter, you might be possibly using IE for playing your sound files even without knowing it. That might be a possibility how starting IE might influence your program. Tomas ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]About order of units...
In reply to your message of August 31, 2003 > I have one idea (although I'm no windows programmer). How do you play > sound files - using some kind of your own code, or relying on default > Windows handlers (i.e. installed Windows codecs)? If it's the latter, > you might be possibly using IE for playing your sound files even > without knowing it. That might be a possibility how starting IE might > influence your program. Sound play is done through the MMSYSTEM unit, which is the interface to MCI (i.e. Codecs). I had no idea that IE might be involved... but it might explain one more of the problems... I might actually be running afoul of my pop-up killer by trying to open two ie windows at once ... now wouldn't that be a laugh! Can anyone confirm if IE would be involved when playing midi, wmi, wave, and mp3 audio files? - L D Blake ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
