一、开机自运行常规方法[转载]
近日在开发过程中遇到WinCE应用程序开机自动运行的问题，在网上找了找，发现大概有以下三种方法：1、 将应用程序和应用程序快捷方式添加到映像里，再将快捷方式添加到StartUp目录下，这样当系统运行后应用程序就能自动运行；2、 直接替换Wince的SHELL，即修改注册表：
view plain copy to clipboard print ? [HKEY_LOCAL_MACHINE/init] "Launch50"="explorer.exe" "Depend50"=hex:14,00, 1e,00 把这个explorer.exe改成你的应用程序（比如：MyApp.exe）； 3、 把应用程序加入到映像，修改注册表： [HKEY_LOCAL_MACHINE/init] "Launch80"="MyApp.exe" "Depend80"=hex:1E,00 可以设置启动顺序和依赖程序， 这个是设定启动顺序，launch后面的数字越大的越是后启动，Depend80后面的指定依赖项，为16进制，上面的语句表明依赖项为launch20 定义的device.exe和launch30中定义的gwes.exe， 注意Launch后面的数字范围为0到99 ，此范围之外的将不会有效果。 以上方法都可行，但是都存在一个问题，就是 应用程序是集成到NK里面的，也就是说每次升级应用程序都要重新编译下载内核，很麻烦，尤其在程序调试阶段，大家都希望把应用程序放在SD卡上，这样更新起来比较容易； 据说通过第三种方法可以实现，即修改"Launch80"="MyApp.exe" 为"Launch80"="/STDCard/MyApp.exe"( STDCard为SD卡目录)， 但是我试了一下没有成功，因为Launch80运行时SD卡的文件驱动还没有加载, 找不到MyApp.exe文件。同样， 采用快捷方式加载SD卡里的应用程序也不可行。
所以我采用了另一种方法，自己编了一个小程序，比如叫ShellExe.exe，将此程序加入到映像里，通过StartUp快捷方式调用ShellExe，ShellExe再去调用SD卡里的应用程序，具体实现步骤如下：1、 在eVC下编译如下代码：
view plain copy to clipboard print ? int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPTSTR lpCmdLine, int nCmdShow) { WIN32_FIND_DATA fd; HANDLE hd = INVALID_HANDLE_VALUE; int iCount = 20; while(iCount--) { hd = ::FindFirstFile(lpCmdLine, &fd); Sleep(500); if(INVALID_HANDLE_VALUE!=hd) break; } if(0==iCount) return 0; FindClose(hd); SHELLEXECUTEINFO ShExeInfo={0}; ShExeInfo.cbSize = sizeof(SHELLEXECUTEINFO); ShExeInfo.fMask = SEE_MASK_NOCLOSEPROCESS; ShExeInfo.hwnd = NULL; ShExeInfo.lpVerb = NULL; ShExeInfo.lpFile = lpCmdLine; ShExeInfo.lpParameters = L""; ShExeInfo.lpDirectory = NULL; ShExeInfo.nShow = SW_SHOW; ShExeInfo.hInstApp = NULL; ShellExecuteEx(&ShExeInfo); return 0; } 生成ShellExe.exe的可执行文件，此段代码主要功能是查找指定的应用程序，然后执行；下面这段代码可以保证在SD卡文件系统正确加载后才去执行应用程序；
view plain copy to clipboard print ? while(iCount--) { hd = ::FindFirstFile(lpCmdLine, &fd); Sleep(500); if(INVALID_HANDLE_VALUE!=hd) break; }
文件的名称和路径由命令行参数指定：
ShExeInfo.lpFile = lpCmdLine;
2、 新建一个快捷方式，如Autorun.lnk，按如下方式编辑其内容：21#/windows/shellexe.exe /stdcard/MyApp.exe
其中/stdcard/MyApp.exe应用程序的绝对路径；3、 将MyApp.exe和Autorun.lnk添加到NK里，方法是在project.bib文件内加入如下内容：ShellExe.exe f:/WINCE420/PBWORKSPACES/LioetEnTer/RelDir/ShellExe.exe NK SAutorun.lnk f:/WINCE420/PBWORKSPACES/LioetEnTer/RelDir/Autorun.lnk NK S
注意：ShellExe.exe的属性不能带H（隐藏）.4、 在project.dat里加入如下内容：Directory("/Windows/Startup"):-File("Autorun.lnk","/Windows/Autorun.lnk")
5、 选择Make Image生成映像（当然Build也可以，就是慢点儿），烧到FLASH里，开机运行，可以看到SD卡里的MyApp.exe被正确执行。总结 这种方法用起来比较方便，ShellExe.exe不用每次都重新编译，只要根据应用程序路径修改Autorun.lnk即可，可以加载Flash、U盘、SD卡里的应用程序。调试及升级应用程序就不用重新烧写内核了。
二、开机运行MFC程序
WinCE开机即运行定制的Shell是很多系统的基本要求，有时还需要屏蔽WinCE自带的Shell。WinCE中程序的自启动，一般有两个实现方法，修改注册表和添加自启动快捷方式。修改注册表比较方便，如下：
view plain copy to clipboard print ? [HKEY_LOCAL_MACHINE/init] "Launch70"="MyApp.exe" "Depend70"=hex:14,00,1e,00
只要将MyApp.exe打包到NK，并在platform.reg中加入上面的注册表信息，这样WinCE启动时便会自动运行该程序。但这时WinCE自带的Shell总是先出来，然后才运行MyApp.exe，为了避免这种情况，我们可以将注册表设置修改如下：
view plain copy to clipboard print ? [HKEY_LOCAL_MACHINE/init] "Launch50"="MyApp.exe" "Depend50"=hex:14,00,1e,00
即将原来启动explorer.exe的值换为MyApp.exe。这样WinCE启动时直接进入定制的Shell，而不启动explorer.exe。但这时有可能引入了新问题，如果定制的Shell是基于MFC编写的，并且其中用到了如CFileDialog等类库时，就会出现意想不到的情况，如下图所示：
图是在不启动Explorer.exe时，尝试导入注册表文件出现的状况截图，而在启动explorer.exe时是没有问题的。这说明CFileDialog在某种程度上依赖于explorer.exe，具体细节没研究。但说明不启动explorer.exe，基于MFC的Shell运行时就可能会出问题。所以explorer.exe必须启动，但又不能出现WinCE界面。要解决这个问题自然就想到修改explorer.exe了。WinCE5.0和WinCE6.0中，这一部分的代码都是公开的，在WinCE6.0中Shell的相关代码在C:/WINCE600/PUBLIC/SHELL/OAK/HPC/EXPLORER/MAIN目录下。
大致看了一下这一部分的代码，发现只需修改如下两个文件，就应该能实现需求。
C:/WINCE600/PUBLIC/SHELL/OAK/HPC/EXPLORER/MAIN/desktop.cpp
view plain copy to clipboard print ? bool CDesktopWnd::Create() { IShellFolder *pSHF; FOLDERSETTINGS fs; RECT rc; HRESULT hr = E_FAIL; // Get a shell folder for the desktop hr = SHGetDesktopFolder(&pSHF); if(hr || !pSHF) goto Cleanup; // create a shell view for it hr = pSHF->CreateViewObject(NULL, IID_IShellView, (LPVOID *)&_psv); if(hr || !_psv) goto Cleanup; fs.ViewMode = FVM_ICON; fs.fFlags = FWF_DESKTOP | FWF_ALIGNLEFT | FWF_NOSCROLL; //++changed by hjb //将Desktop的窗口大小设为0 //SetRect(&rc, 0, 0, GetSystemMetrics(SM_CXVIRTUALSCREEN), GetSystemMetrics(SM_CYVIRTUALSCREEN)); SetRect(&rc, 0, 0, 0, 0); //--changed by hjb // create the desktop's view window (no need to AddRef since CreateViewWindow does it) hr = _psv->CreateViewWindow(NULL, &fs, (IShellBrowser *)this, &rc, &_hWnd); if(hr || !_hWnd) { Release(); goto Cleanup; } RegisterDesktop(_hWnd); Cleanup: if(pSHF) pSHF->Release(); return (hr == S_OK); }
C:/WINCE600/PUBLIC/SHELL/OAK/HPC/EXPLORER/MAIN/explorer.cpp
view plain copy to clipboard print ? DWORD WINAPI CreateTaskBar(LPVOID pEvent) { HANDLE hSyncEvent = *((HANDLE *) pEvent); CTaskBar *pTaskBar = NULL; HWND hwndTB = NULL; pTaskBar = new CTaskBar; //++added by hjb //在创建任务栏时强制终止 if(pTaskBar) { delete pTaskBar; SetEvent(hSyncEvent); return 0; } //--added by hjb if(!pTaskBar) { SetEvent(hSyncEvent); return 0; } g_TaskBar = pTaskBar; if(!pTaskBar->Register(g_hInstance)) { g_TaskBar = NULL; delete pTaskBar; SetEvent(hSyncEvent); return 0; } RegisterTaskBar(pTaskBar->GetWindow()); SetEvent(hSyncEvent); DWORD dwRet = pTaskBar->MessageLoop(); delete pTaskBar; return dwRet; }
修改完这两处后，先编译该目录，然后再重新编译整个系统(执行Sysgen)应该就可以了。Explorer.exe依然启动，依然可以听到WinCE启动的声音，但WinCE的界面已经屏蔽掉了。此时，基于MFC的Shell也能正常工作，如下图所示：
在实际操作时，我没有通过修改源代码编译来完成这个测试。因为在编译C:/WINCE600/PUBLIC/SHELL/OAK/HPC/EXPLORER/MAIN目录时，发现它只生成了explorer.lib。考虑到重新编译整个系统的时间太长，所以直接修改了工程目录下的explorer.exe的文件，MakeImg后测试的。这里应该有快速编译的方法，但目前不知怎么弄。
修改后，在WinCE6.0的模拟器中测试，达到了预想的效果。这样就大概解决了基于MFC的Shell和Explorer.exe之间的矛盾，是不是有隐患还不清楚，目前看来没问题。
另外需要注意，修改public和private目录下的文件时，一定先做好备份，以免后患
