So what's going on?

I'll let this speak for itself. Those thinking I'm dead, think again. Dragons are coming... That is all.

Info regarding HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections\DefaultConnectionSettings

Stuff that I've learned so far about the connection settings binary, I'm placing it here in for my reference later so I don't forget.

1) Byte number zero always has a 3C or 46 - I couldn't find more information about this byte.The next three bytes are zeros.

2) Byte number 4 is a counter used by the 'Internet Options' property sheet (Internet explorer->Tools->Internet Options...).
As you manually change the internet setting (such as LAN settings in the Connections tab), this counter increments.Its not very useful byte.But it MUST have a value.I keep it zero always.The next three bytes are zeros (Bytes 5 to 7).
 
3) Byte number 8 can take different values as per your settings.
The value is :
09 when only 'Automatically detect settings' is enabled
03 when only 'Use a proxy server for your LAN' is enabled
0B when both are enabled
05 when only 'Use automatic configuration script' is enabled
0D when 'Automatically detect settings' and 'Use automatic configuration script' are enabled
07 when 'Use a proxy server for your LAN' and 'Use automatic configuration script' are enabled
0F when all the three are enabled.
01 when none of them are enabled.
The next three bytes are zeros (Bytes 9 to B).
 
4) Byte number C (12 in decimal) contains the length of the proxy server address.For example a proxy server '127.0.0.1:80' has length 12 (length includes the dots and the colon).The next three bytes are zeros (Bytes D to F).

5) Byte 10 (or 16 in decimal) contains the proxy server address - like '127.0.0.1:80' (where 80 is obviously the port number)

6) the byte immediatley after the address contians the length of additional information.The next three bytes are zeros. For example if the 'Bypass proxy server for local addresses' is ticked, then this byte is 07,the next three bytes are zeros and then comes a string i.e. '<local>' (<local> indicates that you are bypassing the proxy server.Now since <local> has 7 characters, the length is 07!).
You will have to experiment on your own for finding more about this.
If you dont have any additional info then the length is 0 and no information is added.

7) The byte immediately after the additional info, is the length of the automatic configuration script address (If you dont have a script address then you dont need to add anything,skip this step and goto step 8).The next three bytes are zeros,then comes the address.

8) Finally, 32 zeros are appended.(I dont know why! Presumably to fill the binary blob, perhaps it is expected to be a certain length by something, don't you wish windows had some source?)

It's been quiet.

Yep I know haven't heard much from me lately. My work ( the stuff I do for a living ) changed buildings last Friday about a mile from where we were previously. Sooo it's pruddy much chaos, I'm typing to you now from a workstation covered in boxs and what not. Our network stuff is dodgy at best, lot's of things not working, so I have been tied up in that, along with our dodgy avaya phone system that is giving me greif.

I actually had to write a batch script yesterday to make internet on the new system work for our laptop users because the visual basic stuff the corporate IT department has ( which is a questionable hack at best ) doesn't work correctly. If you aren't familiar let me tell you, findstr is no substitute for sed and hacking windows registry binary entries with a batch file? Yeah... Fun stuff.

There still enough blocked at the upper corporate level that are tools that our HR department use a on daily basis, that I actually make another proxy here that utilizes tor , polipo, and squid, so people can actually get work done.

Ill get back to hacking phones, but frankly this move thing has occupied almost all my real free time.

The first of the RC5's

So some of you may have looked into the testbuild yesterday, it was a precursor to the RC5's being pushed out. We are getting super close to a 15 final so, you might also notice a couple cosmetic changes, and naming changes, version number changes.

What's in RC5 you ask, well I drug in a ton of good caf code. This means changes to all kinds of things, power management, i/o, adjustments across the board here. This also means this kernel should support the more recent evervolv stuff that Mason stopped working on a while ago when they merged up newer kgsl code. Additionally updated some of the governor code that was getting dated, and unified some things to do it our way. RC5 might be the last RC for this point release. You'll note that the numbering pattern went from v0.15 to 0.1.5. I think I understand now why Linus went to that scheme. It's really the only way to track changes.

Thanks to smelkus and mazdarider23 from Team D.I.R.T for taking that kgsl test build for a early spin for me, you can thank them for doing the leg work to make RC5's drop today as opposed to sometime later this week.

If you want to help the project along and want to test, I higly recommend you drop into #masonic on IRC freenode and idle there, so that I can reach you easy. I'm on too many forums and in too many places, to coordinate that kind of thing via PM. My gtalk has too many people to keep strait, much easier to just ask for a tester on IRC and respond to whoever sticks their hand up.

Mason EI 0.1.5 RC5 sbc

~atyoung

AOKP Progress

So I have been playing around with a few different builds, I finally decided to continue with the evervolv tree, and merge in the good stuff from theplayground. There are any number of reasons for this, but the primary one is, drewis is a mad genius and throws some crazy hacks out that boggle my mind for the 8x50 which is you supersonic people. So much good stuff is coming out of caf at the moment, I feel like that's where the future is for the supersonic so there it is.

That said, I still have a ton of work to do, AOKP has been plagued by random reboots in so many places, I'm trying to resolve some of them. So just because your seeing updates to Mason doesn't mean I'm not working on AOKP, quite the opposite, some of the changes coming to Mason are a direct result of working on the AOKP supersonic tree. So there it is, keep the faith, you'll be hearing from me soon.

When there is something worth testing publicly, you'll here it here first.

~atyoung

How bout some RC4 FSO love

I know you were waiting for these.

Mason I 0.15 RC4 sbc fso
Mason G 0.15 RC4 sbc fso

Enjoy. :)

~atyoung

Introducing RC4 into the mix.

What another RC? Yeah, pumping another one out for you to try. This one shouldn't break, but it's not as extensively tested as the previous ones. This is mostly due to time constraints, so if you're feeling scrappy give it a shot, it shouldn't eat your phone. I series for now, G a little later.

Mason I 0.15RC4 - sbc
Mason G 0.15RC4 - sbc

Mason I RC3 sbc + fso

So until today I hadden't noticed I didn't put one of these out for the I series so here you go. Flash away you ICS users you. FSO love is a good thing for hump day right? Thanks to mazdarider23 of Team D.I.R.T for calling my attention to it and testing the build prior to posting.

Download

TaTa for now.

~atyoung

AOKP development.

So by now you might have heard, I'm going to be maintaining the supersonic build of the official AOKP. With that comes a ton of work, and I do mean a ton. Things in the works, I'm going to be using what was being used for the decks previews, which should bring in the features everyone is looking for. The rom will also run on a specialized Mason, which should actually bring even more customization options, that the already impressive amounts available in the AOKP rom. I will also be looking at whats been broken for some time on the supersonic for AOKP and taking a stab at cleaning it up.

There is lots of work to be done here, and I do have a real life too, so if the speed on the supersonic releases is not strait in line with the other AOKP releases, I apologize in advance, but I feel like quality should come before quantity in this case. For way to long, the supersonic builds have had semi regular breakage, I'd like to restore some faith to the community here. 

What wont happen: You will not find me pushing a versions that hasn't tested out solid and bootable and functional on my supersonic personally, from full clean wipe. Which means, when there's a release, it's going to be legit. That's all for now, more when I get there.

~atyoung

FYI. You might find checking in here every so often a teaser tester much like I've done with the Mason kernels.

Mason G 0.15 RC3

Said I would put this out today, so here it is. There are quite a few changes from the previous RC including some changes to RCU that I thought was in previous one which I noted were decidedly not in there.

Mason I 0.15 RC3

Moving right along to Mason I 0.15 RC3 after the failures of RC2. I believe those issues were directly linked to the inclusion of lulzactive, which is conspicuously absent on this one. Other optimizations have been made, and it's starting to lean out as one would expect when pushing towards a version release.

I think I'm at a feature freeze as far as 15 goes at this point. It's time for clean up, the compile is still quite dirty, and there are a couple rough edges to clean out.

Have fun.

~atyoung

Road to Mason S 15

I never really intended to start from scratch on this one. However after playing around with the few established kernels out there, I found them wanting. Miscellaneous implementations of the HAVS code, different ideas about performance patching to various sub systems. All together unsavory, so I went back to the HTC source and started patching up from there.

What to expect from this upcoming is a brand spanking new kernel derived from the HTC source. So with this it means, you might not find the what looks to be commonly pass around weird patches that I can't seem to actually find the source of. If I can't see where it came from, or determine why it's in there. I'm not going to put it in. This also means Mason S might be rougher than the other lines of mason due to it's infancy. I will probably be releasing a test build of this kernel later today.

Little 15 Mason teaser

So there are a few people who have had this one for a little bit, but I thought I would toss it up to, you know, stir up Mason conversation. This one is non hwa, so don't try it on the latest ICS stuff unless you like it to be broken. It is by far not the complete 15 kernel by any stretch of the imagination, but it will give you a chance to play with a couple of the new features.

Next up we have ourselves a test build for the hwa enabled roms. This one was/is a feature testing build for improvements to zram and inclusion of zcache and related items. No one has this kernel until now. This kernel is probably the most unstable kernel I have ever released, it's really rough, but was built to test the zcache feature and not much else, stability of everything wasn't a concern. You might find that is also has some other changes including xz decompression as well as some improvements to the vr and sio schedulers. It's closer feature wise to the release of 15, but has some very experimental features enabled so your mileage will very. Don't complain if it eats your soul or does horrible things, as it's a tester, not meant for mass adoption, hell it might not even boot at all. How do you turn zram on in the first place you ask? These are the commands you need with superuser privileges in either a terminal emulator or adb shell.

mkswap /dev/block/zram0

swapon /dev/block/zram0

 If you don't know how to put those in, you probably shouldn't be messing with it. That is all.

~atyoung