Winnyを意識して作られている為、Winnyと同様ないし酷似している部分が多い。一方Winnyに対して主に以下の改良点・変更点がある。
拡散アップロード機能
ファイル保持ノードが適当に選んだ相手に対して能動的にアップロードを行うため、監視ノードがファイル保持ノードと狙って接続しにくくする効果があり、匿名性を確保している。Shareは拡散アップロードに関しては一定確率で中継も行い、流通能力の向上と匿名性の強化を図っている。また、充分な拡散アップロードを行った後であれば、一次配布ノードがShareネットワークに接続していなくてもファイルは流通するため、一次配布ノードの負担を減らす効果がある。一次配布は基本的に拡散アップロードで行われる。
専用プラグインによる拡張性
多数のプラグインが開発されているため、さまざまな機能を追加することができる。Shareが抱える欠点や問題点をカバーするために少なくともDiffusionProClone, RegExpFilter, NoSpam等の導入が推奨される。プラグインの開発はSharePDKと呼ばれるプラグイン開発キットを使用しDelphiで開発する。
クラスタの簡易切り替え機能
最大5個のクラスタ・キーワードを使用可能で、専用メニューを利用して事前に登録した最大255個のキーワードから選択できる。クラスタ・キーワードの一括切り替えを行うプラグイン(ClusterChanger)も存在する。
キャッシュ領域の容量制限に対応
任意の容量（但し最低4GiB以上）に制限できるためHDDを使い切る心配が無い。また、必要性の少ないファイルから自動的に削除されるため、管理の手間が省ける。手動で管理したい場合は密告を利用する。
大容量のファイルに対応
最大32GiBまでのファイルに対応している。
Unicodeに対応している
内部では文字列をUTF-16で管理している。そのため、異なる言語が混ざったファイル名も問題なく扱え、またローカライズのしやすさに繋がっている。ただし、Share本体はUnicodeに対応しているが、プラグインがUnicodeに対応しているとは限らない点は注意を要する。
暗号・署名の強化
暗号・署名に関する処理についてはWinnyより丁寧に実装されている。ShareのIDは、IDシステムを現在のものに一新して以来、今のところ偽装の被害は報告されていない。尚、通信の暗号化は本質的には匿名性の向上の効果が無いことが後に示されている。
バージョンアップ告知
新しいバージョンのノードは古いバージョンのノードに対してバージョンアップ告知を送ることができる。Shareでは加えて、指定より古いバージョンのノードを一定時間後に終了させることができ、古いバージョンのノードがいつまでもShareネットワークに残ることを防いでいる。この機能はクラックされるとP2Pネットワークが壊滅させられる恐れがあるため、Winnyではあえて搭載されなかった。
クラック対策
クラック対策の一環としてメモリ上のプログラム本体及びデータを検査しており、ハードウェアの異常でメモリ上のデータが化けた場合でも終了してしまう。そのため、Shareを動作させるパソコンは安定性が高いことが求められる一方、潜在的な不具合を発見できる利点もある。
フィルタ機能
条件に当てはまるファイルを表示しないようにするだけではなく、Shareでは加えて、条件に当てはまるクラスタ・キーワードを持つノードとの接続を拒否する。また、条件に当てはまるファイルについて、他のノードからの拡散アップロードも拒否する。Winnyより弱体化している点もあり、「捏造警告」は他のノードに知らせるだけで該当ファイルの流通に影響を与えない他、「キーを削除」や「捏造警告を追加」を指定してフィルタを行っても該当ファイルのキャッシュは削除されない、そもそも「キーを削除」や「捏造警告を追加」は自身がキャッシュを持っているファイルに対しては無効、という違いがある。
BBS機能を持たない
Winnyでは重点が置かれていたが、ShareではBBS機能を持たない。過去にプラグイン(ShareNNTP)でShareにニュースグループ機能を追加する試みはあった。
ポート0モードを持たない
ルーターの設定変更が必須であるため敷居は高い。UPnPで自動設定を行うプラグイン(UPnP)は存在するが確実ではない。ポート0モードの実装は多くの手間が掛かる割に、共有効率や匿名性に貢献せず足を引っ張る傾向にあるためサポートされなかったと見られる。
二次配布の時にファイル転送は中継しない
二次配布の時にファイル転送の中継は行わない代わりに拡散アップロードで匿名性の確保を行う。尚、拡散アップロードの時には中継を行う。
クエリの送信の廃止
Shareは元々は、「検索」ボタンを押すと周辺ノードに「クエリ」を送信してファイル情報を探す仕様であった。しかしShareは、Winnyの様にネットワークを階層化していないため、クエリの送信はネットワークにとって大きな負担となっていた。このため Ver1.0 A77 で廃止された。この仕様の変更により、目的のファイル情報が自身のノードに辿りつくのを待つしかなくなったため、クラスタ・キーワードやトリガの設定が重要となった。
ファイルについて需要が多ければ多いほど流通が早くなるのはWinnyと同様である。
Shareは全体的に見て一次配布者側が有利な作りとなっている。
Shareはネットワークにおいて、ファイル要求側は受動的に、ファイル保持側は能動的に振る舞う。これは、Winnyなどの他のファイル共有ソフトとは逆になっている。
Shareは、Winnyと比較して一次配布開始からファイルが流通する速度が早い傾向に有る。
これは、Winnyが完全なファイル以外はアップロードしないのに対し、Shareはファイルの一部を受け取った時点でアップロードに参加するため二次配布が早めに開始されるためである。 また、Shareは一次配布の時点で複数のノードに分割してアップロードするため、多くのノードが早い段階で二次配布に参加できることも理由の一つである。
その他の理由として、他のノードとファイル情報を交換する際に、Winnyは常にランダムに選んだファイル情報を交換するのに対して、Shareはランダムに選びつつも一次配布された日付が新しいファイル情報を優先的に残す性質があるため、新しいファイル情報が求めるノードに素早く行き渡る事も挙げられる。
これらの性質は後述するキャッシュ即消しの影響を軽減する追加効果もある。 なぜなら、キャッシュ即消しを行うノードもダウンロードが完了するまでの間は二次配布に参加するからである。
一方でShareは、一次配布開始から時間が経ったファイルは次第にデータが部分的に欠落した「歯抜け」と呼ばれる状態になり、ダウンロードしにくくなる傾向に有る。素早い流通を助けた上記の性質が、このShare最大の欠点の原因となっている。
Shareネットワーク上に完全なファイルを再構築するだけの部分キャッシュが存在しなくなった後も、部分キャッシュのアップロードが行われるため、いつまでも不完全なファイルが流通することになり、それらがShareネットワークに蓄積されていく。また、完全なファイルが大量の不完全なファイルに紛れることで検索しにくくなる問題もある。
Winnyでは歯抜けで悩まされることはあまり無い。Winnyは不完全なファイルの配布を行わないため、不完全なファイルはWinnyネットワークから自然と消滅していくためである。
Winnyユーザーに逮捕者が出た時、Winnyの作者が家宅捜索を受けたため、Winnyの開発は事実上 停止した。 これを受けて、Winnyネットワークの将来に危機感を覚えたShareの作者によってShareの開発が開始され2004年1月5日に初めて公開された。
当時、Winnyの匿名性は絶対の信頼を得ており、逮捕者が出たことは利用者達に非常に大きな衝撃を与えた。そのため、利用者達の間では様々なテーマで多くの議論が行われ、また後継となるソフトが望まれていたこともあって、WinnyからShareに乗り換えるユーザーが多くいた。尚、当時はShareの他にFreenet+FrostやWinOZ（後に実在しないことが判明した。WinMX→Winnyの流れを汲むような名前だけが一人歩きしたものと思われる）が注目された。
Shareのバージョンについて、Ver1.0 CT (Connection Test Release) #1?#21 → Ver1.0 DT (Diffuse Test) 1?41 → Ver1.0 A (Alpha) 1?82 → Ver1.0 EX (Extream) 1?? と移り変わっている。UDP版では Ver1.0 NT (Net Test) 1?5 となっている。
Shareは当初、正式名称が決まっておらず「Share(仮称)」と表記されていた。それがそのまま定着したため、Ver1.0 A75 以降は「Share」と表記するようになった。
当初はWinnyの後継を目指して開発されたShareであるが、Winnyネットワークが予想に反して現在も順調に稼働していることから、今では共存関係となっている。大容量のファイルの扱い・新しいファイルの素早い配布が得意なShareと、長期間の安定した配布が得意なWinnyの住み分けが行われている。また、ShareネットワークとWinnyネットワークとperfect darkネットワークの間でファイルの移植を行っている者がいる。