Related
#NoEnv
SendMode Input
SetWorkingDir %A_ScriptDir%
#SingleInstance force
MuteMic() {
local MM
SoundSet, +1, MASTER:1, MUTE, 9 ; my mic is on 9
SoundGet, MM, MASTER:1, MUTE, 9 ; my mic is on 9
#Persistent
return
}
!Alt+m::MuteMic()
It does not work, here is my current drivers. I am currently on Windows 10 version 1803 (build 17134.1) My hot key is Alt+m. Thanks for the help and input! XD
Master = Speakers, not your Mic, so in essence, you are muting your speakers, not your mic (I think).
What happens when you replace Master with Headphone or Microphone? And also, are you able to move it from outlet #9 to something more direct like #1 or something?
I found this to see if you are REALLY on 9 or not, https://autohotkey.com/docs/commands/SoundSet.htm#Ex but you may have run this already to determine it was on 9.
Issues with your code:
Your hotkey definition
You don't need #Persistent, certainly not in a function in any case.
Try:
!m::
MuteMic() {
SoundSet +1, Microphone:1, MUTE, 9 ; my mic is on 9
SoundGet MM, Microphone:1, MUTE, 9 ; Why do you do this when you're not using it?
}
If you don't really need the value for MM, it could be further simplified to:
!m::SoundSet +1, Microphone:1, MUTE, 9
I've been doing some research, but I only find more and more ways to do what I want and I don't understand any of them.
What code do I need to assemble into an .exe to return 5 to the command line?
I want an exe that, when called, prints 5 .
Research:
printf "5", 0
It requires to link with 2 libraries, and I want to keep it simple.
move ebx, 5 ; or move ax, 5
ret
Why would this print 5 ? This loads a register whith a value 5 and returns. Nothing else.
Could someone explain me the difference between those ways of returning 5?
What would be most appropiate for a very simple Windows EXE executable?
I couldn't get the answers in the questions already asked in StackOverflow.
NOTE, I use: Win 7, WinAsam, MASM
THANKS!
Why not use printf? On windows, it is part of the MS C Runtime that is part of windows now.
Using the Windows API, you would use:
GetStdHandle
And one of the following:
WriteConsole
WriteConsoleOutput
WriteConsoleOutputAttribute
WriteConsoleOutputCharacter
WriteFile
All depends on how you want to do it.
moving something into a register does not print anything, you have to tell the OS to print it.
If you find something that you don't understand, do some research on it, read the documentation, code comments, play around with the code changing things and see how it works.
Operating System: Windows XP 64 bit, SP2.
I have an unusual problem. I am porting some code from 32 bit to 64 bit. The 32 bit code works just fine. But when I call CreateThread() for the 64 bit version the call fails. I have three places where this fails. 2 call CreateThread(). 1 calls beginthreadex() which calls CreateThread().
All three calls fail with error code 0x3E6, "Invalid access to memory location".
The problem is all the input parameters are correct.
HANDLE h;
DWORD threadID;
h = CreateThread(0, // default security
0, // default stack size
myThreadFunc, // valid function to call
myParam, // my param
0, // no flags, start thread immediately
&threadID);
All three calls to CreateThread() are made from a DLL I've injected into the target program at the start of the program execution (this is before the program has got to the start of main()/WinMain()). If I call CreateThread() from the target program (same params) via say a menu, it works. Same parameters etc. Bizarre.
If I pass NULL instead of &threadID, it still fails.
If I pass NULL as myParam, it still fails.
I'm not calling CreateThread from inside DllMain(), so that isn't the problem. I'm confused and searching on Google etc hasn't shown any relevant answers.
If anyone has seen this before or has any ideas, please let me know.
Thanks for reading.
ANSWER
Short answer: Stack Frames on x64 need to be 16 byte aligned.
Longer answer:
After much banging my head against the debugger wall and posting responses to the various suggestions (all of which helped in someway, prodding me to try new directions) I started exploring what-ifs about what was on the stack prior to calling CreateThread(). This proved to be a red-herring but it did lead to the solution.
Adding extra data to the stack changes the stack frame alignment. Sooner or later one of the tests gets you to 16 byte stack frame alignment. At that point the code worked. So I retraced my steps and started putting NULL data onto the stack rather than what I thought was the correct values (I had been pushing return addresses to fake up a call frame). It still worked - so the data isn't important, it must be the actual stack addresses.
I quickly realised it was 16 byte alignment for the stack. Previously I was only aware of 8 byte alignment for data. This microsoft document explains all the alignment requirements.
If the stackframe is not 16 byte aligned on x64 the compiler may put large (8 byte or more) data on the wrong alignment boundaries when it pushes data onto the stack.
Hence the problem I faced - the hooking code was called with a stack that was not aligned on a 16 byte boundary.
Quick summary of alignment requirements, expressed as size : alignment
1 : 1
2 : 2
4 : 4
8 : 8
10 : 16
16 : 16
Anything larger than 8 bytes is aligned on the next power of 2 boundary.
I think Microsoft's error code is a bit misleading. The initial STATUS_DATATYPE_MISALIGNMENT could be expressed as a STATUS_STACK_MISALIGNMENT which would be more helpful. But then turning STATUS_DATATYPE_MISALIGNMENT into ERROR_NOACCESS - that actually disguises and misleads as to what the problem is. Very unhelpful.
Thank you to everyone that posted suggestions. Even if I disagreed with the suggestions, they prompted me to test in a wide variety of directions (including the ones I disagreed with).
Written a more detailed description of the problem of datatype misalignment here: 64 bit porting gotcha #1! x64 Datatype misalignment.
The only reason that 64bit would make a difference is that threading on 64bit requires 64bit aligned values. If threadID isn't 64bit aligned, you could cause this problem.
Ok, that idea's not it. Are you sure it's valid to call CreateThread before main/WinMain? It would explain why it works in a menu- because that's after main/WinMain.
In addition, I'd triple-check the lifetime of myParam. CreateThread returns (this I know from experience) long before the function you pass in is called.
Post the thread routine's code (or just a few lines).
It suddenly occurs to me: Are you sure that you're injecting your 64bit code into a 64bit process? Because if you had a 64bit CreateThread call and tried to inject that into a 32bit process running under WOW64, bad things could happen.
Starting to seriously run out of ideas. Does the compiler report any warnings?
Could the bug be due to a bug in the host program, rather than the DLL? There's some other code, such as loading a DLL if you used __declspec(import/export), that occurs before main/WinMain. If that DLLMain, for example, had a bug in it.
I ran into this issue today. And I checked every argument feed into _beginthread/CreateThread/NtCreateThread via rohitab's Windows API Monitor v2. Every argument is aligned properly (AFAIK).
So, where does STATUS_DATATYPE_MISALIGNMENT come from?
The first few lines of NtCreateThread validate parameters passed from user mode.
ProbeForReadSmallStructure (ThreadContext, sizeof (CONTEXT), CONTEXT_ALIGN);
for i386
#define CONTEXT_ALIGN (sizeof(ULONG))
for amd64
#define STACK_ALIGN (16UI64)
...
#define CONTEXT_ALIGN STACK_ALIGN
On amd64, if the ThreadContext pointer is not aligned to 16 bytes, NtCreateThread will return STATUS_DATATYPE_MISALIGNMENT.
CreateThread (actually CreateRemoteThread) allocated ThreadContext from stack, and did nothing special to guarantee the alignment requirement is satisfied. Things will work smoothly if every piece of your code followed Microsoft x64 calling convention, which unfortunately not true for me.
PS: The same code may work on newer Windows (say Vista and newer). I didn't check though. I'm facing this issue on Windows Server 2003 R2 x64.
I'm in the business of using parallel threads under windows
for calculations. No funny business, no dll-calls, and certainly
no call-back's. The following works in 32 bits windows. I set up the stack for my calculation, well within the area reserved for my program.
All releveant data about area's and start addresses is contained in
a data structure that is passed to CreateThread as parameter 3.
The address that is called contains a small assembler routine
that uses this data stucture.
Indeed this routine finds the address to return to on the stack,
then the address of the data structure.
There is no reason to go far into this. It just works and it calculates
the number of primes below 2,000,000,000 just fine, in one thread,
in two threads or in 20 threads.
Now CreateThread in 64 bits doesn't push the address of the data
structure. That seems implausible so I show you the smoking gun,
a dump of a debug session.
In the subwindow at the bottom right you see the stack, and
there is merely the return address, amidst a sea of zeroes.
The mechanism I use to fill in parameters is portable between 32 and 64 bits.
No other call exhibits a difference between word-sizes.
Moreover why would the code address work but not the data address?
The bottom line: one would expect that CreateThread passes the data parameter on the stack in the same way in 64 bits as in 32 bits, then does a subroutine call. At the assembler level it doesn't work that way. If there are any hidden requirements to e.g. RSP that are automatically fullfilled in C++ that would be very nasty.
P.S. No there are no 16 byte alignment problems. That lies ages behind me.
Try using _beginthread() or _beginthreadex() instead, you shouldn't be using CreateThread directly.
See this previous question.
I wrote a program about 10 years ago in Visual Basic 6 which was basically a full-screen game similar to Breakout / Arkanoid but had 'demoscene'-style backgrounds. I found the program, but not the source code. Back then I hard-coded the display mode to 800x600x24, and the program crashes whenever I try to run it as a result. No virtual machine seems to support 24-bit display when the host display mode is 16/32-bit. It uses DirectX 7 so DOSBox is no use.
I've tried all sorts of decompiler and at best they give me the form names and a bunch of assembly calls which mean nothing to me. The display mode setting was a DirectX 7 call but there's no clear reference to it in the decompilation.
In this situation, is there any pointers on how I can:
pin-point the function call in the program which is setting the display mode to 800x600x24 (ResHacker maybe?) and change the value being passed to it so it sets 800x600x32
view/intercept DirectX calls being made while it's running
or if that's not possible, at least
run the program in an environment that emulates a 24-bit display
I don't need to recover the source code (as nice as it would be) so much as just want to get it running.
One technique you could try in your disassembler is to do a search for the constants you remember, but as the actual bytes that would be contained within the executable. I guess you used the DirectDraw SetDisplayMode call, which is a COM object so can't be as easily traced to/from an entry point in a DLL. It takes parameters for width, height and bits per pixel and they are DWORDs (32-bit) so do a search for "58 02 00 00", "20 03 00 00" and "18 00 00 00". Hopefully that will narrow it down to what you need to change.
By the way which disassembler are you using?
This approach may be complicated somewhat if your VB6 program compiled to p-code rather than native code as you'll just get a huge chunk of data that represents the program rather than useful assembler instructions.
Check this:
http://www.sevenforums.com/tutorials/258-color-bit-depth-display-settings.html
If your graphics card doesn't have an entry for 24-bit display....I guess hacking your code's the only possibility. That or finding an old machine to throw windows 95 on :P.
I have a bad habit of using the cursor keys of my keyboard to navigate source code. It's something I've done for 15 years and this of course means that my navigating speed is limited by the speed of the keyboard. On both Vista and OS X (I dual boot a MacBook), I have my key repeat rate turned all the way up. But in Visual Studio, and other apps, the rate is still much slower than I would prefer.
How can I make the key repeat rate faster in Visual Studio and other text editors?
In Windows you can set this with a system call (SystemParametersInfo(SPI_SETFILTERKEYS,...)).
I wrote a utility for myself: keyrate <delay> <repeat>.
Github repository.
Full source in case that link goes away:
#include <windows.h>
#include <stdlib.h>
#include <stdio.h>
BOOL parseDword(const char* in, DWORD* out)
{
char* end;
long result = strtol(in, &end, 10);
BOOL success = (errno == 0 && end != in);
if (success)
{
*out = result;
}
return success;
}
int main(int argc, char* argv[])
{
FILTERKEYS keys = { sizeof(FILTERKEYS) };
if (argc == 1)
{
puts ("No parameters given: disabling.");
}
else if (argc != 3)
{
puts ("Usage: keyrate <delay ms> <repeat ms>\nCall with no parameters to disable.");
return 0;
}
else if (parseDword(argv[1], &keys.iDelayMSec)
&& parseDword(argv[2], &keys.iRepeatMSec))
{
printf("Setting keyrate: delay: %d, rate: %d\n", (int) keys.iDelayMSec, (int) keys.iRepeatMSec);
keys.dwFlags = FKF_FILTERKEYSON|FKF_AVAILABLE;
}
if (!SystemParametersInfo (SPI_SETFILTERKEYS, 0, (LPVOID) &keys, 0))
{
fprintf (stderr, "System call failed.\nUnable to set keyrate.");
}
return 0;
}
On Mac OS X, open the Global Preferences plist
open ~/Library/Preferences/.GlobalPreferences.plist
Then change the KeyRepeat field. Smaller numbers will speed up your cursor rate. The settings dialog will only set it to a minimum of 2, so if you go to 0 or 1, you'll get a faster cursor.
I had to reboot for this to take effect.
Many times I want to center a function in my window. Scrolling is the only way.
Also, Ctrl-left/right can still be slow in code where there are a lot of non-word characters.
I use keyboardking also. It has a couple of isssues for me though. One, it sometimes uses the default speed instead of the actual value I set. The other is sometimes it ignores the initial delay. I still find it very useful though. They said 4 years ago they would release the source in 6 months... :(
Ok, on the suggestion of someone that modified HCU\...\Keyboard Response, this works well for me.
[HKEY_CURRENT_USER\Control Panel\Accessibility\Keyboard Response]
"AutoRepeatDelay"="250"
"AutoRepeatRate"="13"
"BounceTime"="0"
"DelayBeforeAcceptance"="0"
"Flags"="59"
Windows standard AutoRepeat delay.
13 ms (77 char/sec) repeat rate.
flags turns on FilterKeys?
These values are read at login. Remember to log out and back in for this to take effect.
For Windows, open regedit.exe and navigate to HKEY_CURRENT_USER\Control Panel\Keyboard. Change KeyboardSpeed to your liking.
I'm using KeyboardKing on my PC. It's freeware and it can increase the repeat rate up to 200 which is quite enough. I recommend to set the process priority to High for even smoother moves and less "repeat locks" which happen sometime and are very annoying. With high priority, it works perfectly.
No one understands why we navigate by arrows. It's funny.
Visual Assist has an option to double your effective key movements in Visual Studio which I use all the time.
As mentioned by the hyperlogic, on Mac OS X, internally, there are two parameters dealing with the keyboard speed: KeyRepeat and InitialKeyRepeat. In the System Preferences they are mapped to the Key Repeat Rate and the Delay Until Repeat sliders. The slider ranges and the associated internal parameter values (in parenthesis) are show below. They seem to be multipliers of the 15 ms keyboard sampling interval.
Key Repeat Rate (KeyRepeat) Delay Until Repeat (InitialKeyRepeat)
|--------------------------------| |----------------------|-----------------|
slow (120) fast (2) off (30000) long (120) short (25)
0.5 char/s 33 char/s
Fortunately, these parameters can be set beyond the predefined limits directly in the ~/Library/Preferences/.GlobalPreferences.plist file. I found the following values most convenient for myself:
KeyRepeat = 1 --> 1/(1*15 ms) = 66.7 char/s
InitialKeyRepeat = 15 --> 15*15 ms = 225 ms
Note that in the latest Mac OS X revisions the sliders are named slightly differently.
I do like to work on the keyboard alone. Why? Because when you use the mouse you have to grab it. A time loss.
On the other hand sometimes it seems that every application has its own keyboard type-rates built in. Not to speak from BIOS-properties or OS-settings. So I gathered shortkeys which can be pretty fast (i.e. you are faster typing Ctrl + right(arrow)-right-right than keeping your finger on the right(arrow) key :).
Here are some keyboard shortcuts I find most valuable (it works on Windows; I am not sure about OS X):
ctrl-right: Go to the end of the previous/the next word (stated before)
ctrl-left: Go to the beginning of the previous/the word before (stated before)
ctrl-up: Go to the beginning of this paragraph
(or to the next paragraph over this)
ctrl-down: Go to the end of this paragraph
(or to the next paragraph after this)
ctrl-pos1: Go to the beginning of the file
ctrl-end: Go to the end of the file
All these may be combined with the shift-key, so that the text is selected while doing so. Now let's go for more weird stuff:
alt-esc: Get the actual application into the background
ctrl-esc: This is like pressing the "start-button" in Windows: You can
navigate with arrow keys or shortcuts to start programs from here
ctrl-l: While using Firefox this accesses the URL-entry-field to simply
type URLs (does not work on Stack Overflow :)
ctrl-tab,
ctrl-pageup
ctrl-pagedwn Navigate through tabs (even in your development environment)
So these are the most used shortcuts I need while programming.
For OS X, the kernel extension KeyRemap4MacBook will allow you to fine tune all sorts of keyboard parameters, among which the key repeat rate (I set mine to 15 ms, and it works nice).
I don't know how to accelerate beyond the limit, but I know how to skip further in a single press. My knowledge is only in Windows, as I have no Mac to do this in. Ctrl + Arrow skips a word, and depending on the editor it may just skip to the next section of whitespace. You can also use Ctrl + Shift + Arrow to select a word in any direction.
Seems that you can't do this easily on Windows 7.
When you press and hold the button, the speed is controlled by Windows registry key : HCU->Control Panel->Keyboard->Keyboard Delay.
By setting this param to 0 you get maximum repeat rate. The drama is that you can't go below 0 if the repeat speed is still slow for you. 0-delay means that repeat delay is 250ms. But, 250ms delay is still SLOW as hell. See this : http://technet.microsoft.com/en-us/library/cc978658.aspx
You still can go to Accesibility, but you should know that those options are to help disabled people to use their keyboard, not give help for fast-typing geeks. They WON'T help. Use Linux, they tell you.
I bieleve the solution for Windows lies in hardware control. Look for special drivers for your keyboards or try to tweak existing ones.
Although the question is several years old, I still come across the same issue from time to time in several different developer sites. So I thought I may contribute an alternative solution, which I use for my everyday-developer-work (since the Windows registry settings never worked for me).
The following is my small Autorepeat-Script (~ 125 lines), which can be run via AutoHotkey_L (the downside is, it only runs under Windows, at least Vista, 7, 8.1):
; ====================================================================
; DeveloperTools - Autorepeat Key Script
;
; This script provides a mechanism to do key-autorepeat way faster
; than the Windows OS would allow. There are some registry settings
; in Windows to tweak the key-repeat-rate, but according to widely
; spread user feedback, the registry-solution does not work on all
; systems.
;
; See the "Hotkeys" section below. Currently (Version 1.0), there
; are only the arrow keys mapped for faster autorepeat (including
; the control and shift modifiers). Feel free to add your own
; hotkeys.
;
; You need AutoHotkey (http://www.autohotkey.com) to run this script.
; Tested compatibility: AutoHotkey_L, Version v1.1.08.01
;
; (AutoHotkey Copyright © 2004 - 2013 Chris Mallet and
; others - not me!)
;
; #author Timo Rumland <timo.rumland ${at} gmail.com>, 2014-01-05
; #version 1.0
; #updated 2014-01-05
; #license The MIT License (MIT)
; (http://opensource.org/licenses/mit-license.php)
; ====================================================================
; ================
; Script Settings
; ================
#NoEnv
#SingleInstance force
SendMode Input
SetWorkingDir %A_ScriptDir%
; Instantiate the DeveloperTools defined below the hotkey definitions
developerTools := new DeveloperTools()
; ========
; Hotkeys
; ========
; -------------------
; AutoRepeat Hotkeys
; -------------------
~$UP::
~$DOWN::
~$LEFT::
~$RIGHT::
DeveloperTools.startAutorepeatKeyTimer( "" )
return
~$+UP::
~$+DOWN::
~$+LEFT::
~$+RIGHT::
DeveloperTools.startAutorepeatKeyTimer( "+" )
return
~$^UP::
~$^DOWN::
~$^LEFT::
~$^RIGHT::
DeveloperTools.startAutorepeatKeyTimer( "^" )
return
; -------------------------------------------------------
; Jump label used by the hotkeys above. This is how
; AutoHotkey provides "threads" or thread-like behavior.
; -------------------------------------------------------
DeveloperTools_AutoRepeatKey:
SetTimer , , Off
DeveloperTools.startAutorepeatKey()
return
; ========
; Classes
; ========
class DeveloperTools
{
; Configurable by user
autoRepeatDelayMs := 180
autoRepeatRateMs := 40
; Used internally by the script
repeatKey := ""
repeatSendString := ""
keyModifierBaseLength := 2
; -------------------------------------------------------------------------------
; Starts the autorepeat of the current captured hotkey (A_ThisHotKey). The given
; 'keyModifierString' is used for parsing the real key (without hotkey modifiers
; like "~" or "$").
; -------------------------------------------------------------------------------
startAutorepeatKeyTimer( keyModifierString )
{
keyModifierLength := this.keyModifierBaseLength + StrLen( keyModifierString )
this.repeatKey := SubStr( A_ThisHotkey, keyModifierLength + 1 )
this.repeatSendString := keyModifierString . "{" . this.repeatKey . "}"
SetTimer DeveloperTools_AutoRepeatKey, % this.autoRepeatDelayMs
}
; ---------------------------------------------------------------------
; Starts the loop which repeats the key, resulting in a much faster
; autorepeat rate than Windows provides. Internally used by the script
; ---------------------------------------------------------------------
startAutorepeatKey()
{
while ( GetKeyState( this.repeatKey, "P" ) )
{
Send % this.repeatSendString
Sleep this.autoRepeatRateMs
}
}
}
Save the code above in a text file (UTF-8), for example named "AutorepeatScript.ahk"
Install AutoHotkey_L
Double click on "AutorepeatScript.ahk" to enjoy much fast arrow-keys (or put the file into your autostart-folder)
(You can adjust the repeat delay and rate in the script, see '; Configurable by user').
Hope this helps!
On Mac, it's option-arrow to skip a word and ⌥+Shift+Arrow to select. ⌘+Arrow skips to the end or beginning of a line or the end or beginning of a document. There are also the page up, page down, home and end keys ;) Holding shift selects with those too.
Well, it might be obvious, but:
For horizontal navigation, Home (line start), End (line end), Ctrl-Left (word left), Ctrl-Right (word right) work in all editors I know
For vertical navigation, Page Up, Page Down, Ctrl-Home (text start), Ctrl-End (text end) do too
Also (on a side note), I would like to force my Backspace and Delete keys to non-repeat, so that the only way to delete (or replace) text would be to first mark it, then delete it (or type the replacement text).
Don't navigate character-by-character.
In Vim (see ViEmu for Visual Studio):
bw -- prev/next word
() -- prev/next sentence (full stop-delimited text)
{} -- prev/next paragraph (blank-line delimited sections of text)
/? -- move the cursor to the prev/next occurence the text found (w/ set incsearch)
Moreover, each of the movements takes a number as prefix that lets you specify how many times to repeat the command, e.g.:
20j -- jump 20 lines down
3} -- three paragraphs down
4w -- move 4 words forward
40G -- move to (absolute) line number 40
There are most likely equivalent ways to navigate through text in your editor. If not, you should consider switching to a better one.