Glenn9999

To review what I wrote above, which answers this question completely: All you can hope for is that the compiler will know the proper instruction sets so the possibility of using those instructions exists. Other than that, you don't know what the compiler will actually *do*. You can get assembler dumps with a number of them to find out what the compiler did, but you can influence what the compiler does incredibly little. To that end, your original option A is the only option if you want a guarantee of something to happen. The problem with that is as I detailed above too - you need to know that first, it's a CPU bottleneck involving precisely that code at hand, and then your attempt is helping matters and not hurting them. Truth be told, 99.99% of the instances involved make it not worth your time to mess with it, and that's what I was trying to relay up above.

The file system is corrupted, it looks like. I'd back up any data you can get off the partition safely (i.e. whatever's obviously corrupted) and then run chkdsk or the like and see what happens. It may fix it, or this data may be lost for good. Hard to tell until you try it.

Usually if it's up to the compiler, it's just going to select whatever it thinks is best. You really aren't going to know *exactly* what it does. If you get an option, you can compile for certain architectures. This is important because you need to be able to target for what is available to you. Note, most compilers will default to the most common instruction *sets* unless you tell them different. Like I indicated above, there's no real guarantees on any of the instruction sets you're going to get "most optimized" unless you provide a custom-written ASM function. But then again, as I indicated above as well, it's not a concern to 99% of applications, since it has to be a CPU bottleneck, and the *best* algorithm is always better to be found than to optimize a crappy one. After all, you can't polish a turd no matter how hard you try.

Pretty much any of how you listed in descending order of prominence/priority. Notably, if any optimizations are attempted of this nature, a profiler is run against the code and the bottleneck is identified. Since it has to be a CPU oriented bottleneck (and not disk or API), the number of opportunities for being able to do what you're talking about is limited, and any optimized code is just a limited section of that. Notably as well, adjusting the algorithm has much bigger impacts than looking for CPU instruction optimization - removing a crappy algorithm in favor of a better one will always net better results. The only other outstanding question is that compilers will support most of a subset of CPU instructions (but not all) available a reasonable time before the compiler is released. Since it's a subset, it means the optimization route is always a possible valid one. (I'm reminded of the last two I did, which were optimizable with simple x86 assembler instructions to gain a good speed increase)

Since I don't see a reference, GWX Control Panel may be of interest to the people here. As referenced in the article here: http://www.computerworld.com/article/2993851/windows-pcs/microsoft-antagonizes-users-with-intrusive-new-windows-10-upgrade-tactics.html

I recently had occasion to polish this program up (add some more variabiltiy rather than constants, and add file conversion capabillity). I can share, if someone feels like playing with it. Of course, if the demand's there for this kind of thing, that'll make it real good to release.

What are you looking for, more precisely? Something specific that reads text via computer synthesizer? Or programming for it?

I have a firmware upgrade for a RCA USB device which isn't working on Windows 8.1 x64. I've tried all the compatibility settings, administration, etc, and it just doesn't show up / run in general. Any advice/suggestions on how to get it to run?

You can always try this.

Here you go: Proof regarding the title, if you ever needed it. http://www.computerworld.com/article/2983633/microsoft-windows/microsoft-pushes-windows-10-upgrade-to-pcs-without-user-consent.html

You never know what you run across at times. I ended up picking up an original "The Oregon Trail" disk "for IBM/Tandy". Of course, I don't have a drive that it works in anymore, but interesting that I was able to find it. May look for it online I suppose if I get bored and see what the whole hype was.

Indeed, the literal purpose of the computer has become that. Heaven forbid that anyone expect a reliable tool to get things done that gets made more reliable with time and updates instead of worse. This has always been the case, even back to XP with the file locking bug that they never fixed, and I had to run a stupid TSR to counter. Not to mention, Explorer work is always a PITA and if I didn't have Classic Shell, 8.1 would be unusable. Do you think they would make it better? No, I have to run a stupid TSR now because KB2982791 broke one of my "working" programs because they introduced a bug in how it handles temp files. But none of that matters to Microsoft, just keep hemorraging cash for upgrades and personal data for the NSA (not to mention the obvious opportunity for corporate espionage given Microsoft by all this crap), and all is well to them.

Not to mention how unstable VLC (or Media Player Classic) is in many respects (I know, I've been testing how audio players handle playlists I've been writing from code and VLC is pretty terrible at that compared to other things). Even in my upgrade to Windows 8.1, I discovered after the fact that it broke my DVD player app which worked fine for me in XP. I haven't had a good option to play DVDs on my computer since.

Yeah, if it wasn't for Classic Shell, I'd be on someone's doorstep screaming about a refund over Windows 8.1. Knowing that it burns the bridge back, I'm especially reticient about engaging the Windows 10 upgrade...

It wouldn't be very hard to do, either...

WUAPI was phased in with Windows XP (and maybe 2000?), so VS2005 should handle it just fine.

Next to little. Just mentioning it as opposed to a one shot thing like the program posted in this thread. Next to little between this app and going into Control Panel, uninstalling the update, and then hiding it in Windows Update.

And I did, at least a clone of this one. Being generic would be very easy and probably more preferable since you're messing with bringing back full update lists anyway. I get a corruption of the image every once in a while when I test it. Basically put, you have to find the update in Windows Update, the problem is, it's rather slow sometimes. Good part is, you get an existence test and a chance to hide the update. The problem with it being slow is that it seems you have to use WU in order to hide the update. Of course, the Uninstall method in the API only works for WSUS, so couldn't do that. Anyhow, since it was a just for fun thing, and don't want to horn in on this, have some source: procedure TForm1.Button1Click(Sender: TObject);const theupdate = '3035583'; theupdateid = '1aa3ae66-f3e2-4f9d-a37f-7caa951ee2b0'; //GUID for 3035583var UpdateSession: IUpdateSession; UpdateSearcher: IUpdateSearcher; SearchResult: ISearchResult; Update: IUpdate; updstring: string; procid: DWord; token: LongBool;begin Button1.Enabled := false; UpdateSession := CoUpdateSession.Create; UpdateSearcher := UpdateSession.CreateUpdateSearcher(); UpdateSearcher.ServerSelection := 0; UpdateSearcher.ClientApplicationID := 'test wuapimap'; UpdateSearcher.Online := true; updstring := '(IsInstalled=1) and updateid=''' + theupdateid + ''''; Memo1.Lines.Add('Searching for Update ' + theupdate); SearchResult := UpdateSearcher.Search(WideString(updstring)); if SearchResult.ResultCode <> 2 then // not success begin Memo1.Lines.Add('Search error.'); Button1.Enabled := true; exit; end; if SearchResult.Updates.Count = 0 then // no updates returned begin Memo1.Lines.ADD('Update ' + theupdate + ' not found.'); Button1.Enabled := true; exit; end; Update := SearchResult.Updates.Item[0]; Update.IsHidden := true; Memo1.Lines.Add('Update ' + theupdate + ' hidden.'); Memo1.Lines.Add('Running uninstall - wusa.exe /uninstall /norestart /quiet /kb:' + theupdate); DisableWow64Redirection(token); Execute_program('wusa.exe', '/uninstall /norestart /quiet /kb:' + theupdate, procid, true); RevertWow64Redirection(token); UpdateSearcher._Release; UpdateSession._Release; if MessageDlg('The Machine Needs to be restarted. Do it now?', mtWarning, [mbYes, mbNo], 0) = mrYes then machine_restart; Button1.Enabled := true;end;

I'd have to look into it - it's been quite a while since I worked with WUAPI, but I distinctly remember it possible to do through code. I found out you could do just about everything on the system through the API, I'm sure hiding updates is a small task once you initialize the API. Edit: I did. Very easy. Edit2: Though harder you can do the uninstall through the API too. I may have to attempt this program and release it (generic as I was thinking - list updates available to system, uninstall what user chooses, allow hiding of updates, etc).

Something that presents a menu of installed updates and allows you to select the one you want to uninstall. In case you mean the updates in the menu ought to be limited to those listed in the thread about avoiding Win 10, I do fully agree. I meant something that lists all the updates installed on the system and then gives an option to uninstall the update in question. Of course, it can be expanded to all available updates and allow updates to be hidden, too.

Something that presents a menu of installed updates and allows you to select the one you want to uninstall.

Works great now. Only thing that might be good to add is an existence check (put up a message) if the update is already present. That wouldn't be too hard though. Like I said earlier, it might be worth trying to rig something up that's more generic if there's enough demand.

FWIW, it looks like the versioning will still happen with applications, but through that manifest and not entirely through code. Actually, it's returning 6.3 on mine, as opposed to 6.2 on GetVersionEx.

I meant in terms of what it returns. On my system, GetVersionEx returns 6.2 in a program with no manifest, which is false since it's a Windows 8.1 install. This also happens to describe rn10950's program(s) as a OS version check exists using this function, so they are effectively broken. But you basically explained why. In the future, versioning is basically meaningless, so you have to resort to other methods. In that sense, the application manifest is what determines the version returned, and what is put there determines what kind of app compatibility measures the OS undertakes. So the application manifest (as I quoted it) becomes paramount much more than the OS version. Hence, rn10950's primary corrective is to add that compatibility manifest as I quoted. Though it might be much more preferable from an OS standpoint for him/her to use IsWindowsVersionOrGreater than use GetVersionEx as was done. Of course, the problem with the application manifest is that I forsee having to do a release of my programs (BatchPatcher, namely, as it's the only thing I've done where OS ver return is important) every time Microsoft releases an OS.

Question for those running the Windows 10 preview: Can anyone find out whether GetVersionEx is similarly broken there? (I can cook up a quick test app if necessary)