推 tyc5116:謝謝 11/14 14:20
※ 編輯: EdisonX 來自: 180.177.76.161 (11/14 14:28)
※ 引述《tyc5116 (累人啊....)》之銘言：
: 如題,是最近在工作上突然想到的一個靈感,提出來和大家討論一下
: 類似spice這類軟體的電路模擬
: 一個專案是負責建構實體的模擬環境,另一個是負責觸發的行為
: ex.
: 由A負責一個專案,內容是描述一間屋子的各個電器用品
: 由B負責另一個專案,提供了許多開關,在設定好各開關對應的電器用品後
: 那麼操作B專案上的開關,則A專案內對應的電器用品狀態也會隨之變化
: 但B不限於只能對應B
: 由C負責另一個專案,負責另一間屋子的各個電器用品
: 只要B上的設定沒錯,B也可以直接控制C,而不用大幅度的改變程式
: 有點Design pattern的味道,請問可能可以實作的方向為何呢?
: 謝謝
專有名詞懂得不多，本文敘述可能符合某些專有名詞的行為，若是的話歡迎補充。
比較好的情況是這整份專案都由同一個團隊開發，
也覺得蠻像是 legnaleurc 大說的 mock object，
這種 design pattern 蠻常拿來寫 test unit，
不過大多是針對 source code，較少人針對 exe .
先小提 IPC。
IPC 本質上只是一個概念，只要能達到 Process 相互溝通之目的就是 IPC，
像下面這種架構是 IPC
┌────┐ ┌────┐
│ A.exe │──→│ B.exe │
└────┘ └────┘
不過上面這種太簡單，用 IO Redirection / 簡單 pipe 就辦得到，
大概不會有人承認它是 IPC 架構。比較常拿來做 IPC 範例的簡易架構
┌──────────────────┐
│ ┌────┐ ┌────┐ │
└→│ A.exe │──→│ B.exe │──┘
└────┘ └────┘
上面是單向循序，還有雙向、多個 exe 互通的方式。
然後以你的例子比較像單純的雙向 IPC。
┌────┐──→┌────┐
│ A.exe │ │ B.exe │
└────┘←──└────┘
IPC 實作方法很多，簡單的到從 A/B 靠著一、二個檔案輸出、讀取可以完成通訊；
複雜到用 Shared-Memory / Mapping-Memory 完成， M$ 上達到 IPC 目的有幾個手法
ClipBoard、COM、Data Copy、DDE、
File Mapping、Mailslots、Pipes、PRC、Windows Sockets。
其他的有興趣自己再深入。
但不論是哪種 IPC 手法都綁定一個前提：
A.exe / B.exe 是個人或所屬團隊共同開發的，
一些行為流程或通訊方式準則是有共識的，
所以和你的前提又有相衝突了。
→ tyc5116 :有用C++寫出來的B,反而是A和C是我目前沒有的才對
若 A.exe / C.exe 之 source code 又不是你能動的，
而且又看不見，那其實這行為不就和 cracker / hooker 沒兩樣嗎？
如按鍵精靈，
按鍵精靈可以針對不同之執行檔，送出一樣的 button-push、set-text、get-text，
(雖本質上是合法的做 SendMessage / PostMessage),
這行為不就是你文中所說的「遙控器」？
但事實上一般在 A.exe / C.exe source 不能動的情況下，
比較優先方式是查 A.exe / C.exe 有沒有開放 dll 呼叫做 plug-in,
再去呼叫其 dll，
這種方式可以直接在 A.exe 裡面崁入一份新建的 memu-item，
執行事先寫好的 script。
但前提也是 A.exe / C.exe 當初設計時有考量到加入 plug-in 需求，
沒有的話個人認為和一般 cracker / hooker 沒太大差別。
以上討論就到此結束吧，再談下去離 C/C++ 太遠，
想後續討論的話或許轉 Programming 適合些。
--
就算把新鮮的肝拿回去，還是一樣寫碼到禿頭，加班到天亮，
永遠當老闆的傀儡 你是不是想這麼做？
是的話你就拿回去~ 拿啊！！
九世宅男 : 下輩子不要再讓我幹工程師了 ~
< Kuso 星爺語錄 >
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 180.177.76.161