Using native libraries for application development
#1
Using native libraries for application development
One of the goals I have this year is to write some example programs utilizing some of the more esoteric libraries of IRIX. This is a threefold goal:

1. Native libraries are being RE'd here and there by me and others. Along with this will be the opportunity to document how they work to the best of our knowledge. 

2. Providing sample programs and reference material will inspire others to write native library programs. 

3. As a result improved performance and application behavior will be had as there will be as the applications will be able to utilize native code. 

Some of the potential libraries for this are libdisk, libfam, and maybe dmedia. The last one has a lot of public documentation and the middle one is open source both MIT and GPL (I RE'd the first version) but good luck finding how to do anything with any of them beyond what's out there. Not sure 100% what the final product will look like but as I was already REing libdisk (I haven't touched the project in months but it is not abandoned) it is a good opportunity. I found trying to RE the header to be difficult without knowing what the use cases were for the protos. 

Libdisk being a FOSS product will allow us to improve the handling for media and also for my mount(1) code to actually make sense!

I'm the system admin of this site. Private security technician, licensed locksmith, hack of a c developer and vintage computer enthusiast. 

https://contrib.irixnet.org/raion/ -- contributions and pieces that I'm working on currently. 

https://codeberg.org/SolusRaion -- Code repos I control

Technical problems should be sent my way.
Raion
Chief IRIX Officer

Trade Count: (9)
Posts: 4,240
Threads: 533
Joined: Nov 2017
Location: Eastern Virginia
Website Find Reply
02-19-2024, 03:29 AM
#2
RE: Using native libraries for application development
If possible, with things like Libdisk and dmedia, I think it would be cool to add GUI support for more external drives that have removable properties. I've always found the operating system's limited support of removable SCSI media to be really irritating. There were a lot of removable disks in the day and it be cool to support more stuff via custom icons and usability at the desktop level with eject and insertion supported correctly, without becoming confused. It would also be cool to have better floppy support than what's there as well! Given that a lot of these drives are either somewhat self documenting with the SCSI standard or you could probably read Linux source code to figure out the nuances of how to use a lot of these different drives perhaps that's how we could add support for things like SYQUEST, JAZ, PCMCIA ATA FLASH over SCSI, more optical standards?

Or perhaps the ability to add file system support for more recent versions of file systems like newer UDF support (I mean a more recent standard/implementation than irix has, that other modern OSes use on DVD-RAM media...I've had major interoperability issues), exFAT, and support for DVD-RAM FAT32 automation and GUI support and even DVD-+R/RAM packet writing would be cool!

It just seems to me, and maybe I don't have enough experience if anyone can correct me, that you have to follow a very strict formula and file system requirements to get the Dmedia subsystem to work nicely without having some sort of problem with a lot of removable media & floppy media for PC/Mac interaction.

So some skeleton source code with compilation info and icon examples would be really cool. it's still pretty easy to find SCSI hardware that can do removable optical media that is rewritable. The documentation on some of the specifics is a little scarce but at least if we understood the subsystems involved we could independently research the rest that's device specific.

I know that zip drive support could be better than it is, and of course ZIP did appear at 250 MB that I don't think is supported well.

I know the things I'm talking about are very complex. But sample code could at least start in where do we put information about the drive, how do we inform the operating system about the various statuses and modes, what hooks do we need to implement from the operating system when the drive has a status update or some form of media change, basically how does a simple drive implementation work? And the OS stubs available to link that information into.

I've just seen issues where, as an example, the media demon doesn't understand when media has been ejected and therefore when you insert it it just freaks out. Things of that nature you think would just work but I've had issues with. Obviously it was a simple implementation made to work with very specific drives, they kind of told you this. But there are other removable SCSI drives out there and it be nice to have a more robust base that actually has the chance of handling them.

I also have an external PCMCIA ATA flash adapter to SCSI implementation, most are limited to 2 GB per flash module, but a lot of them can use CF adapters so it makes them pretty usable. If you combine that with a FAT32 file system and suddenly you have a really easy way of getting files back-and-forth on flash media instead of on optical between a modern operating system and a SGI machine.

It would be really nice to see the graphical desktop handle those things with grace versus just freaking out. I assume that these libraries are involved in that plus a little more.

ALso while thngs like ZuluSCSI are great, from what I understand they don't actually work well as a removable live data exchange mechanism, like like how one might use a USB flash drive. They're not designed to be removed while everything is running so you can't just put the SD card in have the OS detect the insertion of the card read the file system and supported Wright files to it then say you're going to eject it and then just remove the card and slip it into a modern machine. From what I understand that make of usage is totally unsupported both in hardware and software. I kind of feel that we need to go towards that kind of thing versus total in place emulation that never undergoes removal. I guess the accepted answer is you're supposed to use a network on the machine to get data on and off. But outside of older SSH support and raw FTP there isn't much else available these days given the change of standards that tap since then. I would feel better putting my machines away with removable drives installed then I would relying on remote connection techniques over ethernet, outside of basic FTP of course.

If that gives you any ideas for small utility apps then that sounds like something I'd be interested in seeing.
weblacky
I play an SGI Doctor, on daytime TV.

Trade Count: (10)
Posts: 1,716
Threads: 88
Joined: Jan 2019
Location: Seattle, WA
Find Reply
02-19-2024, 04:10 AM


Forum Jump:


Users browsing this thread: 1 Guest(s)