Jump to content

50 posts in this topic

Recommended Posts

Advertisement
Posted (edited)

@Andrey1970 thanks for the heads up. I did not expect you to consider my app when it comes to config changes. I check the docs directory on the OpenCorePkg repo almost daily and I did my best to build OCC in such a way that it's easy to account for changes to the spec

 

@ricoc90 honestly I don't like when applications behave like that, so I don't think I will be changing that. I've just accustomed to hitting cmd+q to quit an app

Edited by notiflux

Share this post


Link to post
Share on other sites
3 minutes ago, notiflux said:

@Andrey1970 thanks for the heads up. I did not expect you to consider my app when it comes to config changes. I check the docs directory on the OpenCorePkg repo almost daily and I did my best to build OCC in such a way that it's easy to account for changes to the spec

heads up man thanks for your great work :thumbsup_anim:

Share this post


Link to post
Share on other sites

While @Andrey1970 is right that we do not believe automatic tools can help people improve their experience, and thus are generally anticipate them, I do not believe we can stop people from writing them, and thus will try to be as constructive as possible to avoid extra harm from any side.

 

OpenCore Configurator is an open source application and for this very reason, despite our personal views and no official recommendations, we will try to provide some help at the very least. Substantial differences in our preferences will not help much the process anyway.

 

Regarding configuration changes, starting from 0.0.1 release we have version reporting (exposed through NVRAM). We demand this to be verified by configuration app to ensure compatibility (this is stated in the docs).

— For the released version the warning should appear when the app is unaware of the version used.

— For an unreleased version the warning should always appear. 

— For no version present another warning should appear.

 

We do not care much whether the user decides to continue as long as he is informed about a potential incompatibility. We believe it is very important for the user to be aware of the problem if he still decides to use a configuration app. And the fact that every release has its documentation fixed makes it possible for a configuration app to be compatible with released versions at least in theory.

 

Additionally to that I recently added differential documentation, showing changes between the configurations [1] across the releases. The file will be bundled with the release file, and should help everyone update accordingly to the latest release.

 

Last but not least, while I cannot promise it, but we will try to find some resources to conduct a basic validation process to give recommendations in regards to decisions taken, which we consider to be wrong or improper. Closer to a more stable release of course. For example, recently we discovered that most third party tools reformat and reorder plist files, making their changes hard to discover [2]. If OpenCore Configurator is affected, we hope this is fixed.

 

Thanks for the hard work, and peace :)

 

[1] https://github.com/acidanthera/OpenCorePkg/tree/master/Docs/Differences

[2] https://github.com/corpnewt/ProperTree/issues/5

Share this post


Link to post
Share on other sites

@vit9696 thanks a lot for the info. I will implement the version checks tomorrow.

 

About the restructuring/ordering of the config: afaik OCC does not reorder any entries it isn't supposed to, I will check that thoroughly tomorrow though, since swift dictionaries like throwing values around. It does however change the format slightly, for example it saves data like this 

<data>
T3BlbkNvcmUK
</data>

Instead of this 

<data>T3BlbkNvcmUK</data>

This should not affect OC itself, but indeed does make comparison more difficult when looking at the plist in raw text. However I did not find a way to prevent this from happening, this seems to be the way plists are formatted when writing an NSDictionary to a file. I will investigate this further to see if I can somehow manage to make this work, if nothing else I'll manually strip the newlines after the file was written. 

 

I'm sure the differential documentation will be a huge help for parsing configs of different versions, since atm OCC can only reliably parse the current version.

 

If you have any more suggestions/changes you want to be made, just let me know

 

Thanks again and cheers :)

Share this post


Link to post
Share on other sites
12 hours ago, notiflux said:

 

@ricoc90 honestly I don't like when applications behave like that, so I don't think I will be changing that. I've just accustomed to hitting cmd+q to quit an app

 

Well, personally I don't see the point of having the app stay open if all of its windows are closed, since then you'll have a dock icon with no actual function. 


Anyway, the decision is yours :lol:
 

Share this post


Link to post
Share on other sites

@notiflux, quick googling does not help much in finding on how to provide single line <data> formatting. It is strange, but from what I can tell, most likely you will have to introduce a custom post-processing filter to workaround.

Share this post


Link to post
Share on other sites

@vit9696 I already found a workaround for that which is similar to what CorpNewt did on ProperTree. I just need to make sure that it doesn't reorder things for all subdicts. I already have all the code to do this but I will greatly need to change the structure of my open handler functions, so that will take some more time

 

@iCanaro You don't have any apfs volumes on your High Sierra install, do you?

I currently can't simulate such an environment, could you please run this command in terminal:

diskutil apfs list -plist > ~/apfs.plist

and upload the resulting file from your home directory?

Share this post


Link to post
Share on other sites

High Sierra HFS+ hack 5 signature --> OK
 

High Sierra HFS+ hack 1 signature --> OK

 

High Sierra HFS+ hacK 2 signature --> crash just instantly at launch

I think that the problem is related to this current configuration of the hack

Share this post


Link to post
Share on other sites
On 5/10/2019 at 12:05 AM, notiflux said:

honestly I don't like when applications behave like that, so I don't think I will be changing that. I've just accustomed to hitting cmd+q to quit an app

 

That's right. Everything else is Windows. There is a difference between "close document" and "close application".

Share this post


Link to post
Share on other sites
Posted (edited)
On 5/10/2019 at 1:04 AM, notiflux said:

@vit9696 thanks a lot for the info. I will implement the version checks tomorrow.

 

About the restructuring/ordering of the config: afaik OCC does not reorder any entries it isn't supposed to, I will check that thoroughly tomorrow though, since swift dictionaries like throwing values around. It does however change the format slightly, for example it saves data like this 


<data>
T3BlbkNvcmUK
</data>

Instead of this 


<data>T3BlbkNvcmUK</data>

This should not affect OC itself, but indeed does make comparison more difficult when looking at the plist in raw text. However I did not find a way to prevent this from happening, this seems to be the way plists are formatted when writing an NSDictionary to a file. I will investigate this further to see if I can somehow manage to make this work, if nothing else I'll manually strip the newlines after the file was written. 

 

I'm sure the differential documentation will be a huge help for parsing configs of different versions, since atm OCC can only reliably parse the current version.

 

If you have any more suggestions/changes you want to be made, just let me know

 

Thanks again and cheers :)

It is because NSDictionary doesn't keep the order of key-value pairs, only on arrays. For that you have to write your own xml parser to both read and write a plist, i.e all that with out using NSDictionary. Anyway this is not a bug. About data tag with blank spaces and line feeds, imho is a bug from Open Core since the parser should at least remove them to keep a clean base 64 string, and in fact he already try to skeep spaces:

RETURN_STATUS
EFIAPI
OcBase64Decode (
  IN     CONST CHAR8  *EncodedData,
  IN     UINTN        EncodedLength,
     OUT UINT8        *DecodedData,
  IN OUT UINTN        *DecodedLength
  )
{
  CONST CHAR8 *End = EncodedData + EncodedLength;
  CHAR8 Iter = 0;
  UINT32 Buf = 0;
  UINTN Len = 0;
  
  while (EncodedData < End) {
    UINT8 C = D[(UINT8)(*EncodedData++)];
    
    switch (C) {
      case WHITESPACE:
        continue;       /* skip whitespace */ ----> do the same for '\n' and '\r'

but not '\n' nor '\r', but it should. 

..as already written by someone:

//
// Additional modifications include permitting tabulation and other whitespace
// characters to appear in the encoded data. The intention of those is to support
// Base64 data from property lists.
//

.. because that is normal. looking at any kexts in SLE, data tag are always formatted with '\n, so this parser needs to be fixed.

Edited by vector sigma

Share this post


Link to post
Share on other sites
Posted (edited)

Hi @notiflux

 

I appreciate and applaud your time and commitment developing the OpenCore Configurator, it looks good! but, I tried using your application attached here on your post but it randomly quits unexpectedly. Do you have an updated version ?

 

I have just discovered your your latest version alpha18 . All good! thanks.

Edited by glasgood
update

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   1 member

  • Similar Content

    • By vit9696
      OpenCorePkg / Documentation / Configuration Template / Bugtracker   Discussion and installation should be done in a separate thread! This thread is for development only!
      Current status as of April 2019: Support for UEFI and DuetPkg (legacy) booting APFS and HFS+ compatibility ACPI patcher (adding, dropping, binary patching, relocation) Apple-compatible bless implementation DeviceProperties injection DataHub and SMBIOS generation Symbolic kext and kernel patcher Direct kext injection/patching/blocking within prelinkedkernel Installation/Recovery/FileVault 2 support  Configuration in config.plist with open documentation Simple boot picker for quick launch Direct boot from dmg images  
      Known defects live here.  
      For those, who are not familiar with the history, OpenCore is a project initially born in HermitCrabs Lab that unfortunately almost died before its birth. This release is both a rebirth and a complete rewrite of OpenCore, which brings a number of new ideas, and tries to preserve the smart moves incorporated by iNDi and his team. Other than that, I wish to express my deepest words of gratitude to Acidanthera and WWHC members: your participation was and remains the key for project success, and you are simply the best.
    • By dgsga
      Can I propose a new subforum be created for the new OpenCorePkg OpenCore front end being created by vit9696 and others, it is a fantastic piece of work:
      https://github.com/acidanthera/OpenCorePkg
      Even at version 0.1 it runs my Mojave 10.14.4 setup very nearly flawlessly. It consists of a 10KB bootstrap BootX64.efi and a 200KB OpenCore.efi OS loader. All configuration is done using a very well documented config.plist 
       
       
    • By zhengshiqi
      Hi, first of all, I'd like to extend my hearty thanks to the team's hard work. The reason why I don't post this topic in OpenCore Discussion room because I don't have access to reply in that room.
       
      I successfully boot into macOS, but when I choose BOOTCAMP Windows, the boot loader returns a critical error. `IgnoreForWindows` option do not work for me.
      Also, when I first come in OpenCore boot page, it shows `OCS: Failed to parse real field of type 1`, and quickly disappears.
      Here's my config.plist, and hope for suggestions. 
      P.S. My device is running in UEFI mode.
      config.plist
    • By ITzTravelInTime
      This app can be used to edit or create custom versions of the voodoo tsc sync kext, i have created it because i have seen many times peoples having troubles in finding the right version of voodoo tsc sync for their cpu, so i created a mac app that lets to edit or create a voodoo tsc kext and configure it for your system, i have included 3 ways to edit the kext:
       
      1) configure using one of the existing templates (just chose one of the cpu models listed)
       
      2) specifying the number of logical cores (threads)
       
      3) manually editing the info.plist of the kext using the editor (still experimental, needs some improvements)
       
      This app uses a copy of the VoodooTSCSync in his Resourches folder, or you can open an existing version of VoodooTSC and edit it, there are some other useful features to discover, and new ideas are also welcome to improve this program, i know that with a plist editor you can do what this app does, but this is designed to be more user friendly than editing a plist file manually and just for accomplish the task of configuring this kext for your machines without looking on the web for that specific pre-configured version you need, just download this program and follow a few steps.
       
      Reference topic: VoodooTSCSync Configurator, create a custom version of voodoo tsc sync
×