Re: [twsocket] THTTPCli false 404 pages
Try using an Agent property value the same as the one used by IE. Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] Author of ICS (Internet Component Suite, freeware) Author of MidWare (Multi-tier framework, freeware) http://www.overbyte.be - Original Message - From: [EMAIL PROTECTED] To: TWSocket@elists.org Sent: Monday, June 12, 2006 3:37 AM Subject: [twsocket] THTTPCli false 404 pages Please offer suggestion for this circumstance -- If I use httpcli to get this page: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItemitem=6286283929 everything is perfect. If I try to get non existent auction at same site with INTERNET EXPLORER for example: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItemitem=notauctionnumber is the non existent auction URL. Then a fancy page appears saying item does not exist. WITH HTTPCLI, it gets a 404 error. I have guesses that the ISAPI.dll sends back the fancy -page to IE or that it is something else. Is there any way to get same page as IE? What am I doing wrong for this circumstance with nonexistent auction number? - This mail sent through IMP: http://horde.org/imp/ -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] New ICS-V6 beta
As usual you forgot about the SSL side, right? The .inc' Arno produced for me seems not compatible with the new buffering system! It is exact that I didn't checked the SSL stuff. I was thinking there was no impact on it. Anyway, ICS-V6-SSL is alpha code and is not even available. Also there was no BCB2006 package included!! This package is still alpha code. Your current package is not impacted by the changes. Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] Author of ICS (Internet Component Suite, freeware) Author of MidWare (Multi-tier framework, freeware) http://www.overbyte.be - Original Message - From: Fastream Technologies [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Monday, June 12, 2006 7:36 AM Subject: Re: [twsocket] New ICS-V6 beta As usual you forgot about the SSL side, right? The .inc' Arno produced for me seems not compatible with the new buffering system! Also there was no BCB2006 package included!! Regards, SubZero - Original Message - From: Francois PIETTE [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Sunday, June 11, 2006 8:38 PM Subject: Re: [twsocket] New ICS-V6 beta : To test the new buffering, is it sufficient to copy on the wsockbuf.pas? : My : copy here uses ICSv6SSL and I do not want to change the entire package due : to time constraints... : : Defenitely not. There are changes in WSocket.pas also. All to buffer : handling has been moved to WSockBuf?.pas. Previously only the buffer class : was in WSockBuf.pas. Now the manager is also there. TryToSend and : PutDataInSendBuffer are the most updated routines in TWSocket. Use WinMerge : to find out the changes. : : Only WSockBuf.pas and WSocket.pas has been changed. I think there is no : problem for you to replace those files and even the whole stuff because I : included all your changes and Arno's changes as well. : : -- : [EMAIL PROTECTED] : http://www.overbyte.be : : - Original Message - : From: Francois PIETTE [EMAIL PROTECTED] : To: ICS support mailing twsocket@elists.org : Sent: Sunday, June 11, 2006 7:04 PM : Subject: Re: [twsocket] New ICS-V6 beta : : : Forgot to say that multithread application should also benefit of the : buffer : scheme change because of better concurrency. There is now one critical : section per component instead of one global critical section. : In the future I plan to use a global list of free buffers to reduce : memory : allocation even more. : : -- : [EMAIL PROTECTED] : http://www.overbyte.be : : : - Original Message - : From: Francois PIETTE [EMAIL PROTECTED] : To: twsocket@elists.org : Sent: Sunday, June 11, 2006 5:31 PM : Subject: [twsocket] New ICS-V6 beta : : : I've just uploaded a new ICS-V6 beta to my website. : This version include: : - Latest Arno Garrels fixes and changes (Mostly to support ICS-SSL) : - Latest fastream changes (Mostly to support CBuilder 2006) : - My own changes (A completely revamped TWSocket buffer scheme). : : The new buffer scheme (Located WSockBuf.pas source file) use two doubly : linked list of buffer to optimise memory allocation. This should be much : faster that previous version, specially when putting a lot of data into : the : send buffer (writing fatser than network speed). : : Any comment welcome. : : : -- : Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html : -- : [EMAIL PROTECTED] : http://www.overbyte.be : : : -- : To unsubscribe or change your settings for TWSocket mailing list : please goto http://www.elists.org/mailman/listinfo/twsocket : Visit our website at http://www.overbyte.be : : -- : To unsubscribe or change your settings for TWSocket mailing list : please goto http://www.elists.org/mailman/listinfo/twsocket : Visit our website at http://www.overbyte.be : : -- : To unsubscribe or change your settings for TWSocket mailing list : please goto http://www.elists.org/mailman/listinfo/twsocket : Visit our website at http://www.overbyte.be : : -- : To unsubscribe or change your settings for TWSocket mailing list : please goto http://www.elists.org/mailman/listinfo/twsocket : Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] THTTPCli false 404 pages
Hi ! Opera also gets the fancy page, so it's probably not IE-related. Cheers, Peter On Mon, 12 Jun 2006 03:37:34 +0200, [EMAIL PROTECTED] wrote: Please offer suggestion for this circumstance -- If I use httpcli to get this page: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItemitem=6286283929 everything is perfect. If I try to get non existent auction at same site with INTERNET EXPLORER for example: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItemitem=notauctionnumber is the non existent auction URL. Then a fancy page appears saying item does not exist. WITH HTTPCLI, it gets a 404 error. I have guesses that the ISAPI.dll sends back the fancy -page to IE or that it is something else. Is there any way to get same page as IE? What am I doing wrong for this circumstance with nonexistent auction number? - This mail sent through IMP: http://horde.org/imp/ -- FIGYELEM ! Ennek a levélnek a végén NINCS REKLÁM !!! észrevetted ? -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Enhancements for Thread Attach/Detach methods
Francois PIETTE wrote: You must map old message numbers to the new message numbers before posting them to the new window. I do not see how to map those numbers on a low level easily :( any idea? -- [EMAIL PROTECTED] http://www.overbyte.be - Original Message - From: Arno Garrels [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Sunday, June 11, 2006 3:18 PM Subject: Re: [twsocket] Enhancements for Thread Attach/Detach methods Francois PIETTE wrote: In V6, how can I extract messages of the to be detached socket only? Is it Peekmessage(Msg, OldHWnd, MsgLow, MsgLow + MsgCnt, PM_REMOVE)? No. This would retrieve all messages for all component sharing the same TIcsWndHandler. It is necessary to iterate thru FMsgMap to find all occurence of self and get the corresponding message numbers (see TIcsWndHandler.AllocateMsgHandler) to use in PeekMessage. It is not guaranteed that all messages numbers for a given component are contiguous altough it will most of the time. The problem is to retrieve all message from the old queue and post them in the new queue in the same order. This can be solved by examining the time member in TMsg record. Can you please help me? Something like below, or do I still haven't got it fully? procedure TIcsWndControl.MoveQueuedMessages(NewHwnd: HWND); var I : UINT; Idx : Integer; Msg : tagMsg; P : PMsg; L : TList; function CmpFunc(Item1: Pointer; Item2: Pointer): Integer; begin if PMsg(Item1)^.time = PMsg(Item2)^.time then Result := 0 else if PMsg(Item1)^.time PMsg(Item2)^.time then Result := 1 else Result := -1; end; begin L := TList.Create; try I := 0; while I WH_MAX_MSG do begin if FWndHandler.FMsgMap[I] = Self then begin while PeekMessage(Msg, Handle, I + FWndHandler.FMsgLow, I + FWndHandler.FMsgLow, PM_REMOVE) dobegin New(P); //P^.hwnd := Msg.hwnd; P^.message := Msg.message; P^.wParam:= Msg.wParam; P^.lParam:= Msg.lParam; P^.time := Msg.time; L.Add(P); end; end; Inc(I); end; L.Sort(@CmpFunc); for Idx := 0 to L.Count - 1 do PostMessage(NewHwnd, PMsg(L[Idx])^.message, PMsg(L[Idx])^.wParam, PMsg(L[Idx])^.lParam); finally for Idx := 0 to L.Count - 1 do System.Dispose(L[IDX]); L.Free; end; end; -- [EMAIL PROTECTED] http://www.overbyte.be - Original Message - From: Arno Garrels [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Sunday, June 11, 2006 9:49 AM Subject: Re: [twsocket] Enhancements for Thread Attach/Detach methods Francois PIETTE wrote: AFAIK winsock API function WSAAsyncSelect() is a common, blocking function. In this case it's called to disable winsock notifications. Because the window is detached/destroyed in subsequent lines. BTW: Same is done in V5. So for a short while the detached socket is windowless, that's why I suggested to wait w/o processing messages until it is attached again (not nice but worked for me). To be safe, the order should be: 1) Stop notifications from winsock (WSAAsyncSelect) to the current (old) hidden window 2) Create the new hidden window 3) Extract all messages from old hidden window queue and push them to the new queue In V6, how can I extract messages of the to be detached socket only? Is it Peekmessage(Msg, OldHWnd, MsgLow, MsgLow + MsgCnt, PM_REMOVE)? --- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html 4) Restart notifications from winsock to the new hidden window Probably a good idea to post a FD_READ message in the new queue between 3 and 4 above. Because it may happend that data has been received during the time interval when notifications have been disabled. -- [EMAIL PROTECTED] http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Enhancements for Thread Attach/Detach methods
No genius idea pops up from my head :-( -- [EMAIL PROTECTED] http://www.overbyte.be - Original Message - From: Arno Garrels [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Monday, June 12, 2006 12:29 PM Subject: Re: [twsocket] Enhancements for Thread Attach/Detach methods Francois PIETTE wrote: You must map old message numbers to the new message numbers before posting them to the new window. I do not see how to map those numbers on a low level easily :( any idea? -- [EMAIL PROTECTED] http://www.overbyte.be - Original Message - From: Arno Garrels [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Sunday, June 11, 2006 3:18 PM Subject: Re: [twsocket] Enhancements for Thread Attach/Detach methods Francois PIETTE wrote: In V6, how can I extract messages of the to be detached socket only? Is it Peekmessage(Msg, OldHWnd, MsgLow, MsgLow + MsgCnt, PM_REMOVE)? No. This would retrieve all messages for all component sharing the same TIcsWndHandler. It is necessary to iterate thru FMsgMap to find all occurence of self and get the corresponding message numbers (see TIcsWndHandler.AllocateMsgHandler) to use in PeekMessage. It is not guaranteed that all messages numbers for a given component are contiguous altough it will most of the time. The problem is to retrieve all message from the old queue and post them in the new queue in the same order. This can be solved by examining the time member in TMsg record. Can you please help me? Something like below, or do I still haven't got it fully? procedure TIcsWndControl.MoveQueuedMessages(NewHwnd: HWND); var I : UINT; Idx : Integer; Msg : tagMsg; P : PMsg; L : TList; function CmpFunc(Item1: Pointer; Item2: Pointer): Integer; begin if PMsg(Item1)^.time = PMsg(Item2)^.time then Result := 0 else if PMsg(Item1)^.time PMsg(Item2)^.time then Result := 1 else Result := -1; end; begin L := TList.Create; try I := 0; while I WH_MAX_MSG do begin if FWndHandler.FMsgMap[I] = Self then begin while PeekMessage(Msg, Handle, I + FWndHandler.FMsgLow, I + FWndHandler.FMsgLow, PM_REMOVE) dobegin New(P); //P^.hwnd := Msg.hwnd; P^.message := Msg.message; P^.wParam:= Msg.wParam; P^.lParam:= Msg.lParam; P^.time := Msg.time; L.Add(P); end; end; Inc(I); end; L.Sort(@CmpFunc); for Idx := 0 to L.Count - 1 do PostMessage(NewHwnd, PMsg(L[Idx])^.message, PMsg(L[Idx])^.wParam, PMsg(L[Idx])^.lParam); finally for Idx := 0 to L.Count - 1 do System.Dispose(L[IDX]); L.Free; end; end; -- [EMAIL PROTECTED] http://www.overbyte.be - Original Message - From: Arno Garrels [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Sunday, June 11, 2006 9:49 AM Subject: Re: [twsocket] Enhancements for Thread Attach/Detach methods Francois PIETTE wrote: AFAIK winsock API function WSAAsyncSelect() is a common, blocking function. In this case it's called to disable winsock notifications. Because the window is detached/destroyed in subsequent lines. BTW: Same is done in V5. So for a short while the detached socket is windowless, that's why I suggested to wait w/o processing messages until it is attached again (not nice but worked for me). To be safe, the order should be: 1) Stop notifications from winsock (WSAAsyncSelect) to the current (old) hidden window 2) Create the new hidden window 3) Extract all messages from old hidden window queue and push them to the new queue In V6, how can I extract messages of the to be detached socket only? Is it Peekmessage(Msg, OldHWnd, MsgLow, MsgLow + MsgCnt, PM_REMOVE)? --- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html 4) Restart notifications from winsock to the new hidden window Probably a good idea to post a FD_READ message in the new queue between 3 and 4 above. Because it may happend that data has been received during the time interval when notifications have been disabled. -- [EMAIL PROTECTED] http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto
Re: [twsocket] 64-Bit Processors Issue
Hi, I don't see why your first version could not work. I have programs which basically does the same thing (calling several Send in a row). And I can't imagine why an AMD processor whould fail doing that ! Me neither. btw: Your second versin is much faster (well 50 iterations probably doesn't do any difference). You can also make the code a little bit clear by removing the test and puting one more send at the end of the loop: for I := 0 to Count-1 do begin // Same buffer assemblage BuildMessage(aString, aBuffer); Socket.PutDataInSendBuffer(@aBuffer[0], Length(aBuffer)); end; Socket.Send(nil, 0); Thanks for the tip. Marcelo - Original Message - From: Francois PIETTE [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Saturday, June 10, 2006 4:31 AM Subject: Re: [twsocket] 64-Bit Processors Issue I don't see why your first version could not work. I have programs which basically does the same thing (calling several Send in a row). And I can't imagine why an AMD processor whould fail doing that ! btw: Your second versin is much faster (well 50 iterations probably doesn't do any difference). You can also make the code a little bit clear by removing the test and puting one more send at the end of the loop: for I := 0 to Count-1 do begin // Same buffer assemblage BuildMessage(aString, aBuffer); Socket.PutDataInSendBuffer(@aBuffer[0], Length(aBuffer)); end; Socket.Send(nil, 0); -- Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] http://www.overbyte.be - Original Message - From: Marcelo Grossi [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Friday, June 09, 2006 10:58 PM Subject: Re: [twsocket] 64-Bit Processors Issue Hello again folks, I managed to fix the bug I told you guys about. Aparently it is endeed an ICS related problem or AMD's fault, can't be concise on that. Here's an overview of the problem with the solution in sample codes: Problem: The server did not received the packet from the client, only the first one. The packets in question were being sent from inside a for loop (small one, about 50 iterations). Here is a sample code of the faulty version of the code (Delphi 6): for I := 0 to Count-1 do begin // This line being the assembly of the buffer, // it is a very clean code and is a very fast function and very few data. // Buffer size estimations are about 20- bytes. BuildMessage(aString, aBuffer); // sends rapid-fire buffers to the server Socket.Send(@aBuffer[0], Length(arBuffer)); end; Solution: Using the cumulative send function provided with ICS the problem is strangely resolved and the server receves ok the buffers (in this case, the single buffer made of the small buffers). Here is the sample code: for I := 0 to Count-1 do begin // Same buffer assemblage BuildMessage(aString, aBuffer); // Only sends the packet when the processing is finished (last iteration) if I = (Count - 1) then Socket.Send(@aBuffer[0], Length(aBuffer)) else Socket.PutDataInSendBuffer(@aBuffer[0], Length(aBuffer)); end; I hope I could be of any help and I'm pretty sure this can be reproduced (using the sample codes above) in any client/server model being the client an AMD 64-Bit processor (can't say much about Intel 64-Bit processors because we could not test it out). Anyways, thank you very much for all your responses! Best regards, Marcelo Grossi - Original Message - From: Arno Garrels [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Friday, June 09, 2006 8:24 AM Subject: Re: [twsocket] 64-Bit Processors Issue Marcelo Grossi wrote: Hello again, I'm new to this list and since I've been getting your messages, I was wondering if anyone got the message I sent about the problem I'm having with the 64-Bit AMD processors. I really really need your help on this, because I've never altered the source code of ICS and the problem mentioned (see below) only happens with users of 64-bit AMD (never tested with Intel) processors. It is very very unlikely that ICS in combination with AMD64 is the reason. I personally had troubles with hardware DEP (nx-flag) caused by another third party component, however I got at least a very strange exception. --- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for
Re: [twsocket] 64-Bit Processors Issue
Hi Peter, All I did for months was try to find the cause of the problem in MY work. Then I decided to try this list, and all you fellow gave me your opinions wich were tested and helped me out in finding the error. And most probably the problem resides in either ICS or AMD64 itself, because believe it or not, ALL AMD64 testers I've got so far presented the same issue (by all I mean the two users with that machine configuration, one AMD Athlon 64 and the other AMD Sempron). With the corrections made both users got themselves a working program (tested). Now, why the error exists and in whom the guilt resides? I really can't tell. Could be in my application, I can't discard that, but I just thought of letting you guys know. Who knows if there's an AMD64 user in this list and he has the time to implement the code below just for testing? Imagine if he manages to reproduce the same problem as I did? We may be discovering a serious (in my opinion) problem with either AMD 64 based processors or the ICSv5 component. I think it's worth the shot ... Marcelo. - Original Message - From: Borosnyay Péter [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Saturday, June 10, 2006 6:13 AM Subject: Re: [twsocket] 64-Bit Processors Issue Hello Marcelo, Your problem has nothing to do with AMD processors. It was by coincidence that the machine that produced the problem had an AMD processor. You should try an Intel one also. As far as I know, socket implementations doesn't depend on or differ by processor type. They should not. When you track down a problem, first always try to find the cause in YOUR work, among the things that YOU did. People (including myself) are feeble and tend to forget this. The more experience one has, the higher the probability is, to forget the above. Colleagues, NEVER forget it ! I wish good luck for everyone ! Cheers, Peter On Fri, 09 Jun 2006 22:58:14 +0200, Marcelo Grossi [EMAIL PROTECTED] wrote: Hello again folks, I managed to fix the bug I told you guys about. Aparently it is endeed an ICS related problem or AMD's fault, can't be concise on that. Here's an overview of the problem with the solution in sample codes: Problem: The server did not received the packet from the client, only the first one. The packets in question were being sent from inside a for loop (small one, about 50 iterations). Here is a sample code of the faulty version of the code (Delphi 6): for I := 0 to Count-1 do begin // This line being the assembly of the buffer, // it is a very clean code and is a very fast function and very few data. // Buffer size estimations are about 20- bytes. BuildMessage(aString, aBuffer); // sends rapid-fire buffers to the server Socket.Send(@aBuffer[0], Length(arBuffer)); end; Solution: Using the cumulative send function provided with ICS the problem is strangely resolved and the server receves ok the buffers (in this case, the single buffer made of the small buffers). Here is the sample code: for I := 0 to Count-1 do begin // Same buffer assemblage BuildMessage(aString, aBuffer); // Only sends the packet when the processing is finished (last iteration) if I = (Count - 1) then Socket.Send(@aBuffer[0], Length(aBuffer)) else Socket.PutDataInSendBuffer(@aBuffer[0], Length(aBuffer)); end; I hope I could be of any help and I'm pretty sure this can be reproduced (using the sample codes above) in any client/server model being the client an AMD 64-Bit processor (can't say much about Intel 64-Bit processors because we could not test it out). Anyways, thank you very much for all your responses! Best regards, Marcelo Grossi - Original Message - From: Arno Garrels [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Friday, June 09, 2006 8:24 AM Subject: Re: [twsocket] 64-Bit Processors Issue Marcelo Grossi wrote: Hello again, I'm new to this list and since I've been getting your messages, I was wondering if anyone got the message I sent about the problem I'm having with the 64-Bit AMD processors. I really really need your help on this, because I've never altered the source code of ICS and the problem mentioned (see below) only happens with users of 64-bit AMD (never tested with Intel) processors. It is very very unlikely that ICS in combination with AMD64 is the reason. I personally had troubles with hardware DEP (nx-flag) caused by another third party component, however I got at least a very strange exception. --- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] ICS-V6 HTTP ZLib stuff
Francois PIETTE wrote: I updated ICS-V6 with the ZLib stuff Angus sent to me. See his message below. The DLL are available separately in http://www.overbyte.be/arch/ZLibDll.zip Thanks to Angus. Just downloaded, however OverbyteIcsZLibDll.pas is still from June 07 and doesn't include Angus' fix. -- Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] http://www.overbyte.be - Original Message - From: Angus Robertson - Magenta Systems Ltd [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, June 11, 2006 8:26 PM Subject: Re: ICS HTTP ZLib stuff Attached is a zip containing updated versions of the zlib modules for ICS, that now work with the DLLs. I did test the DLL version with the original HTTP, but when I did FTP a month later I used newer stream based APIs that were not supported by the DLL unit, but did not update it. So now I have. I've removed the DLL names from the INC file and put them in the DLL unit, the single line left could move into icsdefs, but that would need changing a few other units as well. I've not changed high or obj, except for the dates to keep them matched. Angus -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
[twsocket] What to use with BDS 2006
I'm using C++Builder 2006. What is the best version to use for a release (stable) application built with C++Builder 2006? Also, are there any stable SSL components for BDS 2006 yet? I've been waiting for quite some time to support SSL but so far it seems the SSL stuff wasn't good enough/ready. Are there any SSL enabled components that are non-BETA or stable enough for a release application for C++Builder 2006? Thank you! -- Albert Wiersch AI Internet Solutions [EMAIL PROTECTED] http://www.htmlvalidator.com/ -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] THTTPCli false 404 pages
On 12 Jun 2006 at 9:24, Frans van Daalen wrote:
the 404 is correct, IE will also get the 404. But ebay has changed the
layout of the 404 error page to load some other pages
like //snip from 404 page// cfg.sModuleUrl
='http://promo.ebay.com/ws/eBayISAPI.dll?GetPPModulesusecase=2' ; \
so you must read the 404 page and then execute the code in that page :-)
You can read the pae?
I am not sure if httpcli actually gets the vanilla 404 page from the server.
An exception is thrown because it is a 404 status.
I am using code similar to the example that comes with ICS:
try {
Http-Get();
} __except (TRUE) {
// SetButtonState(TRUE)
dm-Lines-Add(GET Failed !);
dm-Lines-Add(StatusCode = + IntToStr(Http-StatusCode));
dm-Lines-Add(ReasonPhrase = + Http-ReasonPhrase);
//
//
//the 404 status sends the program flow here
//
//
//
//
}
I am not sure if httpcli is getting the server's 404 template page or not.
I guess I'll try to see what the document is holding.
Thanks
I mention ed IE but really I mean browser -- system browser.
-
This mail sent through IMP: http://horde.org/imp/
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
Re: [twsocket] ICS-V6 HTTP ZLib stuff
I updated ICS-V6 with the ZLib stuff Angus sent to me. See his message below. The DLL are available separately in http://www.overbyte.be/arch/ZLibDll.zip Thanks to Angus. Just downloaded, however OverbyteIcsZLibDll.pas is still from June 07 and doesn't include Angus' fix. My fault. Angus sent V5 files, not V6 files. Need a little renaming work. -- [EMAIL PROTECTED] http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] What to use with BDS 2006
I'm using C++Builder 2006. What is the best version to use for a release (stable) application built with C++Builder 2006? ICS V5 is the last stable for BCB2006. Fastream is working on ICS-V6. Also, are there any stable SSL components for BDS 2006 yet? I've been waiting for quite some time to support SSL but so far it seems the SSL stuff wasn't good enough/ready. Are there any SSL enabled components that are non-BETA or stable enough for a release application for C++Builder 2006? Again ICS-SSL-V5 is OK for BCB2006. Current ICS-SSL-V5 is still in development but already used in production code. Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] What to use with BDS 2006
Francois, The work for ICS-v6 BCB compatibility is complete! Please let's share it with others. However the work Arno did does not work well with the latest wsockbuf design. I think Arno and you should adopt the code and make the integration. Regards, SZ - Original Message - From: Francois PIETTE [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Monday, June 12, 2006 7:14 PM Subject: Re: [twsocket] What to use with BDS 2006 I'm using C++Builder 2006. What is the best version to use for a release (stable) application built with C++Builder 2006? ICS V5 is the last stable for BCB2006. Fastream is working on ICS-V6. Also, are there any stable SSL components for BDS 2006 yet? I've been waiting for quite some time to support SSL but so far it seems the SSL stuff wasn't good enough/ready. Are there any SSL enabled components that are non-BETA or stable enough for a release application for C++Builder 2006? Again ICS-SSL-V5 is OK for BCB2006. Current ICS-SSL-V5 is still in development but already used in production code. Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] What to use with BDS 2006
Great! Should I wait for a v6 release (non-SSL) and a v6 SLL beta release and use that (v6std + v6SSLBeta)? I can wait if it is available soon. Faststream (SZ?), can I get these files from you (v6std + v6SSLBeta)? Or should I go with ICS V5 and ICS-SSL-V5? What is best for the future? Thank you. -- Albert Wiersch AI Internet Solutions [EMAIL PROTECTED] http://www.htmlvalidator.com/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fastream Technologies Sent: Monday, June 12, 2006 11:27 AM To: ICS support mailing Subject: Re: [twsocket] What to use with BDS 2006 Francois, The work for ICS-v6 BCB compatibility is complete! Please let's share it with others. However the work Arno did does not work well with the latest wsockbuf design. I think Arno and you should adopt the code and make the integration. Regards, SZ - Original Message - From: Francois PIETTE [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Monday, June 12, 2006 7:14 PM Subject: Re: [twsocket] What to use with BDS 2006 I'm using C++Builder 2006. What is the best version to use for a release (stable) application built with C++Builder 2006? ICS V5 is the last stable for BCB2006. Fastream is working on ICS-V6. Also, are there any stable SSL components for BDS 2006 yet? I've been waiting for quite some time to support SSL but so far it seems the SSL stuff wasn't good enough/ready. Are there any SSL enabled components that are non-BETA or stable enough for a release application for C++Builder 2006? Again ICS-SSL-V5 is OK for BCB2006. Current ICS-SSL-V5 is still in development but already used in production code. Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] THTTPCli false 404 pages
You can read the pae?
I found that yes httpcli still gets the page html, though the 404 status threw
the ecpetion below.
Thanks for all your help on sorting it out.
I am not sure if httpcli actually gets the vanilla 404 page from the
server.
An exception is thrown because it is a 404 status.
I am using code similar to the example that comes with ICS:
try {
Http-Get();
} __except (TRUE) {
// SetButtonState(TRUE)
dm-Lines-Add(GET Failed !);
dm-Lines-Add(StatusCode = + IntToStr(Http-StatusCode));
dm-Lines-Add(ReasonPhrase = + Http-ReasonPhrase);
//
//
//the 404 status sends the program flow here
//
//
//
//
}
I am not sure if httpcli is getting the server's 404 template page or not.
I guess I'll try to see what the document is holding.
Thanks
I mention ed IE but really I mean browser -- system browser.
-
This mail sent through IMP: http://horde.org/imp/
-
This mail sent through IMP: http://horde.org/imp/
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
Re: [twsocket] What to use with BDS 2006
Fastream Technologies wrote: Francois, The work for ICS-v6 BCB compatibility is complete! Please let's share it with others. However the work Arno did does not work well with the latest wsockbuf design. I think Arno and you should adopt the code and make the integration. I tried today but got strange errors in constructor and in destructor, SSL uses one more buffer, currently I have no idea what's going on, sorry. Also I think that V6 should get a secure method to move a socket to a different thread context. Required only in multi-threaded server implementations after Accept a client connection. Regards, SZ - Original Message - From: Francois PIETTE [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Monday, June 12, 2006 7:14 PM Subject: Re: [twsocket] What to use with BDS 2006 I'm using C++Builder 2006. What is the best version to use for a release (stable) application built with C++Builder 2006? ICS V5 is the last stable for BCB2006. Fastream is working on ICS-V6. Also, are there any stable SSL components for BDS 2006 yet? I've been waiting for quite some time to support SSL but so far it seems the SSL stuff wasn't good enough/ready. Are there any SSL enabled components that are non-BETA or stable enough for a release application for C++Builder 2006? Again ICS-SSL-V5 is OK for BCB2006. Current ICS-SSL-V5 is still in development but already used in production code. Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
[twsocket] Multi-threaded server implementation : A secure method to move a socket to a different thread context
Also I think that V6 should get a secure method to move a socket to a different thread context. Required only in multi-threaded after Accept a client connection. In that situation, the most secure method is to do it when we get the socket handle from Accept() and before it is assigned to a TWSocketClient instance using Dup(). That instance should be attached the worker thread before having the handle. At that time there is not yet any message in the message queue which could be lost. -- [EMAIL PROTECTED] http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Enhancements for Thread Attach/Detach methods
I do not see how to map those numbers on a low level easily :( any idea? I'm trying to follow. How do the old and the new message numbers differ? What do the old and new numbers look like, can you maybe give a small example list? -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Enhancements for Thread Attach/Detach methods
I do not see how to map those numbers on a low level easily :( any idea? I'm trying to follow. How do the old and the new message numbers differ? What do the old and new numbers look like, can you maybe give a small example list? There can be no relation at all between the two sets ! Of course with simple case, the two sets will looks the same. But it will not be the case when component are destroyed and other created, specially when there are several component types involeved, having each one a different number of message numbers. -- [EMAIL PROTECTED] http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Enhancements for Thread Attach/Detach methods
Francois PIETTE schrieb: I do not see how to map those numbers on a low level easily :( any idea? I'm trying to follow. How do the old and the new message numbers differ? What do the old and new numbers look like, can you maybe give a small example list? There can be no relation at all between the two sets ! Of course with simple case, the two sets will looks the same. But it will not be the case when component are destroyed and other created, specially when there are several component types involeved, having each one a different number of message numbers. So what kind of mapping are you looking for? Which relationship do you need to preserve? -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Enhancements for Thread Attach/Detach methods
So what kind of mapping are you looking for? Which relationship do you need to preserve? A component has allocated a number of message numbers (the messages are now identified by variables since a lot of components share the same hidden window). When the component is attached to another thread, any message still in the old message queue has to be pulled out and posted into the new queue. Before being posted to the new queue, the old messages numbers have to be mapped to the new ones. See TCustomWSocket.AllocateMsgHandlers for reference. I think we don't have enough information saved to do this mapping. Probably TIcsWndHandler.AllocateMsgHandler sould take one more argument to permit the mapping. This argument would be saved in TIcsWndHandler.FMsgMap so that it is available afterward to do the mapping. -- [EMAIL PROTECTED] http://www.overbyte.be - Original Message - From: Stadin, Benjamin [EMAIL PROTECTED] To: twsocket@elists.org Sent: Monday, June 12, 2006 8:58 PM Subject: Re: [twsocket] Enhancements for Thread Attach/Detach methods Francois PIETTE schrieb: I do not see how to map those numbers on a low level easily :( any idea? I'm trying to follow. How do the old and the new message numbers differ? What do the old and new numbers look like, can you maybe give a small example list? There can be no relation at all between the two sets ! Of course with simple case, the two sets will looks the same. But it will not be the case when component are destroyed and other created, specially when there are several component types involeved, having each one a different number of message numbers. So what kind of mapping are you looking for? Which relationship do you need to preserve? -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Enhancements for Thread Attach/Detach methods
Francois PIETTE schrieb: So what kind of mapping are you looking for? Which relationship do you need to preserve? A component has allocated a number of message numbers (the messages are now identified by variables since a lot of components share the same hidden window). When the component is attached to another thread, any message still in the old message queue has to be pulled out and posted into the new queue. Before being posted to the new queue, the old messages numbers have to be mapped to the new ones. See TCustomWSocket.AllocateMsgHandlers for reference. Would it be possible to have one prime number per component, and the message numbers the component allocates are a multiple of this prime? I think we don't have enough information saved to do this mapping. Probably TIcsWndHandler.AllocateMsgHandler sould take one more argument to permit the mapping. This argument would be saved in TIcsWndHandler.FMsgMap so that it is available afterward to do the mapping. -- [EMAIL PROTECTED] http://www.overbyte.be - Original Message - From: Stadin, Benjamin [EMAIL PROTECTED] To: twsocket@elists.org Sent: Monday, June 12, 2006 8:58 PM Subject: Re: [twsocket] Enhancements for Thread Attach/Detach methods Francois PIETTE schrieb: I do not see how to map those numbers on a low level easily :( any idea? I'm trying to follow. How do the old and the new message numbers differ? What do the old and new numbers look like, can you maybe give a small example list? There can be no relation at all between the two sets ! Of course with simple case, the two sets will looks the same. But it will not be the case when component are destroyed and other created, specially when there are several component types involeved, having each one a different number of message numbers. So what kind of mapping are you looking for? Which relationship do you need to preserve? -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Enhancements for Thread Attach/Detach methods
A component has allocated a number of message numbers (the messages are now identified by variables since a lot of components share the same hidden window). When the component is attached to another thread, any message still in the old message queue has to be pulled out and posted into the new queue. Before being posted to the new queue, the old messages numbers have to be mapped to the new ones. See TCustomWSocket.AllocateMsgHandlers for reference. Would it be possible to have one prime number per component, and the message numbers the component allocates are a multiple of this prime? Would be very difficult. Message numbers are given by the TIcsWndHandler class, not the component nor his derived. Messages numbers are 16 bit integers. Available numbers start at WM_USER. The handler allocate at most WH_MAX_MSG (currently 100) message be hidden window. -- [EMAIL PROTECTED] http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
