my next website obituary goes to dxsock.com and brainpatchworkdx.com (site goes to cybersquatter)
DxSock reviewed
High prices, bad product.
This product is meant to complete against Indy. Despite all the bugs that Indy had, it worked. It worked for small projects and open-source. That meant that people could fix the bugs it had and contribute to the product. DxSock and DxInternet was closed-source and the only advertising came from shill statements from Ozz's friends recommending DxSock or DxInternet.
There was no way to try out DxSuck without paying for it. It costed US$899 (or more?). DxInternet was equally worse. There was no demo except paying US$199 (or more?) for it.
When paid, Ozz would deliver the sources as "it is". Promising more upgrades in the future.
(What upgrades?)
Let's see... From one of my friends:
The demos were bad or non-existent. The help file was also non-existent or "nothing". The source code was bad too. There were plenty of places marked "to-do" or the code was not there. Many of the protcols were not handles well or gave errors. For example, the SMTP component did not support SMTP auth well (password rejected?) or IRC component was empty. ("It's under development")...
Trying to get any support was equally bad. My friend got get several MS-Exchange "read-responses" but no reply.
The last post on DxSock's forum was from 2006.
Cyber Squatters now sit on that website.
Updated March 2013 -
Site is still alive but not updated since 2010.
See: Article Corrections
DxSock reviewed
High prices, bad product.
This product is meant to complete against Indy. Despite all the bugs that Indy had, it worked. It worked for small projects and open-source. That meant that people could fix the bugs it had and contribute to the product. DxSock and DxInternet was closed-source and the only advertising came from shill statements from Ozz's friends recommending DxSock or DxInternet.
There was no way to try out DxSuck without paying for it. It costed US$899 (or more?). DxInternet was equally worse. There was no demo except paying US$199 (or more?) for it.
When paid, Ozz would deliver the sources as "it is". Promising more upgrades in the future.
(What upgrades?)
Let's see... From one of my friends:
The demos were bad or non-existent. The help file was also non-existent or "nothing". The source code was bad too. There were plenty of places marked "to-do" or the code was not there. Many of the protcols were not handles well or gave errors. For example, the SMTP component did not support SMTP auth well (password rejected?) or IRC component was empty. ("It's under development")...
Trying to get any support was equally bad. My friend got get several MS-Exchange "read-responses" but no reply.
Updated March 2013 -
Site is still alive but not updated since 2010.
See: Article Corrections
6 comments:
I saw it. But would you want to buy such product? Maybe in the Delphi community... yes...
But in C++ community, there are plenty of free TCP/IP toolkits available. Go figure.
The first person I can think of who will want an update is David Farrell-Garcia from Whidbey Island Software LLC...
His forum post was not answered for nearly 4 years now.
Firstly, I have no idea who David Farrell-Garcia is, nor Whidbey Island Software, LLC.?
Checked NETSOL records: dxsock.com expired on 11/23/2006, August 2006 was the last day we had access to the domain - due to a change of location, we were not informed and lost all of our domains in 2006.
Which was fine, as I had not sold a copy due to warez sites since: DXSock v5.0 aka Oblivion
Client & Server Components
Released March 1st, 2005
Pricing (see: http://web.archive.org/web/20060615212209/http://dxsock.com/ ) scroll to the bottom to see pricing was $298.00 for new customers, $99 for existing customers... and $49.00 for non-source (which was *my* 'trial edition' with full 90 day guarantee).
My $899 package? You mean the collection of *EVERYTHING* we offered (http://web.archive.org/web/20061126182035/www.bpdx.com/newsgroups/index.php?topic=92.0 )
-- even on the bottom of this posting in 2005, I posted I could be reached by cell, which to this date I own that number and check it weekly for messages/questions.
Now yes... 2005/2006 was a very hard year on me personally, and since I code everything - support went to crap. I cannot and will not try to cover that fact ever.
However, for the past 4 years I have been developing the latest version (6.0) - and I am still developing this edition. I elected to support Delphi/C++ Builder because people still use it for some reason... however, I like and live in FPC.
I also want to go on record:
1. And say - people whining about a protocol not support a command tells me they were not a legal customer - who all received a 280 page manual (which explains that protocols change, and extend constantly - and how to trump the internal dynamic command parser which was in 5.5 and older.)
Version 6.0 - is just a cross-platform sore engine for client and server.
2. People who state it does not work with multiple CPUs obviously had their own bugs! And when they lie and say it works in INDY - which I wrote the core server technology since it was Winshoes -- just makes people who repeat it look stupid!
2a. DXSock 5.5 and older has always used TThread - it was how I implemented the creation of the threads which made DXSock perform so well. But TThread was not my code - so, uhhh - if the problem was in my threading - it was in all DELPHI/BCB threading!
2b. I have too many customers who have multiple CPUs running my code, I have customers who never elected to upgrade for many different reasons over the years - and even if you go out and download the old 2.0 DXSock, open up DXServerCore.pas - that is where the magical threading went on - if you have 1/2 an IQ for threading you will see - it is TThread - just creating the thread before needed, or creating an array of threads.
3. Oh my last gripe - the people who complain that 1:1 threading is wrong. Well, yes there are techniques to do multiple I/O calls in a single thread... yes there are different ways to manage I/O with less threads, but do not tell me 1:1 threading is wrong... it just means you do not know how to use {$M a,b,c} setting in your DPR.
Versions of IIS and Apache (and many engines) use multiple processes, with multiple threads in each - doing 1:1 relationship (one thread handling one socket) - it is and will always be faster than other techniques until you implement iocp (windows) or libevent.so or kqueue in *NIX.
$M done correctly uses a lot less memory per thread which means it uses a lot less space in the L1/L2/L3 caches... and with the speed difference between L1 cache hit vs. main memory being in the same order of magnitude as main memory vs. on disk on modern systems, that makes a lot of difference.
As of June 2010, I develop for my company full-time. Prior to now, I have always had a day job and ran BPDX/DXSOCK as my evening company... this is why I will not debate the support and lack of. But the product has had over 50 valid demos available - which are being redesigned for the 6.0 edition.
Firstly, I have no idea who David Farrell-Garcia is, nor Whidbey Island Software, LLC.?
Checked NETSOL records: dxsock.com expired on 11/23/2006, August 2006 was the last day we had access to the domain - due to a change of location, we were not informed and lost all of our domains in 2006.
Which was fine, as I had not sold a copy due to warez sites since: DXSock v5.0 aka Oblivion
Client & Server Components
Released March 1st, 2005
Pricing (see: http://web.archive.org/web/20060615212209/http://dxsock.com/ ) scroll to the bottom to see pricing was $298.00 for new customers, $99 for existing customers... and $49.00 for non-source (which was *my* 'trial edition' with full 90 day guarantee).
My $899 package? You mean the collection of *EVERYTHING* we offered (http://web.archive.org/web/20061126182035/www.bpdx.com/newsgroups/index.php?topic=92.0 )
-- even on the bottom of this posting in 2005, I posted I could be reached by cell, which to this date I own that number and check it weekly for messages/questions.
Now yes... 2005/2006 was a very hard year on me personally, and since I code everything - support went to crap. I cannot and will not try to cover that fact ever.
However, for the past 4 years I have been developing the latest version (6.0) - and I am still developing this edition. I elected to support Delphi/C++ Builder because people still use it for some reason... however, I like and live in FPC.
I also want to go on record:
1. And say - people whining about a protocol not support a command tells me they were not a legal customer - who all received a 280 page manual (which explains that protocols change, and extend constantly - and how to trump the internal dynamic command parser which was in 5.5 and older.)
Version 6.0 - is just a cross-platform sore engine for client and server.
2. People who state it does not work with multiple CPUs obviously had their own bugs! And when they lie and say it works in INDY - which I wrote the core server technology since it was Winshoes -- just makes people who repeat it look stupid!
2a. DXSock 5.5 and older has always used TThread - it was how I implemented the creation of the threads which made DXSock perform so well. But TThread was not my code - so, uhhh - if the problem was in my threading - it was in all DELPHI/BCB threading!
2b. I have too many customers who have multiple CPUs running my code, I have customers who never elected to upgrade for many different reasons over the years - and even if you go out and download the old 2.0 DXSock, open up DXServerCore.pas - that is where the magical threading went on - if you have 1/2 an IQ for threading you will see - it is TThread - just creating the thread before needed, or creating an array of threads.
3. Oh my last gripe - the people who complain that 1:1 threading is wrong. Well, yes there are techniques to do multiple I/O calls in a single thread... yes there are different ways to manage I/O with less threads, but do not tell me 1:1 threading is wrong... it just means you do not know how to use {$M a,b,c} setting in your DPR.
Versions of IIS and Apache (and many engines) use multiple processes, with multiple threads in each - doing 1:1 relationship (one thread handling one socket) - it is and will always be faster than other techniques until you implement iocp (windows) or libevent.so or kqueue in *NIX.
$M done correctly uses a lot less memory per thread which means it uses a lot less space in the L1/L2/L3 caches... and with the speed difference between L1 cache hit vs. main memory being in the same order of magnitude as main memory vs. on disk on modern systems, that makes a lot of difference.
As of June 2010, I develop for my company full-time. Prior to now, I have always had a day job and ran BPDX/DXSOCK as my evening company... this is why I will not debate the support and lack of. But the product has had over 50 valid demos available - which are being redesigned for the 6.0 edition.
Hi Ozz,
I managed to get back with my friend and he managed to get this email you sent to him.
--------------------
Everyone,
Somehow I have totally screwed up my "ACL" security on my development maching. Was able to gain READ-ONLY access to the drive by booting from another drive. I am emailing to ask everyone in my "Contacts" database. To resend any corresponce(s) recently back to me via onixon@dxsock.com while I make a full system backup - and reformat the drive.
Thank you kindly!
Ozz "Broke it again!" Nixon
Maybe you forgot?
> people whining about a protocol not support a command tells me they were not a legal customer.
Wow. (See previous message for an email you sent to over 100+ customers because you forgot the BCC it).
> People who state it does not work with multiple CPUs obviously had their own bugs! And when they lie and say it works in INDY - which I wrote the core server technology since it was Winshoes -- just makes people who repeat it look stupid!
People are not stupid. Your reviewer (et al) migrated to C/C++ and never had to pay for any TCP/IP library ever again. Ditto for C# as well.
Today if I want to build a server solution, I would probably go with Java Server stack or NET stack using C#/IIS/ASP.NET
If I use C/C++ I would use Poco Library, ClanLib, SDL Library (HTTP parts) or LibWWW or other libraries. At least they work well in OSX/Windows/Linux.
> you have 1/2 an IQ for threading you will see
Did you see my post "You don't MK the customer. http://delphihaters.blogspot.com/2011/01/you-dont-mk-customer.html
If you were one of my employees, I don't care how clever you are, if you cannot serve customers without spitting at them, I would just ask you to leave. If you gave this kind of customer service, even I would just leave and not care about you ever again.
> develop for my company full-time
Mr. Ozz Nixon, good luck on your ventures. I wish you well. It is unfortunate that times have changed and we have moved/migrated all the C#/C++ and never looked back.
Unfortunately, I have looked at many data-exchange TCP/IP libraries with high-level interface to transmit and receive data.
The only valid ones (worthwhile of consideration in Delphi community) are:
1) RemObjects SOAP
2) FastReports Server
3) DBISAM
4) NexusDB
5) RealThinClient
I am aware that RemObjects licensed your codes but I gave up on it after we migrated to C/C++/C#.
Post a Comment