最后我用的辦法是：SW_SHOWNORMAL BringWindowToTop

SetForegroundWindow
BringWindowToTop

SwitchToThisWindow
typedef void (WINAPI *PROCSWITCHTOTHISWINDOW) (HWND, BOOL);
PROCSWITCHTOTHISWINDOW SwitchToThisWindow;
HMODULE hUser32 = GetModuleHandle("user32");
SwitchToThisWindow = (PROCSWITCHTOTHISWINDOW)GetProcAddress(hUser32,
"SwitchToThisWindow");

hCurWnd = ::GetForegroundWindow();
dwMyID = ::GetCurrentThreadId();
dwCurID = ::GetWindowThreadProcessId(hCurWnd, NULL);
::AttachThreadInput(dwCurID, dwMyID, TRUE);
::SetForegroundWindow(m_hWnd);
::AttachThreadInput(dwCurID, dwMyID, FALSE);

this->ShowWindow(SW_SHOWNA);//簡單的顯示主窗口完事兒
            this->SetActiveWindow();
            this->SetForegroundWindow();
            //this->SetWindowPos(this,LOWORD(lParam),HIWORD(lParam),c.Width(),c.Height(),SWP_NOACTIVATE);
            this->BringWindowToTop();

SW_HIDE 隱藏窗口，激活另一窗口

SW_MINIMIZE 最小化窗口，激活另一窗口

SW_RESTORE 用原來的大小和位置顯示一個窗口，同時令其進入活動狀態

SW_SHOW 用當前的大小和位置顯示一個窗口，同時令其進入活動狀態

SW_SHOWMAXIMIZED 最大化窗口，并將其激活

SW_SHOWMINIMIZED 最小化窗口，并將其激活

SW_SHOWMINNOACTIVE 最小化一個窗口，但不改變活動窗口

SW_SHOWNA 用當前的大小和位置顯示一個窗口，不改變活動窗口

SW_SHOWNOACTIVATE 用最近的大小和位置顯示一個窗口，同時不改變活動窗口

SW_SHOWNORMAL 與SW_RESTORE相同

posted @ 2014-09-25 09:52 Enic 閱讀(3354) | 評論 (0) | 編輯收藏

轉 gcc源碼編碼格式轉換

gcc
        GNU   C/C++編譯器也可以正確支持wchar_t字符和字符串，但是源代碼的保存格式必須符合
下面條件：
        一、源代碼文件的保存編碼必須是UTF-8
        二、UTF-8編碼格式的源代碼文件，不能有BOM標志頭。
        只有源代碼文件符合上面兩個條件，gcc才會正確支持wchar_t字符和字符串。如果不符合
上面兩個條件的話，有可能會編譯出錯，有可能會產生錯誤的wchar_t字符和字符串。
        gcc在Windows平臺下，wchar_t是16位類型，在Linux平臺下，wchar_t是32位類型。

        另外，GCC提供了以下的參數開關來支持其它文字編碼的源文件：
        （a）-finput-charset=charset
            gcc在默認情況下，總是假設源代碼的編碼是UTF-8，如果是其它編碼的源代碼文件，
            源代碼里面又用到了wchar_t的類型，則可以使用-finput-charset=charset這個參數
            來實現。
            例如通常使用GBK編碼的源代碼可以假如參數：-finput-charset=GBK
         （b）-fwide-exec-charset=charset
            默認情況下，gcc在Windows平臺下，寬字符串串常量的每個字符是16位UTF-16類型，
            在Linux平臺下，寬字符串串常量的每個字符是32位UTF-32類型，
            使用這個參數，可以改變寬字符串串常量的類型。
            例如在x86的機器環境，Linux操作系統下，要使例如 L"漢字" 編譯后保存為UTF-16
            的字符串，則可以使用 -fwide-exec-charset=UTF-16LE

posted @ 2014-09-24 16:49 Enic 閱讀(910) | 評論 (0) | 編輯收藏

rundll32.exe

rundll32.exe編輯

本詞條缺少信息欄，補充相關內容使詞條更完整，還能快速升級，趕緊來編輯吧！

rundll32.exe用于在內存中運行DLL文件，它們會在應用程序中被使用。這個程序對你系統的正常運行是非常重要的。注意：rundl132.exe和rundll32.exe相似。但是rundl132.exe是W32.Miroot.Worm病毒。該病毒允許攻擊者訪問你的計算機，竊取密碼和個人數據。對該文件的建議是立即刪除。

顧名思義，“執行32位的DLL文件”。它的作用是執行DLL文件中的內部函數，這樣在進程當中，只會有 Rundll32.exe，而不會有DLL后門的進程，這樣，就實現了進程上的隱藏。如果看到系統中有多個Rundll32.exe，不必驚慌，這證明用 Rundll32.exe啟動了多少個的DLL文件。當然，這些Rundll32.exe執行的DLL文件是什么，我們都可以從系統自動加載的地方找到。

我來介紹一下Rundll32.exe這個文件，意思上邊已經說過，功能就是以命令行的方式調用動態鏈接程序庫。系統中還有一個 Rundll.exe文件，他的意思是“執行16位的DLL文件”，這里要注意一下。再來看看Rundll32.exe使用的函數原型[1] ：

Void CALLBACK FunctionName (HWND hwnd,HINSTANCE hinst,LPTSTR lpCmdLine,Int nCmdShow);

其命令行下的使用方法為：Rundll32.exe DLLname,Functionname [Arguments]

DLLname為需要執行的DLL文件名；Functionname為前邊需要執行的DLL文件的具體引出函數；[Arguments]為引出函數的具體參數。

posted @ 2014-08-27 09:42 Enic 閱讀(632) | 評論 (0) | 編輯收藏

復習了下umdh

set _NT_SYMBOL_PATH = symsrv*D:\win_Symbols*http://msdl.microsoft.com/download/symbols

gflags -i GameManager.exe +

gflags-i GameManager.exe +

7152 GameManager.exe DUIPlazaWnd

umdh -p:7152 -f:1.txt

umdh -p:7152 -f:2.txt

UMDH -d 1.txt 2.txt >> 1-2.txt

gflags /i GameManager.exe +ust

umdh -p:7152 -f:1.txt

umdh -p:7152 -f:2.txt

UMDH -d 1.txt 2.txt >> 1-2.txt

posted @ 2014-08-26 19:05 Enic 閱讀(159) | 評論 (0) | 編輯收藏

又遇到了wcout不輸出中文 wfstream中文亂碼類的問題

setlocale(LC_ALL, "");

很大一快知識點，暫時不想做深入研究

http://www.360doc.com/content/12/1202/22/3398926_251650422.shtml

posted @ 2014-08-08 11:33 Enic 閱讀(284) | 評論 (0) | 編輯收藏

（轉）客戶端架構設計的簡單總結

客戶端架構設計的簡單總結
（原文連接：http://m.shnenglu.com/weiym/archive/2014/07/26/207819.html）

我們知道，客戶端是相對服務端而言的，客戶端程序相對普通應用程序，主要是增加了網絡通訊功能。在這個移動和云存儲的年代，大部分終端應用程序都有網絡通訊功能，所以都可以稱為客戶端。常見的客戶端如瀏覽器，IM客戶端，網絡會議客戶端，郵件客戶端，微博和微信客戶端等...

通過觀察，我們會發現所有的客戶端基本是大同小異，都會包括一些相同的功能組件，下面簡單例舉下：

通訊協議層

既然客戶端都有網絡功能，就會涉及到通訊方式和數據格式以及協議，這三者不是完全獨立，而是有機統一的。

首先說通訊方式，常見的通訊方式包括TCP，UDP， P2P和http(s), 很多時候我們不會用單一的通訊方式，而是多種通訊方式的結合。比如說TCP端口被封，走不通時，我們會轉成嘗試http(s)。IM中聊天文本走的是TCP，由服務器轉發，但是2個客戶端之間的文件傳輸我們可能走的又是P2P了，多個人之間的語音聊天，我們走的又是UDP了。

其次說數據格式，常見的數據格式包括二進制編碼，開源序列化協議和文本格式。
二進制一般是自定義的私有格式，通常對數值，我們會轉成大頭端，對字符串我們會用UTF8 編碼，因為沒有冗余數據，它的優點是不會浪費帶寬；主要缺點是有硬編碼的味道，不好擴充。
開源序列化協議這里主要是指google的protocal buffer, 現在很多公司都在用，很多人基于它開發了自己的RPC框架。主要優點是數據小，使用簡單而高效。
文本格式主要是指xml和json. 相對來說xml比較清晰和容易擴充，但是冗余數據比較多。json借助javascript對它語言層次的支持，感覺主要是前端人員使用的比較多。

最后再說協議, 協議和我們的應用相關聯。比如郵件客戶端，當然是走SMTP和POP3了; IM客戶端的話，一般走XMPP了; 網絡會議的話，可以走ITU的T.120協議，也可以RFC 6501定義的XCON，信令走SIP，數據走RTP等。

通信協議層是整個客戶端網絡事件驅動的引擎，它可能會比較簡單，也可能會很復雜。如果是基于XMPP的IM，它可能會比較簡單，因為基本上只需要一層文本協議的封包和解包就可以了。當如果是基于T.120網絡會議客戶端，就會比較復雜，它數據包走的自定義的二機制格式，按照T.120協議的建議，在通訊協議層又分了3層：TP, MCS和GCC。TP層主要封裝數據傳輸的方式, 可以讓上層無差別的區分TCP和http(s)。 MCS層主要提供多點傳輸功能，它抽象出通道(channel)這個概念，讓不同session的數據進行邏輯隔離，上層用戶可以同時加入不同的通道來進行一對一和一對多的數據收發，并且通道中的數據有不同的優先級，還有令牌這個機制。我們也可以在MCS層對數據進行加密和壓縮，還可以對上層的大數據包進行切包等。 GCC層主要封裝會議的最基本邏輯，比如創建會議和加入session數據包的格式封裝等，讓上層可以通過API調用而不用關心協議要求的數據包格式。不同的數據包會工作在不同的層次，比如心跳包可能在底層TP層就被攔截了，它不要再往上層發，因為上面不用關心這個；而有些數據包，則需要從底層往上層按照整個協議棧層層轉發，當然每層都會剝離掉自己的協議頭，直至上層用戶數據到達它的最終用戶。

總之，通訊協議層封裝了客戶端和服務端的通訊方式及協議格式，讓上層用戶不用關心底層的通信機制，而只關注應用的接口事件。理論上我們可以在上層應用不做大調整的前提下，直接將網絡會議客戶端中的T.120協議成基于SIP的XCON。

功能組件

一個客戶端程序通常是由很多功能模塊組成，模塊按功能來說可以分為基礎組件和應用組件。

基礎組件為應用組件提供的基礎設施，基礎組件是可以在不同的項目中重復使用的(比如界面控件庫，2D渲染引擎Skia, 跨平臺的網絡和線程庫等)。
應用組件通常和我們當前的特定應用程序相關，比如我們的網絡會議客戶端包含的桌面共享模塊, 文檔共享模塊，視頻音頻模塊，文本聊天模塊等。

應用模塊本身分為帶界面和無界面兩種情況，帶界面的情況下我們通常會給組件提供一個容器窗口的句柄，讓組件自己在內部組織自己的界面。這種帶界面的組件通常會為邏輯和界面的分離帶來麻煩，在Window上實現一些半透明和動畫效果也很難。比如我們想提供跨平臺的SDK來封裝邏輯，這時我們會更傾向讓應用組件采用無界面的模式，組件在跨平臺層只封裝邏輯和提供數據，而把數據發到最上層界面層后再統一處理。

對功能組件我們的設計原則是盡量保持獨立和可復用，最好能以仿COM方式動態升級而不用重新編譯，另外組件之間要保持層次性，避免雙向或是循環依賴。

數據存儲

客戶端本身是處理和收發網絡數據，這里就涉及到對這些數據如何組織和存儲的問題。這個通常會根據客戶端的類型采用不同的處處理方式:
對于永久存儲的數據，當然是保存成文件或是存入數據庫，文件如xml, 數據庫如ACCESS, SQL server, mysql等。
臨時數據當然是存入內存了，根據需要采用不同的數據結構，組織格式如array，list, map, hashmap等。
還有一種是常見的數據保存方式是內存數據庫，最常見是SQLite了，內存數據庫既能高效的分類保存大量數據，又可以直接用基于SQL語句進行查詢和處理，比如foxmail客戶端就是用SQLite存儲的郵件信息。
還有一種是跨進程共享的數據，我們一般當然是內存映射文件了。比如我們有一個實時顯示log的工具，我們通常會在對方應用程序里分配共享內存的內存映射文件，所有的log都寫到里面，然后在log工具程序里讀取和顯示。
當然還有一些數據可能存到網上去的，常見的比如我們的云筆記, 這時數據分服務端數據和本地cache。

對于數據存儲我們的設計原則是根據需要，選擇簡單高效的方式。比如我們在設計網絡會議客戶端時曾討論要不要引入SQLite, 理想情況是引入內存數據庫后各個組件和上層應用的數據都可以統一存儲，采用數據驅動的方式，可以很方便的跟蹤整個客戶端的運行情況。但后來發現這種設計會把本來各自獨立的組件通過數據庫耦合在了一起，而且各組件的數據格式本身都很不要一樣，很難統一存儲，另外很多數據實際也只是臨時數據, 沒必要把簡單的時間做復雜了。

客戶端框架

客戶端框架一般有兩個作用：一是把所有的功能組件組織起來，進行統一的管理和展現；二是實現整個客戶端的主界面。客戶端框架在協調各個組件時，要注意避免讓組件之間產生雙向依賴，而是應該讓組件把事件通知給框架后由框架統一協調和處理，所以客戶端框架通常是整個客戶端邏輯最復雜的部分。一個好的客戶端框架，通常會采用插件方式設計，可以動態插拔需要的組件。最好是可以根據服務端的配置，動態下載和更新所需要的插件。

對于客戶端框架，我們的設計原則是低耦合和可擴展。基本上所有下層組件的改動都會影響到我們的客戶端框架，客戶的很多新需求和新組件也會導致框架產生壞味道，這里我們設計時就要考慮如何讓客戶端框架能及時的適應這些變化。

界面庫

客戶端肯定會有界面，在Windows平臺上，現在的界面大致分為以下幾類：
基于Windows原始窗口控件句柄的C++ native 客戶端，基于.net的winform客戶端，基于.net的WPF客戶端，基于C++的DirectUI客戶端，以嵌入瀏覽器(如webkit)方式實現的客戶端，還有一類是基于Xaml的Metro客戶端。

對于企業級大型安裝應用，主要考慮的是開發效率，所以客戶端還是以.net為主；但是對于互聯網企業，更多的是要求客戶端精簡而高效，所以還是以C++為主。這里就設及到C++的兩種界面庫，一種是基于windows窗口句柄和控件自繪機制的界面庫，還有一中是基于DirectUI的界面庫，現在大一點的公司基本上都有自己的DirectUI界面庫。基于修改Webkit方式實現的界面庫可以通過Canvas和SVG動畫等方式實現一些很炫的效果，但是它和標準程序的用戶體驗還是有一定差距：一來web實現的控件跟Windows標準控件有很大不同，二來web的流式布局和應用程序的網格布局也不一樣。

對于界面，個人覺得這個東西變化實在太快了，所以我覺得應該盡量用界面和邏輯相分離的方式組織代碼。

總結

對于客戶端架構設計，個人覺得最大的原則就分層設計，每層都封裝一個概念并保持獨立，同時根據依賴倒置的原則，站在上層客戶的角度提供接口。軟件工程里面的一條黃金定律:“任何問題都可以通過增加一個間接層來解決。

posted @ 2014-07-30 18:41 Enic 閱讀(210) | 評論 (0) | 編輯收藏

cmake vs2012指定v11_

http://www.cmake.org/Bug/view.php?id=13774

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=89595d6b

http://www.cmake.org/cmake/help/v2.8.10/cmake.html#variable:CMAKE_VS_PLATFORM_TOOLSET

cmake ../ -G"Visual Studio 11" -Tv110_xp

cmake-gui貌似還不知道怎么直接生成，這是CMAKE_VS_PLATFORM_TOOLSET貌似沒用，但是可以先用命令行生成，然后在用gui修改其他變量？

posted @ 2014-06-27 14:12 Enic 閱讀(1567) | 評論 (1) | 編輯收藏

lua的編碼風格很爽啊

這樣完全只要關系邏輯了，別的都秒殺，只是代碼出錯了，多半要用肉眼看，，，
再有就是用luabind class的細節，還不了解

CTestClass =

{

m_TestVal = 0,

m_funcTest = nul

}

function CTestClass:SetValue(v)

self.m_TestVal = v;

end

function CTestClass:TestShow()

print(self.m_TestVal);

end

function CTestClass:SetTestFunc(func)

self.m_funcTest = func;

end

function CTestClass:CallTestFunc()

self.m_funcTest();

end

function CTestClass:TestHandleFunc(msg)

print(msg)

end

t1 = CTestClass;

t1:SetValue(123321);

t1:TestShow();

t1:SetTestFunc(

function ()

t1:TestHandleFunc('TestHandleFunc')

end);

t1:CallTestFunc();

posted @ 2014-06-26 10:58 Enic 閱讀(316) | 評論 (2) | 編輯收藏

UI xml文件方案的選擇

參考了：cegui 魔獸世界迅雷 mygui
主要問題如下：
Q1: 控件的屬性是放到xml節點的屬性中，還是作為子節點。放到屬性中方便，但是xml太長，人眼看的時候費勁，子節點會好很多。
Q2: 控件之間的父子關系是直接用xml的節點父子關系來表達，還是和魔獸世界一樣允許parent="UIParent"，這樣設置。我可能還需要“include”其他xml中定義的控件？
直接xml父子節點：優勢是關系簡單明了，缺陷是UI復雜以后堆積的xml文件太長，人眼也無法看明白了
魔獸世界：他們的做法可以分離每個控件出來，但是層次關系又不明朗了。
允許類似<Window></InsertControlByName name="ChirdControl" type="Type"></Window>這樣的特殊節點，平衡兩者有優劣勢。但是名字空間還是需要非常留意的點。
另外可以支持<ExportControls></Window name="ExportWnd"></ExportControls>，<InportControls></InportControl name="Import" type="Type" ImportFile="xxx.xml"><InportControls>
type屬性不必要，但是加上以后可以讓xml自校驗能力更強

解決名字沖突還是沒什么辦法。但是庫必須提供名字無關的控件消息綁定手段！允許全局重復名字的控件

</Window>

</Window>

</GUILayout>

<Framename="EnterLeaveTest" parent="UIParent">

</Anchors>

</Layer>

</Layers>

ChatFrame1:AddMessage("++ 進入窗體：" .. self:GetName())

</OnEnter>

ChatFrame1:AddMessage("-- 離開窗體：" .. self:GetName())

</OnLeave>

</Scripts>

</Frame>

<xlue>

<attr_def>

</attr_def>

<method_def>

</method_def>

<event_def>

</event_def>

<attr>

<width>father.width</width>

<height>father.height</height>

</attr>

<attr>

<width>father.width</width>

<height>father.height</height>

<visible>false</visible>

<filltype>singlecolor</filltype>

</attr>

<attr>

<width>father.width - 10</width>

<visible>false</visible>

<image>bitmap.right.triangle</image>

</attr>

</obj>

<attr>

<width>father.width - 15</width>

<height>father.height - 6</height>

</attr>

</obj>

</children>

</obj>

</children>

</obj>

</children>

</eventlist>

</objtemplate>

</control>

<?xml version="1.0" encoding="UTF-8"?>

</Widget>

</Widget>

</Widget>

</MyGUI>

posted @ 2014-06-24 11:45 Enic 閱讀(359) | 評論 (0) | 編輯收藏

lua cpp混編-處理事件響應

目前覺得比較好的做法，C++寫具體控件效果，lua處理事件響應
<EventList>
<Event Name="OnCreate" File="LogonWnd.xml.lua" Func="MSG_OnCreate"/>
</EventList>

function MSG_OnCreate(self)

i = 0

print(self)

end

self為事件源注冊到lua中的類型事例。

迅雷界面庫中還有另一種做法：

function OnInit()

local owner = self:GetOwner()

local objFactory = XLGetObject("Xunlei.UIEngine.ObjectFactory")

local newIcon = objFactory:CreateUIObject("icon2","ImageObject")

local xarManager = XLGetObject("Xunlei.UIEngine.XARManager")

newIcon:SetResProvider(xarManager)

newIcon:SetObjPos(45,165,45+70,165+70)

newIcon:SetResID("app.icon2")

local function onClickIcon()

XLMessageBox("Don't touch me!")

end

newIcon:AttachListener("OnLButtonDown",true,onClickIcon)

self:AddChild(newIcon)

end

直接在lua層處理事件，貌似更舒服了。但是所引用的函數不能是上層C的，也不能有self參數了，否則內存管理又是一大害處。
這里的AttachListener應該和上層的Wnd類或者對應的派發消息的CPP里邊的《EventList》關聯，貌似這樣能動態添加消息處理器，而且不用擔心對象生命周期管理。

觀摩了一下迅雷的sdk給的粒子，發現他們可能修改了虛擬機，發現在不同的文件中會有相同的函數，而且都是全局的，聯想到前面配置的時候要給定一個文件名和一個函數名，要么就傻逼的每次調用前都要loadfile一次，不然很可能修改lua虛擬機，或者lua api支持按文件索引。

問題：cpp向lua派發事件的時候函數名，名字沖突。迅雷的做法是文件名+函數名索引，但是目前我的技術積累做不到。
解決辦法：
1.靠自己約定，即自己確保所有lua文件中都沒有相同的函數
2.參考魔獸世界，然后加點佐料的做法：<scripts file="LogonWnd.lua" /> <Event EventName="BtnClick" EventSink="LogonWnd.BtnClick">
也就是默認每個文件名中的所有函數都在以文件名為名字控件的作用域下

posted @ 2014-06-19 11:56 Enic 閱讀(402) | 評論 (0) | 編輯收藏

Error

常用鏈接

留言簿(5)

隨筆分類

隨筆檔案

文章分類

文章檔案

相冊

搜索

最新評論

閱讀排行榜

評論排行榜

rundll32.exe編輯