I have created a User interface in C++\CLI application which uses a C dll for manipulating exif files. This C dll uses system() function opens cmd window and a notepad file for editing and when we close the note pad file the entered data is edited to the exif header comment. Now I have to hide this cmd window I have used "start \b" but this close the cmd window this results in editing of exif header without entering data into the note pad file.
The code for this function is as following.
FILE * file;
int a;
char QuotedPath[PATH_MAX+10];
file = fopen(TempFileName, "w");
if (file == NULL)
{
fprintf(stderr, "Can't create file '%s'\n",TempFileName);
ErrFatal("could not create temporary file");
}
fwrite(Comment, CommentSize, 1, file);
fclose(file);
fflush(stdout); // So logs are contiguous.
{
char * Editor;
Editor = getenv("EDITOR");
if (Editor == NULL)
{
#ifdef _WIN32
Editor = "notepad";
#else
Editor = "vi";
#endif
}
if (strlen(Editor) > PATH_MAX) ErrFatal("env too long");
sprintf(QuotedPath, "%s \"%s\"",Editor, TempFileName);
a = system(QuotedPath);
}
if (a != 0)
{
char message[50]= "";
strcpy(message, "Editor failed to launch");
MessageBoxA(hWnd,message,"Error : ",MB_ICONWARNING);
// perror("Editor failed to launch");
exit(-1);
}
if (hFileOpen != NULL)
{
file = fopen(TempFileName, "r");
if (file == NULL)
{
ErrFatal("could not open temp file for read");
}
// Read the file back in.
CommentSize = fread(Comment, 1, 999, file);
fclose(file);
unlink(TempFileName);
return CommentSize;
}
The best way (in my humble opinion) is to use shellexecuteEx to run the specified exe, this will return a handle to the executed process which you can then monitor and close when finished with it.
Note: I think you should consider reformatting you code blocks
Related
I'm actually playing with BPFTrace and Python BCC to discover the fascinating world of eBPF.
As my first POC for Uprobes, I wanted to print to stdout all the file opened by fopen calls. So, I wrote the following BPFTrace script:
BEGIN
{
printf("Hit Ctrl-C to end.\n");
}
uprobe:/lib/x86_64-linux-gnu/libc.so.6:fopen
{
printf("File opened: %s\n", str(arg0));
}
To test it, I wrote this little C language POC:
#include <stdio.h>
int main(){
char *filename = "/etc/issue";
FILE *fd = fopen(filename, "r");
if (fd == NULL){
return -1;
}
fclose(fd);
return 0;
}
When I run my bpftrace script I get this output:
sudo bpftrace ./trace.bt
Attaching 2 probes...
Hit Ctrl-C to end.
File opened:
It seems like the BPF program is not able to retrieve the filename.
When I modify the C POC like this:
#include <stdio.h>
int main(){
char filename[] = "/etc/issue";
FILE *fd = fopen(filename, "r");
if (fd == NULL){
return -1;
}
fclose(fd);
return 0;
}
The resulting BPF trace is:
sudo bpftrace ./trace.bt
Attaching 2 probes...
Hit Ctrl-C to end.
File opened: /etc/issue
The only difference I notice there is that in the first case, the "/etc/issue" string is stored in .rodata section because of the difference in the variable declaration : char filename[] instead of char *filename.
I am a little bit confused, I do not understand why it makes a difference for Uprobes.
The C code was compiled using: gcc -o test testing.c.
I am using the following environment :
Kali Linux with Kernel Linux kali 6.0.0-kali3-amd64 and bpftrace v0.16.0
EDIT: Well, it appears to be something not really (only?) related to read-only content.
Using this program as a test:
#include <stdio.h>
int main(){
FILE *fds[5];
fds[0] = fopen("/etc/issue", "r");
fds[1] = fopen("/etc/passwd", "r");
fds[2] = fopen("/etc/nanorc", "r");
fds[3] = fopen("/etc/netconfig", "r");
fds[4] = fopen("/etc/pam.conf", "r");
for(int i=0; i<5; i++){
if(fds[i] != NULL){
fclose(fds[i]);
}
}
return 0;
}
I get the following trace:
sudo bpftrace ./trace.bt
Attaching 2 probes...
Hit Ctrl-C to end.
File opened:
File opened: /etc/passwd
File opened: /etc/nanorc
File opened: /etc/netconfig
File opened: /etc/pam.conf
The trace never catches the first arg from the first call to fopen. At this time, I have no idea what is going on and how to go deeper in finding the bug root.
My question is regarding the Recover assignment as part of CS50.
The code is running (finally) and it produces 50 JPEG files, and most of them are the correct images, except the first file is not an image, therefore it doesn't pass check50.
I have spent a long time trying to figure out what the problem is but I cannot pinpoint it so I am hoping someone might be able to help me out so I can move on.
Thanks in advance! Here is my code:
int main(int argc, char *argv[])
{
// ensure proper usage
if (argc != 2)
{
fprintf(stderr, "Usage: Name of Memory Card File\n");
return 1;
}
char *readfile = argv[1];
// open memory card file
FILE *card_ptr = fopen(readfile, "r");
if (card_ptr == NULL)
{
fprintf(stderr, "Could not open %s.\n", readfile);
return 2;
}
//Declare a buffer to read into
unsigned char *buffer = malloc(512);
//to check if we have already found a file
bool (jpgAlreadyNew) = false;
//declare counter for the number of files found and a file pointer
int filenumber = 0;
FILE *new_jpg_ptr = NULL;
char filename[8];
//read in bytes until reach EOF
while (fread(buffer, 1, 512, card_ptr) != 0x00)
{
//if we reach the header pattern of bytes
if (buffer [0] == 0xff && buffer [1] == 0xd8 && buffer [2] == 0xff && (buffer [3] & 0xf0) == 0xe0)
{
//if there is not already a JPEG file found
if (!jpgAlreadyNew)
{
//change the bool value
(jpgAlreadyNew) = true;
//open new file
sprintf(filename, "%03i.jpg", filenumber);
new_jpg_ptr = fopen(filename, "w");
if (new_jpg_ptr == NULL)
{
return 3;
}
//add to counter of files found
filenumber++;
//write files from buffer into new img file
fwrite(buffer, 1, 512, new_jpg_ptr);
}
//if there is already a JPEG file found
if (jpgAlreadyNew)
{
//close the previous file which would now be complete
fclose(new_jpg_ptr);
//open new file
sprintf(filename, "%03i.jpg", filenumber);
new_jpg_ptr = fopen(filename, "w");
if (new_jpg_ptr == NULL)
{
return 4;
}
//add to counter of files found
filenumber++;
//write files from buffer into new img file
fwrite(buffer, 1, 512, new_jpg_ptr);
}
}
// else if we do not see pattern of header bytes
else
{
//if already found a jpg file which is open then write the bytes to that file
if (jpgAlreadyNew)
{
fwrite(buffer, 1, 512, new_jpg_ptr);
}
//if no file found yet, discard and move on
if (!jpgAlreadyNew)
{
continue;
}
}
}
//free memory
free (buffer);
//close pointers and end program successfully
fclose(card_ptr);
fclose(new_jpg_ptr);
return 0;
}
Let's walk through the program starting with finding the first jpeg signature:
This if (!jpgAlreadyNew) evaluates to true, so it enters the if block; the first thing it does is (jpgAlreadyNew) = true;. When it is done creating the file and writing the first block, what happens next? This if (jpgAlreadyNew). Which also evaluates to true. So it closes 000.jpg and moves along.
Since jpgAlreadyNew is a boolean, an if {} else {} construct would suffice.
I have previously used MiniZip (zlib wrapper) to unzip archives. MiniZip cannot be used for Metro applications as it uses deprecated APIs in "iowin32.c" -- CreateFile() and SetFilePointer().
I thought that would be an easy fix and created "iowinrt.c" with CreateFile() and SetFilePointer() replaced with CreateFile2() and SetFilePointerEx(). While this way I obtained a version of MiniZip that uses only approved Win8 APIs, it still turned out to be useless -- I forgot about sandboxing. If I pick a file using FileOpenPicker() and pass its path to my modified MiniZip I still cannot open it -- CreateFile2() will fail with "Access is denied." message.
So it appears that old C API for file access if now mostly useless; it is my understanding that in order to fix this I would need to reimplement my "iowinrt" in C++/CX using the new async file access. Are there any other options? I think I saw somewhere that WinRT does have compress/uncompress functionality but that it only works on individual files, not archives.
Additional requirements it that I need this to work in memory.
For a moment I thought I had a solution via .NET Framework 4.5:
I found this piece of info about how to create .NET classes that can be used from C++/CX:
http://social.msdn.microsoft.com/Forums/en-US/winappswithnativecode/thread/3ff383d0-0c9f-4a30-8987-ff2b23957f01
.NET Framework 4.5 contains ZipArchive and ZipArchiveEntry classes in System.IO.Compression:
http://msdn.microsoft.com/en-us/library/system.io.compression.ziparchive%28v=vs.110%29.aspx#Y0
http://msdn.microsoft.com/en-us/library/system.io.compression.ziparchiveentry%28v=vs.110%29.aspx#Y0
I thought I could create C# Metro Class Library with WinMD Output type exposing ZipArchive and ZipArchiveEntry then use that in my C++/CX project. However, even if it worked it would not work in-memory; it appears that ZipArchive and ZipArchiveEntry work only with files.
Got reading from archive working. Explanation and code below but really just a hack at this point, to see if it's possible at all. I just kept modifying things until I got something working; this is just an example of what works and by no means a production quality code (it's not re-entrant for start). There are undoubtedly many things that are bad/unnecessary/wtf so feel free to use comments to help with clean up.
As mentioned previously, it is no longer enough to pass path to the library -- unless file is in one of KnownFolders (documents, home, media, music, pictures, removable or videos) you end up with "access is denied" message. Instead, library must be able to accept StorageFile^, as returned from FileOpenPicker. At least I haven't found any other way to do it, maybe someone knows better?
MiniZip provides Windows filesystem access layer for zlib via iowin32.h/.c. This still works in desktop mode for old-style apps, but does not work for Metro apps as it uses deprecated APIs and relies on paths. To get MiniZip going on Windows 8, a complete rewrite of iowin32 is required.
To get things working again, first thing was to find a way to pass StorageFile^ all the way down to iowinrt (Windows 8 replacement for iowin32). Fortunately, that was not a problem as MiniZip provides two styles of open file functions -- ones that accept pointer to char, and the others accepting pointer to void. Since ^ is still just a pointer, casting StorageFile^ to void* and than back to StorageFile^ works fine.
Now that I was able to pass StorageFile^ to my new iowinrt, the next problem was how to make new async C++ file access API work with Zlib. In order to support very old C compilers, Zlib is written with old K&R style C. VisualStudio compiler will refuse to compile this as C++, it has to be compiled as C, and new iowinrt must be compiled as C++ of course -- keep that in mind when creating your project. Other things to note about VS project is that I did it as Visual C++ Windows Metro style Static Library although DLL should also work but then you must also define macro to export MiniZip API (I haven't tried this, don't know which macro you have to use). I think I also had to set "Consume Windows Runtime Extension" (/ZW), set "Not Using Precompiled Headers" and add _CRT_SECURE_NO_WARNINGS and _CRT_NONSTDC_NO_WARNINGS to Preprocessor Definitions.
As for iowinrt itself, I've split it in two files. One holds two sealed ref classes -- reader and writer objects; they accept StorageFile^. Reader implements Read, Tell, SeekFromBeginning, SeekFromCurrent and SeekFromEnd (the reason for 3 Seek methods is because ref sealed classes have to stick with RT types and that apparently excludes enums so I just took the easy route). Writer implements just Write at the moment, haven't used it yet.
This is FileReader code:
#include "pch.h"
#include "FileAccess.h" // FileReader and FileWriter
using namespace Concurrency;
using namespace Windows::Security::Cryptography;
using namespace CFileAccess;
FileReader::FileReader(StorageFile^ archive)
{
if (nullptr != archive)
{
create_task(archive->OpenReadAsync()).then([this](IRandomAccessStreamWithContentType^ archiveStream)
{
if (nullptr != archiveStream)
{
_readStream = archiveStream;
}
}).wait();
}
} // end of constructor
int32 FileReader::Read(WriteOnlyArray<byte>^ fileData)
{
int32 bytesRead = 0;
if ((nullptr != _readStream) && (fileData->Length > 0))
{
try
{
auto inputStreamReader = ref new DataReader(_readStream);
create_task(inputStreamReader->LoadAsync(fileData->Length)).then([&](task<unsigned int> dataRead)
{
try
{
bytesRead = dataRead.get();
if (bytesRead)
{
inputStreamReader->ReadBytes(fileData);
}
}
catch (Exception^ e)
{
bytesRead = -1;
}
inputStreamReader->DetachStream();
}).wait();
}
catch (Exception^ e)
{
bytesRead = -1;
}
}
return (bytesRead);
} // end of method Read()
int64 FileReader::Tell(void)
{
int64 ret = -1;
if (nullptr != _readStream)
{
ret = _readStream->Position;
}
return (ret);
} // end of method Tell()
int64 FileReader::SeekFromBeginning(uint64 offset)
{
int64 ret = -1;
if ((nullptr != _readStream) && (offset < _readStream->Size))
{
_readStream->Seek(offset);
ret = 0;
}
return (ret);
} // end of method SeekFromBeginning()
int64 FileReader::SeekFromCurrent(uint64 offset)
{
int64 ret = -1;
if ((nullptr != _readStream) && ((_readStream->Position + offset) < _readStream->Size))
{
_readStream->Seek(_readStream->Position + offset);
ret = 0;
}
return (ret);
} // end of method SeekFromCurrent()
int64 FileReader::SeekFromEnd(uint64 offset)
{
int64 ret = -1;
if ((nullptr != _readStream) && ((_readStream->Size - offset) >= 0))
{
_readStream->Seek(_readStream->Size - offset);
ret = 0;
}
return (ret);
} // end of method SeekFromEnd()
iowinrt sits between MiniZip and FileReader (and FileWriter). It's too long to give everything here but this should be sufficient to reconstruct the rest since it's mostly just more of the same with different function names, plus a bunch of fill_winRT_filefuncxxx() which are obvious:
#include "zlib.h"
#include "ioapi.h"
#include "iowinrt.h"
#include "FileAccess.h"
using namespace Windows::Security::Cryptography;
using namespace Platform;
using namespace CFileAccess;
static FileReader^ g_fileReader = nullptr;
static FileWriter^ g_fileWriter = nullptr;
static StorageFile^ g_storageFile = nullptr;
[...]
static voidpf winRT_translate_open_mode(int mode)
{
if (nullptr != g_storageFile)
{
if ((mode & ZLIB_FILEFUNC_MODE_READWRITEFILTER)==ZLIB_FILEFUNC_MODE_READ)
{
g_fileWriter = nullptr;
g_fileReader = ref new FileReader(g_storageFile);
}
else if (mode & ZLIB_FILEFUNC_MODE_EXISTING)
{
g_fileReader = nullptr;
g_fileWriter = ref new FileWriter(g_storageFile);
}
else if (mode & ZLIB_FILEFUNC_MODE_CREATE)
{
g_fileReader = nullptr;
g_fileWriter = ref new FileWriter(g_storageFile);
}
}
return (nullptr != g_fileReader ? reinterpret_cast<voidpf>(g_fileReader) : reinterpret_cast<voidpf>(g_fileWriter));
}
voidpf ZCALLBACK winRT_open64_file_func (voidpf opaque,const void* storageFile,int mode)
{
g_storageFile = reinterpret_cast<StorageFile^>(const_cast<void*>(storageFile));
return (winRT_translate_open_mode(mode));
}
[...]
Long ZCALLBACK winRT_read_file_func (voidpf opaque, voidpf stream, void* buf,uLong size)
{
uLong bytesRead = 0;
if (nullptr != g_fileReader)
{
auto fileData = ref new Platform::Array<byte>(size);
bytesRead = g_fileReader->Read(fileData);
memcpy(buf, fileData->Data, fileData->Length);
}
return (bytesRead);
}
uLong ZCALLBACK winRT_write_file_func (voidpf opaque,voidpf stream,const void* buf,uLong size)
{
uLong bytesWritten = 0;
if (nullptr != g_fileWriter)
{
auto bytes = ref new Array<uint8>(reinterpret_cast<uint8*>(const_cast<void*>(buf)), size);
IBuffer ^writeBuffer = CryptographicBuffer::CreateFromByteArray(bytes);
bytesWritten = g_fileWriter->Write(writeBuffer);
}
return (bytesWritten);
}
long ZCALLBACK winRT_tell_file_func (voidpf opaque,voidpf stream)
{
long long ret = 0;
if (nullptr != g_fileReader)
{
ret = g_fileReader->Tell();
}
return (static_cast<long>(ret));
}
ZPOS64_T ZCALLBACK winRT_tell64_file_func (voidpf opaque, voidpf stream)
{
ZPOS64_T ret = 0;
if (nullptr != g_fileReader)
{
ret = g_fileReader->Tell();
}
return (ret);
}
[...]
long ZCALLBACK winRT_seek64_file_func (voidpf opaque, voidpf stream,ZPOS64_T offset,int origin)
{
long long ret = -1;
if (nullptr != g_fileReader)
{
switch (origin)
{
case ZLIB_FILEFUNC_SEEK_CUR :
ret = g_fileReader->SeekFromCurrent(offset);
break;
case ZLIB_FILEFUNC_SEEK_END :
ret = g_fileReader->SeekFromEnd(offset);
break;
case ZLIB_FILEFUNC_SEEK_SET :
ret = g_fileReader->SeekFromBeginning(offset);
break;
default:
// should never happen!
ret = -1;
break;
}
}
return (static_cast<long>(ret));
}
int ZCALLBACK winRT_close_file_func (voidpf opaque, voidpf stream)
{
g_fileWriter = nullptr;
g_fileReader = nullptr;
return (0);
}
int ZCALLBACK winRT_error_file_func (voidpf opaque,voidpf stream)
{
/// #todo Get errors from FileAccess
return (0);
}
This is enough to get MiniZip going (at least for reading) but you have to take care how you call MiniZip functions -- since Metro is all about async and blocking UI thread will end up with exception, you must wrap access in tasks:
FileOpenPicker^ openPicker = ref new FileOpenPicker();
openPicker->ViewMode = PickerViewMode::List;
openPicker->SuggestedStartLocation = PickerLocationId::ComputerFolder;
openPicker->FileTypeFilter->Append(".zip");
task<IVectorView<StorageFile^>^>(openPicker->PickMultipleFilesAsync()).then([this](IVectorView<StorageFile^>^ files)
{
if (files->Size > 0)
{
std::for_each(begin(files), end(files), [this](StorageFile ^file)
{ // open selected zip archives
create_task([this, file]()
{
OpenArchive(file);
[...]
});
});
}
else
{
rootPage->NotifyUserBackgroundThread("No files were returned.", NotifyType::ErrorMessage);
}
});
[...]
bool OpenArchive(StorageFile^ archive)
{
bool isArchiveOpened = false;
if (nullptr != archive)
{ // open ZIP archive
zlib_filefunc64_def ffunc;
fill_winRT_filefunc64(&ffunc);
unzFile archiveObject = NULL;
create_task([this, &ffunc, archive]()
{
archiveObject = unzOpen2_64(reinterpret_cast<const void*>(archive), &ffunc);
}).wait();
if (NULL != archiveObject)
{
[...]
I have a third party component written in C/C++ (on VS 2010) which can be downloaded here.
This component accepts 3 parameters as input (a filename and two numbers) and outputs a result in the console, and then outputs a file.
I've used Process and ProcessStartInfo in a C# WinForm project to consume this component which works fine. However, now I want to consume this in a WCF C# RESTful service, in which case the solution I thought with WinForm will not work.
It was suggested that I instead convert this to a MFC DLL and then use InterOp to call the unmanaged DLL through my C# web service (other suggestions are welcome).
Unfortunately, I have no idea on how to do that and my knowledge on C/C++ is fairly average. So my question is: How do I create a DLL from that component which accepts these 3 parameters (taken from main()):
cin >> fname;
cin >> minA;
cin >> minO;
then does whatever calculations it's supposed to do and return this (again taken from main()):
cout << "\nNumber is: " << num;
(and obviously still output the file it's supposed to output) ?
Any help would be HIGHLY appreciated.
Thanks in advance!
UPDATE: As a point of reference, here is my WinForm implementation mentioned above.
ProcessStartInfo cmdStartInfo = new ProcessStartInfo();
Process cmdProcess = new Process();
BackgroundWorker BWorker = new BackgroundWorker();
//is able to report progress
BWorker.WorkerReportsProgress = true;
//is able to be cancelled
BWorker.WorkerSupportsCancellation = true;
//attach events
BWorker.DoWork += worker_DoWork;
BWorker.RunWorkerCompleted += worker_RunWorkerCompleted;
BWorker.RunWorkerAsync();
private void worker_DoWork(object sender, DoWorkEventArgs e)
{
if (firstTimeLoaded)
{
cmdStartInfo.FileName = Path.GetFullPath("../../Resources/thirdparty.exe");
cmdStartInfo.WorkingDirectory = Path.GetFullPath("../../Resources/");
cmdStartInfo.RedirectStandardOutput = true;
cmdStartInfo.RedirectStandardError = true;
cmdStartInfo.RedirectStandardInput = true;
cmdStartInfo.UseShellExecute = false;
cmdStartInfo.CreateNoWindow = true;
cmdProcess.StartInfo = cmdStartInfo;
cmdProcess.SynchronizingObject = this;
cmdProcess.ErrorDataReceived += cmd_Error;
cmdProcess.Exited += cmd_Exited;
cmdProcess.EnableRaisingEvents = true;
cmdProcess.Start();
cmdProcess.BeginErrorReadLine();
firstTimeLoaded = false;
}
while (!cmdProcess.HasExited)
{
if (use)
{
if (BWorker.CancellationPending)
{
e.Cancel = true;
}
StringBuilder builder = new StringBuilder();
//read unbuffered output
while (cmdProcess.StandardOutput.Peek() != -1)
{
char inputChar = (char)cmdProcess.StandardOutput.Read();
if (inputChar != '\r' && inputChar != '\n')
{
builder.Append(inputChar);
}
if (inputChar == '\n')
{
break;
}
}
if (cmdProcess.StandardOutput.Peek() == -1)
{
cmdProcess.StandardOutput.DiscardBufferedData();
}
//process the output
string output = builder.ToString();
//determine appropriate action
switch (output)
{
case "Enter file name: ":
cmdProcess.StandardInput.WriteLine(textBox1.Text);
break;
case "Enter minimum size of A: ":
cmdProcess.StandardInput.WriteLine(textBox2.Text);
break;
case "Enter minimum size of O: ":
cmdProcess.StandardInput.WriteLine(textBox3.Text);
break;
}
if (output.Contains("Number: "))
{
MessageBox.Show("Number is: " + output.Substring(output.LastIndexOf(" ") + 1));
use = false;
}
}
}
}
Let's give this a try.
In VS2010, create a Win32 Project under Visual C++/Win32. For this purpose, call it MyWin32Lib.
Add the thirdparty.cpp file to the project and compile. You should get some warnings, but it's ok.
Create a new header file called thirdparty.h so we can export the function signature.
In the thirdparty.h file, do:
#pragma once
// This will be the interface for third party file
int concepts(char* szFileName, int nMinIntent, int nMinExtent);
In the thirdparty.cpp file, add #include "stdafx.h" right before #include
Change the main function signature to match the one in the header:
//int main()
// Instead of getting input from console, we're passing it the values
int concepts(char* szFileName, int nMinIntent, int nMinExtent)
Comment out all input requests, and just copy the args to the local vars:
//cout << "\n\n***** In-Close 3.0 Concept Miner *****";
//cout << "\n\nEnter cxt file name including extension: ";
//cin >> fname;
//cout << "\nEnter minimum size of intent (no. attributes): ";
//cin >> minIn;
//cout << "\nEnter minimum size of extent (no. objects): ";
//cin >> minEx;
strcpy_s(fname, _countof(fname), szFileName);
minIn = nMinIntent;
minEx = nMinExtent;
Comment out cout << "\nNumber... (this is no longer needed)
At the end of the function, do:
break;
}
//cout << "\n\nHit <enter> to finish";
//while ( !_kbhit());
return numcons;
}
I don't know why there's a while(1) since there's no way to get out of it, but assume we'll doing it only once.
Make sure you compile ok.
Create a new CPP file, call it "Concepts.cpp"
In Concepts.cpp, enter:
#include "stdafx.h"
#include "thirdparty.h"
extern "C"
{
__declspec(dllexport) int GetConcepts(char* szFileName, int nMinIntent, int nMinExtent)
{
return concepts(szFileName, nMinIntent, nMinExtent);
}
}
*You should now have a Win32 DLL that performs the work using arguments instead.
Create a C# Class Library project.
Create a C# class called "Concepts.cs"
In this class, enter:
public class Concepts
{
// Link to the Win32 library through InterOp
[DllImport("MyWin32Lib.dll")]
public static extern int GetConcepts(
[MarshalAs( UnmanagedType.LPStr )] string fileName, int minIntent, int minExtent );
}
*You have to marshal the filename input as ANSI since that's what thirdparty.cpp uses.
I think I got all of it. You can now reference your C# library from a web service.
I have a config.txt file. The file is not compressed during the apk build using the nocompress extension="txt" option. Then I'm openning in my java code asset manager and passing it to the native function. Finally I'm opening a File* using the below code.
The problem is that when calling fgets(line, 32, file) - where line is char * - the content of line is not what is the first line of the file.
AAssetManager* mgr = AAssetManager_fromJava(env, assetManager);
if(NULL == mgr) return -1;
AAsset* asset = AAssetManager_open(mgr, "config.txt", AASSET_MODE_UNKNOWN);
if (NULL == asset) {
return -1;
}
off_t start, length;
int fd = AAsset_openFileDescriptor(asset, &start, &length);
if (fd < 0)
return -1;
FILE * file = fdopen(fd, "r");
As you can see in https://code.google.com/p/java-ide-droid/source/browse/trunk/jni/aapt/jni/Package.cpp (search for "static const char* kNoCompressExt" ) txt is not in the exclude list and may be compressed!
Actually this should lead to fd beeing smaller than zero.