|
rolleyes posted:DOSBox is perfectly capable of mounting local folders as a drive, and you can pass commandline arguments to it so that it will run a particular program on startup. I think you might have misunderstood what DOSBox is though - it's just a DOS emulator and nothing else. Yes I know that but neither of those is what I want. Not to mention that using XP mode can cause issues with certain programs because of how it handles the actual windows to be displayed - if you install say Simcity 2000 in XP Mode, when you launch it it only shows you the menu box window, and not the actual game window or the toolbar window. The only way to properly play it through XP Mode is to open XP Mode as a standard vm window with desktop, or to awkwardly launch Simcity through some other program in XP Mode. Many other older applications have problems like that too. (I bring up SimCity 2000 as an example even though it's 32 bit since on Windows 7 32 or 64 bit, it crashes when you try to load a file, so you have to use some kind of VM. On Vista both 32 bit and 64 bit it ran fine, and it incidentally runs fine in WINE on Linux) That's why I would like to be able to just install things on my actual drive and open them like normal by clicking them, the way WINE works. I already know that DOSBox doesn't do this, which is why I asked you if they had recently made something for it that would allow it to do that.
|
#
?
Dec 27, 2010 22:55
|
|
|
|
| # ? May 17, 2024 07:29 |
|
|
In that case no, you're boned. Price of progress I'm afraid.
|
|
#
?
Dec 27, 2010 22:56
|
|
|
rolleyes posted:In that case no, you're boned. Price of progress I'm afraid. Like I said, that's why I'm waiting for WINE on Windows to get going.
|
|
#
?
Dec 27, 2010 22:58
|
|
|
madprocess posted:WINE on Windows I've heard of this, and know the reasons, but it's still  every time I see it.What irks me is needing to boot a full operating system in order to run a single app. I'm sure they're working on slimming it down, but right now XP Mode is just so obviously a clunky tacked on way to accomplish things.
|
|
#
?
Dec 28, 2010 00:28
|
|
|
LooseChanj posted:What irks me is needing to boot a full operating system in order to run a single app. I'm sure they're working on slimming it down, but right now XP Mode is just so obviously a clunky tacked on way to accomplish things. Er, I really wouldn't put any money on that. It's not beyond the realms of possibility that Windows 8 could be x64 only seeing as even the newer Atom processors (used in netbooks) are x64 now so you'd have no native 16-bit support at all, and the trend is moving away from 16-bit support for obvious reasons. More to the point, why do you think a modern operating system ought to support applications written for a platform which was deprecated in 1995 and a processor which was deprecated in 1985? rolleyes fucked around with this message at 00:56 on Dec 28, 2010 |
|
#
?
Dec 28, 2010 00:46
|
|
|
XP Mode is all you're going to get. Either use it, or get rid of your old poo poo. Sometimes poo poo is just old and needs to be retired, gramps.
|
|
#
?
Dec 28, 2010 00:58
|
|
|
rolleyes posted:Er, I really wouldn't put any money on that. It's not beyond the realms of possibility that Windows 8 could be x64 only seeing as even the newer Atom processors (used in netbooks) are x64 now so you'd have no native 16-bit support at all, and the trend is moving away from 16-bit support for obvious reasons. ~ENTERPRISE COMPUTING~ But seriously it's the way it's always been. It would be nice if say in Windows 8 anything not written for Vista or higher runs in an NTVXPM (NT Virtual XP Machine) and anything that's 32 bit and for Vista or 7 runs in NTVW7M (NT Virtual Windows 7 Machine), both of which isolate programs in the way the NTVDM did, seamlessly.
|
|
#
?
Dec 28, 2010 00:59
|
|
|
GreenNight posted:Sometimes poo poo is just old and needs to be retired, gramps.  Then please explain to me why MAME exists. As well as Atari 2600, NES, etc emulators. DOSbox. Everything they exist to run is old, and in your apparent opinion should be scrapped.
|
|
#
?
Dec 28, 2010 01:14
|
|
|
LooseChanj posted:
Yes they exist because you can't run that poo poo on modern operating systems, which some people think should be done. No it shouldn't be done. Emulate it if you have to but don't bitch because you can't run Pong 2000 from '84 on 7 x64.
|
|
#
?
Dec 28, 2010 01:24
|
|
|
madprocess posted:~ENTERPRISE COMPUTING~ Ok, in two parts: Enterprise Computing: This is really a non-issue. If an enterprise is still running 16-bit server software then they deserve anything they get. In the rare case that it's some ridiculous mission critical proprietary system with no hope of an upgrade because the supplier went bust in the 90s then fine, that poo poo can be virtualized - that's common practise in that kind of situation, and the trend is towards virtualization of modern servers as well so it tends to fit the roadmaps nicely. If an enterprise is still relying on 16-bit client software then, well, much the same applies. Again, if you're stuck with the software for some reason then virtualize it, either in a virtual machine (this is exactly why XP Mode shipped with Win7 Pro and above) or install Windows 3.11 in DOSBox or something. NTVXPM: First of all, let's be clear: this will never, ever happen. Ever. And here's why: 16-bit software is a loving liability. It assumes it has kernel level access to absolutely anything it wants, because that's how it was back in the 16-bit days. Direct sector-level access to the harddisk, access to the processor registers, write access to any memory address in the map (including the ability to overwrite operating system memory), direct access to any connected device, no assumption of shared processor time (DOS apps assumed they had the entire processor to themselves, and Windows 3.11 was not pre-emptively scheduled) - all of these things were available to 16-bit software as the entire system was unprotected. 32-bit architecture introduced protected mode which allowed the operating system to lock many of these things down and introduced the idea of different execution permissions and a difference between kernel mode and user mode. 16-bit translation was a pain in the arse but just about possible as you were only doing with one layer of abstraction but, again, let's be clear - it was and still is risky. The security and integrity of the entire system depends on NTVDM correctly translating unsafe 16-bit operations to safe 32-bit operations, or killing the program outright if it does something which can't be handled safely. One wrong line of code by whichever poor bastards at Microsoft got lumbered with the task of understanding the complete 8086 architecture and the complete 16-bit Windows API system, and your system is rooted. Then we get to 64-bit architecture. 32-bit translation in a 64-bit operating system is just as much of a headache as 16-bit translation is in a 32-bit operating system. Once again, 32-bit applications are allowed to do things which the 64-bit architecture explicitly denies. To add 16-bit translation to this would be an absolute clusterfuck and the complexity would be ridiculous - you'd have a 16-bit API call being translated to a 32-bit API call being translated to a 64-bit API call which returns a response which is translated to a 32-bit API response which is translated to a 16-bit API response and finally given back to the software which made the API call. Additionally, the VDM would have to sanity check every 16-bit operation to ensure it was 32-bit permissible and adjust it to something which allowed if it isn't, and then do exactly the same against the resulting 32-bit operations for the host 64-bit architecture. Even ignoring the gross inefficiency and even if it could be made to work reliably, it would be a security nightmare; any one of the 3 levels of APIs could have a security flaw, and that's before you consider the VDM which is doing the really critical job but now has to do it twice for two different architectures. Again, one mishandled 16-bit ring-0 operation and suddenly an attacker has SYSTEM permissions and can do whatever the hell they like. In short, we're pretty drat lucky Microsoft are able to provide one layer of translation, and even luckier that it works so well that the vast majority of people never know the complexity of what goes on underneath - when you consider what's actually going on it's a small wonder it very rarely falls over. To expect emulation on top of emulation is an extremely big ask, and at this point Microsoft have absolutely no incentive to provide it. The decision comes down to adding a massive attack vector vs. requiring a small minority of customers to invest in some extra virtualization tech which in many cases can be done with no capital expense. Considering the beating Microsoft gets over security the decision is a no-brainer. Final thought: Personally, I really really hope Windows 8 does go the x64-only route. Why? Because that would finally enable the PC architecture to tidied up a bit. We're finallly moving to UEFI instead of BIOS, so it would be nice if the next generation of processors was also able to ditch real mode. That would then free us completely from the reliance on the old 640k memory map and RAID controllers needing to intercept interrupt calls which have been unchanged since the late 1970s in order to initialise storage in a machine built in 2010. Backwards compatibility is fine up to a point (one architecture level IMO, as you've probably guessed) but beyond that it starts to create significant problems - of which the modern PC architecture is a shining example. rolleyes fucked around with this message at 01:52 on Dec 28, 2010 |
|
#
?
Dec 28, 2010 01:43
|
|
|
rolleyes posted:Ok, in two parts: I think you're misunderstanding what I was saying. For enterprise stuff, that's actually the exact reason they kept 16 bit support around for so long and 32 bit Windows 7 still has it - dumb loving corporations with lovely 16 bit software. For the second part, currently in 64 bit Windows, 32 bit stuff pretty much runs the same as 64 bit stuff. I'm saying, it should be completely isolated out the way the NTVDM was (or was supposed to be, rather). Not really emulation on top of emulation, but keeping 32 bit stuff entirely out of the 64 bit stuff. Didn't say anything about putting 16 bit stuff in the 32 bit isolation areas.
|
|
#
?
Dec 28, 2010 01:52
|
|
|
GreenNight posted:Yes they exist because you can't run that poo poo on modern operating systems, which some people think should be done. No it shouldn't be done. Emulate it if you have to but don't bitch because you can't run Pong 2000 from '84 on 7 x64. Ummm...that stuff DOES run on Win7 x64. Emulation is one way to do things, and it's fine. But requiring me to boot an entirely separate OS, with all its baggage, is not. XP "mode" is a kludge, and it was pretty obviously tacked on at the last minute. It should be perfectly straightforward to do the same thing in a much more seamless manner.
|
|
#
?
Dec 28, 2010 01:53
|
|
|
madprocess posted:For the second part, currently in 64 bit Windows, 32 bit stuff pretty much runs the same as 64 bit stuff. I'm saying, it should be completely isolated out the way the NTVDM was (or was supposed to be, rather). Not really emulation on top of emulation, but keeping 32 bit stuff entirely out of the 64 bit stuff. Didn't say anything about putting 16 bit stuff in the 32 bit isolation areas. edit: I've put part of you quote in, because actually I'm not quite sure what you're saying there. So far as I'm aware that's exactly how 32-bit software does run in Vista/7 x64 - a 64-bit equivalent of NTVDM. It's just that they dropped 16-bit support. LooseChanj posted:Ummm...that stuff DOES run on Win7 x64. Emulation is one way to do things, and it's fine. But requiring me to boot an entirely separate OS, with all its baggage, is not. XP "mode" is a kludge, and it was pretty obviously tacked on at the last minute. It should be perfectly straightforward to do the same thing in a much more seamless manner. A SNES emulator is a virtual machine. MAME is a front-end for many emulators, all of which are virtual machines.  Every time you use one you are booting an entirely separate operating system - you just don't appreciate that fact because the operating system in those systems was held in firmware and never exposed to the user. NTVDM (despite its slightly misleading name) is not a virtual machine in that sense because the emulation is built into the processor, so it's more of a translation engine and safety watchdog. rolleyes fucked around with this message at 02:04 on Dec 28, 2010 |
|
#
?
Dec 28, 2010 01:59
|
|
|
I am having a problem deleting the files from an old windows installation. It is on a separate drive than my current windows installation. I am using an admin account, and I've tried every ownership property I've been able to google( taken ownership as admin and as user, cmd takeown command). But I cannot delete the files at all. It says "you require permission from MYPC\My user," I am logged into that user right now. Is it just impossible?
|
|
#
?
Dec 28, 2010 02:04
|
|
|
rolleyes posted:Yeah sorry, I started off replying to you and ended up replying to the "I want 16 bit apps to run natively in my 64 bit OS" crowd. Well the thing is there is a way to do that with WINE. WINE on 64 bit Linux will handle nearly all 16 bit Windows programs just fine. And since it's reimplementing APIs and poo poo instead of really directly executing exactly as stuff would on real 16 bit hardware, it negates a lot of security issues at the cost of some level of compatibility. I'd like for Microsoft to do the same kind of thing, or for the WINE on Windows project to move ahead.
|
|
#
?
Dec 28, 2010 02:04
|
|
|
madprocess posted:Well the thing is there is a way to do that with WINE. WINE on 64 bit Linux will handle nearly all 16 bit Windows programs just fine. And since it's reimplementing APIs and poo poo instead of really directly executing exactly as stuff would on real 16 bit hardware, it negates a lot of security issues at the cost of some level of compatibility. I'd like for Microsoft to do the same kind of thing, or for the WINE on Windows project to move ahead. Not knowing much about WINE I would ask: - Are we talking about 64-bit WINE on 64-bit Linux or 32-bit WINE on 64-bit Linux? - Does WINE support native 64-bit Windows applications using Vista/7 x64 APIs? If the answers are "64 on 64" and "yes" then kudos to the WINE developers, but remember that they don't have to worry about supporting needy enterprise customers when it doesn't quite work right, and they don't have malware writers actively trying to exploit any weaknesses because the install base is tiny.
|
|
#
?
Dec 28, 2010 02:10
|
|
|
rolleyes posted:Every time you use one you are booting an entirely separate operating system - you just don't appreciate that fact because the operating system in those systems was held in firmware and never exposed to the user. Oh, I do appreciate that fact. What you don't seem to recognize is the tremendous performance advantage those operating systems have due to the orders of magnitude greater power of computers today. XP, on an emulated PC, is much closer to needing the same level of hardware as Vista/7, giving it a severe performance handicap. Is it really too much to ask for a little optimization? Oh well, I can't be as young and hip and inexperienced as you so I guess I'll just settle for being right.
|
|
#
?
Dec 28, 2010 02:28
|
|
|
rolleyes posted:Not knowing much about WINE I would ask: It's 64 bit WINE on 64 bit Linux. No, as of yet WINE does not support 64 bit Windows code, but you wouldn't worry about that for WINE on Windows because Windows already has the 64 bit support, I'd just use it for 16 bit Windows apps and some finicky 32 bit stuff. I mean hell DOSBox and Virtual XP Mode both also have trouble running certain programs anyway.
|
|
#
?
Dec 28, 2010 02:40
|
|
|
LooseChanj posted:Oh, I do appreciate that fact. What you don't seem to recognize is the tremendous performance advantage those operating systems have due to the orders of magnitude greater power of computers today. XP, on an emulated PC, is much closer to needing the same level of hardware as Vista/7, giving it a severe performance handicap. Is it really too much to ask for a little optimization? Oh well, I can't be as young and hip and inexperienced as you so I guess I'll just settle for being right. I really don't get what you're expecting Microsoft to do for you. There are literally two options, both of which we've discussed: - Provide legacy WOW & NTVDM on the x64 platform, which is a security and complexity nightmare and if it was going to happen it would have by now. - Provide full virtualisation which they have done and done well in my opinion, the ability to display per-application XP windows side-by-side with native windows on the same desktop is pretty neat. Those are literally the only two technological options, there's nothing more that can be done about it.
|
|
#
?
Dec 28, 2010 02:41
|
|
|
LooseChanj posted:Ummm...that stuff DOES run on Win7 x64. Emulation is one way to do things, and it's fine. But requiring me to boot an entirely separate OS, with all its baggage, is not. XP "mode" is a kludge, and it was pretty obviously tacked on at the last minute. It should be perfectly straightforward to do the same thing in a much more seamless manner. Dude, XP Mode is a complete OS running on Virtual PC, more or less. It's not a new thing.
|
|
#
?
Dec 28, 2010 02:46
|
|
|
madprocess posted:It's 64 bit WINE on 64 bit Linux. No, as of yet WINE does not support 64 bit Windows code, but you wouldn't worry about that for WINE on Windows because Windows already has the 64 bit support, I'd just use it for 16 bit Windows apps and some finicky 32 bit stuff. That's a crucial difference though - to do what a proposed end-to-end 16->32->64-bit WOW/NTVDM system would have to do requires that the end result is a native Windows x64 API call. At the moment I guess what WINE is doing is win16->win32->Linux. I think you might be overlooking that Vista and 7 represent not only a move to x64 but a ground-up rebuild of the operating system architecture (both 32 and 64 bit) which involved some very fundamental changes, whereas (from what I've gathered, please shout up if I'm wrong here) Linux x64 is pretty much the same as Linux x86 - the DWM architecture and API hasn't changed, or is decoupled from WINE to such an extent that it doesn't matter. The Microsoft analogy would be the difference between Windows XP and Windows XP-64. It would have been much more practical to provide 16-bit compatibility on XP-64 because the fundamental OS architecture and API system were much closer to the normal 32-bit Windows XP. This would mean that if you could go from Win16->WinXP32 then the jump to WinXP64 was much smaller. However, Microsoft didn't provide it in XP-64 either - presumably because XP-64 was a stopgap for places like universities and research labs who needed 64-bit before Vista could get to market, so the investment wasn't worth it. rolleyes fucked around with this message at 02:55 on Dec 28, 2010 |
|
#
?
Dec 28, 2010 02:50
|
|
|
rolleyes posted:That's a crucial difference though - to do what a proposed end-to-end 16->32->64-bit WOW/NTVDM system would have to do requires that the end result is a native Windows x64 API call. See the thing is WINE runs on like 50 kinds of Linux and multiple kinds of desktop/window managers and often different APIs. And incidentally a lot of 32 bit Linux stuff won't run at all on most 64 bit distros unless you go and download packages that apply support for the 32 bit stuff. Again though, it's Linux so on some distros the stuff works fine, yadda yadda. 64 and 32 bit Linux are both pretty drat different from all flavors of Windows for that matter. Also I haven't checked recently but I believe WINE on 64 bit OS X also runs 16 bit Windows applications as well. And OS X is again completely different from Windows.
|
|
#
?
Dec 28, 2010 02:59
|
|
|
It may run on the bazillion different Linuxs (Linuxes? Linuxi?) but it has to be compiled for each one. Often someone has precompiled it and stuck it in a package, but it still has to happen. I think this is also the bit where the differences between Windows and Linux come into play. Windows is very tightly coupled because Microsoft have no intention of allowing 3rd parties to play with the underpinnings of the OS, whereas Linux is the exact opposite. Again, I'm not familiar enough to know all the underpinnings involved but I'm aware that there are multiple layers between whatever libraries WINE calls to render applications and it actually appearing on the desktop, not least because there is more than one DWM available. In Windows it's pretty much API call->DWM because there's no need for any further abstraction. So, point being, it may be easier to make WINE play with the different distros and architectures in the Linux ecosystem because someone has done all the work in one of the intermediary libraries. When it comes to rendering to the Vista/7 x64 desktop there's no-one else to do the work - you're back to needing to reverse-engineer everything. On the other hand maybe 32-bit WINE running via WOW64 on 64-bit Windows could run 16-bit applications, although you get the feeling that if it was that simple it would have happened by now. Also, to comment directly on this: madprocess posted:Also I haven't checked recently but I believe WINE on 64 bit OS X also runs 16 bit Windows applications as well. To put it another way, imagine if WINE ran on OS9 and there was a 32-bit and a 64-bit version of OS9, and WINE runs on both of them. The differences between the two OS9's are fairly small. Then along comes OSX, and what you're effectively expecting is that OS9 WINE would run on OSX, which it obviously wouldn't because the entire OS architecture has changed. It's not really the transition from x32 to x64 which is the big issue, it's the fact the entire operating system was redesigned at the same time. This is what happened in the move to NT6; there are still 32-bit and 64-bit versions but they share very little code with NT5 and all the APIs have changed. People just tend not to see it that way because, unlike Apple who only provided an OS9 virtual machine when OSX came out, Microsoft have provided a compatibility layer for 32-bit NT4/5 applications. rolleyes fucked around with this message at 03:38 on Dec 28, 2010 |
|
#
?
Dec 28, 2010 03:25
|
|
|
rolleyes posted:It may run on the bazillion different Linuxs (Linuxes? Linuxi?) but it has to be compiled for each one. Often someone has precompiled it and stuck it in a package, but it still has to happen. Yes but there's tons of applications on Windows that are pretty easy to find in both 32 bit native and 64 bit native versions? I don't know why you think it'd be impossible to have WINE run on Windows 64 bit.
|
|
#
?
Dec 28, 2010 04:03
|
|
|
Femur posted:I am having a problem deleting the files from an old windows installation. It is on a separate drive than my current windows installation. I am using an admin account, and I've tried every ownership property I've been able to google( taken ownership as admin and as user, cmd takeown command). But I cannot delete the files at all. It says "you require permission from MYPC\My user," I am logged into that user right now. Is it just impossible? After you takeown, you have to give youself permissions to the file (off the top of my head, calcs file /E /G MYPC\User:F should work)
|
|
#
?
Dec 28, 2010 04:22
|
|
|
Excursus posted:I got thrown this at work when we first started rolling Windows 7 out, and ended up just going the sysprep root but, as the comment suggests, not everything is copied over like before. So long as you copy the profile as part of the sysprep file, any programs you install under the default profile (and any desktop icons) will be available to everyone who logs on. Start Menu configuration will be reset though, as will some other random things. The e-mail I haven't tried, but you can use group policy to automate that if you need to. Thanks for the response. I think I am just going to go the Sysprep route since it is supported. Maybe one day this will be a more straightforward process. I'd be interested to know how your boss' situation ends up. vikingstrike fucked around with this message at 04:34 on Dec 28, 2010 |
|
#
?
Dec 28, 2010 04:23
|
|
|
Is there a way to make specific folders inside windows explorer to show up as pinned icons. I would like to have one for music and pictures, and be able to change the icon for them. That's another question..where can I change icons for the pinned programs.
|
|
#
?
Dec 29, 2010 10:26
|
|
|
PlasticSpoon posted:Is there a way to make specific folders inside windows explorer to show up as pinned icons. I would like to have one for music and pictures, and be able to change the icon for them. I haven't tried it myself, but Google throws up this which looks promising. In terms of the icon, I guess you mean you want to access the properties of the pinned shortcut right? In that case hold shift while you right-click on it on the taskbar - that will disable the jumplist and give you the normal explorer right-click menu.
|
|
#
?
Dec 29, 2010 12:09
|
|
|
Yep, exactly what I meant. Thanks
|
|
#
?
Dec 29, 2010 12:25
|
|
|
vikingstrike posted:Thanks for the response. I think I am just going to go the Sysprep route since it is supported. Maybe one day this will be a more straightforward process. I'd be interested to know how your boss' situation ends up. Just to follow up. Finished earlier this afternoon and everything was pretty straight forward. The email accounts did make it through Sysprep. Outlook has some quirks you have to work around that, but otherwise, not too many issues.
|
|
#
?
Dec 29, 2010 20:52
|
|
|
vikingstrike posted:Just to follow up. Finished earlier this afternoon and everything was pretty straight forward. The email accounts did make it through Sysprep. Outlook has some quirks you have to work around that, but otherwise, not too many issues. Great, handy to know about Outlook. I never understood why they changed it from XP, but whatever. The TSE server is humming along nicely with a few users too, so *shrug*.
|
|
#
?
Dec 29, 2010 21:12
|
|
|
Well, a new year, and time for me to march forward a step or two into the future. I've turned off the Win 95 GUI and have been futzing around with Aero. I'm not fond of the curvy Mac/Linux rip off GUI with its pointless eye candy that tries to trick you into thinking it's worth the extra money MS wants you to pay for it, but offloading the GUI onto the GPU is logical, and there are some neat little gimmicks like the preview windows. Still, one thing annoys me and that's the border padding. I don't mean the border padding for application windows that you can easily adjust under window color advanced settings, I mean this:  Click here for the full 1024x768 image. I use a 3rd party app to give me the classic start menu and I guess that uses the same preview window type, as it too has a huge, bloated, screen real estate grabbing border that serves no purpose. I've tried googling it, but only get info on how to change the border padding setting I already know about. I assume there's some setting in the registry I can change? Landerig fucked around with this message at 14:45 on Jan 1, 2011 |
|
#
?
Jan 1, 2011 14:41
|
|
|
I'm not sure you can do anything about it on the taskbar / start menu. You mention you're using the classic start menu - does that mean you're not using the search box which is the default selection on the new start menu? Also, I can't remember how at the moment (typing this on my phone) but you can disable visual styles while leaving compositing enabled, although you might quickly find yourself wanting to change it back as certain parts of the UI don't quite look right. rolleyes fucked around with this message at 17:41 on Jan 1, 2011 |
|
#
?
Jan 1, 2011 17:39
|
|
|
Nah, there's gotta be a way I can tweak it. (I wonder if there's something like a TweakUI for Win 7?) Ideally I would like to make the tiny preview window just a little bigger and shrink the border around it to 1 pixel wide. I dunno what the search box has to do with what I want to do, but no, I rarely do any searches on my own computer because I have most everything laid out where I know where it is and can get to it with a few mouse clicks. (Edit: I did find something called Ultimate Windows Tweaker Didn't have what I wanted, but has a lot of other neat stuff.) Landerig fucked around with this message at 20:46 on Jan 1, 2011 |
|
#
?
Jan 1, 2011 20:36
|
|
|
Landerig posted:Nah, there's gotta be a way I can tweak it. (I wonder if there's something like a TweakUI for Win 7?) Google was pretty quick to the rescue - http://windows7themes.net/windows-7-taskbar-preview-size.html
|
|
#
?
Jan 1, 2011 20:54
|
|
|
Search wasn't directly related to your question, I just figured you probably weren't using it. Out of interest, did you give it a day or two to try it out? Imo it's the biggest single UI improvement over XP. For example, starting firefox takes 4 keypresses: [win], "fi", [enter]. Alternatively pin programs you use frequently to the taskbar and then it's [win]+<number corresponding to position on taskbar>. I don't really understand why people choose to disable something like that, but there you go.
|
|
#
?
Jan 1, 2011 21:09
|
|
|
LoKout posted:Google was pretty quick to the rescue - http://windows7themes.net/windows-7-taskbar-preview-size.html Ahh so they're called thumbnails, and taskbar preview size. Well I guess that makes sense. Here I kept searching for variants of "border padding". rollleyes posted:Search wasn't directly related to your question, I just figured you probably weren't using it. Out of interest, did you give it a day or two to try it out? Imo it's the biggest single UI improvement over XP. For example, starting firefox takes 4 keypresses: [win], "fi", [enter]. Alternatively pin programs you use frequently to the taskbar and then it's [win]+<number corresponding to position on taskbar>. No, didn't try the search, no intention of using it either. Again, I know where most everything I want to access is on my computer, or can find it quickly after clicking on the folder it's in. I can launch Firefox from two clicks on my desktop, or one click on my taskbar just like I did in XP. Just going by me, why people would disable something like that is because they either don't want to bother learning it because the way they do things works well enough for them, and has worked for 10-15 years, or they don't trust it and don't want to rely on it in case it's buggy, has security holes, or to go tinfoil hat on you, secretly logs and/or sends data to MS.
|
|
#
?
Jan 2, 2011 01:29
|
|
|
Landerig posted:No, didn't try the search, no intention of using it either. Again, I know where most everything I want to access is on my computer, or can find it quickly after clicking on the folder it's in. I can launch Firefox from two clicks on my desktop, or one click on my taskbar just like I did in XP. I felt that way too, and then I tried it. Turns out it's awesome, especially for programs/files you don't use often.
|
|
#
?
Jan 2, 2011 01:33
|
|
|
Landerig posted:Just going by me, why people would disable something like that is because they either don't want to bother learning it because the way they do things works well enough for them, and has worked for 10-15 years, or they don't trust it and don't want to rely on it in case it's buggy, has security holes, or to go tinfoil hat on you, secretly logs and/or sends data to MS.  <win><c><o><r><enter>Seriously, try it. Aside from animated gif previews, there is literally nothing I like about winXP now.
|
|
#
?
Jan 2, 2011 03:44
|
|
|
|
| # ? May 17, 2024 07:29 |
|
|
Quick question. Upgrading PC. Should I install 32 or 64 bit? My computer is capable of both.
|
|
#
?
Jan 2, 2011 06:55
|
|