Wikipedia:Reference desk/Archives/Computing/2006 November 14

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

November 14

Incompatible software?

I do a lot of graphics design work using Adobe Illustrator and Photoshop Elements (not full Photoshop). Recently at my volunteer work, we obtained a new computer, and I installed the two programs. On the old computer -- and on my computer at home -- they work fine together. But on the new machine, whenever I try to transfer or copy a file from one program to the other, the Elements program shuts down, and then won't re-open unless I reboot the whole computer. I installed everything the same way this time as I did the previous time. Did I do something wrong? Any idea what is causing this? Can it be fixed? — Michael J 02:16, 14 November 2006 (UTC)

Does the new machine have less memory ? Perhaps it can't handle running both programs at once. Or perhaps the new computer has a lot more bloatware running all the time, like a virus scanner, ISP software, etc., so has very little memory left for applications. StuRat 05:06, 14 November 2006 (UTC)

No, the new computer has more memory — that's why we got it. I never even heard of the term "bloatware." I'll have to look into that. — Michael J 10:07, 14 November 2006 (UTC)

Waiting for Computers

I want a really (unneccessarily) nice, compact laptop that is extremely fast and has lots of space. Are there any hardware developments expected in the fairly near future (before september) that I might want to wait for if I'm looking for a great laptop? I know intel just came out with dual somethingoranother processors, and that's supposed to be a big thing. Is there expected to be any similarly important technological breakthrough in the next few months that I should wait for? Thanks a lot, Sashafklein 04:07, 14 November 2006 (UTC)

Nope, Core 2 Duo (that somethingorother you mentioned) is the big thing for this year in consumer computing. Purchase away! Although you might want to save yourself the trouble of installing vista and get one with vista on it.. should be out by january (but I still have my doubts...) --froth^{T C} 04:48, 14 November 2006 (UTC)

Or, get a Mac laptop. I think they might be cheaper. And they are much better. Abeg92 10:25, 14 November 2006 (UTC)

"Cheap" and "Mac" are antonyms. As for "better", the person was asking about hardware, not operating system. There are many laptops with better hardware offerings than Macs. --Kainaw ^(talk) 13:51, 14 November 2006 (UTC)

And of course every other laptop has better OS offerings than macs :) --froth^{T C} 18:26, 14 November 2006 (UTC)

IMHO the next big step in laptop performance will be completely solid state storage (no spinning hard drive). There have been several recent advances and drives are currently sold up to 32GB in size. When the cost comes down and capacity goes up in the next cycle (say 9-12 months) these will change the way we use laptops, since there will be a huge leap in speed, battery life, and durability. Just my .02 and no I don't work for Samsung --Jmeden2000 14:30, 14 November 2006 (UTC)

There is also the push for ubiquitous computing. Your laptop will have nearly no storage. All it will have is the ability to get on a wireless connection to the Internet. Your operating system and all your files will be on the Internet. Also, it won't matter what "laptop" you use as everything is based on your ID. So, if you login to the ubiquitous computing network from my laptop, you'll get your OS and your files, not mine. Personally, I don't like it much. But, I can see it coming. --Kainaw ^(talk) 14:36, 14 November 2006 (UTC)

We'll see that dominate business before it even creeps into the consumer market. Thin clients like you describe aren't much for multimedia and are basically incapable of gaming- however for business it's perfect. If your laptop gets stolen during a trip, no corporate secrets are lost because all the data is on the server, and the systems are highly replacable. But for right now there's no reason for consumers to pay someone to do their processing when they have very cheap, powerful systems at home. --froth^{T C} 18:29, 14 November 2006 (UTC)

Shared hosting and torrents

Last night, I heard someone on IRC mention a concept that intrigued me. He basically had paid to rent a server (shared hosting, I assume). He could upload a .torrent file to it, and the webserver would download all the files from that torrent at a highly appealing speed, then host the files for regular HTTP/FTP download, then continue seeding the torrent until you told it to stop. Is this really possible, or did I misunderstand? What is the technical term for such a service? What companies provide it and how much would it cost? It sounds really nice to me (I can only download between 10pm and 7am so having the webserver download all day and offer me the condensed downloads at night would be great). I'd really appreciate anything anyone can tell me about it, even Wikipedia links, because I'm completely unfamiliar with this sort of thing. Thanks. 202.10.86.63 04:12, 14 November 2006 (UTC)

Very interesting idea, and not very hard to set up at all. Wouldn't want to be that host, though- must be terrifying.. I'd have nightmares about the FBI knocking down my door :) But I suspect it's a specialty service and it's not widespread enough to merit its own name. Might count as some kind of fetch-transfer setup or something like that. By the way 9 hours should be enough to download even the largest torrents (well not technically the largest torrents but you know what I mean) in only a few nights, no use paying. If you're going to pay, might as well get some sweet service like rapidshare --froth^{T C} 04:52, 14 November 2006 (UTC)

Do people really get busted for that kind of thing in the United States?

Yeah :/ --froth^{T C} 18:39, 14 November 2006 (UTC)

You're basically just hosting a BitTorrent torrent and its associated file on a server. Splintercellguy 06:08, 14 November 2006 (UTC)

Er no.. what he described is giving the server the torrent, and letting the server download the files with the wide connection that servers typically have, and then allowing the person download the downloaded file over HTTP to their home computer at high, dedicated speeds. Nothing to do with uploading or hosting --froth^{T C} 18:32, 14 November 2006 (UTC)

But is there some application that the webserver is running to process the torrent files? What terms do I google for to see if a server will provide this? The main appeal of it for me is that it'd be seeding the torrents forever, at a high speed. I have 20kb/s upload with 15GB/month upload limit, so it's hard for me to maintain a good ratio. 202.10.86.63 09:21, 14 November 2006 (UTC)

Sure.. if it's a windows server it could even be running utorrent or azureus, although that would be kind of hard to control remotely from home. I'd bet that it's a *nix server running RTorrent. Downloaded files could be retrieved using a login script running on apache, and they could also be deleted or paused or stopped easily enough through some kind of control panel, though it might be tricky to inteface with rtorrent. --froth^{T C} 18:38, 14 November 2006 (UTC)

Probably not for most shared accounts available. I'm no expert on how torrent files work, but I doubt it would be easy to make a script in PHP or Perl (the two most common server-side languages on Linux). You'd probably need root access in order to run programs with their own processes, which usually means you either need a VPS or dedicated server, both of which are expensive compared to shared accounts.

It's a very good idea though. RevenDS 18:56, 14 November 2006 (UTC)

Uh I think the idea is that the server operator has some torrent software running (and why do you think it would have to run as root?) and he shares out access to his server. Not that some guy buys 10% of a server and then rents out pieces of that.. --froth^{T C} 07:27, 16 November 2006 (UTC)

Webcam software with one broadcaster, many viewers

Is there any webcam software that:

1. Allows multiple viewers to see one broadcaster.
2. Does not allow the viewers to see each other, know each others identities, or indeed, even know that other viewers exist.
3. Has relatively-high video quality, bandwidth permitting. Audio a plus also.
4. Is freely downloadable-- or at least, free for viewers.
5. Allows the broadcaster to approve or deny individual viewers ability to see the feed.

Yahoo messenger has most of the capabilities, but its video feed is rather low quality. Skype with Festoon has most capabilities, but multiple viewers can see each other. I also should note that it does NOT have to have the capability to broadcast to more than 2-3 viewers. -Alecmconroy 11:13, 14 November 2006 (UTC)

You could take a look at webcamXP: http://www.webcamxp.com. It will set up a web server on your computer and host the broadcast through that. It seems to have most of the features you're looking for. Mishatx 16:14, 14 November 2006 (UTC)

I think you can also use Windows Media Encoder to do this. You can choose the quality, and also you can limit who to broadcast to. It is also free, from Microsoft -- Somethingsquare 09:27, 20 November 2006 (UTC)

demo files

can u turn demo files into full files,is there soft ware avaiable to do this. and were would i fined it if there is soft ware to do this.

It depends on the software you are trying to steal. Some demos are full-version without a key. Some are just demos and completely lack the full version. Just Google for "warez", "hackz", or "serialz". You'll find thousands of pages full of nasty things you don't want. But, if you are lucky, you'll find something you need to steal the software you want - along with a long trail of spyware. --Kainaw ^(talk) 15:00, 14 November 2006 (UTC)

Nobody spells "serials" with a z (or cracks/hacks for that matter). If your program has some kind of an activation code entry, then chances are you can just paste one from off the internet. This was very popular for awhile, since it didn't require a secure download- only to give the customer a string of text upon purchase. Now the fad is to actually verify the code against an online database, which often makes it impossible to use the same code for more than a couple of installations. But since you're asking "is there soft ware available to turn demo files into full files" I assume you're not exactly an expert with computers .. and you're unlikely to be able to figure out how to defeat the more advanced protection. Just buy the software --froth^{T C} 18:45, 14 November 2006 (UTC)

Haha! I would not recommend the demo->full way. If you want it, just download the whole thing with a crack. X [Mac Davis] (DESK|How's my driving?) 17:27, 14 November 2006 (UTC)

Superimposition

I'm trying to superimpose a head onto another body - I'm wondering if it's possible to blend the two section by selecting an area of skin of one person to use as the pallete and then telling my program (PSP) to change the colour of the skin of the other person to the nearest colour in that pallete? --Username132 (talk) 15:23, 14 November 2006 (UTC)

You can do it that way, but it will likely bring imprecise results. I've always found it better to manually adjust one image to match the other. The human eye is far more discerning than any software. — Michael J 17:48, 14 November 2006 (UTC)

No, that won't work. The colours in the other head will try to stay the same within the new palette; they won't remap to the new person's colours. I would instead suggest you try to play with the colour balance of one of the images interactively and try to match it to the other skin colouring (and then if you need a paletted image, you could try a palette conversion there). What you really need is some sort of function that will map the palette of your original head to the palette of the new head: rather than find the nearest matching colour, it should find the colour that is in the equivalent position (i.e. if you could have the skin palettes sorted by their greyscale intensities, you could probably replace one with the other with good results). - Rainwarrior 18:11, 14 November 2006 (UTC)

Image data from abandonware game

I was trying to rip the image data from the PC version of one of my favourite old Amiga-era games, Captive. One image file is exactly 40,000 bytes long, which fits with the screen resolution of 320x200px at 5-bit colour depth. However, when I try and interpret the file as a sequence of 5-bit words (one for each pixel, listed row-by-row), I get this image. It's the correct image, but distorted with stripes. I tried a few other things, but then discovered that someone else has already ripped the data from the Amiga version, which looks like this. So problem solved, but I'm still wondering how I should have been interpreting the PC file in order to get that image. Any ideas? — Matt Crypto 17:08, 14 November 2006 (UTC)

The stripes in your image have a repetition after 8 pixels. I suspect this has a lot to do with the fact that continually adding 5 (5-bit) in mod 8 (the usual 8-bit data stream) reaches a cycle after 8 times (5*8 mod 8 = 40 mod 8 = 0). So, I suspect you are extracting the 5 bits incorrectly. Perhaps you are forgetting to shift them over before you store them? I don't know, I'd have to know more about what you're doing at that point in the process. - Rainwarrior 17:57, 14 November 2006 (UTC)

Ah, I found something interesting here. I was wondering if you were reading it as 5 bitplanes, or in 5 bit chunks, but I think if you were doing it the wrong way the image would look like a real mess instead of what you have. - Rainwarrior 18:05, 14 November 2006 (UTC)

LOL, yeah, I actually found that website too. I've been reading in the bytes one at a time, converting each byte to an 8-character string (e.g. "01001101"), and concatenating them all into one long string. Then I split that string up into 5-character pieces and convert them back into integers between 0 and 31. (Yup, pretty inefficient...) I agree that I might be extracting the 5 bits incorrectly, but I'm not sure what to try. One idea I had was that the bits should be taken from the least significant end of the byte first, rather than the most significant end -- getting that wrong would certainly cause a repeating, 8 column wide pattern of stripes in rows of constant colour. So I tried reversing each 8-character string (which I think would correct it) but that didn't fix the stripes, unfortunately. — Matt Crypto 19:00, 14 November 2006 (UTC)

If you had the bits backwards, that would probably introduce stripes like that, but you say you've tried that so perhaps it's something else... actually, if the AMIGA data was supposed to be read in 16 bit chunks, you could have the byte-pair reversed due to endian problems. That could possibly cause the striping... Try reading pairs and swapping them (don't reverse bits, just switch the bytes), or if that doesn't work try reading quads and reversing the byte order (if it was 32 bit). - Rainwarrior 19:23, 14 November 2006 (UTC)

No joy with those either, darn! — Matt Crypto 20:17, 14 November 2006 (UTC)

Wait, are you using the bitplanes separately? (I thought it was probably not the problem, but maybe it could be? I just realized that the screen resolutions are 8:5 as well!) Or are you treating the whole 40000 bytes as one long continuous chunk? You need to take the first bit from every plane, and there are five planes each of 8000 continuous bytes. - Rainwarrior 21:24, 14 November 2006 (UTC)

I took a look at the file. Yeah, it does seem that the bits are chunked rather than in separate planes. I'm not sure what's going on, really. Have you noticed there's an extra 960 bytes in there? (I was looking at size-on-disk by mistake.) - Rainwarrior 22:21, 14 November 2006 (UTC)

(First off, your example output is 320×201; you don't just have an off-by-one error, do you?) It's possible (as a variation of the bitplane idea) that each set of 5 bytes should be interpreted as specifying the colors for 8 different pixels, with the high bit of each byte specifying one pixel, the next highest another, and so on. That is, interpret the sequence of 8-bit bytes 34 12 B5 4D 01 not as the 5-bit sequence 06 10 09 0b 0a 13 08 01 (by taking the top five bits of 3416=001101002 to get 001102=0616, then its bottom three bits (=1002) and the top two of 1216=000100102 (=002) to get 100002=1016, etc.) but as the 5-bit sequence 04 02 14 1c 02 16 08 07, because 0416=001002 indicates that the high bit is only set in the middle number (B5), 0716=001112 indicates that the last three numbers are odd, etc. It's a sort of transposition of the bits.

[a while later, after several edit conflicts] Unfortunately, I've tried this and it doesn't seem to work: more, less intelligible, stripes result, reading the bits in either order. Maybe this will help more: the repeating pattern that generates the dark background for the logo is 84 04 02 24 24 or

1000 0100
0000 0100
0000 0010
0010 0100
0010 0100

It's only 5 bytes long, which makes sense: it's the first byte-multiple of 5 bits. If there were separate bit-planes, this would correspond to (wait for it) a stripe pattern, since it occurs on successive lines. But I can't see any pattern in that, other than there are 8 1s and there are supposed to be 8 (identical, dark gray) pixels generated by the sequence. Anyone have any interpretations? --Tardis 23:14, 14 November 2006 (UTC)

The 5-bit color is likely using a lookup table to assign one of 32 colors (one of which might be "transparent") to each pixel. You would need access to that table or would need to recreate it, then use it to convert the table into 24-bit color or some other color depth. StuRat 23:11, 14 November 2006 (UTC)

The colouration isn't actually the problem here. The palette does not appear in the file (though the amiga palette is indeed composed of 32 12-bit colours), and its recovery would have to be approached by other means. The problem is that the storage format of the image data itself (the colour indices, not the colours themselves) is unknown. - Rainwarrior 07:40, 15 November 2006 (UTC)

If you look at any particular block of 5 bytes from a section that should have, it seems that the right number of 1s and 0s are present to make a proper uniform coloured block. Maybe the bits in any particular 5 byte block are scrambled in a particular way as a form of encryption? I can't see any straightforward pattern of rearrangement. - Rainwarrior 08:08, 15 November 2006 (UTC)

If is the case that the 5-byte blocks are scrambled in some way, whether as obfuscation or for some technical reason, it should be possible to solve it (its a transposition cipher) using a known-plaintext attack. We know where there is a sequence of pixels of the same colour, which gives us at most 32 possible candidates for the plaintext. — Matt Crypto 11:58, 15 November 2006 (UTC)

Here's some more 5-byte blocks representing continuous colour:

0000000000000000000000000000000000000000
0100001000000010101000010000001000000010
1000010000000100000000100010010000100100
0001100011011000000011001101100011011000
0011000110110001010110001001000110010001
0101101011011010101011011101101011011010
0110001100100011111100010000001100000011
1010010100100101010100100010010100100101
1101011010010110101010111011010110110110
1110011100100111111100110010011100100111
1111011110110111111110111011011110110111

Notice that if you count the number of 1s or 0s in each block, then they are a multiple of 8. This is consistent with the hypothesis that each block represents eight identical 5-bit words, just with the bits rearranged in some order. — Matt Crypto 12:47, 15 November 2006 (UTC)

I tried to create a transposition of the bits in a 5-byte block that would remove the stripes from constant sections of colour. Using the above 5-byte blocks, I came up with this:

"0 1 2 3 4 5 6 7 8 9 13 14 10 11 12 22 16 15 20 21 26 18 17 24 25 29 23 19 27 28 34 30 31 32 33 37 38 39 35 36"

(Interpreted as: to form the 11th bit of the output block, use the 14th bit in the input block). This indeed eliminates the stripes from constant sections (see output), but still isn't the correct image (that is the shapes aren't correct, not just the palette). — Matt Crypto 14:44, 15 November 2006 (UTC)

Your basic idea is correct, however. I've shown the bit pattern below, seperated into sections:

             Original data                    Expected data for center block
0000000000 00000 000000000000000 00000 00000  000000000000000
0100001000 00001 010100001000000 10000 00010  010000100001000
1000010000 00010 000000010001001 00001 00100  100001000010000
0001100011 01100 000001100110110 00110 11000  000110001100011
0011000110 11000 101011000100100 01100 10001  001100011000110
0101101011 01101 010101101110110 10110 11010  010110101101011
0110001100 10001 111110001000000 11000 00011  011000110001100
1010010100 10010 101010010001001 01001 00101  101001010010100
1101011010 01011 010101011101101 01101 10110  110101101011010
1110011100 10011 111110011001001 11001 00111  111001110011100
1111011110 11011 111111011101101 11101 10111  111101111011110

Most are pretty straightforward (ror = ROtate Right):

First block: 0 1 2 3 4 5 6 7 8 9
Second block: 13 14 10 11 12 (ror 2)
Fourth block: 34 30 31 32 33 (ror 1)
Fifth block: 37 38 39 35 36 (ror 3)

The remaining block, however, is a bit trickier:

File contents   Expected contents
000000000000000 000000000000000
010100001000000 010000100001000
000000010001001 100001000010000
000001100110110 000110001100011
101011000100100 001100011000110
010101101110110 010110101101011
111110001000000 011000110001100
101010010001001 101001010010100
010101011101101 110101101011010
111110011001001 111001110011100
111111011101101 111101111011110

By turning this on the side, we get the following:

File contents  Expected contents
00001011011    00001011011
01000110111    01000110111
00001011011    00001011011
01000110111    00011100101
00001011011    00010100000
00011100101    00100001111
00010100000    01000110111
00100001111    00001011011
01000110111    00011100101
00011100101    00010100000
00010100000    00100001111
00100001111    01000110111
00011100101    00001011011
00010100000    00011100101
00100001111    00010100000

There are five unique bit patterns in this, with each one occuring three times - this is approriate, since we are dealing with 15 bits, all the same color.

I've created this small list to show where the bit patterns exist, and added a note where they should end up:

Pattern      Positions   Proper relative positioning
00001011011  15, 17, 19  3
00010100000  21, 25, 28  5
00011100101  20, 24, 27  4
00100001111  22, 26, 29  1
01000110111  16, 18, 23  2

This, however, poses us with a bit of a problem - we don't know which one goes where, so there will be multiple possibilities. By doing some quick calculations, you can see that for the first five bits, we have 3 options. For the next 5, there are 2, and the rest will only have one option. This means there will be 3^5*2^5 = 243*32 = 7776 different possibilities.

In order to crack this properly, we'll need at least two bit sequences where TWO colors are present - one on the left, one on the right - and where the middle area contains both of these colors. In the middle area, at least one of these bit sequences must have a single pixel of color 1 (and two pixels of color 2), and another one must have two pixels of color 1 (and a single pixel of color 2). The optimal palette indexes to use here would be 00000 and 11111, in which case two as mentioned above will be sufficient. With other palette indexes, we'll need several sequences.

Mind you, this all assumes the outer bits really are as simple as this - we cannot know that for certain just yet, and to be honest, I'm not sure this is really the case considering the peculiar way of forming the pattern in the middle block. I'll try to write a small program to help find these areas, but it might just be faster for you to find the necessary bit sequences yourself. --Pidgeot (t) (c) (e) 18:49, 15 November 2006 (UTC)

I've fiddled a bit with the sequence, and this one:

0, 1, 2, 3, 4, 13, 14, 10, 11, 12,
5, 6, 7, 8, 9, 22, 16, 15, 20, 21,
29, 23, 19, 27, 28, 26, 18, 17, 24, 25,
37, 38, 39, 35, 36, 34, 30, 31, 32, 33

gives me this picture. The small symbols on the left hand side appear to be correct now, and the "ratt" logo also appears as it should, so it should very nearly be there - sadly, I need to attend a webinar now, so I can't work on it for the next few hours. --Pidgeot (t) (c) (e) 21:03, 15 November 2006 (UTC)

That's getting pretty close there! Good work! (I guess in the sections where it looks fine the incorrectly swapped bits are identical.) I'm really wondering why this would be encrypted like this in the first place? Like... why bother? And if it's not encryption... what is it?? This doesn't really line up with anything I know about the graphics hardware of either the amiga or PC. - Rainwarrior 02:18, 16 November 2006 (UTC)

Nice work, folks. Further to this, I did a bit of hill climbing to get [1].

5,  6,  7,  3,  4,    13, 14, 15, 11, 12,
0,  1,  2,  8,  9,    22, 23, 10, 20, 21, 
29, 30, 31, 27, 28,   26, 16, 17, 24, 25,
37, 38, 39, 35, 36,   34, 18, 19, 32, 33

It's pretty close: I'm not sure which they are, but according to the "fitness function", 28 pixels are incorrect...(update: it appears those 28 pixels can be accounted for because the Captive palette uses both black and transparent as colours. On the game screen, "transparent" is used everywhere for black , but 28 pixels use actual "black" black instead.) — Matt Crypto 13:24, 16 November 2006 (UTC)

And I agree with Rainwarrior, this makes little sense to me. There's a lot of pattern in the sequences we've come up with...if someone was wanting to encrypt this, then they would come up with a much more random rearrangement, surely? — Matt Crypto 12:32, 16 November 2006 (UTC)

Er, I was more saying why encrypt it at all. What's so special about this data that it would need to be protected? I'd say it was a fairly effective encryption, if that's what it was; it certainly deterred us for a little while, though, yeah, they could have gone completely random? Maybe this pattern was achived by shifts and byte swapping or something so that it could be done in only a few steps (rather than looking at individual bits?), which might explain why so many are in-order. Hey, did you try your solution on other files from the game? - Rainwarrior 19:12, 16 November 2006 (UTC)

Sorry, yeah, I intended to add to what you'd said, rather than paraphrase it. And yes, I'm very happy to report that it seems to work correctly on the other game files too (previously ripped here, if you're curious). Maybe I'll track down the guy who did the PC port (Anthony Taglioni) and ask him about it (like he'll remember!). — Matt Crypto 20:54, 16 November 2006 (UTC)

Many thanks to the generous people who contributed brain-cycles to my obscure problem! — Matt Crypto 20:54, 16 November 2006 (UTC)

Solution of Travelling Salesman Problem using Hopfield nets

Has anyone solved the Travelling Salesman problem using Hopfield nets.If so then would you be kind enough to answer the following questions. 1.What is the probability of arriving at the shortest distance path for 5,8,10,12,15,18,20 cities? 2.Is it possible to attain 90% chance of finding the shortest path for 10 cities ? 3.How does the probability of finding the shortest path vary with the number of cities ? 4.Are there algorithms and heuristics to drastically increase the chance of finding the correct path ? 5.Is there any mathematical proof or theorem to suggest that the path lines which form the shortest path do not intersect inside the polygon formed but only at the vertices or outside the polygon.

It was difficult to find resources on these questions. If you would be kind enough to answer any one of them please e-mail me the answers at xxxxxxxxx

For your own protection I've removed your email address- believe me you don't want that sitting here (email harvesters). We also don't answer questions through email --froth^{T C} 18:48, 14 November 2006 (UTC)

The papers that scholar.google.com comes up for tsp "hopfield net" seem relevant. 84.239.129.42 19:20, 14 November 2006 (UTC)

Easy DVD ripper/encoder

Does anyone know of a simple and effective DVD to DivX/XVid encoder. Preferably freeware, or ideally open source? What I'm looking for ideally is something like CDEX for DVDs - pretty much a 'one-click' type solution. I know that programs like that stand on shady ground, what with having to bypass the DVD encryption, surely something like that must exist? There are lots of programs that claim to do it, but most look to be dodgy spyware traps sold through even dodgier websites. I also know there are various free/open solutions avaliable, but most seem to involve fiddling with ten million settings before you can even start.

So, basically, is there any easy, non-spyware-laden DVD to DivX software avaliable, or should I just start reading up on video encoding tutorials?

Thanks :)

AutoGK (AutoGordianKnot), the automated version of Gordian Knot, is a pretty simple one-click solution. Almost, anyway - you still need to rip the .VOB files from the DVD to the hard disk (with something like DVD Decrypter. Its website is at here, and a guide to using it is here. I'm not sure if it's open source, but it's spyware/adware/malware free, and works very well.

Disclaimer: make sure you only rip DVDs that you actually own (but then, you didn't need me to tell you that, did you? :)) — QuantumEleven 10:05, 15 November 2006 (UTC)

Run full-screen apps in a window

In Windows XP, is there a way to force programs which want to run in full screen inside a window? For example, I have a game that runs full screen at 1024x768, but normally I use a higher resolution. Is there a way to run that game in a 1024x768 window on my desktop? This would make it easier to switch between the game and other apps, for example. Seems like there should be a way, but I can't find the answer. — Jonathan Kovaciny (talk|contribs) 20:28, 14 November 2006 (UTC)

Most programs that automatically run in full screen mode use what is called the full screen overlay. There is generally no way to force the program to use a "windowed" mode if there are no options specifically relating to it. Some games however, such as World of Warcraft, support this as a command-line option.--Mabris 22:44, 14 November 2006 (UTC)

I've had several games that start up in full screen mode, but then switch to window mode if you hit escape, so try that. StuRat 22:52, 14 November 2006 (UTC)

If it's directx, try this app. Check windowed under Performance --froth^{T C} 02:23, 15 November 2006 (UTC)

Read the docs. Often, full-screen games have a command-line option to run in windowed mode. --Kainaw ^(talk) 15:53, 15 November 2006 (UTC)

Positioning a Choice box in Java

In Java, how do you position a Choice box at a particular point on the screen? I've tried setBounds() and setLocation() but neither seem to work. --Auximines 22:03, 14 November 2006 (UTC)

Positioning of controls is typically the job of the LayoutManager that's attached to the control's parent (container) widget. If you want to position a control absolutely (which is very rarely a good idea, as it means your application doesn't handle different font sizes and l10n/i18n labels at all well) you can set the LayoutManager on the parent container to null, and then call setBounds or setLocation on the control itself. -- Finlay McWalter | Talk 22:48, 14 November 2006 (UTC)

Thanks very much, that worked (at least, setBounds did, setLocation didn't). I'd completely forgotten about the LayoutManager, I suppose I'll have to bite the bullet and find out how it works. Thanks again. --Auximines 12:32, 15 November 2006 (UTC)

setLocation really did work, but no-one told the poor old control how big to be, so it decided to be 0x0. If memory serves a call to setLocation and setSize amounts to a call to setBounds. -- Finlay McWalter | Talk 18:08, 15 November 2006 (UTC)