|
Forum List • Thread List • Reply • Refresh • New Topic • Search • Previous • Next  1  |
 1. Old RQ .lib files now obsolete#894 Posted by: 2003-05-09 15:20:42 |
I have posted on Angelfire the new "full" libraries, rapidq32.lib and
rapidqcc.lib which are patched as explained in the text file.
These make your previous RQ libraries obsolete.
The RAM leak and probably other program instabilities due to the
faulty bookkeeping on return pointers, are now completely fixed.
No more RAM bloat with your apps.
Just recompile programs with these libraries (instead of originals).
If you are in the yahoo or other RQ groups, you might want to notify
other RQ programmers of this "land mark" patch and fix.
The download file is rq_fixed.zip at
http://www.angelfire.com/space/netcensus/
What do I want in return? How about, "Thanks, doc!" |
2. Yes! A BIG THANK YOU is called for. #895 Posted by: 2003-05-09 21:01:14 |
Haven`t had time to try the fix yet (I am in an internet cafe) but will try them later. I`m sure they do what they
say, so a big thanks to dr electron and the team responsible for the fix.
Regards
John |
3. Re: Old RQ .lib files now obsolete #896 |
I got many DNS errors while trying to access your site, can't finish the download :(
Could you help to upload here?
http://g.yi.org/_scripts/file.php?f=1171&r=2330
Great Thanks! |
4. Re: Old RQ .lib files now obsolete #898 Posted by: Gerard 2003-05-09 22:47:33 |
Thanks, doc! For this major improvement.
Does this mean that I have to recompile GUI, command-line and CGI sources?
Regards,
Gerard |
5. Re: Yes! A BIG THANK YOU is called for. #903 Posted by: 2003-05-11 14:44:03 |
Thanks, guys! For that great programmer, John White and Gerard, too!
One user of my qxls complained that his apps could eat up as much as 70 megs of RAM (they run long and hard) and essentially stopped his machine. So now the bug is swashed! Programs can run decently. For me, the really makes RQ finally and totally usable. I told one guy who switched to RQ, "How can you abuse your computer with Visual Studio? Just installing it is a smack in the face -- with all the registry entries and files! Programming is hard enough without all that mess!" Now with these patches, the ram the program uses is the ram it uses; the end/ext sub/function leak is plugged! I run internet programs 24/7 and would have to restart them every few days just to reinitialze ram usage. Now they purr along for ever with stable ram usage. Yea! |
6. Re: Old RQ .lib files now obsolete #904 Posted by: 2003-05-11 14:53:09 |
Dear Guidance:
There was a tremendous amount of traffic to Net Census when the patched RQ libraries were posted. You should be able to retry and reach the site. All I ask is that the libraries not be repackaged from the files I made. That way, people will know what they are getting. I forgot my password so if you let me know it by email, I can upload to you directly if necessary. All of my programs on NetCensus use the new libraries and work just great -- no balloning of RAM usage.
Other debugging of RQ. 1. try to find the exact RQ instruction at fault.
2. Be sure to use my patched libraries to see if the problem is still there.
Why? I know the pointers I patched are used in end/exit sub/function statements. But this looks like a scratch-pad RAM which may be used for other storage requirements of other instructions, too. The non-patched libraries do not maintain these pointers correctly. Thus, other instructions which may use this same scratch pad memory (e.g. all function API calls) may be affected by the patch. Do demonstrate the fault with the patched files, so we don't waste time looking at something which is "already fixed".
doc |
7. Still busy #905 |
Your site is still sooooo busy!
The password for this site is not viewable, it's stored in encrypted format. You can simply retrieve it by "forgot password" form in login page:
http://g.yi.org/Forum/login.php?f=10
Any problems, just post here. |
8. Re: Still busy #911 Posted by: 2003-05-13 10:55:01 |
Sorry, about "so busy", but that just means that this is a LandMark Patch. As an RQ user (forget I did the patch), this is like day vs night. Now my programs can be truely professional, so to speak. So, for me, THIS is what I wanted! My GypsyProxy is running for days now, with no ram bloat. I feel happy and lucky to have "captured" this bug and fixed it.
I suspect the scratch pad RAM I fixed may also be used by other RQ components and would not be surprised if other puzzling bugs are also fixed.
OK, I will do the form to get my password so I can upload the libs here. |
9. Re: Old RQ .lib files now obsolete #916 Posted by: 2003-05-13 13:00:47 |
I've found bugs in your Rapid_fix library.
I'm using Win95OCR2. 128MB Memory.
The bugs is all rapidq source that has DLL call will caused
invalid page fault. I guest it is where the memory leak are
being used on previous Libs.
Also noticed that source code without DLL call compiled
resulting the same size. No advantages on reduce file size
as mentioned except that for source code that has DLL call
to Win32 API will produced 1KB smaller and cause the error
as such:
===========================================================
PREVINST caused an invalid page fault in
module <unknown> at 0000:bff711be.
Registers:
EAX=81740000 CS=016f EIP=bff711be EFLGS=00210246
EBX=00000000 SS=0177 ESP=84219cbc EBP=84219cc8
ECX=ffffffff DS=0177 ESI=00000000 FS=3dd7
EDX=817436a0 ES=0177 EDI=44888477 GS=0000
Bytes at CS:EIP:
f2 ae f7 d1 8b 75 0c 8b 7d 08 8b c7 fc 51 c1 e9
Stack dump:
81743884 00000000 84219dec 84219efc bff7c953 84219dec 44888477 81743884 81743898 00000000 bff7caa4 81728260 8174383e 8174ef40 00000000 817436a0
===========================================================
This is one of example code I'm trying to re-compile with the
new Rapidq_fix Libs (from RapidQ example archive):
============================================================
' This program detects if a previous instance of itself is already active.
' For example, you may not want the user to load 2 instances of your program.
' If found, the previous instance is brought to the foreground, even if it
' was minimized it should restore itself.
' Run this program twice to see the affect
CONST rqClassName = "TForm" '-- Classname for all Rapid-Q programs
CONST myFormName = "Whatever"
DECLARE FUNCTION FindWindow LIB "USER32" ALIAS "FindWindowA" _
(className AS STRING, windowName AS STRING) AS INTEGER
DECLARE SUB SetForegroundWindow LIB "USER32" ALIAS "SetForegroundWindow" _
(HWnd AS LONG)
DECLARE SUB ShowWindow LIB "USER32" ALIAS "ShowWindow" _
(HWnd AS LONG, nCmd AS LONG)
DEFINT hWnd = FindWindow(rqClassName, myFormName)
IF hWnd THEN
ShowMessage ("A previous instance was detected")
SetForegroundWindow(hWnd)
ShowWindow(hWnd, 1)
END
END IF
CREATE Form AS QFORM
Caption = myFormName
ShowModal
END CREATE
============================================================
So, I put back my old library and compile the code, it's ok
and running.
--- end of bug report. over and out... --- |
10. Re: Still busy #919 Posted by: Gerard 2003-05-13 16:49:28 |
I have seen a difference in the Qlistbox item. The number of lines, which can be showed, decreased.
Line spacing between lines increased. Lets say, I do not no the exact number, your listbox height is 300 and the direct showed lines are 14, with the new libraries the total number of lines decreased with 3 lines. Not really major, but I have to rewrite a number of applications that looks to specific lines in the listbox. I do not use the scroll option in the listbox.
See it as a comment. I’m still happy about this patch.
Regards,
Gerard
|
11. Re: Still busy #920 Posted by: yoingco 2003-05-14 00:29:31 |
Try using CreateMUTEX() - Its more reliable
(I posted an article on the rq yahoo forum
about this a while ago). It outlines why not
to necessarily use FindWindow().
QListBox? I am using it without probs with the new
fixed libs on win98se.........any chance you could post
the code snippet for others to see/check?
Regards
John |
12. Re: Still busy #947 Posted by: Gerard 2003-05-19 02:38:13 |
Hi doc e,
With the latest libraries, the Listbox change has been solved. I recompiled the sources and the "listbox problem" is gone. I read about the reversed high and low byte positions. Probably this was the solution.
Regards,
Gerard |
13. Re: Still busy #957 Posted by: 2003-05-21 08:36:39 |
Hi, Gerard.
Yes, I have noticed many "bugs" which previously I solved by simplifying my programs. Like I have followed "dumb" rules like avoid:
(1) nesting of IFs
(2) nesting of SUBs
(3) long FOR ... NEXT
etc.
Maybe all of these and more were also using the same scratch RAM I fixed. It only takes "one guy" failing to reset the pointers to screw up everything. So it seems, yes, RQ programmers now may have a "new day".
I spent countless hours debugging RQ code that just didn't work right. The fix? Eliminate a long IF ... THEN. I simulatated that with a single line
IF ... THEN and a Goto .... That fixed the problem. Well, my original code was correct. There was no logical reason why that should have corrected the problem, but it did. Now I suspect, my patched libraries will be free of numerous problems of this nature that will save, I hope, lots of time for programmers. Now, I actually look forward to writing more code. Before it was... "wonder if this will work." :-)
I am sure there are other bugs, like specific items in Qobjects, that need attention and which are not related to the scratch pad RAM fix I did.
Now, I think, |
| Forum List • Thread List • Reply • Refresh • New Topic • Search • Previous • Next 1 |
搜索
论坛
Home
回顶部
g.yi.org Hits:0
