我寫了一個使用glew初始化OpenGL上下文的DLL。首先，我創建了一個虛擬窗口來創建適當的上下文。其次，創建最終的上下文和窗口。 glewInit()函數調用成功和一些布爾變量，如GLEW_ARB_texture_storage設置爲1（我有一個視頻適配器與opengl 3.3兼容）。glewInit（）和客戶端程序中的GLEW_ARB_xxx_失敗
注意
glewExperimental=GL_TRUE
雖然。
但是，當我使用上面的DLL編寫客戶端程序時，同樣的GLEW_ARB_texture_storage變量等於GL_FALSE。
因此，我想知道glewInit()應該在哪裏最終被調用？ 似乎從DLL調用它是不夠的。我是否也應該從客戶端程序端調用它？
我其實不會在你的虛擬上下文中初始化GLEW。考慮手動加載您需要手動創建最終上下文所需的一個或兩個擴展（例如WGL_ARB_create_context和WGL_ARB_pixel_format）。當您創建兩個不同的上下文時，不保證在Windows上獲得相同的ICD實現。這就是創建GLEW MX的原因。
現在，我懷疑發生在您的案例中並不是實際上您正在獲得兩種不同的ICD（這在現實世界中極爲罕見），但實際上您創建的第一個上下文是兼容性配置文件，其次是核心概況。
GLEW使用擴展字符串初始化變量（如GLEW_ARB_texture_storage），但在覈心配置文件中，GLEW不夠聰明以正確的方式解析該字符串（多次調用glGetStringi (...)）。這就是爲什麼你必須使用GLEW_EXPERIMENTAL。
GLEW_EXPERIMNETAL告訴GLEW嘗試加載它所知道的每個擴展的每個函數指針，而無需先解析任何擴展字符串來檢查可用性。這是核心配置文件中的必要罪惡，但不是兼容性（因爲舊的擴展字符串機制在兼容性方面仍然有效）。任何依賴解析擴展字符串的GLEW部分都不能在覈心配置文件中正常工作。
我寫了使用GLEW
那不是GLEW做初始化OpenGL上下文的DLL。 GLEW不初始化OpenGL上下文，GLEW加載OpenGL擴展函數地址並初始化函數指針。您必須調用帶有已創建的OpenGL上下文的GLEW，並在調用glewInit()的線程中進行調用。
你的程序在某個地方創建了一個OpenGL上下文，之後顯然調用了glewInit()。並且從描述它的方式來看，您的DLL可能只是通過DllMain入口函數調用glewInit()，該函數在DLL加載時調用，這通常在調用進程WinMain或/ main函數之前調用，因此OpenGL上下文沒有被創建。你當然可以在你的DLL中創建一個OpenGL上下文，但是你必須問自己，如果這對DLL的用戶有意義。
你好。在我的DLL中，我當然在調用glewInit（）之前創建了一個相應的窗口和一個有效的opengl上下文。 – Zyend 2014-12-02 06:27:48
好的。它是否也解釋了爲什麼glGetString（GL_EXTENSIONS）在創建虛擬上下文時返回有效的字符串，並且在創建最終上下文時返回NULL指針？ – Zyend 2014-12-02 06:31:17
@Zyend：是的，不僅如此。但是當你在最終的上下文中調用它時，它也會生成'GL_INVALID_ENUM'。在調用之前和之後檢查'glGetError（...）'。 – 2014-12-02 08:26:52
你是對的Andon，第一個創建的上下文是兼容性配置文件，第二個是核心配置文件。將GLEW_EXPERIMENTAL設置爲GL_TRUE可以解決我庫中的問題。 但是，在客戶端程序中，例如，我無法測試GLEW_ARB_texture_storage。而在DLL端這個變量= GL_TRUE。我改變了我的DLL到一個靜態庫...並在那裏工作。 – Zyend 2014-12-02 08:55:20