版本編譯後的時序告警

⑴ 本來這個代碼之前可以運行，後面重裝了C++後就不能運行了，編譯後就有這個問題，求解

VC9編譯的程序在沒有裝過VC9（確切的說是.Net Framework3.5）的機器上運行時，如果提示「由於應用程序配置不正確，應用程序未能啟動。重新安裝應用程序可能會糾正這個問題。」這個錯誤，那 么就說明該程序動態鏈接了VC9的運行時庫，（如果還用到了MFC，那麼可能動態鏈接了VC9的MFC庫，同理還有ATL庫），以及缺少對應的 manifest文件，程序在目標機器上沒有找到這些庫和配置文件，因此導致了這個錯誤。出現這種情況的VC9編譯器可能存在3個版本，接下來分別闡明：
1、沒有打過任何補丁的VS2008
該版本對應的CRT/MFC/ATL庫的版本號為9.0.21022.8，這個版本號在後面 會用到。這個版本的程序部署比較簡單，直接把VC安裝目錄下的redist目錄（C:/Program Files/Microsoft Visual Studio 9.0/VC/redist）中需要的庫以及對應的manifest文件拷貝到執行程序同目錄下，這樣程序到任何機器上都能夠正常運行了。
2、打過SP1補丁的VS2008
打過該補丁後，系統中存在著兩個版本的CRT/MFC/ATL庫，版本號分別為 9.0.21022.8和9.0.30729.1，這導致了manifest文件中記錄的版本號和實際庫的版本號不一致（程序要求它們的版本號一致才能運 行）。這個版本的程序部署需要兩個步驟，首先要使manifest文件中依賴項的版本號與實際庫的版本號一致，均為9.0.30729.1，方法是在工程 設置中增加一個宏定義_BIND_TO_CURRENT_VCLIBS_VERSION，該宏定義於C:/Program Files/Microsoft Visual Studio 9.0/VC/include/crtassem.h文件中，然後重新編譯程序。接下來還是將VC安裝目錄下的redist目錄（C:/Program Files/Microsoft Visual Studio 9.0/VC/redist）中需要的庫以及對應的manifest文件拷貝到執行程序同目錄下，然後修改manifest文件中依賴項的版本號為 9.0.21022.8，這樣使得程序誤以為該目錄下庫的版本號為9.0.21022.8（實際上是9.0.30729.1版本），這樣程序到任何機器上 都能夠正常運行了。
3、打過SP1補丁與SP1 ATL 安全更新 (KB973675)的VS2008
這是最新的更新。在SP1補丁之後，微軟又於近日發布了一個用於智能設備的 Microsoft Visual Studio 2008 Service Pack 1 ATL 安全更新 (KB973675)， 該補丁又將CRT/MFC/ATL庫的版本號升級，為9.0.30729.4148，這次升級比較好，manifest文件與庫的版本號一致了，不像 SP1一樣升級的不徹底。這樣只需要在工程設置中增加一個宏定義_BIND_TO_CURRENT_VCLIBS_VERSION，接下來重新編譯程序， 然後直接把VC安裝目錄下的redist目錄中需要的庫以及對應的manifest文件拷貝到執行程序同目錄下，這樣程序到任何機器上都能夠正常運行了。
順便提一下，如果不想在發布程序時帶上這些庫和manifest文件（如果沒有必要的話），那麼可以採用靜態編譯CRT和MFC，然後把manifest文件添加到資源中，這樣編譯出的程序只要一個exe就可以在任何機器上直接運行了。
參考文章：
1、「應用程序配置不正確，程序無法啟動」的解決方法資料收集：
有的時候，你在Visual C++上面經過好幾個月的辛勤努力，終於將程序編寫完成並且測試完畢，然而當你試圖在客戶的發布機上運行剛寫好的程序時，有可能會碰到類似下面的錯誤，操 作系統告訴你「由於應用程序配置不正確，應用程序未能啟動。重新安裝應用程序可能會糾正這個問題」.
一般情況下，這個問題都是由於程序不能找到所需要的C運行庫（CRT）而引起的。

在Windows XP SP2以後，Windows引入了Side-by-Side執行的概念，這個概念本來是.NET提出來的，但是Windows後來將這個概念集成到操作系統層面上來了。大家都應該知道Dll Hell 的問題，為了解決Dll Hell 的問題，Side-By-Side提出不同版本的dll文件可以同時存在於同一個系統裡面，而且依賴於不同版本dll的應用程序在運行的時候可以使用到它當初被編譯生成的dll。前面的話，有點繞，舉個例子：
1. 假定你編寫了一個C++程序A，是使用MFC 8.0（這個版本是隨著Visual Studio 2005）發布的。
2. 之後你的機器升級了Visual Studio的版本，從2005升級到2008，2008的MFC庫是9.0版本的，這個時候你的操作系統裡面安裝了兩個版本的MFC，分別是8.0和9.0。
3. 你在Visual Studio 2008編寫了另外一個C++程序B，B依賴與MFC 9.0。
4. 如果你運行程序A的話，操作系統會將MFC 8.0載入到A的進程裡面。
5. 如果你這時同時運行程序B，操作系統會將MFC 9.0載入到B的進程裡面。這就是Side-by-side的執行概念。

操作系統之所以能夠這樣做，是因為它在載入程序A和B之前，除了查看PE格式裡面A和B所依 賴的Dll信息，都會查看A和B的manifest文件。Manifest文件保存了Windows可執行文件（包括exe和dll文件）要運行起來的環 境設置信息，文件名一般是可執行文件的文件全名加上.manifest。例如notepad.exe的manifest文件就應該是 notepad.exe.manifest。例外有的程序將manifest文件直接嵌入到可執行文件的資源裡面了，這也就是為什麼有的時候你看不到程序 的manifest文件的原因。通常來說，一個manifest文件的內容如下（test.exe.manifest文件）：

⑵ Quartus ii 下用Verilog編譯成功後，為什麼總有很多警告

不用care的
這些warning一些設置的東西，比如說pin分配，懸空管腳的約束，時序約束等。
當然你要是想學好，用好這個軟體，你可以根據warning提示進行相關設置，然後重新編譯，就可以消除的！

⑶ 用quartus ii 11.0編譯quartus ii 9.0建立的工程後下載到fpga里出現異常

你好！
重新建立工程，拷貝源文件到新建文件中編譯下載完成！
我的回答你還滿意嗎~~

⑷ Windows 10 20170編譯版本帶來了哪些變化

電腦已經成為了人們日常生活中不可缺少的生活工具，電腦所使用的場景也越來越普遍，人們對電腦性能的要求也越來越高。 Window10 20170翻譯版本上線，然後很多人都想知道它有哪些變化。接下來小編帶大家進行了解。

就這次更新小編個人看來這次更新還是可以的。不知道大家這次有什麼看法。歡迎在下面留言評論。

⑸ 關於c++Builder XE英文版本編譯問題

第一個問題：
\n 和 endl 表示回車。

第二個問題：
1、gets(str);
是從緩沖區中讀取字元串，然後保存到數組str中直到遇到回車符，換行符不作為字元串的內容，讀取的換行符會轉換為NULL值，由此標志程序的結束。

2、cin.getline(char*line,int size,char ='"n')是讀入一行字元,第二個參數是本次讀取的最大字元個數，第三個參數是分隔字元，作為讀取一行結束的標志,默認是\n。

3、cin.get()第一個用法，是讀入一個字元。 cin.get()第二個用法，也是輸入一行（同cin.getline()），但是區別就是，不輸出分隔符

補充一下：
cin.getline() 與 cin>>str 的一個不同是，前者輸入一行，行中可以包含空格，後者卻以空格或回車作為字串結束，不包含空格。

補充：get() 和getline()的異同
1）相同點：
要獲取一行的輸入，標准流類的成員函數getline(),get()都有三個參數，比如getline(char*line,int size,char ='\n')。其中第一個參數指向存儲結果字元的緩沖區指針，第二個表示緩沖區大小（本次讀取的最大字元個數，不能夠超過其限度），第三個表示知道什麼時候停止讀輸入的終止符（讀取一行結束的標志）。終止符有一個經常用到的預設值"\n"。兩個函數遇到輸入終止符時，都把零儲存在結果緩沖區里。
2）不同點：
1.一般來講，get()一次讀入一個字元，getline()一次讀入一行字元
2.在處理字元串時，get()遇到輸入流的分隔符時就停止，而不從輸入流中提取分隔符。比如用cin.get(myarray1,20,'*'); 處理字元串1111*2222，碰到*就停止。cout<<myarray1;會輸出1111。然後再調用cin.get(ch1)，cout<<ch1;輸出的還是這個分隔符*。getline()與其相反，它從輸入流中提取分隔符，但仍沒有把它儲存在結果緩沖區里。如果用cin.getline(myarray2,20,'*');處理上面同樣的字元串1111*2222，碰到*停止。 cout<<myarray2;會輸出1111。然後再調用cin.get(ch2)，cout<<ch2;輸出的是分隔符後面的2。

3）代碼演示：
#include <iostream>
#include <iomanip>
using namespace std;

void main()
{
char myarray1[20],myarray2[20];
cin.get(myarray1,20,'*');
cout<<myarray1;
char ch1;
cin.get(ch1);
cout<<ch1;

cin.getline(myarray2,20,'*');
cout<<myarray2;
cin.get(ch1);
cout<<ch1;
}

4）read 函數和 write函數
最近開始從事搜索引擎的工作,所以又重新開始了c/c++的旅程,時隔4年
不得不復習一下c/c++其中的內容,以下內容有網上別的朋友發表的,也有我自己總結的.
1. read
#include
ssize_t read(int filedes, void *buf, size_t nbytes);

返回值：讀取到的位元組數；0（讀到 EOF）；-1（出錯）
read 函數從 filedes 指定的已打開文件中讀取 nbytes 位元組到 buf 中。以下幾種情況會導致讀取到的位元組數小於 nbytes ：
A. 讀取普通文件時，讀到文件末尾還不夠 nbytes 位元組。例如：如果文件只有 30 位元組，而我們想讀取 100
位元組，那麼實際讀到的只有 30 位元組，read 函數返回 30 。此時再使用 read 函數作用於這個文件會導致 read 返回 0 。
B. 從終端設備（terminal device）讀取時，一般情況下每次只能讀取一行。
C. 從網路讀取時，網路緩存可能導致讀取的位元組數小於 nbytes 位元組。
D. 讀取 pipe 或者 FIFO 時，pipe 或 FIFO 里的位元組數可能小於 nbytes 。
E. 從面向記錄（record-oriented）的設備讀取時，某些面向記錄的設備（如磁帶）每次最多隻能返回一個記錄。
F. 在讀取了部分數據時被信號中斷。
讀操作始於 cfo 。在成功返回之前，cfo 增加，增量為實際讀取到的位元組數。
2. write
#include
ssize_t write(int filedes, const void *buf, size_t nbytes);

返回值：寫入文件的位元組數（成功）；-1（出錯）
write 函數向 filedes 中寫入 nbytes 位元組數據，數據來源為 buf 。返回值一般總是等於 nbytes，否則就是出錯了。常見的出錯原因是磁碟空間滿了或者超過了文件大小限制。
對於普通文件，寫操作始於 cfo 。如果打開文件時使用了 O_APPEND，則每次寫操作都將數據寫入文件末尾。成功寫入後，cfo 增加，增量為實際寫入的位元組數。
From : antigloss

⑹ 主板報警聲

從網上找的，希望對你有幫助
1.拔掉音頻線，如果沒有噪音了，則是電腦音效卡輸出有問題
2.拔掉音頻線如果還有，是音響自身問題
原因是音頻放大迴路的零漂引起。
有聲音就代表是硬體了，那麼在轉動的硬體是那些呢？主要就是風扇了，看看顯卡、CPU等的風扇是否正常吧
4.有些木馬是利用Rundll32.exe載入DLL形式運行的，但大多數情況下Rundll32.exe都是載入系統的DLL文件，不用太擔心,如果用最新殺軟掃描過應該沒什麼問題(現在SRENG2.5.16.900版本的診斷一般很准確).可以從查看硬體入手,另外我覺得您應該具體描述以下是怎響的:1、是否是在連網的狀態下2、是否是在瀏覽網頁的狀態下3、開機多長時間開始響，頻率如何4、進程的截圖最好傳個上來
BIOS告警。。。
請按照告警聲與下面文章對照

BIOS告警聲全版

1. AMI BIOS
1短--內存刷新失敗
2短--內存ECC校驗錯誤
3短--系統基本內存（第1個64K）檢查失敗
4短--系統時鍾出錯
5短--中央處理器（CPU）錯誤
6短--鍵盤控制器錯誤
7短--系統實模式錯誤，不能切換到保護模式
8短--顯示內存錯誤（顯示內存可能有所損壞）
9短--ROM BIOS檢驗和錯誤
1長3短--內存錯誤（內存損壞，請更換）
1長8短--顯示測試錯誤（顯示器數據線松動或顯示卡沒插穩）
2. Award BIOS
1短--系統正常啟動
2短--常規錯誤，請進入CMOS SETUP重新設置不正確的選項
1長1短--RAM或主板出錯
1長2短--顯示錯誤（顯示器或顯示卡）
1長3短--鍵盤控制器錯誤
1長9短--主板FlashRAM或EPROM錯誤（BIOS損壞）
不斷地響（長聲）--內存沒插穩或損壞
不停地響--電源、顯示器和顯示卡沒有連接好
重復短響--電源故障
無聲音無顯示--電源故障
3. Phoenix BIOS
1短--系統正常啟動
3短--系統加電自檢初始化（POST）失敗
1短1短2短--主板錯誤（主板損壞，請更換）
1短1短3短--主板電池沒電或CMOS損壞
1短1短4短--ROM BIOS校驗出錯
1短2短1短--系統實時時鍾有問題
1短2短2短--DMA通道初始化失敗
1短2短3短--DMA通道頁寄存器出錯
1短3短1短--內存通道刷新錯誤（問題范圍為所有的內存）
1短3短2短--基本內存出錯（內存損壞或RAS設置錯誤）
1短3短3短--基本內存出錯（很可能是DIMM槽上的內存損壞）
1短4短1短--基本內存某一地址出錯
1短4短2短--系統基本內存（第1個64K）有奇偶校驗錯誤
1短4短3短--EISA匯流排時序器錯誤
1短4短4短--EISA NMI口錯誤
2短1短1短--系統基本內存（第1個64K）檢查失敗
3短1短1短--第1個DMA控制器或寄存器出錯
3短1短2短--第2個DMA控制器或寄存器出錯
3短1短3短--主中斷處理寄存器錯誤
3短1短4短--副中斷處理寄存器錯誤
3短2短4短--鍵盤時鍾有問題，在CMOS中重新設置成Not installed來跳過POST
3短3短4短--顯示卡RAM出錯或無RAM，不屬於致命錯誤
3短4短2短--顯示器數據線鬆了或顯示卡沒插穩或顯示卡損壞
3短4短3短--未發現顯示卡的ROM BIOS
4短2短1短--系統實時時鍾錯誤
4短2短3短--鍵盤控制器（8042）中的Gate A20開關有錯，BIOS不能切換到保護模式
4短2短4短--保護模式中斷錯誤
4短3短1短--內存錯誤（內存損壞或RAS設置錯誤）
4短3短3短--系統第二時鍾錯誤
4短3短4短--實時時鍾錯誤
4短4短1短--串列口（COM口、滑鼠口）故障
4短4短2短--並行口（LPT口、列印口）錯誤
4短4短3短--數學協處理器（8087、80287、80387、80487）出錯

⑺ XILINX FPGA時序告警如何消除時序告警得分很高，但被告警的線都是些不重要的(不必分析的)。

false path
ignore
參見這2條約束

⑻ 錯誤 1 error C1853: 「Debug\test.c.pch」預編譯頭文件來自編譯器的早期版本，或者預編譯頭為 C++ 而在 C

告警信息里有說明，可能是你包含的頭文件是不當前所使用編譯器里的頭文件。
檢查一下頭文件是不是當前所使用的編譯器里的文件。

⑼ quartus全編譯總是提示時序不滿足

時序分析不滿足當然時序模擬不會正確了呀，功能模擬是不計算邏輯單元與走線延時的，只能進行功能驗證，時序模擬含有時序信息，說明你的設計沒有遵循同步時序邏輯設計

⑽ 在高版本內核上編譯的程序在低版本內核運行會崩潰

glibc主版本號。
而且編譯的時候如果CGFLAGS和CXXFLAGS如果沒有-g選項的話用gdb調試無法看到變數名，默認是提示有問題。