Jump to content

Clover Problems and Solutions


ErmaC
3,206 posts in this topic

Recommended Posts

 

8:696  0:001  Found internal video device FFFF@3BD2, unusable
What's 3BD2 ?

 

3BD2 is the offset in the DSDT where the device is found.

 

Instead of viewing your DSDT with MaciASL.app, use the command line to disassemble it and display offset and bytes of each line using this command:

~/src/opt/local/bin/iasl -l -d pathtoyourdsdtfile
You may want to know what devadr, devsize, j and j+10 are too:

DBG("Found internal video device FFFF@%x (size=%d), unusable devadr=%x, devsize=%d j=%x j+10=%x\n", devadr1, devsizel, devadr, devsize, j, j+10);
The "Advanced Configuration and Power Interface Specification Version 6.1 [January, 2016]" can tell you what the bytes mean - their meaning should correspond to the disassembly output.
Link to comment
Share on other sites

  • 2 weeks later...

Latest Updated to  r3575 at r3578

 

Clover EFI

v2.3k r3575:3578  
 
Why two revision in one Package ???
 
================= Post =================
[bUILD] Post
### /Applications/Xcode.app/Contents/Developer/usr/bin/Rez - SysError -37 during create of "sym/Clover_v2.3k_r3575:3578.pkg".
### /Applications/Xcode.app/Contents/Developer/usr/bin/Rez - Fatal error trying to open the resource file "sym/Clover_v2.3k_r3575:3578.pkg" for writing.
Fatal Error!
### /Applications/Xcode.app/Contents/Developer/usr/bin/Rez - Fatal Error, can't recover.
### /Applications/Xcode.app/Contents/Developer/usr/bin/Rez - Since errors occurred, sym/Clover_v2.3k_r3575:3578.pkg's resource fork was not completely updated.
### /Applications/Xcode.app/Contents/Developer/usr/bin/Rez - SysError -43 during set file info.
 
 --------------------------
 Building process complete!
 --------------------------
 
 Build info.
 ===========
  Package name: Clover_v2.3k_r3575:3578.pkg
  MD5:          da7e508297e3d86180758ffe3ac7fde3
  Version:      v2.3k
  Stage:        v2.3k
  Date/Time:    2016-06-26 11:11:24
  Built by:     chris
  Copyright     2012
 
edit*****  SOLVED
Now I am going to try a completed new Build!
 
Solved with a completed new Build!
Link to comment
Share on other sites

 

To my seems more simple to create a key (supportedOSes) as string where you can write the supported OSes in a component separated by the "," char inside each KextsToPatch dictionary:

supportedOSes = 10.11,10.12,10.11.7

just an idea.

Clover should create an array by split the components separated by "," as supported Os for the relative patch. So can be dinamically applied  when the OS version match.

 

Another good idea.

But more complicate to release.

These way we can edit OS specific settings in GUI, in more huge GUI.

 

Very good, but it can't be applied to Clover sources without some refactoring.

#include <string.h> is impossible in the project. All string functions must be replaced by analogous. And I seems have no analog for strtok()

 

Hi Slice I have a working solution (made my own functions):

Platform.h.zip

Settings.c.zip

 

Only, I don't know where to keep the OSVersion, as you can see at line 1121 (Settings.c):

struct MatchOSes currOStoc; GetStrArraySeparatedByChar("10.11.6" /* need GetOSversion here */, '.',  &currOStoc);

..I had to do it manually and must be changed.

 

Usage:

 

MatchOS = 10.10.5,10.7,10.11.6,10.12.x

a string contains the OSes  separated by commas intrested for the KextsToPatch to be enabled. Can also be a sigle OS (w/o comma(s) in this case)

                       <dict>
				<key>MatchOS</key>
				<string>10.7.x,10.8.x,10.9.x,10.10.x,10.11.x</string>
				<key>Comment</key>
				<string>Zeroing 11d41983 codec (patched by AppleHDA Patcher.app)</string>
				<key>Find</key>
				<data>gxnUEQ==</data>
				<key>Name</key>
				<string>AppleHDA</string>
				<key>Replace</key>
				<data>AAAAAA==</data>
			</dict>
			<dict>
				<key>Comment</key>
				<string>Zeroing 11d4198a codec (patched by AppleHDA Patcher.app)</string>
				<key>MatchOS</key>
				<string>10.12.x</string>
				<key>Find</key>
				<data>ihnUEQ==</data>
				<key>Name</key>
				<string>AppleHDA</string>
				<key>Replace</key>
				<data>AAAAAA==</data>
			</dict> 

format like 10.12.x or 10.7.x means that all revisions of 10.12 or 10.7 are good to run the patch. Specific component like 10.11.6 mean that this patch will be activated only for 10.11.6 (not for 10.11.5 for example).

 

Limits:

MatchOS string should not begin or end with the separator (',') otherwise the patch will be disabled. In the event it would be a user error.

 

struct MatchOSes {

    UINTN   count;

    CHAR8  * array[100];

} MatchOSes;

 

the array is actually set to 100 components.. edit if you want a bigger/smaller capacity.

 

Log:

0:137  0:000  KextsToPatch: 6 requested
0:137  0:000  KextsToPatch 0: IOAHCIBlockStorage (Enable TRIM for SSD) (no MatchOS)
0:137  0:000   Kext bin patch, data len: 11
0:137  0:000  KextsToPatch 1: AppleUSBXHCIPCI (remove usb limit) (no MatchOS)
0:137  0:000   Kext bin patch, data len: 7
0:137  0:000  KextsToPatch 2: AppleHDA (Zeroing 11d41983 codec) (enabled by MatchOS)
0:137  0:000   Kext bin patch, data len: 4
0:137  0:000  KextsToPatch 3: AppleHDA (Zeroing 11d4198a codec (patched by AppleHDA Patcher.app)) (disabled by MatchOS)
0:137  0:000  KextsToPatch 4: AppleHDA (Zeroing 11d41984 codec (patched by AppleHDA Patcher.app)) (no MatchOS)
0:137  0:000   Kext bin patch, data len: 4
0:137  0:000  KextsToPatch 5: AppleHDA (Patching 11d4198b with 111d76e0 codec (patched by AppleHDA Patcher.app)) (no MatchOS)
0:137  0:000   Kext bin patch, data len: 4 

KextsToPatch 2 enabled and KextsToPatch 3 disabled because running in 10.11.6, all others have no "MatchOS" set and are working as usual  :D

This is an example, but the Scenario is cool because patching new Sierra's AppleHDA (for example) I need to zeroing one codec, instead in El Capitan another one.... like can be for other kexts :lol:

 

Need to be well tested but hope you like it  :)

  • Like 9
Link to comment
Share on other sites

Usage:

 

MatchOS = 10.10.5,10.7,10.11.6,10.12.x

a string contains the OSes  separated by commas intrested for the KextsToPatch to be enabled. Can also be a sigle OS (w/o comma(s) in this case)

 

format like 10.12.x or 10.7.x means that all revisions of 10.12 or 10.7 are good to run the patch. Specific component like 10.11.6 mean that this patch will be activated only for 10.11.6 (not for 10.11.5 for example).

 

Limits:

MatchOS string should not begin or end with the separator (',') otherwise the patch will be disabled. In the event it would be a user error.

 

the array is actually set to 100 components..

I would like to see a regular expression library added to Clover (such as the one at https://github.com/cesanta/slre). It could be used in so many places to match strings in config.plist. In this case you're MatchOS string could look like this:

<key>MatchOS</key>
<string>^10\.(7|8|9|10|11)\..*</string>
In a more general case example, for "Arbitrary" properties, the "PciAddr" string could be replaced by a regular expression that can match to any properties of a device which Clover can concatenate into a larger string. Clover can construct a string using a known format containing the PciAddr, device id, vendor id, class code, name, device path, etc. Then the match string can be a regular expression that matches to any combination of those properties. This could make matching even more capable than Apple's info.plist IOKitPersonalities matches.

 

The regular expression could contain capture strings that could be used in subsequent regular expressions. For example, "Find", then "Replace".

 

A benefit of a regular expression is that it could be used to make a config setting applicable to more systems without modification. In the above PciAddr example, matching to a device id and vendor id might be more compatible (system independent) than a hard coded PciAddr (system dependent). In another case, a patch to rename an ACPI device could apply to multiple DSDTs if the Find string could be a regular expression containing all the source possibilities; example: Find "(AZAL|HDAS)" Replace: "HDEF".

  • Like 1
Link to comment
Share on other sites

 

 

 

Hi Slice I have a working solution (made my own functions):

attachicon.gifPlatform.h.zip

attachicon.gifSettings.c.zip

 

Only, I don't know where to keep the OSVersion, as you can see at line 1121 (Settings.c):

struct MatchOSes currOStoc; GetStrArraySeparatedByChar("10.11.6" /* need GetOSversion here */, '.',  &currOStoc);

..I had to do it manually and must be changed.

 

Usage:

 

MatchOS = 10.10.5,10.7,10.11.6,10.12.x

a string contains the OSes  separated by commas intrested for the KextsToPatch to be enabled. Can also be a sigle OS (w/o comma(s) in this case)

                       <dict>
				<key>MatchOS</key>
				<string>10.7.x,10.8.x,10.9.x,10.10.x,10.11.x</string>
				<key>Comment</key>
				<string>Zeroing 11d41983 codec (patched by AppleHDA Patcher.app)</string>
				<key>Find</key>
				<data>gxnUEQ==</data>
				<key>Name</key>
				<string>AppleHDA</string>
				<key>Replace</key>
				<data>AAAAAA==</data>
			</dict>
			<dict>
				<key>Comment</key>
				<string>Zeroing 11d4198a codec (patched by AppleHDA Patcher.app)</string>
				<key>MatchOS</key>
				<string>10.12.x</string>
				<key>Find</key>
				<data>ihnUEQ==</data>
				<key>Name</key>
				<string>AppleHDA</string>
				<key>Replace</key>
				<data>AAAAAA==</data>
			</dict> 

format like 10.12.x or 10.7.x means that all revisions of 10.12 or 10.7 are good to run the patch. Specific component like 10.11.6 mean that this patch will be activated only for 10.11.6 (not for 10.11.5 for example).

 

Limits:

MatchOS string should not begin or end with the separator (',') otherwise the patch will be disabled. In the event it would be a user error.

 

struct MatchOSes {

    UINTN   count;

    CHAR8  * array[100];

} MatchOSes;

 

the array is actually set to 100 components.. edit if you want a bigger/smaller capacity.

 

Log:

0:137  0:000  KextsToPatch: 6 requested
0:137  0:000  KextsToPatch 0: IOAHCIBlockStorage (Enable TRIM for SSD) (no MatchOS)
0:137  0:000   Kext bin patch, data len: 11
0:137  0:000  KextsToPatch 1: AppleUSBXHCIPCI (remove usb limit) (no MatchOS)
0:137  0:000   Kext bin patch, data len: 7
0:137  0:000  KextsToPatch 2: AppleHDA (Zeroing 11d41983 codec) (enabled by MatchOS)
0:137  0:000   Kext bin patch, data len: 4
0:137  0:000  KextsToPatch 3: AppleHDA (Zeroing 11d4198a codec (patched by AppleHDA Patcher.app)) (disabled by MatchOS)
0:137  0:000  KextsToPatch 4: AppleHDA (Zeroing 11d41984 codec (patched by AppleHDA Patcher.app)) (no MatchOS)
0:137  0:000   Kext bin patch, data len: 4
0:137  0:000  KextsToPatch 5: AppleHDA (Patching 11d4198b with 111d76e0 codec (patched by AppleHDA Patcher.app)) (no MatchOS)
0:137  0:000   Kext bin patch, data len: 4 

KextsToPatch 2 enabled and KextsToPatch 3 disabled because running in 10.11.6, all others have no "MatchOS" set and are working as usual  :D

This is an example, but the Scenario is cool because patching new Sierra's AppleHDA (for example) I need to zeroing one codec, instead in El Capitan another one.... like can be for other kexts :lol:

 

Need to be well tested but hope you like it  :)

 

Interesting, but in addition to what @joevt said, you're missing the whole point of a structure. The structures in C were created in order to bypass the limitation of a predetermined array.

 

Try to solve the below problem and you'll understand what I mean.

http://cdn.cs50.net/2016/x/psets/5/pset5/pset5.html

Anyway, good try.  :) 

 

Best regards.

 

  • Like 1
Link to comment
Share on other sites

 

 

 

Hi Slice I have a working solution (made my own functions):

attachicon.gifPlatform.h.zip

attachicon.gifSettings.c.zip

 

Only, I don't know where to keep the OSVersion, as you can see at line 1121 (Settings.c):

struct MatchOSes currOStoc; GetStrArraySeparatedByChar("10.11.6" /* need GetOSversion here */, '.',  &currOStoc);

..I had to do it manually and must be changed.

 

 

 

This is very significant note as OS version is not available at the time of reading config.plist.

But I like this idea and rework it using these procedures.

So, when reading config.plist we just remember what patch for a what and show this in debug.log.

When starting a Mac OS we determine its version and then apply patches if they allowed.

Some reformatting to Teano Code Style and some security improvements.

Revision 3580.

  • Like 1
Link to comment
Share on other sites

I just built 3580 because I could really use this OS-specific patching to tidy things up.

 

However, it's not applying patches that are shared between OS versions. So if I'm booting 10.10.5 and have a patch that's valid for 10.10.x and 10.11.x it gets skipped. It will only apply patches that have MatchOS set to 10.10.x.

 

In bdmesg it shows the matched OSes for the patches so I'm guessing I have the syntax right for the MatchOS line (10.10.x,10.11.x,10.12.x).

  • Like 1
Link to comment
Share on other sites

I just built 3580 because I could really use this OS-specific patching to tidy things up.

 

However, it's not applying patches that are shared between OS versions. So if I'm booting 10.10.5 and have a patch that's valid for 10.10.x and 10.11.x it gets skipped. It will only apply patches that have MatchOS set to 10.10.x.

 

In bdmesg it shows the matched OSes for the patches so I'm guessing I have the syntax right for the MatchOS line (10.10.x,10.11.x,10.12.x).

Please set

	<key>KernelAndKextPatches</key>
	<dict>
		<key>Debug</key>
		<true/>

and look on the screen what is happen.

Link to comment
Share on other sites

 

Micky1979

 

Support 10.6 too.

Thanks

should work with all supported OS by Clover

 

Interesting, but in addition to what @joevt said, you're missing the whole point of a structure. The structures in C were created in order to bypass the limitation of a predetermined array.

 

Try to solve the below problem and you'll understand what I mean.

http://cdn.cs50.net/2016/x/psets/5/pset5/pset5.html

Anyway, good try.   :) 

 

Best regards.

 

Thanks. In truth the struct must have a fixed size known at compile time otherwise we have to use malloc to dinamically allocate space for it and then free it as soon as possible/where it possible. And no one can stop Slice to make it this way, I just thought this is really enough, to handle the new key. (I guess users don't make their thesis there ha ha)

Thanks also for the link that refear to some Academic stuff. Just 4 days ago I had my last "High School" diploma exam (explain my Thesis) as "Accountant"  programmers branch (chose that instead of commerce branch after the first two years) and now I need to think about college, but really do not know if it will have to deal with softwares since I'm already an active Dev on the Apple Store since last years (I'm selling softwares  :hysterical: ) What I mean is that also today I receive a small amount from "Payments and Finacial Reports" on Itunes, but Its not enough. Maybe I will look to maintain the interests of the family, but it requires a degree in Mechanical Engineering.. (90%)

I would like to see a regular expression library added to Clover (such as the one at https://github.com/cesanta/slre). It could be used in so many places to match strings in config.plist. In this case you're MatchOS string could look like this:

<key>MatchOS</key>

<string>^10\.(7|8|9|10|11)\..*</string>

Yep the idea is cool but is less simple for noobs, powerfull for advanced user.

 

This is very significant note as OS version is not available at the time of reading config.plist.

But I like this idea and rework it using these procedures.

So, when reading config.plist we just remember what patch for a what and show this in debug.log.

When starting a Mac OS we determine its version and then apply patches if they allowed.

Some reformatting to Teano Code Style and some security improvements.

Revision 3580.

Thanks  :thumbsup_anim:

 

I just built 3580 because I could really use this OS-specific patching to tidy things up.

 

However, it's not applying patches that are shared between OS versions. So if I'm booting 10.10.5 and have a patch that's valid for 10.10.x and 10.11.x it gets skipped. It will only apply patches that have MatchOS set to 10.10.x.

 

In bdmesg it shows the matched OSes for the patches so I'm guessing I have the syntax right for the MatchOS line (10.10.x,10.11.x,10.12.x).

 

I'm at Home just now.. going to try me too..

Link to comment
Share on other sites

Please set

	<key>KernelAndKextPatches</key>
	<dict>
		<key>Debug</key>
		<true/>

and look on the screen what is happen.

 

Yep, that's what I've done. This is how I can see that when booting Yosemite on my X79 it's only applying the patches where the MatchOS is "10.10.x".

 

The patches where it's "10.10.x,10.11.x" or "10.10.x,10.11.x,10.12.x" aren't being applied.

 

I've attached a screengrab of a video I recorded of the debug boot. See how patches 7, 8 and 10 are applied. But 9 is disallowed.

 

Here's the relevant patch section of bdmesg. See that patch 9 is multi-OS while 7, 8 and 10 are only for Yosemite:

 

 

0:108  0:000  KextsToPatch 7: AppleIntelCPUPowerManagement (Sandy Bridge-E patch for 10.10 (1/7))Matched OSes: 10.10.x

0:108  0:000   Kext bin patch, data len: 12

0:108  0:000  KextsToPatch 8: AppleIntelCPUPowerManagement (Sandy Bridge-E patch for 10.10 (2/7))Matched OSes: 10.10.x

0:108  0:000   Kext bin patch, data len: 3

0:108  0:000  KextsToPatch 9: AppleIntelCPUPowerManagement (Sandy Bridge-E patch for 10.10 (3/7))Matched OSes: 10.10.x,10.11.x,10.12.x

0:108  0:000   Kext bin patch, data len: 4

0:108  0:000  KextsToPatch 10: AppleIntelCPUPowerManagement (Sandy Bridge-E patch for 10.10 (4/7))Matched OSes: 10.10.x

0:108  0:000   Kext bin patch, data len: 12

0:108  0:000  KextsToPatch 11: AppleIntelCPUPowerManagement (Sandy Bridge-E patch for 10.10 (5/7))Matched OSes: 10.10.x

0:108  0:000   Kext bin patch, data len: 3

0:108  0:000  KextsToPatch 12: AppleIntelCPUPowerManagement (Sandy Bridge-E patch for 10.10 (6/7))Matched OSes: 10.10.x,10.11.x,10.12.x

0:108  0:000   Kext bin patch, data len: 5

0:108  0:000  KextsToPatch 13: AppleIntelCPUPowerManagement (Sandy Bridge-E patch for 10.10 (7/7))Matched OSes: 10.10.x,10.11.x

 

post-267996-0-66273900-1467654554_thumb.jpg

Link to comment
Share on other sites

looks like a problem comparing strings with "AsciiStrCmp". Each components of the MacOS key in config are splitted and the null character added to each one. Also 'CurrOS' have it?

EDIT not this problem looking at your spoiler. But what's it show running Sierra?


Asked this because if not applied you should not see "Kext bin patch, data len: 4" because the for loop "continue" w/o apply the patch.. I'm wrong?

Link to comment
Share on other sites

looks like a problem comparing strings with "AsciiStrCmp". Each components of the MacOS key in config are splitted and the null character added to each one. Also 'CurrOS' have it?

EDIT not this problem looking at your spoiler. But what's it show running Sierra?

Asked this because if not applied you should not see "Kext bin patch, data len: 4" .. I'm wrong?

 

With Sierra it only applied the three patches that had MatchOS as "10.12.x" and then panicked because it had skipped the others.

 

As for the "Kext bin patch, data len: 4", I wasn't expecting to see that either.  But it seems that Clover still runs through all the patches, it just doesn't apply the ones that don't match the target OS.

Link to comment
Share on other sites

Sorry, only first chunk 10.10.5 is analysed

+BOOLEAN IsOSValid(CHAR8 *MatchOS, CHAR8 *CurrOS)
+{
+  /* example for valid matches are:
+   10.7, only 10.7 (10.7.1 will be skipped)
+   10.10.2 only 10.10.2 (10.10.1 or 10.10.5 will be skipped)
+   10.10.x (or 10.10.X), in this case is valid for all minor version of 10.10 (10.10.(0-9))
+   */
+  struct MatchOSes osToc;
+  struct MatchOSes currOStoc;
+  BOOLEAN ret = FALSE;
+  INTN i;
+  
+  if (!MatchOS || !CurrOS) {
+    return TRUE; //undefined matched corresponds to old behavior
+  }
+  
+  GetStrArraySeparatedByChar(MatchOS, '.', &osToc);

Tomorrow will rework the algo.

  • Like 3
Link to comment
Share on other sites

Yep the idea is cool but is less simple for noobs, powerfull for advanced user.

Of course we wouldn't want any change to affect existing config.plist's, so adding regular expression support would require a method to determine that the match string is a regular expression. Probably the best way to do that is by using a different key name, maybe with an RE suffix.
  • Like 1
Link to comment
Share on other sites

The ones with only one component. Can you edit these keys (7, 8 and 11) something like that: MatchOS = "10.10.x,10.10.x" instead of only one? ...just to ensure that this is the problem

Link to comment
Share on other sites

I changed the "10.10.x" entries to "10.10.x,10.11.x" and none of the patches were applied.

 

This was with my earlier compile of 3580, not the one you posted here. I rolled back so I could boot into Yosemite OK without the KP from partial patching.

  • Like 1
Link to comment
Share on other sites

Ok you are right. Booting into el capitan works good, but booting in Sierra sure something is not applied even though the bdmesg apperar to be good:

0:384  0:000  KextsToPatch: 6 requested
0:384  0:000  KextsToPatch 0: IOAHCIBlockStorage (Enable TRIM for SSD) Kext bin patch, data len: 11
0:384  0:000  KextsToPatch 1: AppleUSBXHCIPCI (remove usb limit) Kext bin patch, data len: 7
0:384  0:000  KextsToPatch 2: AppleHDA (Zeroing 11d41983 codec)Matched OSes: 10.7.x,10.8.x,10.9.x,10.10.x,10.11.x
0:384  0:000   Kext bin patch, data len: 4
0:384  0:000  KextsToPatch 3: AppleHDA (Zeroing 11d4198a codec (patched by AppleHDA Patcher.app))Matched OSes: 10.12.x
0:384  0:000   Kext bin patch, data len: 4
0:384  0:000  KextsToPatch 4: AppleHDA (Zeroing 11d41984 codec (patched by AppleHDA Patcher.app)) Kext bin patch, data len: 4
0:384  0:000  KextsToPatch 5: AppleHDA (Patching 11d4198b with 111d76e0 codec (patched by AppleHDA Patcher.app)) Kext bin patch, data len: 4

They are all enabled.. In El Capitan my audio still work because Clover cannot find KextsToPatch 3

Link to comment
Share on other sites

Looks good

Sergeys-iMac:1 slice$ gcc test_micky.c -o test_micky
Sergeys-iMac:1 slice$ ./test_micky 10.10.x,10.7,10.6.8 10.10.1
patch 10.10.x,10.7,10.6.8 is enabled for 10.10.1End
Sergeys-iMac:1 slice$ ./test_micky 10.10.x,10.7,10.6.8 10.10.5
patch 10.10.x,10.7,10.6.8 is enabled for 10.10.5End
Sergeys-iMac:1 slice$ ./test_micky 10.10.x,10.7,10.6.8 10.8
patch 10.10.x,10.7,10.6.8 is not enabled for 10.8End
Sergeys-iMac:1 slice$ ./test_micky 10.10.x,10.7,10.6.8 10.7.5
patch 10.10.x,10.7,10.6.8 is enabled for 10.7.5End
Sergeys-iMac:1 slice$ ./test_micky 10.10.x,10.7,10.6.8 10.6.3
patch 10.10.x,10.7,10.6.8 is not enabled for 10.6.3End
Sergeys-iMac:1 slice$ 

test_micky.c.zip

Link to comment
Share on other sites

Looks good

Sergeys-iMac:1 slice$ gcc test_micky.c -o test_micky
Sergeys-iMac:1 slice$ ./test_micky 10.10.x,10.7,10.6.8 10.10.1
patch 10.10.x,10.7,10.6.8 is enabled for 10.10.1End
Sergeys-iMac:1 slice$ ./test_micky 10.10.x,10.7,10.6.8 10.10.5
patch 10.10.x,10.7,10.6.8 is enabled for 10.10.5End
Sergeys-iMac:1 slice$ ./test_micky 10.10.x,10.7,10.6.8 10.8
patch 10.10.x,10.7,10.6.8 is not enabled for 10.8End
Sergeys-iMac:1 slice$ ./test_micky 10.10.x,10.7,10.6.8 10.7.5
patch 10.10.x,10.7,10.6.8 is enabled for 10.7.5End
Sergeys-iMac:1 slice$ ./test_micky 10.10.x,10.7,10.6.8 10.6.3
patch 10.10.x,10.7,10.6.8 is not enabled for 10.6.3End
Sergeys-iMac:1 slice$ 

attachicon.giftest_micky.c.zip

 

I tried 3581 but it only applied patches 9, 12 and 13 and panicked afterwards. So now it's applying the patches with multiple OSes but skipping the ones with just a single matched OS.

 

Yes appear to be good less when only one os is given:

else {
    // str contains only one component and it is our string!
    mo->array[0] = str;
  }

when  is only one "token" fails because later we call "FreePool" but  is not allocated by malloc (AllocatePool). We have to use "AllocatePool" also for that otherwise cannot be freed.  

EDIT

 

or skip it if the count == 1

  • Like 1
Link to comment
Share on other sites

×
×
  • Create New...