I've tried to include Kaj de Vos's excellent C library binding available in ANSI.reds, but still cannot find a way to read a directory listing.
I thought that maybe if I could read the . file in binary, I could parse it, but I just get back a NULL pointer:
sizedir: 0
dir: read-file-binary "my-dir/." :sizedir
print-line dir
If I try reading it as a text file, I get a:
*** Runtime Error 1: access violation
*** at: 0040152Eh
Any ideas?
A piece of additional code and definitions needs to be written to read the directory structure and interpret it. It's tricky, because it's partly system dependent, so it goes beyond the ANSI part of my C library binding. Also, to achieve a higher abstraction level on the way to the directory functions in REBOL, you'd have to think about extra data structures that are not native to Red/System.
Related
I tried copying the c++ example as mentioned here -
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieac100/ieac1-cwe-json-prog.htm
However, I am getting the following JCL error when running on my system :
IEF344I XC1CPLLE COMPILE SYSLIB - ALLOCATION FAILED DUE TO DATA FACILITY SYSTEM ERROR
IGD17045I SPACE NOT SPECIFIED FOR ALLOCATION OF DATA SET
SIEAHDR.H
IEF272I XC1CPLLE COMPILE - STEP WAS NOT EXECUTED.
Here is a copy of my modified program :
https://gist.github.com/4349183c3ec6d223a0073b87b9c2da8b
The JCL to which you provide a link contains a JCL error. The SYSLIB DD of the COMPILE step has no DISP and thus defaults to DISP=(NEW,DELETE,DELETE). A status of NEW requires space allocation and none is provided, so you get the error in your question. To fix this particular problem, I suggest coding DISP=SHR on the SYSLIB DD in the COMPILE step.
I recommend talking to your support staff about standard compile procedures, as most shops implement their own.
I have a code written in Atmel Studio to read/write data from a SD card. I am using FatFs here. My problem is the code doesn't compile when I use some of the functions (f_chdir, f_getcwd...) in FatFs. Some functions works fine (f_puts, f_open, f_mount, f_mkdir...). All these functions are located in same header file (ff.h, ff.c)
The error says "undefined reference to -function-, ld returned 1 exit status". When I go to the error it shows the end of the code while it is suppose to show where the error is.
I cannot understand the problem with my code. Any help is appreciated.
Just ran into this using the SD card for a project using SAM4S Xplained Pro (Atmel 7, ASF 3.20).
Make sure you have all the asf projects (fatfs, sd_mmc, memory access control, and then the other basics e.g. pmc, gpio, and maybe a few more). My asf did NOT include sd_mmc_mem.c and sd_mmc_mem.h for some reason, so I had to include those myself. Also remember to do the sd_mmc_init() at the top of your main loop. As for the configuration...
If you look closely at ffconf.h, the first thing it does is include conf_fatfs.h, which (wait for it!) is EXACTLY the same file line by line as ffconf.h. All the variables are defined there first and foremost (and guarded by an #ifndef FFCONF and NOT an CONF_FATFS) aka that's where it counts..
Go into conf_fatfs.h and change _USE_STRFUNC to 1 or 2 et voila.
Also note that in the places where you use it, you'll have to #include the ff.h preceded by either ffconf.h or conf_access.h
ASF is a real snake pit if you don't know what you're looking for.
Enjoy.
By default, the memory control access interface is disabled in the ASF wizard. In order to enable the memory control access, please follow the steps below.
Open the ASF wizard (Alt + W).
Enable the Memory Control Access as follows.
ASF SD sd_mmc_mem.h memory access enable
Finally, click the “Apply” option to make the changes.
This adds sd_mmc_mem.h /.c files
Open the ffconf.h in your favorite editor and set _FS_RPATH to 2. From ffconf.h:
#define _FS_RPATH 0
/* This option configures relative path feature.
/
/ 0: Disable relative path feature and remove related functions.
/ 1: Enable relative path feature. f_chdir() and f_chdrive() are available.
/ 2: f_getcwd() function is available in addition to 1.
/
/ Note that directory items read via f_readdir() are affected by this option. */
Which features of the fatfs library are included in your build is configurable, so that you don't have to lose valuable ROM space (as well as a few bytes of RAM) for functions you're not using.
For versions of the FatFS library prior to 0.8a, _FS_RPATH supports only values 0 and 1; f_getcwd is not available in these versions.
Additionally, in versions prior to 0.8, it is necessary for C++ code to explicitly include its headers as C headers to avoid name mangling:
extern "C" {
#include "ff.h"
}
From version 0.8 onwards, it does this internally. You can find the new versions here if you're still working with an old one -- the comment you left leads me to believe that this might be the case.
Check if _FS_MINIMZE in ffconf.h is 0 to have all functions available.
In my version that I downloaded from elm-chan it was by default set to 3 and lead to the compiler error: undefined reference.
In file ffconf.h, set #define _USE_FIND to 1.
/* This option switches filtered directory read functions, f_findfirst() and
/ f_findnext(). (0:Disable, 1:Enable 2:Enable with matching altname[] too) */
I needed to use f_findfirst() and f_findnext() functions and i was getting undefined reference errors.
Now this solved my problem.
Drive/directory handling functions are under #if _FS_RPATH >= 1 (or similar preprocessors) .
So I have a software program that for reasons that are beyond this post, I will not include but to put it simply, I'd like to "MOD" the original software. The program is launched from a Windows Application named ViaNet.exe with accompanying DLL files such as ViaNetDll.dll. The Application is given an argument such as ./Statup.cat. There is also a WatchDog process that uses the argument ./App.cat instead of the former.
I was able to locate a log file buried in my Windows/Temp folder for the ViaNet.exe Application. Looking at the log it identifies files such as:
./Utility/base32.atc:_Encode32 line 67
./Utilities.atc:MemFun_:Invoke line 347
./Utilities.atc:_ForEachProperty line 380
./Cluster/ClusterManager.atc:ClusterManager:GetClusterUpdates line 1286
./Cluster/ClusterManager.atc:ClusterManager:StopSync line 505
./Cluster/ClusterManager.atc:ConfigSynchronizer:Update line 1824
Going to those file locations reveal files by those names, but not ending with .atc but instead .cat. The log also indicates some sort of Class, Method and Line # but .cat files are in binary form.
Searching the program folder for any files with the extension .atc reveals three -- What I can assume are uncompiled .cat files -- files. Low and behold, once opened it's obviously some sort of source code -- with copyright headers, lol.
global ConfigFolder, WriteConfigFile, App, ReadConfigFile, CreateAssocArray;
local mgrs = null;
local email = CreateAssocArray( null);
local publicConfig = ReadConfigFile( App.configPath + "\\publicConfig.dat" );
if ( publicConfig != null )
{
mgrs = publicConfig.cluster.shared.clusterGroup[1].managers[1];
local emailInfo = publicConfig.cluster.shared.emailServer;
if (emailInfo != null)
{
if (emailInfo.serverName != "")
{
email.serverName = emailInfo.serverName;
}
if (emailInfo.serverEmailAddress != "")
{
email.serverEmailAddress = emailInfo.serverEmailAddress;
}
if (emailInfo.adminEmailAddress != null)
{
email.adminEmailAddress = emailInfo.adminEmailAddress;
}
}
}
if (mgrs != null)
{
WriteConfigFile( ConfigFolder + "ZoneInfo.dat", mgrs);
}
WriteConfigFile( ConfigFolder + "EmailInfo.dat", email);
So to end this as simply as possible, I'm trying to find out two things. #1 What Programming Language is this? and #2 Can the .cat be decompiled back to .atc. files? -- and vice versa. Looking at the log it would appear that the Application is decoding/decompiling the .cat files already to interpret them verses running them as bytecode/natively. Searching for .atc on Google results in AutoCAD. But looking at the results, shows it to be some sort of palette files, nothing source code related.
It would seem to me that if I can program in this unknown language, let alone, decompile the existing stuff, I might get lucky with modding the software. Thanks in advance for any help and I really really hope someone has an answer for me.
EDIT
So huge news people, I've made quite an interesting discovery. I downloaded a patch from the vendor, it contained a batch file that was executing ViaNet.exe Execute [Patch Script].atc. I quickly discovered that you can use Execute to run both .atc and .cat files equally, same as with no argument. Once knowing this I assumed that there must be various arguments you can try, well after a random stroke of luck, there is one. That being Compile [Script].atc. This argument will compile also any .atc file to .cat. I've compiled the above script for comparison: http://pastebin.com/rg2YM8Q9
So I guess the goal now is to determine if it's possible to decompile said script. So I took a step further and was successful at obtaining C++ pseudo code from the ViaNet.exe and ViaNetDll.dll binaries, this has shed tons of understanding on the proprietary language and it's API they use. From what I can tell each execution is decompiled first then ran thru the interpreter. They also have nicknamed their language ATCL, still no idea what it stands for. While searching the API, I found several debug methods with names like ExecuteFile, ExecuteString, CompileFile, CompileString, InspectFunction and finally DumpObjCode. With the DumpObjCode method I'm able to perform some sort of dump of script files. Dump file for above script: http://pastebin.com/PuCCVMPf
I hope someone can help me find a pattern with the progress I made. I'm trying my best to go over the pseudo code but I don't know C++, so I'm having a really hard time understanding the code. I've tried to seperate what I can identify as being the compile script subroutines but I'm not certain: http://pastebin.com/pwfFCDQa
If someone can give me an idea of what this code snippet is doing and if it looks like I'm on the right path, I'd appreciate it. Thank you in advanced.
I have reinstalled emacs 24.2.50 on a new linux host and started a new dotEmacs config based on magnars emacs configuration. Since I have used CEDET to some success in my previous workflow I started configuring it. However, there is some strange behaviour whenever I load a C++ source file.
[This Part Is Solved]
As expected, semantic parses all included files (and during the initial setup parses all files specified by the semantic-add-system-include variables), but it prints this an error message that goes like this:
WARNING: semantic-find-file-noselect called for /usr/include/c++/4.7/vector while in set-auto-mode for /usr/include/c++/4.7/vector. You should call the responsible function into 'mode-local-init-hook'.
In the above example the error is printed for the STL vector but a corresponding error message is printed for every file included by the one I'm visiting and any subsequent includes. As a result it takes quite a long time to finish and unfortunately the process is repeated any type I open a new buffer.
[This Problem Is Solved Too]
Furthermore it looks like the parsing doesn't really work as when I place the point above a non-c primitive type (i.e. not int,double,float, etc) instead of printing the type's definition in the modeline an error message like
Idle Service Error semantic-idle-local-symbol-highlight-idle-function: "#<buffer DEPFETResolutionAnalysis.cc> - Wrong type argument: stringp, (((0) \"IndexMap\"))"
Idle Service Error semantic-idle-summary-idle-function: "#<buffer DEPFETResolutionAnalysis.cc> - Wrong type argument: stringp, ((\"fXBetween\" 0 nil nil))"
where DEPFETResolutionAnalysis.cc is the file & buffer I'm currently editing and IndexMap and fXBetween are types defined in files included by the file I'm editing/some file included by the file I'm editing.
I have not tested any further features of CEDET/semantic as the problem is pretty annoying. My cedet config can be found here.
EDIT: With the help of Alex Ott I kinda solved the first problem. It was due to my horrible cedet initialisation. See his first answer for the proper way to configure CEDET!
There still remains the problem with the Idle Service Error (which, when enabling global-semantic-idle-local-symbol-highlight-mode, occurs permanently, not only when checking the definition of the type at point).
And there is the new problem of how to disable the site-wise init file(s).
EDIT2: I have executed semantic-debug-idle-function in a buffer where the problem occurs and it produces a ~700kb [sic!] output. It looks like it is performing some operations on a data container which, by the looks of it, contains information on all the symbols defined in the files parsed. As I have parsed a rather large package (~20Mb source files) this table is rather large. Can semantic handle a database that large or is this impossible and the reason of my problem?
EDIT3: Deleting the content of ~/.semanticdb and reparsing all includes did the trick. I still need to disable the site-wise init files but as this is not related to CEDET I will close this question (the question related to the site-wise init files can be found here).
You need to change your init file so it will perform loading of CEDET only once, not in the hook that will be called for each .h/.hpp/.c/.cpp files. You can change this config as the base, and read more in following article.
The problem that you have is caused because Semantic is trying to analyze header files, and when it tries to open them, then its initialization routines are called again, and again...
The first problem was solved by correctly configuring CEDET which is discribed on Alex Ott's homepage. His answer solves this first problem. The config file specified in his answer is a great start for a nice config; I have used the very same to config CEDET for my needs.
The second problem vanished once I updated CEDET from 1.1 to the bazaar (repository) version, which is explained here and in Alex' article. Additionaly one must delete the content of the directory ~/.semanticdb (which contains the semantic database and was corrupted I guess).
I'd like to thank Alex Ott for his help and sticking with me throughout my journey to the solution :)
Let's assume I want to change something in the 000F5344 address of an executable. How do I go about it?
#Pablo Santa Cruz provides an excellent way, but in C. If you prefer to go pure C++, here's how:
Open file: fstream::open (remember to use the binary flag)
Set the put pointer position: fstream::seekp
Write data at the put pointer position: fstream::put
Close file: fstream::close
This is by no means better than the C version though.
Four steps solution follows:
Open the file with binary flag (use fopen).
Move to the address (offset) (use fseek).
Write your data (use fwrite).
Close the file (use fclose).
Use google to get help on the four mentioned functions calls. Will also work in C.