frank.lukas wrote:What about integrate mke2fs in the Tool with no need of an LNX or RAW partition ?
ThorstenOtto wrote:frank.lukas wrote:What about integrate mke2fs in the Tool with no need of an LNX or RAW partition ?
That tool is not a harddisk driver or something, and it also does not partition it. You will need a recognizable partition first. And afaik the mint kernel always requires a LNX or RAW partition for ext2fs, otherwise it would try to access it as FAT.
Also the parameters for mke2fs are very different than for fat, there is no such thing as numbers of fat, sectors/cluster etc. Dunno wether it makes sense to integrate it. But if you look at the source you will notice that it is actually very simple, so you might as well write a similar program for mke2fs. All the actual work is done by a commandline tool anyway, gemkfatfs is just a gui frontend for it.
ThorstenOtto wrote:It has 3 versions, one that uses that kernel32.slb, one that should work without it, and another one for coldfire. The first 2 were compiled for plain 68000.
Neurotoxic wrote:when using the version that is supposed to work without kernel32.slb I've got an error message that kernel32.slb was missing
Neurotoxic wrote:I copied the *.slb files into my slb folder.
Neurotoxic wrote: the third time it worked Just don't ask me why.
ThorstenOtto wrote:Ok i checked it once again, removing all ocurrences of kernel32.slb, and activating a debug trace in Aranym before starting the app. It does not try to Slbopen kernel32, not does it complain. What i could imagine is that you started the other version first, and that gemma.slb from that version was still in memory. I think mint immediately removes it when the last application using it exits. Maybe MagiC behaves differently there, by keeping it alive until the memory is needed otherwise.
Neurotoxic wrote:In the first test I just didn't replace the gemma.slb and I just renamed the kernel32.slb. That was wrong, I think.
Neurotoxic wrote:Could you explain to me what's the difference between the two versions? Which one is better? Or isn't there any great difference for a normal user that I have to care about?
ThorstenOtto wrote:The main difference is that one use kernel32.slb to make TOS/MiNT calls, while the other calls them directly like a normal application would. As user you should not notice any difference. And i think that kernel32.slb was mainly done as a proof of concept. The main purpose of such a shared library is to save memory when more than one program needs it. However in this case, calling the functions defined in the shared lib takes as much space as calling the TOS function directly, so all it does it add a little overhead.
Neurotoxic wrote:Thank you very much for bringing us such a nice little tool!
ThorstenOtto wrote:Thank you very much for testing Now i only have to convince Alan to merge the changes, Vincent to build and upload the libraries, and Miro to make the needed changes to the build system of freemint
Users browsing this forum: No registered users and 5 guests