Search Results

Search found 5127 results on 206 pages for 'mscorwks dll'.

Page 2/206 | < Previous Page | 1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >

  • Error while dynamically loading mapi32.dll

    - by The_Fox
    Our application uses Simple MAPI to send e-mails. One of our clients has problems sending e-mail from a session on his terminal server. The mapi32.dll is loaded with a call to LoadLibrary which succeeds, but then our application tries to get the addresses of the functions MAPILogon, MAPILogOff, MAPISendMail, MAPIFreeBuffer and MAPIResolveName. The problem is that GetProcAddress fails for those functions with an ERROR_ACCESS_DENIED (code: 5) except for MAPIFreeBuffer. It looks like some sort of security thing. How can I fix this or should I use another method to send mail? FWI, here some more information about OS and contents of registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Messaging Subsystem: OS info: 5.2.3790 VER_PLATFORM_WIN32_NT Service Pack 2 Contents of SOFTWARE\Microsoft\Windows Messaging Subsystem InstallCmd: rundll32 setupapi,InstallHinfSection MSMAIL 132 msmail.inf MAPI: 1 CMCDLLNAME: mapi.dll CMCDLLNAME32: mapi32.dll CMC: 1 MAPIX: 1 MAPIXVER: 1.0.0.1 OLEMessaging: 1 Contents of SOFTWARE\Microsoft\Windows Messaging Subsystem\MSMapiApps inetsw95.exe: choosusr.dll: msab32.dll: nwab32.dll: outstore.dll: Microsoft Outlook CDOEXM.DLL: EMSMDB32.DLL: EMSABP32.DLL: newprof.exe: Microsoft Outlook outlook.exe: wfxmsrvr.exe: Microsoft Outlook msexcimc.exe: exchng32.exe: schdmapi.dll: Microsoft Outlook pilotcfg.exe: Microsoft Outlook mailmig.exe: Microsoft Outlook admin.exe: msspc32.dll: Microsoft Outlook cnfnot32.exe: Microsoft Outlook ilpilot.exe: Microsoft Outlook events.exe: I'm on Delphi 7.0, but that shouldn't matter. Edit, added version information: Fileversion info of C:\WINDOWS\system32\mapi32.dll Fileversion: 6.5.7226.0 FileDescription=Extended MAPI 1.0 for Windows NT CompanyName=Microsoft Corporation InternalName=MAPI32 Comments=Service Pack 1 LegalCopyRight=Copyright (C) 1986-2003 Microsoft Corp. All rights reserved. LegalTradeMarks=Microsoft(R) and Windows(R) are registered trademarks of Microsoft Corporation. OriginalFileName=MAPI32.DLL ProductName=Microsoft Exchange ProductVersion=6.5 Fileversion info of C:\Program Files\Common Files\SYSTEM\MSMAPI\1043\msmapi32.dll Fileversion: 11.0.5601.0 FileDescription=Extended MAPI 1.0 for Windows NT CompanyName=Microsoft Corporation InternalName=MAPI32.DLL LegalCopyRight=Copyright © 1995-2003 Microsoft Corporation. All rights reserved. OriginalFileName=MAPI32.DLL ProductName=MAPI32 ProductVersion=11.0.5601

    Read the article

  • Reference a GNU C (POSIX) DLL built in GCC against Cygwin, from C#/NET

    - by Dale Halliwell
    Here is what I want: I have a huge legacy C/C++ codebase written for POSIX, including some very POSIX specific stuff like pthreads. This can be compiled on Cygwin/GCC and run as an executable under Windows with the Cygwin DLL. What I would like to do is build the codebase itself into a Windows DLL that I can then reference from C# and write a wrapper around it to access some parts of it programatically. I have tried this approach with the very simple "hello world" example at http://www.cygwin.com/cygwin-ug-net/dll.html and it doesn't seem to work. #include <stdio.h> extern "C" __declspec(dllexport) int hello(); int hello() { printf ("Hello World!\n"); return 42; } I believe I should be able to reference a DLL built with the above code in C# using something like: [DllImport("kernel32.dll")] public static extern IntPtr LoadLibrary(string dllToLoad); [DllImport("kernel32.dll")] public static extern IntPtr GetProcAddress(IntPtr hModule, string procedureName); [DllImport("kernel32.dll")] public static extern bool FreeLibrary(IntPtr hModule); [UnmanagedFunctionPointer(CallingConvention.Cdecl)] private delegate int hello(); static void Main(string[] args) { var path = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "helloworld.dll"); IntPtr pDll = LoadLibrary(path); IntPtr pAddressOfFunctionToCall = GetProcAddress(pDll, "hello"); hello hello = (hello)Marshal.GetDelegateForFunctionPointer( pAddressOfFunctionToCall, typeof(hello)); int theResult = hello(); Console.WriteLine(theResult.ToString()); bool result = FreeLibrary(pDll); Console.ReadKey(); } But this approach doesn't seem to work. LoadLibrary returns null. It can find the DLL (helloworld.dll), it is just like it can't load it or find the exported function. I am sure that if I get this basic case working I can reference the rest of my codebase in this way. Any suggestions or pointers, or does anyone know if what I want is even possible? Thanks. Edit: Examined my DLL with Dependency Walker (great tool, thanks) and it seems to export the function correctly. Question: should I be referencing it as the function name Dependency Walker seems to find (_Z5hellov)? Edit2: Just to show you I have tried it, linking directly to the dll at relative or absolute path (i.e. not using LoadLibrary): [DllImport(@"C:\.....\helloworld.dll")] public static extern int hello(); static void Main(string[] args) { int theResult = hello(); Console.WriteLine(theResult.ToString()); Console.ReadKey(); } This fails with: "Unable to load DLL 'C:.....\helloworld.dll': Invalid access to memory location. (Exception from HRESULT: 0x800703E6) *Edit 3: * Oleg has suggested running dumpbin.exe on my dll, this is the output: Dump of file helloworld.dll File Type: DLL Section contains the following exports for helloworld.dll 00000000 characteristics 4BD5037F time date stamp Mon Apr 26 15:07:43 2010 0.00 version 1 ordinal base 1 number of functions 1 number of names ordinal hint RVA name 1 0 000010F0 hello Summary 1000 .bss 1000 .data 1000 .debug_abbrev 1000 .debug_info 1000 .debug_line 1000 .debug_pubnames 1000 .edata 1000 .eh_frame 1000 .idata 1000 .reloc 1000 .text Edit 4 Thanks everyone for the help, I managed to get it working. Oleg's answer gave me the information I needed to find out what I was doing wrong. There are 2 ways to do this. One is to build with the gcc -mno-cygwin compiler flag, which builds the dll without the cygwin dll, basically as if you had built it in MingW. Building it this way got my hello world example working! However, MingW doesn't have all the libraries that cygwin has in the installer, so if your POSIX code has dependencies on these libraries (mine had heaps) you can't do this way. And if your POSIX code didn't have those dependencies, why not just build for Win32 from the beginning. So that's not much help unless you want to spend time setting up MingW properly. The other option is to build with the Cygwin DLL. The Cygwin DLL needs an initialization function init() to be called before it can be used. This is why my code wasn't working before. The code below loads and runs my hello world example. //[DllImport(@"hello.dll", EntryPoint = "#1",SetLastError = true)] //static extern int helloworld(); //don't do this! cygwin needs to be init first [DllImport("kernel32", CharSet = CharSet.Ansi, ExactSpelling = true, SetLastError = true)] static extern IntPtr GetProcAddress(IntPtr hModule, string procName); [DllImport("kernel32", SetLastError = true)] static extern IntPtr LoadLibrary(string lpFileName); public delegate int MyFunction(); static void Main(string[] args) { //load cygwin dll IntPtr pcygwin = LoadLibrary("cygwin1.dll"); IntPtr pcyginit = GetProcAddress(pcygwin, "cygwin_dll_init"); Action init = (Action)Marshal.GetDelegateForFunctionPointer(pcyginit, typeof(Action)); init(); IntPtr phello = LoadLibrary("hello.dll"); IntPtr pfn = GetProcAddress(phello, "helloworld"); MyFunction helloworld = (MyFunction)Marshal.GetDelegateForFunctionPointer(pfn, typeof(MyFunction)); Console.WriteLine(helloworld()); Console.ReadKey(); } Thanks to everyone that answered~~

    Read the article

  • Windows 7 dsound.dll load from dll crash

    - by Jonas Byström
    I'm getting a crash when loading dsound.dll from another DLL in Windows 7. The following code crashes: #include <Windows.h> #include <mmreg.h> #include <dsound.h> #include <assert.h> HRESULT (WINAPI *pDirectSoundEnumerateA)(LPDSENUMCALLBACKA pDSEnumCallback, LPVOID pContext); HMODULE hDsound; BOOL CALLBACK DSEnum(LPGUID a, LPCSTR b, LPCSTR c, LPVOID d) { return TRUE; } void CrashTest() { HRESULT hr; hDsound = LoadLibraryA("dsound.dll"); assert(hDsound); *(void**)&pDirectSoundEnumerateA = (void*)GetProcAddress(hDsound, "DirectSoundEnumerateA"); assert(pDirectSoundEnumerateA); hr = pDirectSoundEnumerateA(DSEnum, NULL); assert(!FAILED(hr)); } BOOL APIENTRY DllMain(HANDLE hModule,DWORD ul_reason_for_call,LPVOID lpReserved) { if (ul_reason_for_call == DLL_PROCESS_ATTACH) { DisableThreadLibraryCalls(hModule); CrashTest(); } } with this error code: Unhandled exception at ... in ...: 0xC0000005: Access violation reading location 0x00000044. (it's always 0x44 for some reason). It works on Windows XP or when loading directly from the .exe (not from a separate DLL). Help!?! :)

    Read the article

  • How to change the language of driver interface for Canon Pixma printers?

    - by Sammy
    Is there a way to change the language of the driver interface for Canon Pixma printers? Which language is used seems to be determined by the language of the OS or the Windows localization settings. I really don't want that, I want to be able to set the language manually to my own liking, either during the driver installation or afterwards. I have found a workaround for Pixma IP2770 where you edit the setup.ini file by replacing the language names and the DLL search paths with <SELECT> under the LANGUAGES section. So instead of... 0000=<SELECT> 0001=Arabic,RES\STRING\IJInstAR.ini,RES\DLL\IJInstAR.dll 0804=Simplified Chinese,RES\STRING\IJInstCN.ini,RES\DLL\IJInstCN.dll 0404=Traditional Chinese,RES\STRING\IJInstTW.ini,RES\DLL\IJInstTW.dll 0005=Czech,RES\STRING\IJInstCZ.ini,RES\DLL\IJInstCZ.dll 0006=Danish,RES\STRING\IJInstDK.ini,RES\DLL\IJInstDK.dll 0007=German,RES\STRING\IJInstDE.ini,RES\DLL\IJInstDE.dll 0008=Greek,RES\STRING\IJInstGR.ini,RES\DLL\IJInstGR.dll 0009=English,RES\STRING\IJInstUS.ini,RES\DLL\IJInstUS.dll 000A=Spanish,RES\STRING\IJInstES.ini,RES\DLL\IJInstES.dll 000B=Finnish,RES\STRING\IJInstFI.ini,RES\DLL\IJInstFI.dll 000C=French,RES\STRING\IJInstFR.ini,RES\DLL\IJInstFR.dll 000E=Hungarian,RES\STRING\IJInstHU.ini,RES\DLL\IJInstHU.dll 0010=Italian,RES\STRING\IJInstIT.ini,RES\DLL\IJInstIT.dll 0011=Japanese,RES\STRING\IJInstJP.ini,RES\DLL\IJInstJP.dll 0012=Korean,RES\STRING\IJInstKR.ini,RES\DLL\IJInstKR.dll 0013=Dutch,RES\STRING\IJInstNL.ini,RES\DLL\IJInstNL.dll 0014=Norwegian,RES\STRING\IJInstNO.ini,RES\DLL\IJInstNO.dll 0015=Polish,RES\STRING\IJInstPL.ini,RES\DLL\IJInstPL.dll 0016=Portuguese,RES\STRING\IJInstPT.ini,RES\DLL\IJInstPT.dll 0019=Russian,RES\STRING\IJInstRU.ini,RES\DLL\IJInstRU.dll 001D=Swedish,RES\STRING\IJInstSE.ini,RES\DLL\IJInstSE.dll 001E=Thai,RES\STRING\IJInstTH.ini,RES\DLL\IJInstTH.dll 001F=Turkish,RES\STRING\IJInstTR.ini,RES\DLL\IJInstTR.dll 0021=Indonesian,RES\STRING\IJInstID.ini,RES\DLL\IJInstID.dll You get.... 0000=<SELECT> 0001=<SELECT> 0804=<SELECT> 0404=<SELECT> 0005=<SELECT> 0006=<SELECT> 0007=<SELECT> 0008=<SELECT> 0009=English,RES\STRING\IJInstUS.ini,RES\DLL\IJInstUS.dll 000A=<SELECT> 000B=<SELECT> 000C=<SELECT> 000E=<SELECT> 0010=<SELECT> 0011=<SELECT> 0012=<SELECT> 0013=<SELECT> 0014=<SELECT> 0015=<SELECT> 0016=<SELECT> 0019=<SELECT> 001D=<SELECT> 001E=<SELECT> 001F=<SELECT> 0021=<SELECT> .... in case English is the preferred language. It's a way to force the installation program to only install the English language support. IP2770 is a model for the Asian market, so if you want to check this out you need to go to the Canon India download page (for instance) to get the driver. Unfortunately this method is not possible with my IP4000. There is no driver even available for it to download for Windows Vista. But is there really no way of changing the language of the UI in any normal way, you know... without having to hack it? Besides, the driver for my printer comes with Windows Vista, so I don't even have to install any drivers. And little do I get the chance to set the language, knowing that the installation never happens. Any ideas?...

    Read the article

  • Program can't start because dll is missing

    - by Kruug
    Any executable that I attempt to run on this laptop pops up an error stating The program can't start because LPK.dll is missing from your computer. Try reinstalling the program to fix this problem. I have tried doing regsvr32 lpk.dll from within system32, but that returns the error The module "lpk.dll" was loaded but the entry-point DLLRegisterServer was not found. Make sure that "lpk.dll" is a valid DLL or OCX file and then try again. I was able to copy the DLL file from a working computer, but I get the same issue. How would I go about registering this DLL? Or, alternatively, which program would I have to reinstall to get the DLL to work again? The system is Windows 7 Professional 64-bit with Service Pack 1. I would really like not to reinstall the OS, but at this point, I'm about ready to.

    Read the article

  • Referencing both an old version and new version of the same DLL (VB.Net)

    - by ckittel
    Consider the following situation: WidgetCompany produced a .NET DLL in 2006 called Widget.dll, version 1.0. I consumed this Widget.dll file throughout my VB.Net application. Over time, WidgetCompany has been updating Widget.dll, I never bothered to keep up, continuing to ship version 1.0 of Widget.dll with my software. It's now 2010, my project is now a VB.Net 3.5 application and WidgetCompany has come out with Widget.dll version 3.0. It looks and functions almost identical to Widget.dll version 1.0, using all the same namespaces and type names from before. However, Widget.dll version 3.0 has many run-time breaking changes since 1.0 and I cannot simply cut over to the new version; however, I don't want to continue developing against the 1.0 version and therefore keep digging myself deeper in the hole. What I want to do is do all new development in my project with Widget.dll version 3.0, whilst keeping Widget.dll version 1.0 around until I find time to convert all of my 1.0 consumption to the newer 3.0 code. Now, for starters, I obviously cannot simply reference both Widget.dll (Ver 1.0) and Widget.dll (Ver 3.0) in Visual Studio. Doing so gives me the following message: "A reference to 'Widget.dll' could not be added. A reference to the component 'Widget' already exists in the project." To work around that, I can simply rename version 3.0 Widget.dll to Widget.3.dll. But this is where I'm stuck. Any attempts to reference types found in "the dll" leads to ambiguity and the compiler obviously doesn't have any clue as to what I really want in this or that case. Is there something I can do that gives a DLL a new "root" Namespace or something? For example, if I could say "Widget.dll has a new root namespace of Legacy" then I could update existing code to reference the types found in Legacy.<RootNamespace> namespace while all new code could simply reference types from the <RootNamespace> namespace. Pipe dream or reality? Are there other solutions to situations this (besides "don't get in this situation in the first place")?

    Read the article

  • Safely Remove Hardware (USB drive) needs End Process for rundll32.exe - Windows XP SP3

    - by Michael Warner
    Image Name PID Modules ========================= ====== ============================================= rundll32.exe 252 ntdll.dll, kernel32.dll, msvcrt.dll, GDI32.dll, USER32.dll, IMAGEHLP.dll, ShimEng.dll, AcGenral.DLL, ADVAPI32.dll, RPCRT4.dll, Secur32.dll, WINMM.dll, ole32.dll, OLEAUT32.dll, MSACM32.dll, VERSION.dll, SHELL32.dll, SHLWAPI.dll, USERENV.dll, UxTheme.dll, guard32.dll, fltlib.dll, comctl32.dll, comctl32.dll, NvMcTray.dll, SETUPAPI.dll, IMM32.dll, nvapi.dll I have to end the rundll32.exe process to safely remove my USB drive. Given the modules rundll32.exe is running, do you know which running module(s) would prevent the USB drive from being safely removed, and if so is there a more permanent straightforward solution such as changing an automatic service (the list from services.msc) into a disabled/manual service or maybe something else you can think of?

    Read the article

  • Memory concerns while plotting escape from DLL Hell in Delphi

    - by Peter Turner
    I work on a program with about 50 DLLs that are loaded from one executable, it's an old organically grown program where the only rationale for creating a new DLL is that one previously didn't exist to fill a given need. (and namespaces didn't exist in Delphi so it never crossed our mind to make dll1.main.pas, dll2.main.pas or something even more unique) What we want to do is consolidate all these DLLs into one executable, since none of them are used out of the program, there shouldn't be much of a problem. The concern my boss has is that if we did this, the memory overhead for terminal server clients would go through the roof. So, I've stepped through enough initialization code to know that lots of stuff is done every time a DLL is loaded in to memory, but say I've got a project with about 4000 files, and 50 dlls, 10 of which are probably utilized by any one user in any one session of the program. The 50 dlls are about 2/3rds form files, if not more, but beyond that there's not a lot of other resources being loaded (only a few embedded pictures, icons, cursors, etc..). If I loaded all these files in to memory, how much memory is used per unit? how much is used per class? How do I keep the overhead down? and what is the biggest project one can reasonably expect to build with Delphi? This tidbit won't help answering, but I think it might clarify what my boss is worried about, we currently start our program at about 18megs, normal working conditions are usually less than 40 megs, he thinks it could climb as high as 120 megs.

    Read the article

  • organization of DLL linked functions

    - by m25
    So this is a code organization question. I got my basic code working but when I expand it will be terrible. I have a DLL that I don't have a .lib for. Therefore I have to use the whole loadLibrary()/getprocaddress() combo. it works great. But this DLL that i'm referencing at 100+ functions. my current process is (1) typedef a type for the function. or typedef short(_stdcall *type1)(void); then (2) assign a function name that I want to use such as type1 function_1, then (3) I do the whole LoadLibrary, then do something like function_1 = (type1)GetProcAddress(hinstLib, "_mangled_funcName@5"); normally I would like to do all of my function definitions in a header file but because I have to do use the load library function, its not that easy. the code will be a mess. Right now i'm doing (1) and (2) in a header file and was considering making a function in another .cpp file to do the load library and dump all of the (3)'s in there. I considered using a namespace for the functions so I can use them in the main function and not have to pass over to the other function. Any other tips on how to organize this code to where it is readable and organized? My goals are to be able to use function_1 as a regular function in the main code. if I have to a ref::function_1 that would be okay but I would prefer to avoid it. this code for all practical purposes is just plane C at the moment. thanks in advance for any advice!

    Read the article

  • Using Enums that are in an external dll C#

    - by user1443233
    I have a project I am working that will involve creating one DLL that will be used across multiple other sites. Inside this DLL we need to reference about 10 Enums. The values of these Enums however will be different for each site the DLL is used on. For example: MyBase.dll may have a class MyClass with an attribute of type MyEnum. MyBase.dll is then referenced in MySite. MyStie will also reference MyEnums.dll which will contain the values for the MyEnum type. Is there any way to accomplish this? While building MyBase.dll, I know what enums will exist in side of MyEnums.dll. The problem is I cannot build MyBase.dll without specifically referenceing the MyEnums.dll, which is not created until the MyBase.dll is used in a specific project. I hope that makes sense and hope I can find an answer here. Thanks.

    Read the article

  • Where to download replacement "Explorerframe.DLL" Files for x64 Windows 7 Pro?

    - by Ben Franchuk
    After posting this question, I did some research to reveal what the problem likely was, and found what I need to fix. Following this is the original post, then my updated question. A few months ago I ended up requiring to change my computer's SID to fix a problem it had been having- Instead of fixing the problem, though, it screwed up my at-the-time current install of windows, to the point of me needing to do a fresh install. As I am in possession of an OEM copy of Windows 7 Pro 64 Bit, I successfully reinstalled over the dead copy with that (all the files that were on the computer previous to this windows install were put in a Windows.old folder). Everything installed and worked absolutely fine, except for one thing. The problem I am experiencing is that, in some Windows Explorer windows, the explorer pane doesn't show. Instead, it simply shows a white area where the pane would show. This makes some software not usable, I recently realized; Software such as Cubase, which use just the explorer pane to select file save locations, cannot save at all as the pane itself is... not operational. Below is a screenshot of this problem as it occurs in cubase; ...and again as it shows in UTorrent in the save location selector window. The highlighted area is where the sidebar would NORMALLY be. Pardon my scribbling over some of the things in the window- I would personally rather the internet did not get a glimpse of my files. I have yet to find a common reason why the pane works in some applications when they pull explorer, and others not. I have yet to see it go away, and the software affected by it has been affected since I reinstalled my copy of windows. Initially, I was able to live with it as I can type out save locations in the file name bar to navigate, but with software like Cubase, I do not have this option. Reinstalling windows again is NOT an option. Here's the updated question. After posting this question originally, I did some research on the problem in question, and it turns out that this is extremely easily fixable via replacing the file "ExplorerFrame.DLL" which is located in the System32 and SystemWOW64 Folders, in the windows folder, on the C:\ drive. As I quite frequently customize my computer, this is a normal thing for me to do and I know exactly how to safely and properly replace this file. The only problem is that I cannot for the life of me find a download of this file that actually works with my computer. I tried a couple from some different sites but they all caused explorer to not restart (I was given an error when starting the application from Task Manager) and was forced to revert to the broken .DLL files. Since there are 2 separate "ExplorerFrame.DLL" files; one for 64 bit and the other for 32 bit, I am assuming that I will need to download 2 separate versions to replace the corrupted ones. Where can I acquire these files? I am currently running Windows 7 Professional x64 Bit.

    Read the article

  • Change imported Dll name ?

    - by Rajakumar
    hi to all , In a Portable-Executable ,we can change the imported dll name ,by editing PE file , here , i had changed in one imported dll name of application exe,that time it changed normally ....e.g advapi32.dll to ^dvapi32.dll ,so here system32 or any other PATH location doesnt have ^dvapi32.dll ..this time simply i changed the real advapi32.dll into ^dvapi32.dll and put in the application directory ,this time its work fine ....but when i am trying with ntdll & gdi32.dll ,it doesnt supported ,i cant resolve the problem ,pls help me towards the problem ..thanks.

    Read the article

  • Change Name of Outputted DLL

    - by Changeling
    If my project name is ABC and the DLL currently outputs as ABC.DLL, how can I make my DLL be outputted as say CBA.DLL and so that when the .LIB is compiled linked against, it is not looking for ABC.DLL, but CBA.DLL. I tried changing the name under Linker General Output File but when I linked to the .lib in my other application, it was still looking for ABC.DLL and CBA.DLL.

    Read the article

  • Exposing API through a DLL

    - by MageNewbie
    I have a C++ application; I would like to expose an API from that application allowing me to control the C++ app from a VB6 app. I want to expose the API through a DLL file. Is this a viable option (is it possible) ? I haven’t been able to find any literature on using DLLs in this way. In fact from what I have read it seems like this is not possible because DLLs create their own new instance for every application they are linked in. If you have meet theses requirements in an application you built or if your knowledgeable on the subject, please give me a push in the right direction.

    Read the article

  • How to export a C++ class library to C# using a dll?

    - by SICGames2013
    In my previous revision game engine I deported major functions for the game editor for C#. Now, I'm beginning to revise the game engine with a static library. There's a already dynamic library created in C++ to use DLLEXPORT for C#. Just now I want to test out the newer functions and created a DLL file from C++. Because the DLL contains classes I was wondering how would I be able to use DLL Export. Would I do this: [DLLEXPORT("GameEngine.dll", EntryPoint="SomeClass", Conventional=_stdcall)] static extern void functionFromClass(); I have a feeling it's probably DLLImport and not DLLExport. I was wondering how would I go about this? Another way I was thinking was because I already have the DLL in C++ prepared already to go the C# Class Library. I could just keep the new engine as a lib, and link the lib with the old DLL C++ file. Wouldn't the EntryPoint be able to point to the class the function is in?

    Read the article

  • How to write own DLL in Visual Studio, C language (not C++)

    - by oneee
    Dear all, I'm trying to create my own DLL... I used wizzard in VS2008 to create template for DLL. This works fine and the dll builds successfully (Test.dll is created). BUT, when I rename the file from Test.cpp to Test.c (which I guess causes compilation in C-mode), solution rebuilds also successfully, but no .dll is created. The list of all created files follows: mt.dep BuildLog.htm vc90.idb Test.dll.embed.manifest Test.dll.intermediate.manifest Test.obj MySecondCFile.obj vc90.pdb Test.dll.embed.manifest.res For my purposes it's essential that the dll be in C not C++, while I already have a lot of code written in C, which does not compile as C++. Do you know, why .dll is not created? What should I do?

    Read the article

  • Sys. engineer has decided to dynamically transform all XSLs into DLLs on website build process. DLL

    - by John Sullivan
    Hello, OS: Win XP. Here is my situation. I have a browser based application. It is "wrapped" in a Visual Basic application. Our "Systems Engineer Senior" has decided to spawn DLL files from all of our XSL pages (many of which have duplicate names) upon building a new instance of the website and have the active server pages (ASPX) use the DLL instead. This has created a "known issue" in which ~200 DLL naming conflicts occur and, thus, half of our application is broken. I think a solution to this problem is that, thankfully, we're generating the names of the DLLs and linking them up with our application dynamically. Therefore we can do something kludgy like generate a hash and append it to the end of the DLL file name when we build our website, then always reference the DLL that had some kind of random string / hash appended to its name. Aside from outright renaming the DLLs, is there another way to have multiple DLLs with the same name register for one application? I think the answer is "No, only between different applications using a special technique." Please confirm. Another question I have on my mind is whether this whole idea is a good practice -- converting our XSL pages (which we use in mass -- every time a response from our web app occurs) into DLL functions that call a "function" to do what the XSL page did via an active server page (ASPX), when we were before just sending an XML response to an XSL page via aspx.

    Read the article

  • mac's .dll equivalent

    - by kalaracey
    Hello all-- so, a DLL is similar to a folder, but it allows for multiple programs/executables to access it at once, thus conserving memory (I think). What is Mac's equivalent of a DLL? I was looking through the Google Chrome folders inside ~/Library/Application Support, and instead of the regular Windows Default.dll there was just a folder, "Default" as a regular file, with contents, I assume, would regularly be inside the DLL. Does the Mac equivalent provide the same function?

    Read the article

  • Mixing Silverlight-Specific System.Xml.Linq dll with Non-Silverlight System.Xml.Linq dll

    - by programatique
    I have a Logic layer that references Silverlight's System.Xml.Linq dll and a GUI that is in WPF (hence using the non-Silverlight System.Xml.Linq dll). When I attempt to pass an XElement from GUI project to a method in the Logic project, I am getting (basically) "XElement is not of type XElement" errors. To complicate matter, I am unable to edit the Logic layer project. The Non-Silverlight DLL is at: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5\System.Xml.Linq.dll THe Silverlight DLL is at: C:\Program Files (x86)\Microsoft SDKs\Silverlight\v3.0\Libraries\Client\System.Xml.Linq.dll I am new to C# but I'm fairly sure my issue is that I am referencing different DLL's to access the System.Xml.Linq namespace. I attempted to replace my non-Silverlight System.Xml.Linq.dll with the Silverlight's System.Xml.Linq.dll, but received assembly errors. Is there any way to resolve this short of scrapping my WPF GUI project and creating a Silverlight project?

    Read the article

  • Make DLL dependent to other DLLs (Visual Studio IDE)

    - by Artefacto
    I'm having an inconsistency when compiling a DLL (let's call it x.dll) by calling cl.exe obj1.obj obj2.obj ... lib1.lib lib2.lib ... /link /out:x.dll /dll /debug and When using the IDE (which calls link directly, I believe). Let's say lib1.lib is an import library for lib1.dll. Opening the DLL generated by calling cl.exe in the depency walker shows it depends on lib1.dll. However, when using the IDE, the generated program is smaller and does not depend on lib1.dll. This IDE-generated image makes the program that uses x.dll crash sometimes. The question is: how do I get the correct behaviour from the IDE?

    Read the article

  • including library and dll into c++ project

    - by user1612986
    i have a third party library (say tp.lib) and the third party dll (say tp.dll) which i need to use in my C++ project (my project is a dll project, lets call it my.dll). i have include the library with the #pragma comment(lib, "libraryname") in the header file and also included the path of the library file in the configurationproperties-linker-additional library directories in my c++ visual studio project. the code compiles okay. but fails to execute. when i use depends to check if i am missing someting i observe that the tp.dll is missing from my.dll. the tp.dll resides in the same library folder where the tp.lib resides. my quesiton is what should i do so that tp.dll get included to my.dll thanks in advance

    Read the article

  • Fatal error when using FILE* in Windows from DLL

    - by AlannY
    Hi there. Recently, I found a problem with Visual C++ 2008 compiler, but using minor hack avoid it. Currently, I cannot use the same hack, but problem exists as in 2008 as in 2010 (Express). So, I've prepared for you 2 simple C file: one for DLL, one for program: DLL (file-dll.c): #include <stdio.h> __declspec(dllexport) void print_to_stream (FILE *stream) { fprintf (stream, "OK!\n"); } And for program, which links this DLL via file-dll.lib: Program: #include <stdio.h> __declspec(dllimport) void print_to_stream (FILE *stream); int main (void) { print_to_stream (stdout); return 0; } To compile and link DLL: cl /LD file-dll.c To compile and link program: cl file-test.c file-dll.lib When invoking file-test.exe, I got the fatal error (similar to segmentation fault in UNIX). As I said early, I had that the same problem before: about transferring FILE* pointer to DLL. I thought, that it may be because of compiler mismatch, but now I'm using one compiler for everything and it's not the problem. ;-( What can I do now? UPD: I've found solution: cl /LD /MD file-dll.c cl /MD file-test.c file-dll.lib The key is to link to dynamic library, but (I did not know it) by default it links staticaly and (hencefore) error occurs (I see why). P.S. Thanks for patience.

    Read the article

  • A problem regarding dll inheritance

    - by Adam
    Hello all I have created a dll that will be used by multiple applications, and have created an installer package that installs it to the program files, as well as adds it to the Global Assembly Cache. The dll itself uses log4net, and requires a xml file for the logging definitions. Therefore when the installer is run, the following files get copied to the install directory within program files: The main dll that I developed - The Log4Net.dll - the Log4Net.xml file I am now experiencing a problem. I have created a test console application for experimentation. I have added my dll as a reference, and set the 'local copy' flag to false. When I compile the test console exe however, I noticed that it has copied the log4net.dll and log4net.xml files to the bin directory. And when running the test console, it appears that it will only work if the log4net.dll is in the same directory as the exe. This is dispite the fact that the test console application does not use log4net, only the dll that was added as a reference does. Is there some way to have it so that the log4net.dll & xml files used will be the ones that were installed to the program files, rather than any application needed to copy over local copies? The applications that will be using my dll will not be using log4net, only the dll that they are referencing uses it. Many thanks

    Read the article

  • Sharing a global/static variable between a process and DLL

    - by minjang
    I'd like to share a static/global variable only between a process and a dll that is invoked by the process. The exe and dll are in the same memory address space. I don't want the variable to be shared among other processes. Elaboration of the problem: Say that there is a static/global variable x in a.cpp. Both the exe foo.exe and the dll bar.dll have a.cpp, so the variable x is in both images. Now, foo.exe dynamically loads (or statically) bar.dll. Then, the problem is whether the variable x is shared by the exe and dll, or not. In Windows, these two guys never share the x: the exe and dll will have a separate copy of x. However, in Linux, the exe and dll do share the variable x. Unfortunately, I want the behavior of Linux. I first considered using pragma data_seg on Windows. However, even if I correctly setup the shared data segment, foo.exe and bar.dll never shares the x. Recall that bar.dll is loaded into the address space of foo.exe. However, if I run another instance of foo.exe, then x is shared. But, I don't want x to be shared by different processes. So, using data_seg was failed. I may it use a memory-mapped file by making an unique name between exe and dll, which I'm trying now. Two questions: Why the behavior of Linux and Windows is different? Can anyone explain more about this? What would be most easiest way to solve this problem on Windows?

    Read the article

  • Specifying a DLL reference

    - by Jesse
    I'm having trouble setting the path to a DLL that is not in the same directory as the executable. I have a reference to dllA.dll. At present, everything is just copied into the same directory and all is well; however, I need to move the executable to another directory while still referencing the DLL in the original directory. So, it's setup like: C:\Original\Dir program.exe dllA.dll dllB.dll dllC.dll But I need to have it setup like: C:\New\Dir program.exe dllB.dll dllC.dl Such that it is still able to reference dllA.dll in C:\Original\dir I tried the following, but to no avail: Set the "Copy Local" value to false for dllA.dll because I want it to be referenced in its original location. Under "Tools Options Projects and Solutions VC++ Directories" I have added the path to "C:\Original\Dir" Added "C:\Original\Dir" to both the PATH and LIB environment variables At runtime, it informs me that it cannot locate dllA.dll Maybe the above steps I took only matter at compile time? I was able to find this http://stackoverflow.com/questions/1382704/c-specifying-a-location-for-dll-reference But I was thinking that my above method should've worked. Any ideas?

    Read the article

< Previous Page | 1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >