DLLImport Scilab'a

Witam

Chodzi mi o import funkcji z DLL WINAPI. Jak poradzić sobie z typami danych typu char*, int* przykładowo
BOOL StartScilab(char *SCIpath, char *ScilabStartup, int *Stacksize);

Ja wywołałem tą funkcję tak (bez parametrów):

[DllImport("C:\\Program Files\\scilab-5.2.0\\bin\\call_scilab.dll")]
        public static extern int StartScilab(char* SCIPATH, char* SCIlabStartUp, int* RozmiarStosu);

        private void button1_Click(object sender, EventArgs e)
        {
            if (StartScilab(null,null,null) == 0)
            {
                MessageBox.Show("Nie załadowano");
            }
            else
            {
                MessageBox.Show("Załadowano Scilaba");
            }
        }

Oczywiście zaimportowałem InteropServices oraz klasa została zdefiniowana jako kod niebezpieczny
public unsafe partial class Form1 : Form

Ponadto atrybut DLLImport posiada inne parametry. Jak ich używać. Jak dokonywać konwersji parametrów funkcji Winapi na typy .Net?

Nie rozumiem pytania... Jeśli chodzi o Int* to nie są 'parametry WinApi' tylko zwykły wskaźnik do inta, konwersja jest dość prosta (operatory & i *). Patrz chociażby tutaj - http://www.c-sharpcorner.com/UploadFile/rajeshvs/PointersInCSharp11112005051624AM/PointersInCSharp.aspx

Zgadza się. Tak deklarowało się tablice znaków w C. W C# tablice są zupełnie czymś innym.
Nie chciałem używać kodu niezabezpieczonego. Użyłem System.IntPtr - wskaźnik do jakiegokolwiek typu zmiennej.
Zrobiłem to tak:

[DllImport("C:\\Program Files\\scilab-5.2.0\\bin\\call_scilab.dll")]
        public static extern int StartScilab(System.IntPtr SCIPATH, System.IntPtr SCIlabStartUp, System.IntPtr RozmiarStosu);
        
        [DllImport("C:\\Program Files\\scilab-5.2.0\\bin\\call_scilab.dll")]
        public static extern int TerminateScilab(System.IntPtr ScilabQuit);

        [DllImport("C:\\Program Files\\scilab-5.2.0\\bin\\call_scilab.dll")]
        public static extern int SendScilabJob(System.IntPtr job);

        private void button1_Click(object sender, EventArgs e)
        {
            if (StartScilab(System.IntPtr.Zero, System.IntPtr.Zero, System.IntPtr.Zero) == 0)
            {
                MessageBox.Show("Nie załadowano");
            }
            else
            {
                MessageBox.Show("Załadowano Scilaba");
            }
        }

Dokopałem się do klasy Marshal. Posiada ona m.in. jakieś metody statyczne, które mogłyby posłużyć do konwersji typ .NET - System.IntPtr
Czy dobrze myślę? Czy ktoś już to przerabiał?

Jak to w zyciu bywa w tej chwili wiekszosc naglowkow jest tlumaczona

http://forge.scilab.org/index.php/p/scilab-xll/source/tree/master/Scilab_XLL/src/Addin/Scilab_cs_wrapper.cs

aby zrozumiec trzeba troche wskaznikami sie pobawic a potem c#

Mellon napisał(a)

Nie chciałem używać kodu niezabezpieczonego.

Całe winapi jest „niezabezpieczone” w rozumieniu .Net, więc czym się tu przejmować?

Azarien napisał(a)

Mellon napisał(a)

Nie chciałem używać kodu niezabezpieczonego.

Całe winapi jest „niezabezpieczone” w rozumieniu .Net, więc czym się tu przejmować?

Zgadza się. To zupełnie nowa "technologia", w której stosowanie bezpośrednio wskaźników niby jest niezalecane.

reichel napisał(a)

Jak to w zyciu bywa w tej chwili wiekszosc naglowkow jest tlumaczona

http://forge.scilab.org/index.php/p/scilab-xll/source/tree/master/Scilab_XLL/src/Addin/Scilab_cs_wrapper.cs

aby zrozumiec trzeba troche wskaznikami sie pobawic a potem c#

Dzięki za link http://forge.scilab.org
Prześledzę ten projekt. Wskaźniki nie były takie straszne (pamiętam je z pacala i C++), ale podobno ich stosowanie w C# nie jest zalecane "Język C# 2008 i platforma .NET 3.5" Andrew Troelsen.

Wskaźników? W ogóle odwołań do kodu natywnego, jedyne poprawne politycznie biblioteki to insze assembly.

deus. napisał(a)

Wskaźników? W ogóle odwołań do kodu natywnego, jedyne poprawne politycznie biblioteki to insze assembly.

A co zrobić jak istnieje bardzo dobry projekt natywny tu np. środowisko matematyczne scilab. Pisało go sporo ludzi przez klika lat. I jak nie wykorzystać istniejący kod :-)
Napisanie samemu ok 200 MB kodu to nie jest zajęcie na jedną noc.

Czy ktoś zna wszystkie parametry DLLImport? Pierwszym parametrem jest nazwa biblioteki dll winapi. Jeśli nie podano ścieżki to gdzie będzie ona szukana? Tam, gdzie kod aplikacji?

Mellon napisał(a)

To zupełnie nowa "technologia", w której stosowanie bezpośrednio wskaźników niby jest niezalecane.

W jakim sensie nowa?

Mellon napisał(a)

Czy ktoś zna wszystkie parametry DLLImport? Pierwszym parametrem jest nazwa biblioteki dll winapi. Jeśli nie podano ścieżki to gdzie będzie ona szukana? Tam, gdzie kod aplikacji?

Standardowo jak kazda biblioteka -> katalog aplikacji, pozniej katalogi z %PATH%, dodatkowo w .NET katalogi podane jako katalogi PrivateBinPath i ProbeForAssemblies z aktualnej AppDomain. Lece z pamieci, moze byc niedokladnie.

Co do tematu - wiekszosc standardowych typow jest tlumaczona w locie, char* to string, int* to out int albo zwykly IntPtr. Klasa Marshal pozwala na kopiowanie miedzy zarzadzalnymi i niezarzadzalnymi typami (np. tablice, stringi tez). Oprocz tego moze zarezerwowac pamiec i ja zwolnic.

Dzięki johny_bravo. :-) Bardzo konstruktywna odpowiedź.

somekind napisał(a)

Mellon napisał(a)

To zupełnie nowa "technologia", w której stosowanie bezpośrednio wskaźników niby jest niezalecane.

W jakim sensie nowa?

Na to pytanie to można by napisać książkę o .Net i WinApi. :-/
Chociażby import klas z pakietów zupełnie inaczej wygląda niż w "dawnych" czasach. O wspólnej specyfikacji typów nie wspomnę, obsłudze zdarzeń, wprowadzeniu interfejsów. Najfajniejsze jest to, że z właściwości .NET korzystają wszystkie języki programowania zaimplementowane na tą platformę. Zatem wielojęzyczność nie sprawia wielkiego problemu

Mellon napisał(a)

O wspólnej specyfikacji typów nie wspomnę

‌ Co to jest?

obsłudze zdarzeń, wprowadzeniu interfejsów.

‌ O przepraszam, to C# ma interfejsy (oraz właściwości) żywcem wzięte z Delphi, nie odwrotnie.
Zresztą twórcą C#, Delphi a nawet Turbo Pascala jest ten sam człowiek, Anders Hejlsberg. I to widać.

Najfajniejsze jest to, że z właściwości .NET korzystają wszystkie języki programowania zaimplementowane na tą platformę. Zatem wielojęzyczność nie sprawia wielkiego problemu

‌ Najmniej fajne jest, że .NET niejako wymusza na języku implementację ogromnej większości tego co .Net udostępnia, zrównując różnice między językami głównie do kwestii kosmetycznych.
Taki VB.Net jest tylko składnią zbliżony do dawnego VB, jest to praktycznie C# ze składnią basicową.
Z mniej znanych, język Oxygene to C# ze składnią pascalową. Nemerle to "C# udziwniony". Nie da się pod .Net zrobić języka istotnie różnego od C#, bo będzie kulawy i w porównaniu z resztą niepełnosprawny.
Najbardziej odstaje C++/CLI, w którym można pisać trojako: ceidalnie, ceplusplusowo i ceszarpowato.
‌ Framework jest jaki jest, i te wszystkie klasy, struktury, interfejsy, tablice, property, generyki, i co tam jeszcze zawsze muszą być. Tylko że nagle robi się nam z tego drugi C#...

Azarien napisał(a)

Mellon napisał(a)

O wspólnej specyfikacji typów nie wspomnę

‌ Co to jest?

Common Type System.

Azarien napisał(a)

Nie da się pod .Net zrobić języka istotnie różnego od C#, bo będzie kulawy i w porównaniu z resztą niepełnosprawny.

Sugerujesz, że F# jest podobny do C#? Chyba jest na tyle udany, że został włączony do Visual Studio 2010.

Mellon napisał(a)

Na to pytanie to można by napisać książkę o .Net i WinApi. :-/

Się nie zrozumieliśmy.
Pytałem tylko, czemu określasz ośmioletnią technologię epitetem "nowa"?

Azarien napisał(a)

‌ Najmniej fajne jest, że .NET niejako wymusza na języku implementację ogromnej większości tego co .Net udostępnia, zrównując różnice między językami głównie do kwestii kosmetycznych.

Czego przykładem są np. argumenty domyślne funkcji. Są w VB.NET, a w C# [do 3.5] podobno nie... Ale skoro CLR implementuje takie coś, to i na siłę da się do C# wstawić (interop, refleksje, atrybuty Optional, DefaultParameterValue).

deus. napisał(a)

Sugerujesz, że F# jest podobny do C#?

No to jest właśnie to, do zupełnie niepodobnego ocamla musiano dodać mnóstwo .netowych "ficzersów".

Kunai napisał(a)

Czego przykładem są np. argumenty domyślne funkcji. Są w VB.NET, a w C# [do 3.5] podobno nie...

Są jeszcze drobiazgi jak to, że VB pozwala na modyfikację bieżącego elementu w pętli typu for each, a C# (chyba nawet w VS2010) - nie.

Ze względu, że i tak każdy język kompilowany jest do CIL to każdy język .NET będzie mógł posiadać podobne cechy do innych na tą platformę. Jednak F# jest językiem funkcyjnym a C# zdecydowanie nie. Być może trochę należałoby dopracować niektóre kompilatory.

Mellon napisał(a)

Jednak F# jest językiem funkcyjnym a C# zdecydowanie nie.

Hm, C# ma lambdy, jest LINQ, są extension methods z bibliotek LINQ dodające funkcje wyższego rzędu... C# jest wieloparadygmatowy, od biedy i programowanie funkcyjne wspiera, w nie aż tak mniejszym stopniu niż np. Scala. W sumie ogólnie C# idzie lekko w kierunku Scali np. patrząc po polimorfizmie i typach generycznych w C# 4.0. Swoją drogą śmieszna sprawa, wychodzi na to, że mniej/więcej w tym samym czasie Scala i C# zyskają opcjonalne i nazwane argumenty funkcji.

To fakt. Każdy język wspomaga kilka paradygmatów programowania. Dzięki Linq, wyrażeń lambda czy późne wiązanie C# to bardzo elastyczny język. Jednak realizacja w nim pakietu typu Matlab nadal byłaby trudna.

reichel napisał(a)

Jak to w zyciu bywa w tej chwili wiekszosc naglowkow jest tlumaczona

http://forge.scilab.org/index.php/p/scilab-xll/source/tree/master/Scilab_XLL/src/Addin/Scilab_cs_wrapper.cs

aby zrozumiec trzeba troche wskaznikami sie pobawic a potem c#

Mam małe pytanko
w pliku Scilab_cs_wrapper.cs mamy deklarację stałych łańcuchowych z nazwami bibliotek DLL

        private const string CALL_SCILAB_DLL = "call_scilab.dll";
        private const string API_SCILAB_DLL = "api_scilab.dll";
        private const string GRAPHICS_DLL = "graphics.dll";
        private const string OUTPUT_STREAM_DLL = "scioutput_stream.dll";

Próbowałem je znaleźć. Pierwsze trzy znajdują się w katalogu głównym aplikacji\bin
np. <url>C:\Program Files\scilab-5.2.0\bin</url>
Znajduje się tam wiele bibliotek DLL i LIB. Jednak tej ostatniej nie ma.
Czy kolega wie jak ją znaleźć? Za to jest output_stream.dll Czy to ta sama biblioteka DLL tylko pod inną nazwą?

Z szukanej biblioteki użyta jest funkcja

[DllImport(OUTPUT_STREAM_DLL, CharSet = CharSet.Ansi)]
        public unsafe static extern int GetLastErrorCode();

Podobny problem istnieje dla wersji 5.2.1 a nie tylko 5.2.0

Proszę o wypowiedź kolegę z FTiMS reichel. Czy kolega stosował SCILAB w aplikacjach C#?

 [DllImport(CALL_SCILAB_DLL, CharSet = CharSet.Ansi)]
        public static extern int SendScilabJob([In]String job);

Jaki ma wpływ modyfikator [In] parametru metody?
Co się stanie, gdy metoda zostanie zadeklarowana bez niego?

msdn napisał(a)

Indicates that data should be marshaled from the caller to the callee, but not back to the caller.
...
The InAttribute is optional. The attribute is supported for COM interop and platform invoke only. In the absence of explicit settings, the interop marshaler assumes rules based on the parameter type, whether the parameter is passed by reference or by value, and whether the type is blittable or non-blittable. For example, the StringBuilder class is always assumed to be In/Out and an array of strings passed by value is assumed to be In.

Czytaj: robi roznice dla argumentow przekazywanych przez referencje. Plus wzmianka w dokumentacji o tym, ze:

msdn napisał(a)

Combining the InAttribute and OutAttribute is particularly useful when applied to arrays and formatted, non-blittable types. Callers see the changes a callee makes to these types only when you apply both attributes.

troche sie watek rozwinal a ja nie obserwowalem ...

Nie nie stosowal, samo scilab tak ale jakos mi nie przypadlo do gustu.

Jednak bardziej chodzilo mi o to by inni uczyli sie szukac, pakietow jest z milion jak nie wiecej i ta wiedza jest zazwyczaj opisna. Nalezy troche sie wysilic i szukac (tu przyklad johny_bravo znalalzl odpowiedz, dokumentacja jest, jest jej nawet bardzo duzo ale to wciaga duzo czasu ... niestety. Zazwyczaj za to, ze cos jest darmowe placi sie wlasnym czasem)

Pobieznie czytalem ale twierdzenie o tym aby nie stosowac kodu unsafe pewnie sie odnosi do tego aby nie pisac w starym modelu. Wydaje mi sie, ze wrapery na biblioteki jak najbardziej ... w koncu samo .NET (nawet 3.5, 4.0 nie zagladalem ale na 99% tez) nadal jest nakladka na winapi.

Dzięki. Już prawie rozgryzłem temat. Właśnie buduję bibliotekę DLL do współpracy ze Scilabem z poziomu Aplikacji .NET. Korzystam z Sandlcastle Help Builder do tworzenia dokumentacji. Przez te komentarze pliki się rozrosły.