Apr 03, 2018 Open DMG Files with 7-Zip. 7-Zip is a lightweight, but powerful compression tool that is free to download. In addition to extracting DMG files, you can use 7-Zip to extract most types of compressed files out there, including ZIP, CAB, ISO, RAR, and WIM, to name just few. Once downloaded, open the DMG. Find PackageMaker.app and open the package contents, then navigate to Contents/Resources. Copy Flat Package Editor.app to /Applications or elsewhere then open it. From this app you can open a.pkg and edit the contents by dragging files out, editing them and dragging them back in, then saving the package. This Site is dedicated to SimPE a Sims 2.package (DBPF) Editor, which can. Body Shop: The Sims 2 Body Shop is a utility that allows you to create and customize Sims with literally millions of possible. The sims 2 package editor. Use Clean Installer to extract the package files from your Sims2Pack files.
- Flat Package Editor Dmg Software
- Flat Package Editor Dmg Download
- Flat Package Editor Dmg Download
- Flat Package Editor Dmg Free
- Flat Package Editor Dmg Software
Flat Package Editor Dmg Software
I was recently involved with a daemon-style Java project that needed a simple installer solution for OSX. We didn’t require a huge amount of sophistication from the installer. So we opted for flat packages. Flat packages are simple, self-contained files that are easy to pass around.
Prior to Leopard (10.5), packages weren’t flat at all. They were bundles, which are just folders that OSX treats in a special way. Bundles contain a variety of files. Package bundles, for example, contain files used as part of the install process such as a bill of materials, the application payload, and a collection of localized resources among other things. Previously, if you wanted to distribute one of these packages, you’d have to put the package inside a DMG or tar it up.
Another interesting thing happened during the evolution of OSX packages. PackageMaker, a wart in the eyes of many developers and source control systems, was officially deprecated and dropped in Xcode 4.6 (and there was much rejoicing :-)). Developers were left with three terminal-based utilities that could be used to build packages – pkgbuild, productbuild, and pkgutil.
For more information on the evolution of OSX packages, I highly recommend reading this MacTech article which goes into the subject in some depth.
pkgbuild
pkgbuild is a tool for creating a very basic, bare-bones component package. The resulting package will contain the payload for a single component. It also supports preinstall/postinstall scripts. And that’s about it.
productbuild
productbuild is a tool for creating a “product archive”, which is kind of like a super-package. I like to think of it as a package of packages. But it’s really so much more. You can customize the UI, as well as explicitly declare installation prerequisites such as the minimum required RAM, OS version, etc. Even JavaScript is supported for some things. If you create apps for the Mac App store, this is the tool you’ll be using to build your packages.
pkgutil
pkgutil is kind of like a Swiss Army knife for packages. With pkgutil, you can rip a package apart and then put it back together again. It doesn’t matter if it’s a product archive or a component package. If it’s a pkg file, pkgutil can work with it. It also provides a number of options for examining package contents and performing tasks like package verification and repair.
I’m going to give a quick overview on how I use these three utilities to build the flat package for our product. This approach can be adapted for your own needs.
Simple Component Packages
If you want to create a very simple package for a single component application, the easiest tool for the job is pkgutil. A complete list of options for pkgutil can be found on the man page. But here are the ones that are important.
--root – This option specifies the location of the source content you want packaged up. This can be a path containing anything. Our own application is Java-based and is nothing more than a folder of JAR files. We simply point --root to the folder containing all of our JAR artifacts.
--component – You can use this option as an alternative to --root. With --component, you’re being a bit more specific by giving pkgbuild the path to a component bundle. This might be an app bundle, a browser plugin bundle, etc. Why would you use this option instead of --root? If pkgbuild knows it’s working with a bundle, it can infer some of the other configuration options it needs, such as package identifier and install location.
--identifier – The identifier is a unique string that identifies your component. The normal convention for the identifier resembles something like a backwards domain. You start with a TLD, then follow that with a company name or developer name, and then follow that with a product name. So an identifier for Roadie Assist (not an iOS or OSX app, but could be someday) might look like “com.shanekirk.roadieassist” (this is indeed the package name on the Google Play store). There’s certainly flexibility in how you name your package IDs. They just need to be unique. But don’t deviate too much from the convention. It’ll only cause confusion.
--version – This is a monotonically increasing number. The idea is that every time you release a new version of the component, you need to increase this value. Otherwise, the upgrade process may fail. If this value isn’t set, pkgutil defaults with a value to 0. (Tip: If your build system keeps track of build numbers, consider using that as your package version. If the whole thing is automated with scripts, you’ll probably never have to think too much about this value again.)
--install-location – This is where you want to place the component on the target system. For instance, if you’ve built an application bundle, you’ll probably want to place it in /Applications on the target machine.
--scripts – Packages support a number of scripts that are invoked during the install process. If you have a script called preinstall, this will be invoked before the component is installed. If you have a script called postinstall, it will be invoked after the component is installed. The --scripts option specifies where you’re storing these scripts. The scripts can be in any language so long as the files are marked executable and have the appropriate shebang indicating the path to the interpreter. If either of the scripts return a number other than 0, Installer assumes a failure occurred and the installation halts.
A typical invocation of pkgbuild might look like so…
For many folks, this may be all that’s needed. From within Finder, you can double click the resulting package and component can be installed without having to do much else. If you would like to customize the UI a bit, allow for a more “componentized” installation, or distribute your application through the Mac App store, you’ll need to use productbuild.
Product Archives with productbuild
Flat Package Editor Dmg Download
Much of what you can do with pkgbuild you can also do with productbuild. But don’t be fooled. Product archives and component packages aren’t quite the same thing. Synthesizing a distribution from a product archive (package created with productbuild), for example, will fail, but doing the same thing with a component package (package created with pkgbuild) works just fine (have no idea what I just said? Don’t worry. You will soon.) With productbuild, you can also customize quite a bit of what the end user sees. If you peruse the man page for productbuild, you’ll find that many of the command-line options you used with pkgbuild are there for productbuild as well. But you’ll also see a few other things mentioned like plugins, distribution files, resource folders, etc.
Regardless of how you created your package, you’ll probably want to update the UI or perform more sophisticated prerequisites checking. To do this you’ll need to create a distribution file.
A distribution file is just an XML file. It’s used to configure both look and feel, as well as behavior, of the package installer. The idea is that you create this file and then use productbuild to create a new package from the old one and the new distribution file. Confused yet? Let’s work through an example.
productbuild example
Let’s assume we have a package called mypackage.pkg kicking around (if you’re reading closely, you’ll notice this is the same package I use as an example above while discussing pkgbuild.). Our goal is to change the title and background image shown to the user. So we need to create a distribution file and modify it to suit our needs. Fortunately for us, productbuild is able to synthesize a skeleton distribution file for us.
Note that this only works against component packages created with pkgbuild. If you try to do this against a pkg created by productbuild, it’ll result in an error. The resulting XML will look something like the following.
So far, so good. Let’s first change our package title. We want the title to be “My Example Application”. Open the distribution XML with your favorite text editor. Within the installer-gui-script element, create a new child element called “title” and set the element’s character data appropriately. It should look something like this.
Now let’s create a new background image for our installer. The recommended size for the background image is 620×418. The background image I’ll be using for this is example is a simple PNG as shown below.
Create a new folder for your installer resources and place the image in there. We’ll call it the file background.png.
Now, let’s add the PNG reference to the distribution.xml. Open the XML file and within the root installer-gui-script element, create a new element called background. Add two attributes, one called “file” that simply names the file and one called “mime-type” that describes the image type. For example, your background element might look like so.
Save your changes. Now we just need to create a new package with our modified distribution file. Using productbuild the command might look like so.
This command produces a new package called myimprovedpackage.pkg that has the new modified background image. If you double click on it with Finder, you should see your new background image, but it should also install the new package just as it did the old one.
For a complete list of everything you can do to a distribution.xml, check out the distribution xml schema reference. You’ll find that there’s a lot of flexibility in what you can do to your packages. There are some things I always do, such as customize the welcome, license, readme pages, run JavaScript as part of the startup validation, and limit install locations to the root volume. But I’ll save discussion of those types of things for a future blog post.
Injecting Files Into Flat Packages
At some point in your journey with flat packages, you’ll find that you can’t get something into the package file that you really think should be there. This might be an extra script or even an Installer plugin (a topic that deserves its own blog entry). Both pkgbuild and productbuild promise to copy content out of the scripts or resources folders, but sometimes they just don’t. So we need to get these files into our package. That’s where pkgutil comes in.
pkgutil allows you to expand a package to a folder structure like so.
This creates a folder called expandedcontent that contains the expanded content of the package. If you explore the folder structure, most of what you see will only make sense if you’re familiar with the structure of the original package bundles. I strongly advise you to read up on the history of the package format I mentioned in the beginning to be effective at shuffling stuff around within these folders.
Once you’ve got things where they need to be, then you can flatten everything again like so.
Conclusion
And that’s it. I realize I glossed over a lot of interesting stuff with regards to the distribution XML file. Experiment with it. I hope to write a followup to expand on some of these topics in closer detail. If you have questions, post them!
Hay folks,
I got something to share:
This is a scan of the main logic board for the DMG 01. I had been wanting an image like this for a while, and decided to make it myself. I started removing components before I had the necessary equipment, so some things aren't as pretty as they could be, but I nit-pick.
My motivation for what became a massive project started when I saw some minor inconsistencies between the only information I could find (which is right here) and what I was seeing while reverse-engineering the poor gameboy you see to the left, but it was more than enough for me to get started. I'll explain more of my motivations later. But now you get to see the fruits of my labor!
Flat Package Editor Dmg Download
(1890 x 1854, 6.13 MB)
Aaaand this is the back. Without the copper sticker of questionable purpose. (I'll have other quandaries some of you may be able to answer later.
(1890 x 1854, 5.82 MB)
Before I go any further, please know this is the first revision. Everything looks right to my eyes, but they may not be as trained as some of yours. Let me know what may need to be corrected.
The biggest thing I wanted when drafting these documents was transparency. I wanted all this to be understandable to someone with only basic understanding of what circuits are and how they work. I'll give a crash course later in this topic on how to read this schematic if you're having troubles.
(The rest of these images are a lot smaller than the photos, but at beautiful 3125 resolution - just so you can thoroughly appreciate the detail)
<smug> This is it, folks. All of it. Everything. All 80 hours of work, plus or minus (I'd rather not think about it). The usefulness of this image is less than the others because it's so detailed. But I must show the detail nevertheless.</smug>
This does give me the opportunity to tell you a little about the prints you're looking at (or whatever they're called in digital format).
Source: The gameboy I dissembled had an early production of the sixth revision of the CPU PCB. I know this because I am only the second owner of this gameboy. The gentleman I bought this from sold me his and his brother's, saying he had gotten his, from the store, soon after his brother had gotten his. His brother's has a revision five. I can spot a few differences between them, but they're small things that shouldn't matter.
Accuracy: The scans I made had some distortion because it didn't lay perfectly flat against the glass. I corrected this in Photoshop by re-distorting the image. I didn't get it perfect - as in: there's a total of 0.4mm of drift in the image, I hope you can deal with that. I did attempt to get things as accurate as I could. The initial draft followed the image to a minimum of 1/20th of a mm. I then went back through and took some liberties with spacing. There are only a couple places that bother me, but I doubt any of you are looking that closely.
Applicability: If you were to make this board as I've shown and soldered all the bits to it, would it work? Yes. Would it fit in your DMG case? Yes, but it'd be a little snug. Why did I do this? Haha, silence... I mean, science!
This is the more reasonable 'fully loaded' version. This shows just the traces of the front (in red), back (in blue), and silk screening (in white). The font isn't the same, because there's a level of absurdity even I can anticipate. I didn't split as many hairs with the silk as with the traces (the red/blue bits) - the purpose of this image is to cross reference the location and orientation of the components because I left the silk out of the rest of the plans for clarity. If you're not sure what the symbols, abbreviations, or values are - look for a crash-course later in this topic.
This is for general reference. Just the traces as seen from the front. I should note that the front is red, and the back is shown all 'x-ray' like in blue.
Because I know not everyone has spent the hours staring at this that I have, I anticipate some of you will still find the previous plan confusing, or only happen to care about one side of the board for some reason. This is the front, the whole front, and nothing but the front...
... and the back. This image shows the back as it is viewed from the back - not inverted as it is in the rest of the plans.
OK, now for some more technically relevant information. There are three major things I wanted to communicate with these plans. This is part of one of them: How power enters the circuit. The highlighted traces is the path from the positive terminal on the battery bay to the DC power jack. Why? Because there is an important break in the circuit at this point. When external power is provided via this jack, the gameboy is kind enough to stop sapping your batteries of their life juice. It does this by having a switch in the jack itself. That means that if you're modding your GB and want to draw power from somewhere, you can't draw it from this path if you're using the external DC jack. This is the type of thing I know I'd end up raging about if I needed to troubleshoot. That's why this is here.
(It might still work if you have batteries installed, but you run the risk of overheating/leaking/exploding/etc. the batteries depending on the configuration if you also have the external power plugged in. Something about messing with the chemical reaction occurring in the batteries. Just something to keep in mind.)
The second leg of the power's journey is shown here. The circuit at this point assumes it has power. It travels from the DC jack up to the switch that we all know makes the 'buh-ding' happen. That switch is an inverted 'single pole double throw' switch. Which means that when you flip the switch, two things are happening. When in the 'on' state, the switch completes the circuit between the bottom 2 pins, and only the bottom 2 pins. When it is 'off', it completes the circuit for the top 2 pins, and only the top 2 pins.
Then something interesting occurs. The power for most of the circuit leaves this board and runs off to another one (which I'm sure is the power regulator, but I haven't taken that apart yet). What's interesting is that this unregulated power runs off to the 2nd pin of the flex cable that goes to your screen's circuit board, and another part branches off to the 4th pin of the amp. So, yeah. That's a thing.
What I assume is the regulated power re-enters the board just a few holes below the point it left, and makes a highway-loop around most everything. This is where I recommend pulling power from, which is fairly convenient because it's mostly on the back, so it's easy to follow. Everything labeled VCC on the schematic comes directly from this.
As with every yin, there is a yang. For every high there is a low. Every positive, a negative. And for every VCC, there is a GND. As you can see, the grounding plain is quite sizable, so there you go. The VCCs and GNDs are the second thing I wanted to communicate with you folks. Have at it.
The third and final thing I wanted to show you is how the CPU gets the amp to make all the 'bleeps' and 'bloops' everyone here has come to love. Particularly so for the DMG. This is the left and right audio out from the CPU to capacitors 3 and 4, through resistors 5 and 6 and finally into the amp.
These last two images are really straight forward. This one is the path the left audio takes from the amp, off the board, and to the headphone panel.
And this is showing the right audio doing the same.
While you're looking, see if you can follow the trace from pin 3 on the amp to pin 20 on the flex cable socket going to the screen's board. That's the summed mono audio heading to the speaker on the bottom right of the gameboy.
So, yeah. That's about it for that. Enjoy!
Flat Package Editor Dmg Free
Also, hi. I'm new here
Flat Package Editor Dmg Software
Last edited by bit 9 (Aug 24, 2014 2:25 am)