Assume I want to set a page dirty in kernel, can I just emulate it like this:
#define PG_dirty 4
struct page page1;
page1.flags |= (1 << PG_dirty);
Then this page is marked dirty?
I see there is a macro in <mm.h>
#define SetPageDirty(page) set_bit(PG_dirty, &(page)->flags)
It seems that set_bit does a lot more things.
Related
I am learning Win32 API programming. I read this paragraph, it says:
https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-systemparametersinfoa
SPI_SETMOUSETRAILS
Enables or disables the Mouse Trails feature, which improves the visibility of mouse cursor movements by briefly showing a trail of cursors and quickly erasing them.
To disable the feature, set the uiParam parameter to zero or 1. To enable the feature, set uiParam to a value greater than 1 to indicate the number of cursors drawn in the trail.
Windows 2000: This parameter is not supported.
I tried to write the following code:
#include <windows.h>
int main(int argc, char *argv[], char *envp[])
{
//SystemParametersInfo(SPI_SETMOUSETRAILS, NULL,(PVOID)10, 0);
SystemParametersInfo(SPI_SETMOUSETRAILS, NULL,(PVOID)0, 0);
}
But it doesn't seem to make a difference.
Can anyone tell me how this macro works? I couldn't find an example on the Internet, so I am asking here.
Read the documentation again more carefully:
To disable the feature, set the uiParam parameter to zero or 1. To enable the feature, set uiParam to a value greater than 1 to indicate the number of cursors drawn in the trail.
Look at the declaration of the function:
BOOL SystemParametersInfoA(
UINT uiAction,
UINT uiParam,
PVOID pvParam,
UINT fWinIni
);
Your code is setting the uiParam parameter to 0 (disabling the feature), and setting the pvParam parameter to the cursor count (which is ignored).
Try this instead:
#include <windows.h>
int main(int argc, char *argv[], char *envp[])
{
UINT cursorCount = ...;
SystemParametersInfo(SPI_SETMOUSETRAILS, cursorCount, NULL, 0);
return 0;
}
I couldn't find an example on the Internet
Really? When I enter just SPI_SETMOUSETRAILS by itself into Google, literally the 1st link returned contains an example:
http://ntcoder.com/bab/tag/spi_setmousetrails/
SystemParametersInfo is a powerful function which does and retrieves whole lot of things related to windows general behavior for eg: turning on and off certain features like mouse trails which we normally do via control panel->main.cpl
Look up MSDN for more information on SystemParametersInfo. I’ll just show a demo on how to turn on and off mouse trails…
// Turn on mouse trails, showing 10 cursors drawn in the trail
SystemParametersInfo( SPI_SETMOUSETRAILS, 10, 0, 0 );
// Turn off mouse trails, set trail count to 1 or zero to disable trails
SystemParametersInfo( SPI_SETMOUSETRAILS, 1, 0, 0 );
System is basic but I have terrible problem and I can not solve it pls help me. When my system works PIC keep running but clear the registers 4-5 times in a day.
How system should work:
-I have a PIC, pneumatic cylinder and 3 sensor(works with 24V DC).
-Main sensor take the signal from another system.
-When a signal came from main sensor, if the cyclinder is backward, cylinder should go to forward until forward sensor see it and if the cylinder is forward, cyclinder should come to backward until backward sensor see it.
Program:
#include <16F628A.h>
#FUSES NOWDT //No Watch Dog Timer
#FUSES NOBROWNOUT //No brownout reset
#FUSES NOLVP //No low voltage prgming, B3(PIC16) or
B5(PIC18) used for I/O
#use delay(crystal=4000000)
#use fast_io(a)
#use fast_io(b)
#define goForward PIN_A0
#define comeBackward PIN_A1
#define main_sensor PIN_B0
#define positionSensorForward PIN_B5
#define positionSensorBackward PIN_B4
int1 pistonPositionedForward=0, pistonPositionedBackward=1;
int1 positionForwardReg=0, positionBackwardReg=0;
int1 pistonForwarding=0, pistonBackwarding=0;
#priority rb,ext
#int_RB NOCLEAR
void B_change()
{
positionForwardReg=input(positionSensorForward);
positionBackwardReg=input(positionSensorBackward);
if(positionForwardReg&&pistonForwarding) //if forwarding and forward sensor see
{
disable_interrupts(INT_RB);
output_low(goForward);
pistonPositionedForward=1;
pistonPositionedBackward=0;
write_eeprom(0,1);
write_eeprom(1,0);
pistonForwarding=0;
pistonBackwarding=0;
clear_interrupt(int_ext);
enable_interrupts(INT_EXT);
}
else if(positionBackwardReg&&pistonBackwarding) //if backwarding and backward sensor see
{
disable_interrupts(INT_RB);
output_low(comeBackward);
pistonPositionedForward=0;
pistonPositionedBackward=1;
write_eeprom(0,0);
write_eeprom(1,1);
pistonForwarding=0;
pistonBackwarding=0;
clear_interrupt(int_ext);
enable_interrupts(INT_EXT);
}
clear_interrupt(int_rb);
}
#int_ext NOCLEAR
void ext_interrupt()
{
disable_interrupts(INT_EXT);
positionForwardReg=input(positionSensorForward);
positionBackwardReg=input(positionSensorBackward);
if(positionForwardReg^positionBackwardReg) //if one of position sensor is see then position according to sensor, else position according to memory
{
pistonPositionedForward=positionForwardReg;
pistonPositionedBackward=positionBackwardReg;
}
if(pistonPositionedForward)
{
pistonBackwarding=1;
pistonForwarding=0;
output_high(comeBackward);
clear_interrupt(int_rb);
enable_interrupts(INT_RB);
}
else if(pistonPositionedBackward)
{
pistonForwarding=1;
pistonBackwarding=0;
output_high(goForward);
clear_interrupt(int_rb);
enable_interrupts(INT_RB);
}
clear_interrupt(int_ext);
}
void main()
{
//to remember last position after power off
pistonPositionedForward=read_eeprom(0);
pistonPositionedBackward==read_eeprom(1);
set_tris_a(0x00);
set_tris_b(0xFF);
output_a(0x00);
delay_ms(1000);
ext_int_edge(L_TO_H);
clear_interrupt(int_ext);
enable_interrupts(INT_EXT);
enable_interrupts(GLOBAL);
while(TRUE)
{
}
}
And my circuit:
CIRCUIT
*j2,j3 connected selonoid valve
*J4,J5,J6 connected 3 sensors 1. pin +24VDC,2. pin GND, 3.pin sensor data
***B1 and B2 connections changed. Now B1 connected to B5,B2 connected to B4
And These are I tried:
-I have 3 PIC all of them do same thing
-I changed 24V power supply
-I cancelled 7805 and 7812 and I connected seperate 5V power supply istead of 7805.
I am debugging via LEDs. Sometimes system stop running just waiting at one of positions. Take main sensor signal but doesnot anything, And pistonPositionedForward and pistonPositionedBackward register values are 0. I cant find problem how can it clear these registers?
You have unconnected pins on RB that are configured as inputs, with no internal pull ups set. Electrical noise may well trigger unwanted interrupts on PORTB, that has been known to happen.
The use of interrupts is making the overall logic a bit hard to follow for such a simple device. Have you tried rewriting the program NOT using interrupts (except maybe for EXT)? It should not take long and I think it may greatly improve the reliability - and maintainability, without impacting performance of the physical system.
I suggest you first configure the unused PORTA and PORTB pins as outputs, and see if the problem goes away. If that fails, a rewrite not using interrupts should take no more than an hour. This would probably make sense since that is probably way shorter than the time you have already spent chasing the issue.
Reading the description, I came up with this solution.
#include <16F628A.h>
#FUSES NOWDT //No Watch Dog Timer
#FUSES NOBROWNOUT //No brownout reset
#FUSES NOLVP //No low voltage prgming, B5(PIC18) used for I/O
#use delay(crystal=4000000)
#use fast_io(a)
#use fast_io(b)
#define FWD_MOVE PIN_A0
#define BACK_MOVE PIN_A1
#define PORTA_RESET (0x00) // outputs=LO, unused pins as outputs
#define PORTA_TRISTATE (0x00)
#define EXT_SENSOR PIN_B0
#define FWD_REST PIN_B5
#define BACK_REST PIN_B4
#define PORTB_RESET (0xCE) // can't use pull ups because of HW logic...
#define PORTB_TRISTATE (0x31)
#define EEPROM_STATUS_ADDR (0x0000)
#define EEPROM_STATUS_FWD (0x01)
#define EEPROM_STATUS_BACK (0x00)
int1 extLast;
int1 extCur;
void main()
{
// setup
output_a(PORTA_RESET):
output_b(PORTB_RESET):
// setting to last known state...
// safety check.
output_low(FWD_MOVE);
output_low(BACK_MOVE);
// This will activate the outputs to make sure we have good
// positioning.
switch(eeprom_read(EEPROM_STATUS_ADDR))
{
default: // EEPROM error... I'll let you decide what to do here.
// either move forward or back.
// this implementation goes back by default.
eeprom_write(EEPROM_STATUS_ADDR, EEPROM_STATUS_BACK);
disable_interrupts(GLOBAL);
// falling through...
case EEPROM_STATUS_BACK:
output_high(BACK_MOVE);
break;
case EEPROM_STATUS_FWD:
output_high(FWD_MOVE);
break;
}
// activate outputs... watch your fingers!
set_tris_a(PORTA_TRISTATE);
set_tris_b(PORTB_TRISTATE);
extLast = input(EXT_SENSOR);
for (;;)
{
// read external sensor, take action.
extCur = input(EXT_SENSOR);
if (extCur && !extlast)
{
// safety check.
output_low(FWD_MOVE);
output_low(BACK_MOVE);
// control logic
switch(eeprom_read(EEPROM_STATUS_ADDR))
{
default: // should never happen.
// falling through...
case EEPROM_STATUS_BACK:
output_high(FWD_MOVE);
eeprom_write(EEPROM_STATUS_ADDR, EEPROM_STATUS_FWD);
disable_interrupts(GLOBAL);
break;
case EEPROM_STATUS_FWD:
output_high(BACK_MOVE);
eeprom_write(EEPROM_STATUS_ADDR, EEPROM_STATUS_BACK);
disable_interrupts(GLOBAL);
break;
}
}
extLast = extCur;
// mechanical interface:
// read the limit guards and stop movement when done.
if (input(FWD_REST))
{
output_low(FWD_MOVE);
}
if (input(BACK_REST))
{
output_low(BACK_MOVE);
}
}
}
Of course, I could not check the above code on-site :).
After reviewing the schematics, I must also advise to add 1N4001 diodes in parallel of the 2 output MOSFETS to give them better protection against reverse voltage spikes. MOSFET built-in diodes are not very sturdy. 1N4148 or 1N914 would work there as well.
The 16F628 has very limited stack space. It looks like you are experiencing stack overflow during the call to write_eeprom. Calling write_eeprom from an interrupt may not be such a good idea after all.
There was a bug in older CCS compilers, related to the use of write_eeprom. It seems write_eeprom is enabling interrupts during the call. I've added calls to disable interrupts after the writes. I don't know if that bug was fixed, since I never use CCS.
[EDIT] after checking your HW. I realized you cannot use internal pull-ups because the HW logic is positive-going. The pull-ups in the PIC are meant to work with NPN transistors in the open collector configuration (emitter to ground). I changed the code accordingly.
The way you write to EEPROM is not good. eeprom writes take time, and the second write is usually taken care of in the eeprom interrupt. The CCS bug that enables the global interrupt and unmask the EEIE in eeprom_write does not help. Unhandled interrupts do generate a reset.
In order to add a toolbar to my MFC dialog baced class, I tried all ways of adding resources>toolbars but they didn't work. Finally I came up to the point to create a toolbar dynamically. This is the code that I have used:
Resource.h
#define IDB_PanTbrBtn 139
#define IDB_NewTbrBtn 140
#define IDB_ZoomInTbrBtn 141
#define IDB_ZoomOutTbrBtn 142
#define IDC_FirstToolBar 1011
#define IDC_NEWTBRBTN 1012
#define IDC_ZOOMINTBRBTN 1013
#define IDC_ZOOMOUTTBRBTN 1014
#define IDC_PANTBRBTN 1015
InitialJobProject2Dlg.h : header file for the dialog baced project
#pragma once
#include "WndResizer.h"
#include "afxdlgs.h"
#include "FilesWorkFlow.h"
#include "OpenGLControl.h"
CWndResizer m_resizer;
CMFCToolBar m_FirstToolBar;
FilesWorkFlow *m_files;
COpenGLControl *m_oglWindow;
InitialJobProject2Dlg.cpp : the codes related to the toolbar in the function OnInitDialog()
bool bAnchored = false;
bAnchored = m_resizer.Hook(this);
assert(bAnchored);
bool ToolbarCreated = m_FirstToolBar.CreateEx(this, AFX_DEFAULT_TOOLBAR_STYLE, 100 );
if(ToolbarCreated)
{
m_FirstToolBar.SetDlgCtrlID(IDC_FirstToolBar);
bAnchored = m_resizer.SetAnchor(IDC_FirstToolBar,ANCHOR_LEFT | ANCHOR_TOP);
assert(bAnchored);
m_FirstToolBar.SetPaneStyle(m_FirstToolBar.GetPaneStyle() & ~(CBRS_GRIPPER|CBRS_SIZE_DYNAMIC|CBRS_BORDER_ANY));
VERIFY(m_FirstToolBar.LoadBitmapW(IDB_NewTbrBtn));
VERIFY(m_FirstToolBar.GetImages()->Load(IDB_NewTbrBtn,nullptr,TRUE));
int imageIndex = m_FirstToolBar.GetImages()->GetCount();
m_FirstToolBar.InsertButton(CMFCToolBarButton(IDC_NEWTBRBTN,imageIndex));
VERIFY(m_FirstToolBar.LoadBitmapW(IDB_PanTbrBtn));
VERIFY(m_FirstToolBar.GetImages()->Load(IDB_PanTbrBtn,nullptr,TRUE));
imageIndex = m_FirstToolBar.GetImages()->GetCount();
m_FirstToolBar.InsertButton( CMFCToolBarButton( IDC_PANTBRBTN,imageIndex));
VERIFY(m_FirstToolBar.LoadBitmapW(IDB_ZoomInTbrBtn));
VERIFY(m_FirstToolBar.GetImages()->Load(IDB_ZoomInTbrBtn,nullptr,TRUE));
imageIndex = m_FirstToolBar.GetImages()->GetCount();
m_FirstToolBar.InsertButton( CMFCToolBarButton( IDC_ZOOMINTBRBTN,imageIndex));
VERIFY(m_FirstToolBar.LoadBitmapW(IDB_ZoomOutTbrBtn));
VERIFY(m_FirstToolBar.GetImages()->Load(IDB_ZoomOutTbrBtn,nullptr,TRUE));
imageIndex = m_FirstToolBar.GetImages()->GetCount();
m_FirstToolBar.InsertButton(CMFCToolBarButton(IDC_ZOOMOUTTBRBTN,imageIndex));
CSize size = m_FirstToolBar.CalcFixedLayout( FALSE, TRUE );
m_FirstToolBar.SetWindowPos( NULL, 0, 0, size.cx + 10, size.cy + 10 , SWP_NOACTIVATE | SWP_NOZORDER );
}
this is my project's resource view:
and this one is the res folder of my program:
images that I want to be shown as the icons of toolbar buttons are 48x48 ,32 bit depth bitmap images but I had the same problem with 24x24 ones
The problem is when I run the program:
IT's clear that there is just one button as the toolbar button but I have inserted four buttons dynamically as you see in the code.
and the image is not shown even for this known button.
My code does not have any compiler or run-time error so I don't understand what is happening and whats the problem?
and since I'm new to MFC(this is my first program of MFC) I didn't know that adding a toolbar to a dialog-based application is such a hard task!!!! **
**So I created a dialog-based project at start and now that my program has been developed, I do need a toolbar
please help me. this is the forth question I have posted about adding a toolbar on a dialog based MFC application.
after writing the code to add a toolbar to a dialog-based mfc the dialog doesn't run
My toolbar on a dialog based mfc application is not shown
having trouble with LoadToolBarEx function of the CMFCToolBar class and set ID for the COpenGLControl class
But the problem has not been completely solved yet?
**Please introduce me a good reference that has taught adding toolbars to the MFC dialogs step by step from the scratch and has been useful for yourself
Oh and if there's a need to my project, it is downloadable here
as #Edward Clements suggested I changed the code to this but nothing changed.
VERIFY(m_FirstToolBar.LoadBitmap(IDB_NewTbrBtn));
m_FirstToolBar.InsertButton(CMFCToolBarButton(IDC_NEWTBRBTN,1));
VERIFY(m_FirstToolBar.LoadBitmap(IDB_PanTbrBtn));
m_FirstToolBar.InsertButton( CMFCToolBarButton( IDC_PANTBRBTN,2));
VERIFY(m_FirstToolBar.LoadBitmap(IDB_ZoomInTbrBtn));
m_FirstToolBar.InsertButton( CMFCToolBarButton( IDC_ZOOMINTBRBTN,3));
VERIFY(m_FirstToolBar.LoadBitmap(IDB_ZoomOutTbrBtn));
m_FirstToolBar.InsertButton(CMFCToolBarButton(IDC_ZOOMOUTTBRBTN,4));
Firstly, according to the MFC sources, LoadBitmap() [NOT LoadBitmapW(), that seems to happen because of VS Intellisense picking up a #define from WinUser.h] adds the bitmap to the image list, so calling m_FirstToolBar.GetImages()->Load() will load the image twice.
Secondly, the InsertButton() should specify the index of the image of the button, m_FirstToolBar.GetImages()->GetCount() will always point to an invalid index value.
VERIFY(m_FirstToolBar.LoadBitmap(IDB_NewTbrBtn));
VERIFY(m_FirstToolBar.LoadBitmap(IDB_PanTbrBtn));
VERIFY(m_FirstToolBar.LoadBitmap(IDB_ZoomInTbrBtn));
VERIFY(m_FirstToolBar.LoadBitmap(IDB_ZoomOutTbrBtn));
m_FirstToolBar.InsertButton(CMFCToolBarButton(IDC_NEWTBRBTN, 0));
m_FirstToolBar.InsertButton(CMFCToolBarButton(IDC_PANTBRBTN, 1));
m_FirstToolBar.InsertButton(CMFCToolBarButton(IDC_ZOOMINTBRBTN, 2));
m_FirstToolBar.InsertButton(CMFCToolBarButton(IDC_ZOOMOUTTBRBTN, 3));
Is it hard coded into gcc's source or fetched somehow programatically?
I think it is hardcoded in arch-specific folder, e.g. for sparc
http://www.google.com/codesearch#Yj7Hz1ZInUg/trunk/gcc-4.2.1/gcc/config/sparc/sparc.h
/* No data type wants to be aligned rounder than this. */
#define BIGGEST_ALIGNMENT (TARGET_ARCH64 ? 128 : 64)
/* The best alignment to use in cases where we have a choice. */
#define FASTEST_ALIGNMENT 64
...
/* Make strings word-aligned so strcpy from constants will be faster. */
#define CONSTANT_ALIGNMENT(EXP, ALIGN) \
((TREE_CODE (EXP) == STRING_CST \
&& (ALIGN) < FASTEST_ALIGNMENT) \
? FASTEST_ALIGNMENT : (ALIGN))
/* Make arrays of chars word-aligned for the same reasons. */
#define DATA_ALIGNMENT(TYPE, ALIGN) \
(TREE_CODE (TYPE) == ARRAY_TYPE \
&& TYPE_MODE (TREE_TYPE (TYPE)) == QImode \
&& (ALIGN) < FASTEST_ALIGNMENT ? FASTEST_ALIGNMENT : (ALIGN))
and sparc.c in the same folder.
Some basic alignment rules are defined in gcc/tree.c e.g. for void:
/* We are not going to have real types in C with less than byte alignment,
so we might as well not have any types that claim to have it. */
TYPE_ALIGN (void_type_node) = BITS_PER_UNIT;
TYPE_USER_ALIGN (void_type_node) = 0;
It will be compiled into gcc in the build process.
So, default aligns are compiled in, but can be changed by manipulating TREE type objects from the gcc code.
UPDATE: x86 config has better comments:
/* Minimum size in bits of the largest boundary to which any
and all fundamental data types supported by the hardware
might need to be aligned. No data type wants to be aligned
rounder than this.
Pentium+ prefers DFmode values to be aligned to 64 bit boundary
and Pentium Pro XFmode values at 128 bit boundaries. */
#define BIGGEST_ALIGNMENT 128
/* Decide whether a variable of mode MODE should be 128 bit aligned. */
#define ALIGN_MODE_128(MODE) \
((MODE) == XFmode || SSE_REG_MODE_P (MODE))
/* The published ABIs say that doubles should be aligned on word
boundaries, so lower the alignment for structure fields unless
-malign-double is set. */
/* ??? Blah -- this macro is used directly by libobjc. Since it
supports no vector modes, cut out the complexity and fall back
on BIGGEST_FIELD_ALIGNMENT. */
...
#define BIGGEST_FIELD_ALIGNMENT 32
...
/* If defined, a C expression to compute the alignment given to a
constant that is being placed in memory. EXP is the constant
and ALIGN is the alignment that the object would ordinarily have.
The value of this macro is used instead of that alignment to align
the object.
If this macro is not defined, then ALIGN is used.
The typical use of this macro is to increase alignment for string
constants to be word aligned so that `strcpy' calls that copy
constants can be done inline. */
#define CONSTANT_ALIGNMENT(EXP, ALIGN) ix86_constant_alignment ((EXP), (ALIGN))
/* If defined, a C expression to compute the alignment for a static
variable. TYPE is the data type, and ALIGN is the alignment that
the object would ordinarily have. The value of this macro is used
instead of that alignment to align the object.
If this macro is not defined, then ALIGN is used.
One use of this macro is to increase alignment of medium-size
data to make it all fit in fewer cache lines. Another is to
cause character arrays to be word-aligned so that `strcpy' calls
that copy constants to character arrays can be done inline. */
#define DATA_ALIGNMENT(TYPE, ALIGN) ix86_data_alignment ((TYPE), (ALIGN))
/* If defined, a C expression to compute the alignment for a local
variable. TYPE is the data type, and ALIGN is the alignment that
the object would ordinarily have. The value of this macro is used
instead of that alignment to align the object.
If this macro is not defined, then ALIGN is used.
One use of this macro is to increase alignment of medium-size
data to make it all fit in fewer cache lines. */
#define LOCAL_ALIGNMENT(TYPE, ALIGN) ix86_local_alignment ((TYPE), (ALIGN))
...
/* Set this nonzero if move instructions will actually fail to work
when given unaligned data. */
#define STRICT_ALIGNMENT 0
For arm, mips, sparc, and others archs (which limits unaligned access to memory) the alignment requires of any machine instruction may be recorded in arch.md file (e.g. in sparc.md)
Is it possible to replace the Mac OS X login window, /System/Library/CoreServices/loginwindow.app, with a custom login window application? (See my rational for doing so.)
I'm afraid my Cocoa programming skills are rudimentary. I do find it interesting that, when I run probe CGSession (which is a undocumented utility that performs fast user switching) to see what functions it uses, by doing
nm -mg /System/Library/CoreServices/Menu\ Extras/User.menu/Contents/Resources/CGSession
that one of the linked function is:
(undefined [lazy bound]) external _CGSCreateLoginSession (from ApplicationServices)
I haven't found documentation on the ApplicationServices framework. I suspect I'm getting deep into Service Provider Interfaces instead of Application Programmer Interfaces.
I did find this really interesting snippet: (google cache) (direct link to down page; it appears the site is undergoing re-organization) from an application that claims to switch to the login window even if fast user switching is disabled.
#include "CGSInternal.h"
int main (int argc, const char * argv[]) {
// switch to the login window
CGSCreateLoginSession(NULL);
return 0;
}
I take CG to mean CoreGraphics, and don't understand what that has to do with logging in (except with perhaps putting a login dialog up over the current user's work).
Even if it is not possible to achieve a replacement for the login window, I'd be interested to know what can be done along these lines (by people who don't work for Apple).
The login window application is defined as part of the launchd configuration in /System/Library/LaunchDaemons/com.apple.loginwindow.plist.
In theory you can replace the login window with your own but I don't know what you have to do in the new app - I think the login window does a bit more then authentication and setting up the user session -> amongst others, it looks like its doing some launchd related chores.
I've compiled an application that calls CGSCreateLoginSession and once you run it it transitions to the login window via the rotating cube. I imagine this is why it requires CoreGraphics - it's just a graphics function that calls logout at the end.
You could try an InputManager and see it the login window loads the code -> if it does, you could then alter the loginwindow NIB (LoginWindowUI.nib) and add some buttons to display a new window with the user browser. Once the student chooses a picture of him/herself you could autofill the username and password fields in the loginwindow.
Node this is all theory, and it looks very fragile and unsafe.
Good luck.
Later edit
Please note this is very unsafe so use with care - I did hose my system a couple of times when trying out this stuff
Here's a proof-of-concept implementation that injects code in the loginwindow.
#include <stdio.h>
#include <unistd.h>
#include <sys/time.h>
#include <strings.h>
#include <syslog.h>
#import <Cocoa/Cocoa.h>
#include <execinfo.h>
#interface LLApp:NSApplication
#end
#implementation LLApp
- (void)run
{
syslog(LOG_ERR, "LLApp being run");
[super run];
}
#end
void my_openlog(const char *ident, int logopt, int facility);
typedef struct interpose_s
{
void * new_func;
void * orig_func;
} interpose_t;
int MyNSApplicationMain(int argc, const char ** argv);
static const interpose_t interposers[] __attribute__ ((section("__DATA, __interpose"))) = {
{ (void *) my_openlog, (void *) openlog },
};
void my_openlog(const char *ident, int logopt, int facility)
{
openlog(ident, logopt, facility);
if(!strcmp(ident, "/System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow"))
{
[LLApp poseAsClass:[NSApplication class]];
}
else
{
syslog(LOG_ERR, "Ignoring unknown indent: >%s<", ident);
}
return;
}
The code compiles with:
gcc -Wall -dynamiclib -undefined dynamic_lookup -o ~/Desktop/libinterposers.dylib testin.m -framework Cocoa
Code loading is based on interposing so the launchd definition of loginwindow has to contain an additional entry (to enable interposing in the dynamic linker), i.e.:
<key>EnvironmentVariables</key>
<dict>
<key>DYLD_INSERT_LIBRARIES</key>
<string>path_to/Desktop/libinterposers.dylib</string>
</dict>
yes, you can use the SFAuthorizationPluginView
here the reference link at ADC