Following up on the "How do I code and compile an Amiga application?" question, which development library is required to boot an Amiga application from a floppy disk?
Update: (2012-04-10) To consider the question solved, I have edited the title and body to focus only on the library. Still missing are boot from floppy deployment tools that can be asked in another question.
Detailed description of how to write boot blocks on floppies
You'll need to learn how to use trackdisk.device. I strongly advise not bypassing trackdisk; the requirements to read floppies are tricky and you have to know the allowed mechanical variances; the trackdisk floppy code is really, really good and deals with errors better than anything anyone else did. Published books on how to "code at the bare-metal level" for the Amiga (and in particular the book on using the floppies directly) have so many errors and failed assumptions that my copy had a forest of stickies marking errors.
Note bene: I was the person at Commodore who totally rewrote trackdisk for AmigaOS 2.0.
If you're talking a normal AmigaOS application, you'd have a startup-script file on the disk to boot the disk and start the application (plus minimal set of AmigaOS files), and an icon/executable to start it if the Amiga booted off another disk or HD. Hunt around, and search for info on making a bootable disk for the Amiga.
Related
I'm a first year grad student trying to write an Operating System from scratch as a side project. I've read the Linux Programming Interface, Modern Operating Systems 4th edition, a bunch of articles on OSdev wiki's, and anything I can find on Google, but I'm having a tough time finding what I should be doing next after writing a simple bootloader, and a kernel that can take user input and display it back onto the screen.
I have a feeling that I need to create some drivers that interact with the file system and memory, but I'm not entirely sure. I'm trying to work my way up with just physical memory and one process running "kernel" for right now. I'll worry about virtual memory (pagging) and multi-processes later. If anyone can give me some kind of direction or better understanding of what happens when the kernel is finally put into memory, that would be great.
Thanks.
I would like to point a resource that will be of great help for you to understand this stuff in real details. One of the great and evolving resource that is being maintained on git.
https://github.com/0xAX/linux-insides/tree/master/Booting
I'm using a commandline tool to do some processing on a file. The thing is that this file should not be stored on disk (security reasons). So I was wondering whether it's possible in Windows to use a part of memory as a virtual file that is accessible bu the commandline tool as if it was a real physical file.
Yes, it's possible with things referred to as "ramdisks" usually. What's the best ramdisk for Windows? over at superuser.com has some links.
Have you written the command line tool yourself? If so, you can simply allocate a section of memory to your program and use it in your processing. There's little reason to trick the app into thinking it's using a file on a physical disk. The specifics on how to do so depend on what language your app is written in.
If not, you'll need to create a RAM disk and tell the program to use that. Using a RAM disk on Windows requires third-party software; a comprehensive list of options is available here on Super User.
Note, though, neither using a RAM disk nor storing all of your data in memory will make it more secure. The information stored in RAM is just as accessible to prying eyes and malicious applications as data that is saved on the hard disk. Probably more so than data that has been deleted from the hard disk.
If you need a ready to use application, there are several ramdisk applications (including free ones) on the market, and then your question here is offtopic. If you need to do this in code, than one of our virtual storage products (SolFS, CallbackDisk, Callback File System) will work, and Callback File System has a sample project that stores files in memory.
If you're using .NET, you might look into MemoryStream.
Note Cody Gray's answer though, which is only too true insofar as having something in memory does not guarantee that it can't be compromised. Though opinions differ on this subject. Most people would argue that writing to disk is even less secure, especially in the age of wear-levelling where controlling what is deleted and what is not is practically impossible.
RAM has its own disadvantages, but on the positive side, what's gone is gone :-)
I'm concerned about the dangers of using memory-mapped IO, via CreateFileMapping, on FAT filesystems. The specific scenario is users opening documents directly from USB sticks (yeah, you try and ban them doing this!).
The MSDN Managing Memory-Mapped Files article doesn't say anything about file system constraints.
Update
I didn't have any real reason to be concerned but a vague feeling that I'd read about problems with them at some point (my career spans over 25 years so I have a lot of vague depths in my memory, all the way back to 8-bit micros!). The issue of whether or not they should be supported is pretty important for me to recommend so I wanted to ask if anyone could corroborate my concerns. Thanks for putting my mind at rest.
Memory-mapped files is one of my favorite features. It's absolutely no danger. It's one of the base extremely optimized Windows I/O features. If one starts an EXE or load indirect a DLL it is implemented internally as memory-mapped file mapping.
It is supported on all types of file systems including FAT.
By the way atzz say that memory-mapped files are allowed on network drives. I can add it is not only allowed, but it is strictly recommended to use memory-mapped file also with files from network. In the case the I/O operation will be cached in very good way, which is not done with other (C/C++) I/O.
If you want that the EXE will not crash if you open it from the CD or network one can mark Program Executable with one bit in the header (linker switch /SWAPRUN see http://msdn.microsoft.com/en-us/library/chzz5ts6.aspx). There are no option for documents opened from USB stick.
But what exact problem do the users have? Do they don't use "Safely Remove Hardware" Icon? Then they have to learn to do this exactly like they have to learn to not switch computer power, but shutdown the computer properly.
Could you explain why you find dangers to use memory-mapped files, and in what situations you have problems and is usage of other I/O operation has no such problem?
Yes it does. It even supports mapping of files on CDFS or on network drives. What is the source of your doubts?
I'm developing a commercial project on an ARM based embedded board with a custom Linux kernel on it, using Ruby. Target workspace of the project and the device is a closed-environment, no ethernet, inernet, I/O devices etc... I want to protect my code/program so that; it'll only work on the specific machines I let (so; people cant just copy and paste my code/program on to their embedded boards and run it w/o permission). This can probably done with the machine's MAC address tho; I don't have any experience on the subject. I guess, just a simple if(device.MACAddr == "XX:XX....XX") wouldn't be depandable (not to mention people can just easily delete the check from my code). I can't use some ruby obfuscators, which I found thru google, beacuse; the device doesnt run ruby-external-C-libraries or such stuff, only pure ruby code.
So; what are your suggestions, what type of approach should I take?
you can't really protect it, its hard enough protecting native code! and even then that basically fails if someone really wants to copy the software.
basically do very little if anything to secure it, its mostly wasted time and effort
This is isomorphic to the problem of DRM. You're giving a person both a lock and the key to that lock, and trying to stop that person from using the key in a way you don't like.
Therefore, I suggest using the same methods that other DRM users do: put your terms in the license, and sue them if they violate it. You need to use the law to enforce the other terms of the license, anyway.
I am trying to investigate the behaviour of the Windows Kernel with respect to Memory Mapped Files / Virtual Memory. Specifically I am interested in determining how frequently the contents of a memory mapped file are flushed (by Windows) to disk and what criterion Windows uses for deciding it is time to do so.
I have done a bit of research online and, apart from the MSDN which deals more with the 'hows and whys' rather than detailing the internal workings, there doesn't appear to be much information. If anyone can point me to any articles or has looked into this before and has some insight I would welcome it.
Thanks.
I suggest reading Microsoft Windows Internals by Mark Russinovich and David Solomon, in fifth edition also with Alex Ionescu.
Memory mapped files are controlled by the modified page writer in the kernel - they're flushed whenever the memory that backs the page needs to be re-used (so it can happen under memory pressure).
The system also keeps track of the number of dirty pages and writes them after a threshold is reached.
You can find more information about in this article about Windows memory management changes for Windows Vista - it doesn't directly answer your question about how the memory manager treats modified pages but you can infer some of the details based on the information in the article.
The internal workings are an implementation detail and subject to change. They're not documented anywhere because Microsoft doesn't want you relying on the details.
I've got to ask: Why do you care? If you have hard real-time requirements, Windows might not be the OS for you...
I would suggest that you obtain a copy of
Microsoft® Windows® Internals
Fourth Edition: Microsoft Windows Server 2003 Windows XP and Windows 2000
There are pdfs floating around in the cyber cloud.
This is the book done by the "sysinternals" crowd who have written some very good windows utils over the years.
http://www.microsoft.com/technet/sysinternals
You will have to read the chapters on
Memory Management
Storage Management
Cache Manager
File Systems
They don't directly address your concern but if you manage to read, digest and grasp the very techical paragraphs you can work it out yourself. However if you can predict why Windows does what it does "You are a better man than most".
Happy brain freeze reading that lot.