I need to retrieve information about a hard disk and am using the statfs function to do so.
When your computer displays free space on the HD, does it use "free blocks" or "free blocks available to unpriveleged user"?
Does statfs work with SSDs?
How would the "path" to the main hard drive be stored? On windows it's generally C:, but I am new to OSX.
The man pages don't seem to provide a very comprehensive look of how statfs works.
Mac OSX Snowleopard using C/Objective-C. Xcode 3.2.6
1) Look at man statfs; the structure returned has both counts available (f_bfree and f_bavail).¹
2) Yes, it works on filesystems, not hard drives, so it doesn't matter what type of hard drive (if any) the filesystem is on.
3) /
¹ In case the first part of the question was not about what statfs returns but what “the computer” displays in general, I guess the answer depends on the program used to display the amount of free space. Compare the two values returned by statfs to those displayed by the program you are interested in.
Related
I am specifically talking about physical RAM, I do not want virtual memory stats to be included. I am on Mac OSX Snow leopard but would prefer a solution that would work on ALL OS X platforms (i.e. Lion). I am using Objective-C but solutions in C would also obviously be valid.
It sounds like what you want to be able to report is the same stuff that the command line utility vm_stat displays? If so then it's probably easiest just to check out its source code, which is amongst the stuff Apple provide as open source.
The relevant code is at the bottom; it all falls back on a call to host_statistics64, which appears to be defined via mach/mach.h. A quick search of my machine shows it also to be available (or, at least, defined) in iOS.
Use this to return the amount of physical RAM of the system in bytes as an unsigned long long integer:
-(unsigned long long)getPhysicalMemoryValue{
NSProcessInfo *pinfo = [NSProcessInfo processInfo];
return [pinfo physicalMemory];
}
Is there a utility that will show me a program's current memory contents? Like a hex dump of the entire memory being used by the program? Thanks.
My utility, Bit Slicer, which runs on 10.6 or later can do this for regular applications.
1) Run the program and select a target process.
2) Go to Tools -> Dump All Memory... This will save all the current readable memory in a directory with a bunch of files each indicating a particular memory region and a file that merges everything as well. These files can then be viewed with a hex editor.
3) There's also the real-time memory viewer in the Memory menu for looking at a particular spot.
Dmalloc - Debug Malloc Library
This program came with OS 10.6 but it seems to have disappeared with OS 10.7 (which has many, many, many ... programming complications). Excluding 10.7 regrets, Dmalloc is wonderful way to examine every memory allocation.
Ah ha...
Mac OS 10.7 provides Menu-Product-Profile. I have not investigated fully used it, however, I recognize the Dmalloc icon within it.
I want to develop a VGA graphics driver (for Linux(Ubuntu)) with support for the basic primitives such as putpixel, drawline, fillrect and bitblt. I want to do it in protected mode.
I´ve been googling for a week and the following four links are the best I have found:
http://www.brackeen....vga/basics.html
http://www.osdever.n...VGA/vga/vga.htm
http://bos.asmhacker...sing%20bios.htm
Unfortunately, the first one uses a BIOS call so I cannot use it. The second link has lots of information on the VGA registers but no examples showing how to make them work together. The third example is a example to switch in 13h mode but i've tried it and nothing happened. Can you guys give me a hint? Thanks in advance!
--Vincenzo
my code at http://bos.asmhackers.net/docs/vga_without_bios/snippet_5/vga.php
works fine if you are in 32bit mode with full hardware access. Unfortunately I doubt that any Linux variant will let you directly access the VGA ports. I'm not sure how you develop this driver, but if you made sure that you have full access to the VGA ports it should work. In my example code I only switch between mode 0x03 and 0x13, but in the folders above you'll be able to find port values for most other common VGA modes, as well as C code to do the switch if you prefer that.
Christoffer code include files are found BOS operating system source code like text.inc and font8x16.inc
http://bos.asmhackers.net/downloads.php
This is coming many many years later but I think it's still very relevant and if somebody is struggling I hope they can find it useful.
First of all, it is completely possible to configure VGA only using registers without interrupts, as hard as it may be. A useful resource about registers and how to configure them can be found here, but unless you have a ton of time to spare to learn how to properly do all of it, move to the following section.
If you wish to really learn how to do it, I suggest going through with the documentation provided earlier. However, some of it is already done!
Chris Giese did a great job demonstrating exactly how to do this for MS-DOS system, and while you may think that doesn't help you, it really does.
Chris's code can be found here. If you want another useful codes check here as well.
Now, while it only works for MS-DOS it's actually easy to convert to other systems. The code already contains all data needed to configure the registers in many different modes. And that's the part that saves you a ton of time going through documentation.
The code uses functions outportb, inportb, which are MS-DOS functions, to write/read single byte to/from a port. Therefore, you have to redefine these functions to read/write for your own system. Redefinition complexity depends on the system you operate on.
In addition, you will also need to provide means to write to physical memory region between 0xA0000-0xBFFFF which corresponds to standard VGA memory area. Once you have that allocated, you need to also redefine the functions pokeb pokew peekb which will help you output things (text or pixel data) on the screen.
One last note: the code is already defined to work with many different modes including both text and display modes.
This is a multi-part question to SO folks before I engage more with core team.
Summary: On OS X, pdfs should be created using quartz, not postscript. Files are smaller, anti-aliased better, OS fonts including opentype are readily available, encoding is less painful, overall I think it’s a better device. On other platforms, it would be reasonable to use cairo, again a more modern pdf-writing device.
Consider the behavior of the png() device. Although it is allegedly slated to move out of x11.R, it handles c("cairo", "Xlib", "quartz") with a default (options("bitmapType")) set by zzz.R (quartz if capabilities("aqua"), cairo if available, Xlib otherwise). PDF needs to behave the same way, so that in Sweave (or babel or whatever) my pdf figures can be generated using the appropriate device.
My Sweave png patch works because png() takes care of getting the device option. An earlier version of the patch (which I still use) flips the device in Sweave, but I was smacked down for this and I know it’s sort of the wrong the place to do it.
There’s some alias cairo_pdf() (also in x11.R) that probably should not be there, shouldn’t that be merged into a device-switching pdf() ?
One approach is to add option "pdfType", which in turn I think should probably be more general – there is already a default device, it’s just that pdf() ignores it! I’m especially wary of introducing new global options because they are more likely to be rejected by core.
I don't think you'd need to implement a device driver. Mostly it sounds like you want to alias pdf() so that it calls quartz() or cairo() as appropriate. The quartz() device already supports PDF output to a file (among others) on OS X.
For your own personal use (I doubt this would find its way into core) you could just alias pdf() to take the appropriate action on each of your platforms and bring it in as a package or in your Rprofile.
pdf.orig = pdf
pdf = function(...) {
// Insert code here
}
Would it be possible to take the source code from a SNES emulator (or any other game system emulator for that matter) and a game ROM for the system, and somehow create a single self-contained executable that lets you play that particular ROM without needing either the individual rom or the emulator itself to play? Would it be difficult, assuming you've already got the rom and the emulator source code to work with?
It shouldn't be too difficult if you have the emulator source code. You can use a method that is often used to store images in c source files.
Basically, what you need to do is create a char * variable in a header file, and store the contents of the rom file in that variable. You may want to write a script to automate this for you.
Then, you will need to alter the source code so that instead of reading the rom in from a file, it uses the in memory version of the rom, stored in your variable and included from your header file.
It may require a little bit of work if you need to emulate file pointers and such, or you may be lucky and find that the rom loading function just loads the whole file in at once. In this case it would probably be as simple as replacing the file load function with a function to return your pointer.
However, be careful for licensing issues. If the emulator is licensed under the GPL, you may not be legally allowed to store a proprietary file in the executable, so it would be worth checking that, especially before you release / distribute it (if you plan to do so).
Yes, more than possible, been done many times. Google: static binary translation. Graham Toal has a good howto paper on the subject, should show up early in the hits. There may be some code out there I may have left some code out there.
Completely removing the rom may be a bit more work than you think, but not using an emulator, definitely possible. Actually, both requirements are possible and you may be surprised how many of the handheld console games or set top box games are translated and not emulated. Esp platforms like those from Nintendo where there isnt enough processing power to emulate in real time.
You need a good emulator as a reference and/or write your own emulator as a reference. Then you need to write a disassembler, then you have that disassembler generate C code (please dont try to translate directly to another target, I made that mistake once, C is portable and the compilers will take care of a lot of dead code elimination for you). So an instruction of a make believe instruction set might be:
add r0,r0,#2
And that may translate into:
//add r0,r0,#2
r0=r0+2;
do_zflag(r0);
do_nflag(r0);
It looks like the SNES is related to the 6502 which is what Asteroids used, which is the translation I have been working on off and on for a while now as a hobby. The emulator you are using is probably written and tuned for runtime performance and may be difficult at best to use as a reference and to check in lock step with the translated code. The 6502 is nice because compared to say the z80 there really are not that many instructions. As with any variable word length instruction set the disassembler is your first big hurdle. Do not think linearly, think execution order, think like an emulator, you cannot linearly translate instructions from zero to N or N down to zero. You have to follow all the possible execution paths, marking bytes in the rom as being the first byte of an instruction, and not the first byte of an instruction. Some bytes you can decode as data and if you choose mark those, otherwise assume all other bytes are data or fill. Figuring out what to do with this data to get rid of the rom is the problem with getting rid of the rom. Some code addresses data directly others use register indirect meaning at translation time you have no idea where that data is or how much of it there is. Once you have marked all the starting bytes for instructions then it is a trivial task to walk the rom from zero to N disassembling and or translating.
Good luck, enjoy, it is well worth the experience.