I’m hoping to port an application to open vms using HP C++7.3, but at the minute just trying out a few examples to establish if it's a potential way forward but a bit stuck. Being completely new to open vms it's being a lot of fun so far.
For starters I've not got very far building boost as a whole, after some googling I found a few mentions of people having dcl scripts to build boost but no actual scripts. I don’t suppose anyone has any or can pint me to some. I ‘only’ need asio and threading.
Currently I’m just trying to compile the asio chat examples. And as I said I’m completely new to VMS and the compiler, I managed to get a few things to compile but now get a “could not open source file "sys/select.h"’, a bit of googling suggests I may need to have an HP porting library installed or maybe I’m just missing an prepocessor directive to include the correct code, can’t see anything obvious in socket_types.hpp to set?
Any pointers in the right general direction would be gratefully appreciated.
No answers since the questio is too open ended and in a realm I know little about.
Just some thoughts.
Select can be provided by the OpenVMS TCPIP services (aka UCX), or other TCP stack.
At the dcl prompt try: $ HELP TCPIP_Services Programming_Interfaces Socket_API
Async programming on OpenVMS is typically 'event driven'.
Google for SYS$QIO and AST
There is a public access OpenVMS system which holds 'NOTES FILES' (pre-cursor to web-forums)
Try TELNET to EISNER.DECUS.ORG and you'll get sign up instructions.
Once you are in find your way to the PORTING_TO_VMS conference
Once in the NOTES conference you can issue the command DIRECTORY or DIR/TIT=xxx
Unfortunately there is not topic for select, but you can find some interesting
reading using NOTES> SEARCH "select(" followed by repeated SEARCH commands)
( $ NOTES ... OPEN PORT ... SEARCH "select(" ... SEARCH [] ... SEARCH ... )
The PERL folks did an admirable job getting open stuff to work on OpenVMS.
Good luck!
boost library on OpenVMS can be used directly from headers.
I remember one thing to make sure was that BOOST logical is defined concealed, so the relative-includes work.
Related
I'm building a barebones Notepad-styled project (console-based, does not have a GUI as of now) and I'd like to track, display (and later use it in some ways) the number of times the console application has been launched. I don't know if this helps, but I'm building my console application on Windows 10, but I'd like it to run on Windows 7+ as well as on Linux distros such as Ubuntu and the like.
I prefer not storing the details in a file and then subsequently reading from it to maintain count. Please suggest a way or any other resource that details how to do this.
I'd put a strikethrough on my quote above, but SO doesn't have it apparently.
Note that this is my first time building such a project so I may not be familiar with advanced stuff... So, when you're answering please try to explain as is required for a not-so-experienced software developer.
Thanks & Have a great one!
Edit: It seems that the general advice is to use text files to protect portability and to account for the fact that if down-the-line, I need to store some extra info, the text file will come in super handy. In light of this, I'll focus my efforts on the text file.
Thanks to all for keeping my efforts from de-railing!
I prefer not storing the details in a file
In the comments, you wrote that the reason is security and you consider using a file as "over-kill" in this case.
Security can be solved easily - just encrypt the file. You can use a library like this to get it done.
In addition, since you are writing and reading to/from the file only once each time the application is opened/closed, and the file should take only small number of bytes to store such data, I think it's the right, portable solution.
If you still don't want to use a file, you can use windows registry to store the data, but this solution is not portable
Is there a Library that implements XDebug's DBGP in C/C++?
I'm interested in wrtting debugger and if such library exists will save me a lot!
I want to add the debugger to my editor coded in C++ Language but it is an editor for PHP Files.
None Exists. There was one from GSOC (App not a library) but I cannot take time to read and convert to my needs plus its written for wx2.8
So I will roll a class to Just glue up with my Editor
Edit
I ended using that one as I said.
Inside there is buggy libDBGp but I will fix it myself huh!
If you are interested its here (thanks to GitHub)
There are a few GDB based libraries that help debugger frontend writers like libgdb. DBGP is a very stupid and protocol with very small feature set - not enough for debugging C++.
For windows there is nothing like this. You can read the PDB database but it's pretty difficult. I spend a week to see how far i can get but wasn't very successfull. only the theory is easy. It might be better to write a frontend for the command line debugger windbg just like in the old days where you had to do this for GDB.
What does it take to build a Native Client app from scratch? I have looked into the documentation, and fiddled with several apps, however, I am now moving onto making my own app and I don't see anything related to creating the foundation of a native client app.
Depending on the version of the SDK you want to use, you have a couple of options.
Pepper 16 and 17: use init_project.py or use an example as a starting point
If you are using pepper_16 or pepper_17, you will find a Python script init_project.py in the project_templates in the SDK. It will setup up a complete set of files (.cc, .html, .nmf) with comments indicating where you need to add code. Run python init_project.py -h to see what options it accepts. Additional documentation can be found at https://developers.google.com/native-client/pepper17/devguide/tutorial.
Pepper 18 and newer: use an example as the starting point
If you are using pepper_18 or newer, init_project.py is no longer included. Instead you can copy a very small example from the examples directory (e.g., hello_world_glibc or hello_world_newlib for C or hello_world_interactive for C++) and use that as a starting point.
Writing completely from scratch
If you want to write your app completely from scratch, first ensure that the SDK is working by compiling and running a few of the examples. Then a good next step is to look at the classes pp::Module and pp:Instance, which your app will need to implement.
On the HTML side, write a simple page with the EMBED element for the Native Client module. Then add the JavaScript event handlers for loadstart, progress, error, abort, load, loadend, and message and have the handlers write the event data to, e.g., the JavaScript console, so that it's possible to tell what went wrong if the Native Client module didn't load. The load_progress example shows how to do this.
Next, create the manifest file (.nmf). From pepper_18 and onwards you can use the generate_nmf.py script found in the tools/ directory for this. If you want to write it from scratch, the examples provide examples both for using newlib and glibc (the two Standard C librares currently supported). See hello_world_newlib/ and hello_world_glibc/, respectively.
If you haven't used a gcc-family compiler before, it is also a good idea to look at the Makefile for some of the examples to see what compiler and linker flags to use. Compiling both for 32-bit and 64-bit right from the beginning is recommended.
Easiest way is to follow the quick start doc at https://developers.google.com/native-client/pepper18/quick-start, in particular steps 5-7 of the tutorial ( https://developers.google.com/native-client/pepper18/devguide/tutorial ) which seems to be what you are asking about.
I've recalled using little 'filesystems' before that basically provided an interface to something else. For example, I believe there was a GMail filesystem that created an entry in My Computer and could be used like any other drive on your local computer. How can I go about implementing something like this in C++?
Thank you!
Try Dokan. It's like FUSE, except for Windows. I think there are certain limitations to namespace extensions, like they cannot be accessed from the command line, but I'm really not sure as of now.
Writing an actual file-system involves writing a driver; which means kernel-mode code (scary stuff) and paying for getting the IFS DDK. (edit: looks like they don't charge for it anymore)
What you probably want is a “namespace extension”.
Try this: The Complete Idiot's Guide to Writing Namespace Extensions - CodeProject
This may be a starting point to extending NTFS in the way that the GMail filesystem used to do: Windows NT reparse points.
The GMail Filesystem is just the name given; it is not any filesystem as such. It is just a namespace extension for Windows Explorer that links with the GMail account of yours!
I dont know exactly what you are trying to do, but in anyway, I believe, the following link will be of some use to you:
http://msdn.microsoft.com/en-us/magazine/cc188741.aspx
Just as a reference: virtual drives can be created using our Callback File System product, which is a supported, documented and maintained solution.
I was thinking of this too, perhaps some example code ? (email me if i forget plz ;p doin sdk now)
I'm thinking of a similar filesystem that would plug in as a driver and allow dynamic 'soft raid' on larger files mostly by putting them on more than one disk, perhaps some compression options and 'smart' filters to toggle usage in high disk space low usage and other situations more effectively, with status controls and indicators as a normalish program too
Seems like I would load the driver kit,
then i want the file writing event, and am mostly replacing fopen and similar functions automatically as an intermediate driver with a little windows network driver experience
I also heard good things about developing on a virtual machine for less crashing and more debugging
Also perhaps more metainfo on some or all files, including files in special folders with options too, including maybe both fast and simple (obfuscated and/or symmetic key) encryption options on folder, specified, all, letter, etc, or whatever, or the slower version and maybe integrated and optional (also profitable) online cvs-like diff style backups that mostly target changes to hot files for online backup at intervals and prices, mostly perhaps with matching keyboard events and might even be useful as simply a keylogging online backup service that is reasonably secure too
while avoiding common files like windows files or the normal stuff in the 'programs' directory that can be copied easily with pirate tools, unlike all of your documents.
I'm trying to write a chat client for a popular network. The original client is proprietary, and is about 15 GB larger than I would like. (To be fair, others call it a game.)
There is absolutely no documentation available for the protocol on the internet, and most search results only come back with the client's scripting interface. I can understand that, since used in the wrong way, it could lead to ruining other people's experience.
I've downloaded the source code of a couple of alternative servers, including the one I want to connect to, but those
contain no documentation other than install instructions
are poorly commented (I did a superficial browsing)
are HUGE (the src folder of the target server contains 12 MB worth of .cpp and .h files), and grep didn't find anything related
I've also tried searching their forums and contacting the maintainers of the server, but so far, no luck.
Packet sniffing isn't likely to help, as the protocol relies heavily on encryption.
At this point, all my hope is my ability to chew through an ungodly amount of code. How do I start?
Edit: A related question.
If your original code is encrypted with some well known library like OpenSSL or Ctypto++ it might be useful to write your wrapper for the main entry points of these libraries, then delagating the call to the actual library. If you make such substitution and build the project successfully, you will be able to trace everything which goes out in the plain text way.
If your project is not using third party encryption libs, hopefully it is still possible to substitute the encryption routines with some wrappers which trace their input and then delegate encryption to the actual code.
Your bet is that usually enctyption is implemented in separate, relatively small number of source files so that should be easier for you to track input/output in these files.
Good luck!
I'd say
find the command that is used to send data through the socket (the call depends on the network library)
find references of this command and unroll from there. If you can modify-recompile the server code, it might help.
On the way, you will be able to log decrypted (or, more likely, not yet encrypted) network activity.
IMO, the best answer is to read the source code of the alternative server. Try using a good C++ IDE to help you. It will make a lot of difference.
It is likely that the protocol related material you need to understand will be limited to a subset of the files. These will contain references to network sockets and things. Start from there and work outwards as far as you need to.
A viable approach is to tackle this as a crypto challenge. That makes it easy, because you control so much.
For instance, you can use a current client to send a known message to the server, and then check server memory for that string. Once you've found out in which object the string ends, it also becomes possible to trace its ancestry through the code. Set a breakpoint on any non-const method of the object, and find the stacktraces. This gives you a live view of how messages arrive at the server, and a list of core functions essential to message processing. You can next find related functions (caller/callee of the functions on your list).