Lines Matching refs:first
24 I first looked in Wine in misc/registry.c and was also influenced by
42 the first 64 bytes seem to be used and a checksum is calculated over
43 the first 0x200 bytes only!
62 marked with ???? the rest of the first 4kb page is not important...
135 All offset-values are relative to the first hbin-block and point to the
204 0x0004 D-Word ASCII: the first 4 characters of the key-name, padded with 0's. Case sensitiv!
252 | first sub | | | | Usage cnt. |
260 | first sub |------+ +------------+ | xxxxx |
650 * Iterate over the keys, depth first, calling a function for each key
661 int first, int last);
725 /* List the key first, then the values, then the sub-keys */
786 * Take the first component and search for that in the list
819 * Make sure that the first component is correct ...
1167 * we don't find any. There must be a match on the first component ...
1377 * If we reach here we could not find the the first component
1444 * Look until we hit the first component that does not exist, and
1445 * then add from there. However, if the first component does not
1462 * first component ...
1769 * ndx already points at the first entry of the new block
2249 * The -1 accounts for the fact that we included the first byte of
2424 /* Update the last mod date, and then go get the first NK record and on */
2442 * Get a pointer to the first key from the hreg_hdr
2777 * Windows lays out the DACL first, but since there is no SACL, it might be
2778 * that first, then the owner, then the group SID. So, we do it that way
2790 * Now, fill in the first two fields, then lay out the various fields
2908 * We store this depth first, and defer storing the lf struct until
3010 * The structures are stored in a depth-first fashion, with all records
3012 * the lists that contain them. SK records are layed down first, however.
3028 * Store the first key, which will store the whole thing
3920 void *data_blk, int terminal, int first, int last)
3925 if (!terminal && first)