So, I am writing an application in C#, and I have some old C code that I want
to use. Now, i tried to convert it to a DLL, and while I easily got it
working, it didn't work like it was supposed to. The problem, is that there
are global structures, with values that change as you write to certain
functions.

To be less vague, the C code is an old FM Chip emulator, so most of the
structures' values have to be stored in memory, as I make calls to change
them. Then I render the sound wave, based on the structure's values, with
another function call. The DLL idea didn't work, because it's making
seperate calls to the functions, and all data used is reset each call.

So, with DLLs out of the question, I'm asking for people's opinions on what
would be the best way to use the code in C#. I was considering converting it
to managed C, and using multiple file assemblies, but I'm unsure if it would
keep the data in memory between calls.

Any ideas are appreciated.

Thanks

I was actually thinking of writing the code into an executable and then
calling the functions from there, but again, I have to make multiple writes
to the emulated "ports" and then get a final write of data. I can only put
command line arguments in. I can't really think of a way, perhaps writing it
as a COM?

"ccurrens" wrote:

> So, I am writing an application in C#, and I have some old C code that I want
> to use. Now, i tried to convert it to a DLL, and while I easily got it
> working, it didn't work like it was supposed to. The problem, is that there
> are global structures, with values that change as you write to certain
> functions.
>
> To be less vague, the C code is an old FM Chip emulator, so most of the
> structures' values have to be stored in memory, as I make calls to change
> them. Then I render the sound wave, based on the structure's values, with
> another function call. The DLL idea didn't work, because it's making
> seperate calls to the functions, and all data used is reset each call.
>
> So, with DLLs out of the question, I'm asking for people's opinions on what
> would be the best way to use the code in C#. I was considering converting it
> to managed C, and using multiple file assemblies, but I'm unsure if it would
> keep the data in memory between calls.
>
> Any ideas are appreciated.
>
> Thanks
>

ccurrens <(E-Mail Removed)> wrote:
>The DLL idea didn't work, because it's making
>seperate calls to the functions, and all data used is reset each call.

?? DLLs can have data which persists between calls. I don't know what
you observed, but you shouldn't have, and the idea was fine.

--
Lucian

Really.

Well, my observation showed it didn't work. Is there any particular way to
make sure of that? The data structs were global, and I was defining and
calling the functions via [DLLImport].

Is there perhaps another way to do it with a DLL that I'm not using, or am I
just going to have to find the problem?

"Lucian Wischik" wrote:

> ccurrens <(E-Mail Removed)> wrote:
> >The DLL idea didn't work, because it's making
> >seperate calls to the functions, and all data used is reset each call.
>
> ?? DLLs can have data which persists between calls. I don't know what
> you observed, but you shouldn't have, and the idea was fine.
>
> --
> Lucian
>

Well, I discovered that the DLL shouldn't be unloaded by my app. Mine was
being unloaded, which is why the data did not persist. I know how to do
this, and I wasn't.

Now, would I still call the library the same way in C# (using [dllimport])?

"Lucian Wischik" wrote:

> ccurrens <(E-Mail Removed)> wrote:
> >The DLL idea didn't work, because it's making
> >seperate calls to the functions, and all data used is reset each call.
>
> ?? DLLs can have data which persists between calls. I don't know what
> you observed, but you shouldn't have, and the idea was fine.
>
> --
> Lucian
>

Why not store the data in datasets or datatables between calls? This seems
like a good scenario for a .Net app.

"ccurrens" <(E-Mail Removed)> wrote in message
news:079A0D4D-790D-4894-9850-(E-Mail Removed)...
> So, I am writing an application in C#, and I have some old C code that I
> want
> to use. Now, i tried to convert it to a DLL, and while I easily got it
> working, it didn't work like it was supposed to. The problem, is that
> there
> are global structures, with values that change as you write to certain
> functions.
>
> To be less vague, the C code is an old FM Chip emulator, so most of the
> structures' values have to be stored in memory, as I make calls to change
> them. Then I render the sound wave, based on the structure's values, with
> another function call. The DLL idea didn't work, because it's making
> seperate calls to the functions, and all data used is reset each call.
>
> So, with DLLs out of the question, I'm asking for people's opinions on
> what
> would be the best way to use the code in C#. I was considering converting
> it
> to managed C, and using multiple file assemblies, but I'm unsure if it
> would
> keep the data in memory between calls.
>
> Any ideas are appreciated.
>
> Thanks
>

"ccurrens" <(E-Mail Removed)> wrote in message
news:F5E4FFCD-F5CF-45CC-ADC3-(E-Mail Removed)...
> Well, I discovered that the DLL shouldn't be unloaded by my app. Mine was
> being unloaded, which is why the data did not persist. I know how to do
> this, and I wasn't.
>
> Now, would I still call the library the same way in C# (using
> [dllimport])?

You can use LoadLibrary to lock the DLL in memory, and then call into it
using DllImport.


>
> "Lucian Wischik" wrote:
>
>> ccurrens <(E-Mail Removed)> wrote:
>> >The DLL idea didn't work, because it's making
>> >seperate calls to the functions, and all data used is reset each call.
>>
>> ?? DLLs can have data which persists between calls. I don't know what
>> you observed, but you shouldn't have, and the idea was fine.
>>
>> --
>> Lucian
>>

ccurrens <(E-Mail Removed)> wrote:
>Well, I discovered that the DLL shouldn't be unloaded by my app. Mine was
>being unloaded, which is why the data did not persist. I know how to do
>this, and I wasn't.

Oh. I always thought that in C#, once a DLL is loaded by a
[dllimport], it remains loaded until the application terminates. Is
this incorrect? When does unloading happen?

--
Lucian

"Lucian Wischik" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> ccurrens <(E-Mail Removed)> wrote:
>>Well, I discovered that the DLL shouldn't be unloaded by my app. Mine was
>>being unloaded, which is why the data did not persist. I know how to do
>>this, and I wasn't.
>
> Oh. I always thought that in C#, once a DLL is loaded by a
> [dllimport], it remains loaded until the application terminates. Is
> this incorrect? When does unloading happen?
>

You are quite right in your thinking, you have to explicitly unload a Library
(FreeLibrary(hModule)), the CLR doesn't care about loaded DLL's.

Willy.