RE: RFC: WMI Enhancements

[Mario.Limonciello]

> -----Original Message-----
> From: Pali RohÃr [mailto:pali.rohar@xxxxxxxxx]
> Sent: Tuesday, May 9, 2017 2:29 AM
> To: Limonciello, Mario <Mario_Limonciello@xxxxxxxx>
> Cc: dvhart@xxxxxxxxxxxxx; rjw@xxxxxxxxxxxxx; luto@xxxxxxxxxxxxxx;
> len.brown@xxxxxxxxx; corentin.chary@xxxxxxxxx; luto@xxxxxxxxxx;
> andriy.shevchenko@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; platform-
> driver-x86@xxxxxxxxxxxxxxx; linux-pm@xxxxxxxxxxxxxxx
> Subject: Re: RFC: WMI Enhancements
> 
> On Tuesday 09 May 2017 01:10:54 Mario.Limonciello@xxxxxxxx wrote:
> > >
> > > I found dmsdos implementation of that DS compression at:
> > > http://cmp.felk.cvut.cz/~pisa/dmsdos
> > >
> > > Then took relevant decompression code and it really decompressed that
> > > binary MOF WMI buffer. But still decompressed format is binary, but I
> > > now see all WMI GUID encoded in UTF-16. Decompressed BMF file has again
> > > "FOMB" magic header.
> >
> > Well that's great.  Is it possible that this compression is used for every time
> > a class was declared?
> 
> Looks like not. That decompressed output seems to be not compressed
> anymore. Just use same magic header.
Actually it looks like a new magic header to me after decompressed.

46 4f 4d 42 54 15 00 00  01 00 00 00 01 00 00 00
That's now FOMBT

> 
> Now it looks like binary representation of MOF. Where structures and
> types are encoded by binary sequences.
Yes, and I notice in here even mentions of the locale (which was required
to decompress using mofcomp too).

00000150  08 00 00 00 00 00 00 00  10 00 00 00 4c 00 6f 00  |............L.o.|
00000160  63 00 61 00 6c 00 65 00  00 00 00 00 4d 00 53 00  |c.a.l.e.....M.S.|
00000170  5c 00 30 00 78 00 34 00  30 00 39 00 00 00 00 00  |\.0.x.4.0.9.....|

> 
> > >
> > > I pushed my decompression utility here:
> > > https://github.com/pali/bmfdec
> >
> > Did you forget another commit for pulling in arguments and opening a file
> > or were you just putting the whole buffer into pin?
> 
> Whole BMF file should be on stdin (with that 16 bytes header) and is
> decompressed on stdout.
Oh my mistake, that wasn't clear when I glanced at it.