Thanks for pointing that out.

Well OK then, I just have thought that non working decryption would have been the reason, for me having lot's of "patch_text_segment failed" errors in dmesg after "DSMOS has arrived" and the system was up as well...
Looking forward to try the next build.

Would you mind to answer some questions to me?
First I wonder what's the purpose of libunwind - I know it is required for building dyld and that this hasn't been the case on Leopard. (That's what even zero-coder like me can understand when looking at the src.^^)
I guess missing libunwind is the reason for having to use upx on some binary - is it?
Do you think you can port libunwind for Snow Leopard?

1. Who do you think has added all the important code, for us AMD users to what you use to call "Nawcom kernel"?!
Without the efforts of Andyvand you would still be using sort of pure legacy mode kernel / without any 64-Bit capability.

2. What sentence in the first post don't you understand?! "I updated the latest patch to include a custom dyld." or "This dyld is beta"???

3. Even if you don't know the meaning of some words, it should be possible to understand that this is a) about keeping development going, and b) no final release, what usually means that testers are wanted.
If even getting that is beyond your scope of mind, you should better hold your tongue instead of posting provocative shit into technical topics.

---

Nawcom's kernel package doesn't yet have a custom dyld built in.
It's actually the same as booting this kernel with the following boot argument:
std_dyld=Yes
...
Don't worry, development is proceeding on the dyld.
I'm going to reverse engineer the Apple libunwind procedures from Apple's dyld (i386 and x86_64 dyld part).
I'll keep you posted if I succeed

Yeah, we need to pack some binaries with upx for this reason.
I'm going to reverse engineer the routines used in Apple's dyld though (32bit + 64bit Intel part).
I think this will fix the last little issues with the dyld and that it then will be the first dyld release.

Hello,

Can anyone tell me how to compile ucl & upx so that i can use the kernel?!
Would be really nice too know because i never compiled anything.

Thx & Greetz

I found mine on InsanelyMac, precompiled and working great...

I am also working on a new dyld.
Latest attempt is replacing the used exception code from the libunwind.a code to the libgcc_eh.a code.
Currently done (as it's also used this way on iOS I only needed to change a certain #if)
I also changed some other code so it shouldn't crash on load of System Profiler, etc...
I also updated the voodoobuild script so that it uses rebase_dyld to rebase the address of the dyld (i386 and x86_64, for security purposes...) and pre-patched the dyld sysenter trap so that the kernel doesn't need to look for it each time over again... this is faster...
Work in progress thus, I'll let you guys know if it works.

Would it be enough if i download an compiled upx and copy it to /usr/bin or do i need ucl too?

Greetz & Thx for your reply

Just download a compiled copy and use it like this from within Terminal:
sudo upx --best /System/Library/CoreServices/pbs

[quote name='sfx.' date='Jan 25 2011, 07:04 AM' post='1628889']
Waiting patiently Fingers crossed.
[/quote]
I've achieved a lot more success.
Right now every app runs stable without upx (except for /System/Library/CoreServices/pbs, pack this with upx).
If you use Vodafone Mobile Connect, pack this too...

Fixed:
- SystemUIServer crashes on Finder icons
- Disk Utility, System Profiler, etc... all work without packing
- dyld speed issues solved
- On-The-Fly patching works for all

It's stable enough to use on a SL install DVD as main patcher.

Download full package:
http://rapidshare.com/files/44441607...-AnV-0.4.1.zip

Let me know what you think of it so far...

For fellow developers:
When Finder should fail (for the moment after a file copy, folder copy, zip action, probably others :wacko: ) it always crashes on GetDYLDEntry.
If somebody could debug and trace this for me so I can fix this last little issue.
This was after a file copy...
Other than that it's fine, so please, lend me your eyes, devs so we can together close this chapter down.

Could somebody who has a 64 bit processor (Intel / AMD)

For AMD:
boot up with arch=i386 -force64

For Intel:
boot up with arch=i386 patcher_opts=49 -amd -force64

and see if the 64bit Finder (not a decrypted one from Marvin's Utility) runs without those issues.
I am beginning to suspect that the rebasing of the dyld may have something to do with the last bug.
I also think that they are i386 dyld related (not x86_64 dyld)...
I am currently rebuilding a kernel with sysenter trap pre-patched in dyld but not rebased to see if this is the case.
I have also made a decrypt of "Finder" (32bit only though), removed the code signature and packed it with upx to test in case this doesn't work.
Working hard on a final solution...
Please, somebody who can, do me a lot of fun and test it... all for the sake of progress...